ift issueshttps://gitlab.mpcdf.mpg.de/groups/ift/-/issues2017-05-28T06:56:12Zhttps://gitlab.mpcdf.mpg.de/ift/nifty/-/issues/123SmoothingOperator: Correct units for sigma if `log_distances=True`?2017-05-28T06:56:12ZTheo SteiningerSmoothingOperator: Correct units for sigma if `log_distances=True`?Should the sigma be in log-units, too, if `log_distances` is set to True? If yes, how?Should the sigma be in log-units, too, if `log_distances` is set to True? If yes, how?Martin ReineckeMartin Reineckehttps://gitlab.mpcdf.mpg.de/ift/nifty/-/issues/72libsharp_wrapper is broken2017-05-27T14:04:09ZMartin Reineckelibsharp_wrapper is brokenWhile running comparison tests with my new wrapper code, I noticed that the gauleg() routine in libsharp_wapper, which is used from GLSpace.weight(), is broken.
The symptoms are:
- because of incorrect loop bounds, the computation will n...While running comparison tests with my new wrapper code, I noticed that the gauleg() routine in libsharp_wapper, which is used from GLSpace.weight(), is broken.
The symptoms are:
- because of incorrect loop bounds, the computation will not compute the central point when nlat is an odd number. (This is not too problematic, since NIFTy currently forbids such a setting.)
- because of the incorrect usage of abs() instead of fabs(), the iteration for determining the roots of the Legendre polynomial terminates after the first iteration and therefore gives extremely inaccurate results.
I'm not sure whether the original project is still maintained, so I'm posting the warning here. Don't use this code!https://gitlab.mpcdf.mpg.de/ift/nifty/-/issues/84Tweaking the copyright notices2017-05-24T10:40:49ZMartin ReineckeTweaking the copyright noticesThis is not urgent, but needs to be addressed before the first real public release...
The current copyright notices are insufficient/inaccurate in a few respects:
- copyright year: this should not be just "2017" but the range of year...This is not urgent, but needs to be addressed before the first real public release...
The current copyright notices are insufficient/inaccurate in a few respects:
- copyright year: this should not be just "2017" but the range of years since this file was created
- copyright holder: as far as I know, copyright is held by "Max-Planck-Society"
- author: this should be a list of all people who have significantly contributed to the file. So Marco should be added in many of the files.
I know this makes things complicated, since not all files will have the same copyright header. But I really think that the principle "better safe than sorry" applies here.
A small silver lining: I'm pretty sure that the `__init__.py` files don't need copyright notices at all; their content is trivial (in legal German: they don't have sufficient "Schöpfungshöhe" :)
Unfortunately I cannot provide a merge request since I do not know the history of the individual files.Theo SteiningerTheo Steiningerhttps://gitlab.mpcdf.mpg.de/ift/nifty/-/issues/129Bug in plotting of GLSpace2017-05-24T10:27:22ZTheo SteiningerBug in plotting of GLSpace```
from nifty import *
x = GLSpace(15)
f = Field.from_random(domain=x, random_type="normal")
my_plotter = plotting.GLPlotter(title='test')
my_plotter(f)
```
yields
![newplot](/uploads/0df31a3f1e97de7d9e20dba05d797f19/newplot.png)
Plo...```
from nifty import *
x = GLSpace(15)
f = Field.from_random(domain=x, random_type="normal")
my_plotter = plotting.GLPlotter(title='test')
my_plotter(f)
```
yields
![newplot](/uploads/0df31a3f1e97de7d9e20dba05d797f19/newplot.png)
Plotting of HPSpace works fine.Martin ReineckeMartin Reineckehttps://gitlab.mpcdf.mpg.de/ift/pyHealpix/-/issues/1README: Add flags to configure2017-05-24T10:11:22ZTheo SteiningerREADME: Add flags to configureOne could add the flags `--enable-openmp --enable-native-optimizations` to the install instructions.One could add the flags `--enable-openmp --enable-native-optimizations` to the install instructions.Martin ReineckeMartin Reineckehttps://gitlab.mpcdf.mpg.de/ift/nifty/-/issues/135Drawing random fields, problem on monopol and highest frequency2017-05-23T23:39:28ZPumpe, Daniel (dpumpe)Drawing random fields, problem on monopol and highest frequencyJakob and I encountered a problem with .power_synthesize.
```
from nifty import *
import numpy as np
x1 = RGSpace(200, zerocenter=False, distances=.1)
k1 = RGRGTransformation.get_codomain(x1)
# setting spaces
npix = np.array(...Jakob and I encountered a problem with .power_synthesize.
```
from nifty import *
import numpy as np
x1 = RGSpace(200, zerocenter=False, distances=.1)
k1 = RGRGTransformation.get_codomain(x1)
# setting spaces
npix = np.array([200]) # number of pixels
total_volume = 1. # total length
# setting signal parameters
lambda_s = .2 # signal correlation length
sigma_s = 1.5 # signal variance
# calculating parameters
k_0 = 4./(2*np.pi*lambda_s)
a_s = sigma_s**2.*lambda_s*total_volume
# creation of spaces
x1 = RGSpace(npix, distances=total_volume/npix,
zerocenter=False)
k1 = RGRGTransformation.get_codomain(x1)
p1 = PowerSpace(harmonic_partner=k1, logarithmic=False)
# # creating Power Operator with given spectrum
spec = (lambda k: a_s/(1+(k/k_0)**2)**2)
p_field = Field(p1, val=spec, dtype=np.float64)
# creating FFT-Operator and Response-Operator with Gaussian convolution
FFTOp = FFTOperator(domain=x1, target=k1,
domain_dtype=np.float64,
target_dtype=np.complex128)
# drawing a random field
sp = Field(p1, val=lambda z: spec(z) ** (1. / 2))
no_spec= 10000
sps = Field(p1, val=0.)
for ii in xrange(no_spec):
sk = sp.power_synthesize(real_signal=True, mean=0.)
sps += Field(p1, val=sk.power_analyze()**2, dtype=np.float64)
mean_power = sps/10000.
```
First and last mode of mean_power are wrong by a factor of 2.https://gitlab.mpcdf.mpg.de/ift/nifty/-/issues/130What is the correct data type for field norms?2017-05-23T01:19:12ZMartin ReineckeWhat is the correct data type for field norms?While running the nonlinear Wiener filter demo, I observed warnings about casting complex values to float. This can be traced back to the norm() method of the Field class returning complex numbers if the field is complex. At least for th...While running the nonlinear Wiener filter demo, I observed warnings about casting complex values to float. This can be traced back to the norm() method of the Field class returning complex numbers if the field is complex. At least for the 2-norm this should probably be replaced by a float value, but I'm not absolutely sure about other possible norms.https://gitlab.mpcdf.mpg.de/ift/nifty/-/issues/128Powerspectrum consistency2017-05-22T20:09:16ZReimar H LeikePowerspectrum consistencyAt the current state of nifty, it not properly documented and not intuitiv when to give a method a power spectrum and when to pass its root. Different conventions are used for power_synthesize and Power Opertor.At the current state of nifty, it not properly documented and not intuitiv when to give a method a power spectrum and when to pass its root. Different conventions are used for power_synthesize and Power Opertor.Theo SteiningerTheo Steiningerhttps://gitlab.mpcdf.mpg.de/ift/nifty/-/issues/86Docstring: Space classes2017-05-19T01:25:16ZTheo SteiningerDocstring: Space classesReimar H LeikeReimar H Leikehttps://gitlab.mpcdf.mpg.de/ift/nifty/-/issues/89Docstring: Minimizers2017-05-19T01:25:07ZTheo SteiningerDocstring: Minimizershttps://gitlab.mpcdf.mpg.de/ift/nifty/-/issues/90Docstring: Energy class2017-05-19T01:24:57ZTheo SteiningerDocstring: Energy classJakob KnollmuellerJakob Knollmuellerhttps://gitlab.mpcdf.mpg.de/ift/nifty/-/issues/87Docstring: Field class2017-05-19T01:24:49ZTheo SteiningerDocstring: Field classhttps://gitlab.mpcdf.mpg.de/ift/nifty/-/issues/103Add adjoint_times to FFT/SHT operators.2017-05-18T11:48:49ZTheo SteiningerAdd adjoint_times to FFT/SHT operators.Related to #78Related to #78Martin ReineckeMartin Reineckehttps://gitlab.mpcdf.mpg.de/ift/nifty/-/issues/92Update README2017-05-18T11:48:20ZTheo SteiningerUpdate READMEEspecially install instructions. Docker, etc...Especially install instructions. Docker, etc...Martin ReineckeMartin Reineckehttps://gitlab.mpcdf.mpg.de/ift/nifty/-/issues/80HDF5 tests are not run by the pipelines2017-05-16T21:48:52ZMartin ReineckeHDF5 tests are not run by the pipelinesThis is a minor thing; I'm just mentioning it so we don't forget...
Although HDF5 is installed in one of the CI configurations, the relevant tests (test_serialization.py) are not executed. On my own machine, where the standard h5py pack...This is a minor thing; I'm just mentioning it so we don't forget...
Although HDF5 is installed in one of the CI configurations, the relevant tests (test_serialization.py) are not executed. On my own machine, where the standard h5py package is available, they are run when I do "nosetests -vv". So I expect there is some problem with the automatic setup (e.g. in install_h5py.sh).https://gitlab.mpcdf.mpg.de/ift/nifty/-/issues/102Clarify and explain (pseudo?-)unitarity of FFT/SHT operators.2017-05-16T21:40:25ZTheo SteiningerClarify and explain (pseudo?-)unitarity of FFT/SHT operators.https://gitlab.mpcdf.mpg.de/ift/nifty/-/issues/125pyfftw tests are not being run2017-05-16T21:20:26ZMartin Reineckepyfftw tests are not being runI just noticed that continuous integration does not run pyfftw tests, even when the package should be available. This accounts for the 2400 tests that are currently skipped in the pipelines.
I'm not sure why this happens. The relevant te...I just noticed that continuous integration does not run pyfftw tests, even when the package should be available. This accounts for the 2400 tests that are currently skipped in the pipelines.
I'm not sure why this happens. The relevant tests in `test_fft_operator.py` are guarded by
```
if module == "fftw" and "pyfftw" not in di:
raise SkipTest
```
which looks correct to me.https://gitlab.mpcdf.mpg.de/ift/nifty/-/issues/41apply_scalar_function2017-05-15T22:01:45ZGhost Userapply_scalar_function*apply_scalar_function* is removed from field, this breaks *nifty_power_conversion_rg*: in the function *power_backward_conversion_rg* and in the function *power_backward_conversion_rg**apply_scalar_function* is removed from field, this breaks *nifty_power_conversion_rg*: in the function *power_backward_conversion_rg* and in the function *power_backward_conversion_rg*https://gitlab.mpcdf.mpg.de/ift/D2O/-/issues/1tests: only make h5py test if h5py is avaiable.2017-05-15T21:27:26ZTheo Steiningertests: only make h5py test if h5py is avaiable.Theo SteiningerTheo Steiningerhttps://gitlab.mpcdf.mpg.de/ift/nifty/-/issues/78SHTs are not unitary transforms2017-05-15T18:23:29ZMartin ReineckeSHTs are not unitary transformsCurrently, SHTs are part of Nifty's FFT operator class, which states (via a property) that its transforms are unitary.
However this is not true for SHTs: their matrix representation is not generally square. As a consequence, the SHT ope...Currently, SHTs are part of Nifty's FFT operator class, which states (via a property) that its transforms are unitary.
However this is not true for SHTs: their matrix representation is not generally square. As a consequence, the SHT operator is not invertible.
So, on the FFT side we have:
- forward transform
- backward transform (which is the inverse, and simultaneously the adjoint of forward)
whereas for SHTs we have:
- alm2map (this can be implemented accurately)
- adjoint alm2map (also accurate)
The inverse alm2map operation ("map2alm") is currently "faked" by a weighted adjoint alm2map, but this only works in specific situations (if the map is band-limited), and in the case of Healpix only approximately.
I'm not sure if this has any significant consequences for the usage of SHTs in Nifty, but we should probably think about separating them from FFTs, to avoid confusion and potentially incorrect application of the SHT operators.
We should make it clear that SHTs can only be used in situations where only the transform from position space to harmonic space and its adjoint are required, but not its inverse.