ift issueshttps://gitlab.mpcdf.mpg.de/groups/ift/-/issues2017-04-05T14:09:00Zhttps://gitlab.mpcdf.mpg.de/ift/nifty/-/issues/68How to run unit tests on the command line?2017-04-05T14:09:00ZMartin ReineckeHow to run unit tests on the command line?Before creating a merge request, I'd like to run the test suite to make sure there are no regressions.
Unfortunately "python setup.py test" doesn't do anything helpful, and I'm not familiar enough with Python projects to run the tests c...Before creating a merge request, I'd like to run the test suite to make sure there are no regressions.
Unfortunately "python setup.py test" doesn't do anything helpful, and I'm not familiar enough with Python projects to run the tests completely by hand.
Could the testing procedure please be documented in README.md?https://gitlab.mpcdf.mpg.de/ift/nifty/-/issues/69Documentation bug in RGSpace?2017-04-05T18:48:07ZMartin ReineckeDocumentation bug in RGSpace?The docstring for RGSpace says that "only even numbers of grid points per axis are supported":
https://gitlab.mpcdf.mpg.de/ift/NIFTy/blob/master/nifty/spaces/rg_space/rg_space.py#L76
However there are no checks in the sources that e...The docstring for RGSpace says that "only even numbers of grid points per axis are supported":
https://gitlab.mpcdf.mpg.de/ift/NIFTy/blob/master/nifty/spaces/rg_space/rg_space.py#L76
However there are no checks in the sources that enforce this constraint.
In fact, some tests explicitly specify odd grid dimensions.
So I think that this line should be removed.https://gitlab.mpcdf.mpg.de/ift/nifty/-/issues/70create_power_operator2017-04-10T12:40:19ZPumpe, Daniel (dpumpe)create_power_operatorHi Theo, while checking volume factors in my code I stumbled over a potential bug in sugar.py create_power_operator. In line 27 the DiagonalOperator should be bare=True (default is False). Else wise the application of such a "PowerOperat...Hi Theo, while checking volume factors in my code I stumbled over a potential bug in sugar.py create_power_operator. In line 27 the DiagonalOperator should be bare=True (default is False). Else wise the application of such a "PowerOperator" does not match the results as if the code would be run in Nifty 1. Or am I missing something, please correct me if I see something wrong.
# Power Spectrum differences
# NIFTY_1
x1 = rg_space(200, zerocenter=False, dist=0.1)
k1 = x1.get_codomain()
spec1 = (lambda k: 42/(1+k**2))
S1 = power_operator(k1, spec=spec1)
test1 = field(x1, val=3)
result1 = S1.inverse_times(test1)
# NIFTy_3
x3 = RGSpace(200, zerocenter=False, distances=0.1)
k3 = RGRGTransformation.get_codomain(x3)
spec3 = (lambda k:42/(1+k**2))
S3 = create_power_operator(k3, spec3)
FFT3 = FFTOperator(domain=x3, target=k3,
domain_dtype=np.float64,
target_dtype=np.complex64)
test3 = Field(x3, val=3)
result3 = FFT3.inverse_times(S3.inverse_times(FFT3.times(test3)))https://gitlab.mpcdf.mpg.de/ift/nifty/-/issues/71FFT transformations, RGSpace(zerocenter)2017-04-10T23:29:10ZPumpe, Daniel (dpumpe)FFT transformations, RGSpace(zerocenter)Hi, during a few small tests Martin and me came across a serious problem concerning harmonic transformations. If one uses a RGSpace with npix%2 !=0 and zerocenter=True the FFT gives wrong results (see example res4.val).
As the handling...Hi, during a few small tests Martin and me came across a serious problem concerning harmonic transformations. If one uses a RGSpace with npix%2 !=0 and zerocenter=True the FFT gives wrong results (see example res4.val).
As the handling of the zerocenter-keyword seems to give rise to various problems and in particular complexity in the code, we have to ask the question "what is it necessary for". If we come to the conclusion that we can drop it in fewer of simplicity, which necessary functionality would we loose?
`x1 = RGSpace(200, zerocenter=False, distances=0.1)
k1 = RGRGTransformation.get_codomain(x1, zerocenter=False)
FFT1 = FFTOperator(domain=x1, target=k1,
domain_dtype=np.float64,
target_dtype=np.complex64)
test_field_1 = Field(x1, val=1.)
res1 = FFT1.inverse_times(FFT1.times(test_field_1))
x2 = RGSpace(200, zerocenter=True, distances=0.1)
k2 = RGRGTransformation.get_codomain(x2, zerocenter=True)
FFT2 = FFTOperator(domain=x2, target=k2,
domain_dtype=np.float64,
target_dtype=np.complex64)
test_field_2 = Field(x2, val=1.)
res2 = FFT2.inverse_times(FFT2.times(test_field_2))
x3 = RGSpace(199, zerocenter=False, distances=0.1)
k3 = RGRGTransformation.get_codomain(x3, zerocenter=False)
FFT3 = FFTOperator(domain=x3, target=k3,
domain_dtype=np.float64,
target_dtype=np.complex64)
test_field_3 = Field(x3, val=1.)
res3 = FFT3.inverse_times(FFT3.times(test_field_3))
x4 = RGSpace(199, zerocenter=True, distances=0.1)
k4 = RGRGTransformation.get_codomain(x4, zerocenter=True)
FFT4 = FFTOperator(domain=x4, target=k4,
domain_dtype=np.float64,
target_dtype=np.complex64)
test_field_4 = Field(x4, val=1.)
res4 = FFT4.inverse_times(FFT4.times(test_field_4))```https://gitlab.mpcdf.mpg.de/ift/nifty/-/issues/82create_power_operator2017-04-29T01:16:10ZPumpe, Daniel (dpumpe)create_power_operatorHi,
while testing my code I came across a potential problem concerning volume factors in the outcome of the application of an operator created by 'create_power_operator'
minimal example to show differences between Nifty_1 and Nifty_3 ...Hi,
while testing my code I came across a potential problem concerning volume factors in the outcome of the application of an operator created by 'create_power_operator'
minimal example to show differences between Nifty_1 and Nifty_3
[tt.py](/uploads/ffe6ef7ca3fb4aae2b9a2ab3e01001c7/tt.py)
Since 'res_1!= res_2', either Nifty_1 or Nifty_3 calculates something wrong.
In my mind Nifty_1 does the calculation properly. An easy fix in Nifty_3 create_power_operator could be setting the bare keyword in line 43 of the DiagonalOperator to true.
Cheers,
Danielhttps://gitlab.mpcdf.mpg.de/ift/nifty/-/issues/74RGSpace: get_distance_array() returns incorrect results for odd lengths2017-04-29T01:19:53ZMartin ReineckeRGSpace: get_distance_array() returns incorrect results for odd lengthsWith current master, try the following code in ipython:
```
from nifty import *
s_space = RGSpace([3])
s_space.get_distance_array('not')
```
The result I get is
```
<distributed_data_object>
array([ 0.33333333, 0.33333333, 0. ...With current master, try the following code in ipython:
```
from nifty import *
s_space = RGSpace([3])
s_space.get_distance_array('not')
```
The result I get is
```
<distributed_data_object>
array([ 0.33333333, 0.33333333, 0. ])
```
However, I would rather expect something like
`array([0., 0.33333333, 0.33333333 ])`https://gitlab.mpcdf.mpg.de/ift/nifty/-/issues/79Rename operator property "symmetric"2017-05-01T00:35:19ZMartin ReineckeRename operator property "symmetric"Strictly speaking, the property of EndomorphicOperator (and children) called "symmetric" does not reflect the symmetry of the operator matrix, but rather whether it is self-adjoint/hermitian. (Otherwise, DiagonalOperator could always jus...Strictly speaking, the property of EndomorphicOperator (and children) called "symmetric" does not reflect the symmetry of the operator matrix, but rather whether it is self-adjoint/hermitian. (Otherwise, DiagonalOperator could always just return "True" for this property.)
I'd suggest to rename this property to "self_adjoint" or "hermitian". If there is agreement, I'll provide a merge request.https://gitlab.mpcdf.mpg.de/ift/nifty/-/issues/76dtype of spaces2017-05-01T00:37:25ZTheo Steiningerdtype of spacesInvestigate fully if spaces need a dtype from the conceptual point of view. If not -> remove it from spaces/field_types.Investigate fully if spaces need a dtype from the conceptual point of view. If not -> remove it from spaces/field_types.https://gitlab.mpcdf.mpg.de/ift/nifty/-/issues/67Arbitrary constraints on GL geometry2017-05-01T01:34:10ZMartin ReineckeArbitrary constraints on GL geometryIn gl_space.py on current master, there are constraints on the grid layout which in my opinion make no sense.
- in _parse_nlat, the number of rings is not allowed to be odd. Why ist this the case? I would argue that any positive number o...In gl_space.py on current master, there are constraints on the grid layout which in my opinion make no sense.
- in _parse_nlat, the number of rings is not allowed to be odd. Why ist this the case? I would argue that any positive number of rings is allowed and useful.
- in _parse_nlon, a warning is given if nlon!=2*nlat-1. Depending on the actual values of lmax and mmax for the codomain, this choice is not necessarily the best one.
For GL grids, the connections between nlat, nlon, mmax and lmax should be the following:
- nlat = lmax+1 (this is always a good choice, and a warning could safely be given if the user specifies something different)
- nlon >= 2*mmax+1 (this is the minimum number of pixels per ring that can represent spherical harmonics up to and including mmax. However, it may be preferrable to choose a slightly higher nlon for performance reasons: if possible, nlon should be a product of prime factors <=5).
I am aware that the constructor for GLSpace currently does not have the desired lmax and mmax values at hand, and so cannot warn if the relations above do not hold. However, the current tests should be changed, since they are arbitrary and their restrictions do not improve the code in any way.https://gitlab.mpcdf.mpg.de/ift/nifty/-/issues/66Bug in gl_space.py?2017-05-01T01:34:57ZMartin ReineckeBug in gl_space.py?In gl_space.py I stumbled over the statement
at https://gitlab.mpcdf.mpg.de/ift/NIFTy/blob/master/nifty/spaces/gl_space/gl_space.py#L164
` lat = qr_tuple[0]*(np.pi/(self.nlat-1)) `
It seems that the code assumes that the ri...In gl_space.py I stumbled over the statement
at https://gitlab.mpcdf.mpg.de/ift/NIFTy/blob/master/nifty/spaces/gl_space/gl_space.py#L164
` lat = qr_tuple[0]*(np.pi/(self.nlat-1)) `
It seems that the code assumes that the ring latitudes of the GL grid are equidistant ... which is definitely not the case.
However I'm wondering if the "get_distance_array" functionality is needed at all for spaces that do not live in the harmonic domain. If I understand correctly, this is only used for binning when producing a power spectrum.
If this assumption is correct, I suggest to remove the "distance_array" related methods from GL and HP spaces. (This involves removing a few tests as well.)
Maybe it would be good to make it explicit in the class hierarchy that this method is only supported by spaces which live in the harmonic domain.https://gitlab.mpcdf.mpg.de/ift/nifty/-/issues/77Fix hashing/identifier of domain_objects.2017-05-02T08:51:39ZTheo SteiningerFix hashing/identifier of domain_objects.https://gitlab.mpcdf.mpg.de/ift/nifty/-/issues/104NIFTy_3 on prelude2017-05-09T07:57:09ZPumpe, Daniel (dpumpe)NIFTy_3 on preludeDear all,
during the NIFTy week of coding we should discuss, what the best way of using NIFTy_3 in its latest version on prelude is. As all required packages for NIFTy_3 evolve so rapidly, I guess it would be a good idea to have someon...Dear all,
during the NIFTy week of coding we should discuss, what the best way of using NIFTy_3 in its latest version on prelude is. As all required packages for NIFTy_3 evolve so rapidly, I guess it would be a good idea to have someone responsible for this (keeping all packages up to date, installed etc.) This NIFTy installation should be accessible for everyone.
I think this could save us all a lot of time while running our codes on prelude.2017-05-08https://gitlab.mpcdf.mpg.de/ift/nifty/-/issues/106Clarify dot product on multiple spaces2017-05-09T21:38:21ZJakob KnollmuellerClarify dot product on multiple spaceshttps://gitlab.mpcdf.mpg.de/ift/nifty/-/issues/35Remove MPI from nifty configuration2017-05-09T21:39:14ZTheo SteiningerRemove MPI from nifty configurationThe spaces check for a valid comm, still. Until this is removed, gdi and gc must provide information about them.
-> remove MPI related stuff from nifty_config:
- dependency_injector
- nifty_configuration.register(...)The spaces check for a valid comm, still. Until this is removed, gdi and gc must provide information about them.
-> remove MPI related stuff from nifty_config:
- dependency_injector
- nifty_configuration.register(...)Theo SteiningerTheo Steiningerhttps://gitlab.mpcdf.mpg.de/ift/nifty/-/issues/88Docstring: Operators2017-05-15T07:07:19ZTheo SteiningerDocstring: OperatorsPumpe, Daniel (dpumpe)Pumpe, Daniel (dpumpe)https://gitlab.mpcdf.mpg.de/ift/nifty/-/issues/101Clarify the roles of 'implemented' and 'bare'.2017-05-15T18:22:56ZTheo SteiningerClarify the roles of 'implemented' and 'bare'.https://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.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/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/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.