ift issueshttps://gitlab.mpcdf.mpg.de/groups/ift/-/issues2018-01-18T15:57:53Zhttps://gitlab.mpcdf.mpg.de/ift/nifty/-/issues/9Add "S_inv" keyword to propagator_operator2018-01-18T15:57:53ZTorsten EnsslinAdd "S_inv" keyword to propagator_operatorIf S_inv is set to an inverse operator, it should be use instead of S.inverse_multiply/times in
D^-1 = S_inv + M
Usecase: Sometimes only a non-invertable smoothness enforcing operator S_inv \propto k^2 or k^4 should be used, or an ...If S_inv is set to an inverse operator, it should be use instead of S.inverse_multiply/times in
D^-1 = S_inv + M
Usecase: Sometimes only a non-invertable smoothness enforcing operator S_inv \propto k^2 or k^4 should be used, or an explicitly coded pixel space operator. 2018-01-19https://gitlab.mpcdf.mpg.de/ift/nifty/-/issues/32Matplotlib backend hardcoded in __init__.py2018-01-18T15:57:29ZButler, David (dbutler)Matplotlib backend hardcoded in __init__.pyThe backend selection for matplotlib is hardcoded in '__init__.py". The chosen backend 'Agg' only functions when printing to a file, it does not allow launching plot windows directly from the terminal.
Selecting a different backend via ...The backend selection for matplotlib is hardcoded in '__init__.py". The chosen backend 'Agg' only functions when printing to a file, it does not allow launching plot windows directly from the terminal.
Selecting a different backend via 'use' must be done before importing NIFTy and may instead break file outputs.https://gitlab.mpcdf.mpg.de/ift/nifty/-/issues/97Tests: Operators2018-01-18T15:55:29ZTheo SteiningerTests: Operatorshttps://gitlab.mpcdf.mpg.de/ift/nifty/-/issues/38Enable nifty_fft classes to operate on global NIFTy MPI communicator2018-01-12T09:21:39ZTheo SteiningerEnable nifty_fft classes to operate on global NIFTy MPI communicatorRelated to Issue #37 Related to Issue #37 Theo SteiningerTheo Steiningerhttps://gitlab.mpcdf.mpg.de/ift/nifty/-/issues/178Replace the current implementation of MPI FFTs2018-01-11T14:25:44ZMartin ReineckeReplace the current implementation of MPI FFTsThe current way of performing MPI-parallel FFTs has several problems:
- it relies on a fork of `pyfftw` that may or may not be merged with the official version in the future, causing potential confusion for users
- it does not work for ...The current way of performing MPI-parallel FFTs has several problems:
- it relies on a fork of `pyfftw` that may or may not be merged with the official version in the future, causing potential confusion for users
- it does not work for all array sizes due to FFTW limitations.
The second point already makes broad regression testing of many different FFT sizes quite tricky.
My suggestion to overcome both these drawbacks is based on the fact that MPI communication during an FFT is _only_ needed if the first field dimension needs to be transformed, and that a multi-D FFT can be separated in to FFTs along individual axes.
If an FFT along the first axis is required, NIFTy (or D2O) could just do the following:
- MPI-tanspose the field in such a way that the first dimension is no longer distributed across CPUs
- perform the FFT along this dimension (no MPI required)
- revert the transpose again
- (perform FFTs along the other requested axes)
Internally this is exactly how FFTW handles this problem as well.
The transposition algorithm is not trivial, but certainly implementable without too many difficulties.
Doing this would also get rid of the special "fftw" distribution strategy.
Additional bonus: MPI FFTs would then also work with numpy FFT. The dependence on MPI-enabled FFTW would vanish, making NIFTy configuration simpler.https://gitlab.mpcdf.mpg.de/ift/nifty/-/issues/188Field.real/imag copy arrays, contrary to documentation2018-01-11T14:25:17ZMartin ReineckeField.real/imag copy arrays, contrary to documentation```
import nifty as ift
a=ift.RGSpace(10)
f=ift.Field(a,val=1.+1j)
f.real.val+=2
f.imag.val+=2
print f.val
```
This prints '1+1j' as the field value, i.e. the manipulations of real and imaginary parts did not affect the original field....```
import nifty as ift
a=ift.RGSpace(10)
f=ift.Field(a,val=1.+1j)
f.real.val+=2
f.imag.val+=2
print f.val
```
This prints '1+1j' as the field value, i.e. the manipulations of real and imaginary parts did not affect the original field. This seems to contradict the documentation, which states that the data is not copied.https://gitlab.mpcdf.mpg.de/ift/nifty/-/issues/195Announce merge dates from nightly branch to master2018-01-11T14:24:22ZMartin ReineckeAnnounce merge dates from nightly branch to masterThe tentative plan is to merge new (potentially disruptive) changes from nightly to master after they have been on the nightly branch for about two weeks.
It might still be helpful to announce a precise date when the next merge of this ...The tentative plan is to merge new (potentially disruptive) changes from nightly to master after they have been on the nightly branch for about two weeks.
It might still be helpful to announce a precise date when the next merge of this kind is planned. @Theos, what's your schedule?https://gitlab.mpcdf.mpg.de/ift/nifty/-/issues/193Field method; Field.integrate2018-01-11T13:31:00ZPumpe, Daniel (dpumpe)Field method; Field.integrateMartin, Sebastian and I think that it would be advantageous to have a Field method, `.integrate(spaces)` in case one has to integrate over one or multiple dimensions of a field. `.integrate` would thereby take care of all necessary volum...Martin, Sebastian and I think that it would be advantageous to have a Field method, `.integrate(spaces)` in case one has to integrate over one or multiple dimensions of a field. `.integrate` would thereby take care of all necessary volume factors as they appear in integrals.
What do you think about it (@reimar, @kjako @theos)?https://gitlab.mpcdf.mpg.de/ift/nifty/-/issues/196What does Field.vdot() do if the spaces keyword is present?2018-01-11T13:30:42ZMartin ReineckeWhat does Field.vdot() do if the spaces keyword is present?What is the expected result if we call
`a.vdot(b,spaces=0)`
where a is a Field living on one space and b is a Field living on two spaces?
I'm asking because the documentation says that the result should be float or complex, but the co...What is the expected result if we call
`a.vdot(b,spaces=0)`
where a is a Field living on one space and b is a Field living on two spaces?
I'm asking because the documentation says that the result should be float or complex, but the code actually returns a Field object.
Is there an undocumented constraint that both Fields must have the same number of domains?https://gitlab.mpcdf.mpg.de/ift/nifty/-/issues/206vdot on subspaces2018-01-11T13:30:06ZPumpe, Daniel (dpumpe)vdot on subspacesHi Martin,
I just recognised that ift.Field.vdot does only work on 'whole' fields and does not yet support .vdot on subspaces.
```
In [1]: import nifty2go as ift
In [2]: x1 = ift.RGSpace(200)
In [3]: x2 = ift.RGSpace(150)
In [4]: ...Hi Martin,
I just recognised that ift.Field.vdot does only work on 'whole' fields and does not yet support .vdot on subspaces.
```
In [1]: import nifty2go as ift
In [2]: x1 = ift.RGSpace(200)
In [3]: x2 = ift.RGSpace(150)
In [4]: m = ift.Field((x1,x2), val=.5)
In [5]: m.vdot(m, spaces=1)
---------------------------------------------------------------------------
NotImplementedError Traceback (most recent call last)
<ipython-input-5-5c9f18522742> in <module>()
----> 1 m.vdot(m, spaces=1)
/Users/danielpumpe/CloudStation/dpumpe/construction/NIFTy_2go/lib/python2.7/site-packages/nifty2go-3.9.0-py2.7.egg/nifty2go/field.pyc in vdot(self, x, spaces)
339 return fct*dobj.vdot(y.val, x.val)
340
--> 341 raise NotImplementedError("special case for vdot not yet implemented")
342 active_axes = []
343 for i in spaces:
NotImplementedError: special case for vdot not yet implemented
```
What it be possible to provide this functionality?Martin ReineckeMartin Reinecke2018-01-11https://gitlab.mpcdf.mpg.de/ift/nifty/-/issues/205NIFTy2go: DirectSmoothingOperator missing2017-12-28T17:54:04ZPumpe, Daniel (dpumpe)NIFTy2go: DirectSmoothingOperator missingHi,
to make 'educated' initial guesses for D4PO it can be helpful to have a DirectSmoothingOperator. Unfortunately this Operator is missing in NIFTy2go. Is there any reason behind this?Hi,
to make 'educated' initial guesses for D4PO it can be helpful to have a DirectSmoothingOperator. Unfortunately this Operator is missing in NIFTy2go. Is there any reason behind this?Martin ReineckeMartin Reineckehttps://gitlab.mpcdf.mpg.de/ift/nifty/-/issues/204NIFTy2go, FFTOperator2017-12-12T16:00:11ZPumpe, Daniel (dpumpe)NIFTy2go, FFTOperatorHi Martin,
unfortunately the FFTOperator on ProductSpaces does not work or am I missing something?
```
In [13]: x1 = ift.RGSpace(200)
In [14]: x2 = ift.RGSpace(200)
In [15]: k1 = x1.get_default_codomain()
In [16]: k2 = x2.get_defau...Hi Martin,
unfortunately the FFTOperator on ProductSpaces does not work or am I missing something?
```
In [13]: x1 = ift.RGSpace(200)
In [14]: x2 = ift.RGSpace(200)
In [15]: k1 = x1.get_default_codomain()
In [16]: k2 = x2.get_default_codomain()
In [17]: FFT = ift.FFTOperator(domain=(x1,x2), target=(k1, k2), space=1)
---------------------------------------------------------------------------
TypeError Traceback (most recent call last)
<ipython-input-17-da937f755b58> in <module>()
----> 1 FFT = ift.FFTOperator(domain=(x1,x2), target=(k1, k2), space=1)
/Users/danielpumpe/CloudStation/dpumpe/construction/NIFTy_2go/lib/python2.7/site-packages/nifty2go-3.9.0-py2.7.egg/nifty2go/operators/fft_operator.pyc in __init__(self, domain, target, space)
93 self._target = [dom for dom in self.domain]
94 self._target[self._space] = target
---> 95 self._target = DomainTuple.make(self._target)
96 adom.check_codomain(target)
97 target.check_codomain(adom)
/Users/danielpumpe/CloudStation/dpumpe/construction/NIFTy_2go/lib/python2.7/site-packages/nifty2go-3.9.0-py2.7.egg/nifty2go/domain_tuple.pyc in make(domain)
49 if isinstance(domain, DomainTuple):
50 return domain
---> 51 domain = DomainTuple._parse_domain(domain)
52 obj = DomainTuple._tupleCache.get(domain)
53 if obj is not None:
/Users/danielpumpe/CloudStation/dpumpe/construction/NIFTy_2go/lib/python2.7/site-packages/nifty2go-3.9.0-py2.7.egg/nifty2go/domain_tuple.pyc in _parse_domain(domain)
69 if not isinstance(d, DomainObject):
70 raise TypeError(
---> 71 "Given object contains something that is not an "
72 "instance of DomainObject class.")
73 return domain
TypeError: Given object contains something that is not an instance of DomainObject class.
```Martin ReineckeMartin Reineckehttps://gitlab.mpcdf.mpg.de/ift/nifty/-/issues/191Field.power_synthesize(): some clarifications needed2017-12-09T14:10:49ZMartin ReineckeField.power_synthesize(): some clarifications neededI'm trying to understand the intricacies of `Field.power_synthesize()` and am encountering a few points that are unclear to me:
- which combinations of `real_signal` and `real_power` are allowed? Specifically, is it allowed/sensible to ...I'm trying to understand the intricacies of `Field.power_synthesize()` and am encountering a few points that are unclear to me:
- which combinations of `real_signal` and `real_power` are allowed? Specifically, is it allowed/sensible to have `real_signal==True` and `real_power==False`?
- if `self.dtype==float`, does it make sense to have `real_power==False`? In that case, `local_rescaler.imag` will become zero.
Once I understand all of this better, I'd volunteer to extend the docstring, and (if necessary) add a few sanity checks to the code.https://gitlab.mpcdf.mpg.de/ift/nifty/-/issues/189PowerSpace volume factors2017-12-01T20:18:08ZMartin ReineckePowerSpace volume factorsAs mentioned in the NIFTy paper, there are many different ways to define volume factors for the PowerSpace.
If I remember correctly, the agreement that we reached some time ago was that `PowerSpace.weight()` should use a weight of 1, i....As mentioned in the NIFTy paper, there are many different ways to define volume factors for the PowerSpace.
If I remember correctly, the agreement that we reached some time ago was that `PowerSpace.weight()` should use a weight of 1, i.e. it should not do anything. However, the current implementation uses `rho` as weights.
I suggest to change this to 1 as discussed. The advantage of using this weight over the others is that the user does not need to do any additional corrections when they have to use a different weight; they can just apply their own volume factors without needing to undo anything the space did by default.https://gitlab.mpcdf.mpg.de/ift/nifty/-/issues/199Fairly urgent: decide on convention for diagonal in DiagonalOperator2017-11-16T10:02:14ZMartin ReineckeFairly urgent: decide on convention for diagonal in DiagonalOperatorRecently I removed the last remaining uses of the `bare` keyword in some methods of `DiagonalOperator`, and this change has now been merged into the `nightly` branch. The code now behaves as if `bare=False`, which was the default before....Recently I removed the last remaining uses of the `bare` keyword in some methods of `DiagonalOperator`, and this change has now been merged into the `nightly` branch. The code now behaves as if `bare=False`, which was the default before.
However Torsten argues that it would be more natural to behave as if `bare=True`.
Both is fine with me, but we need to decide very quickly, because the first people have started adapting to `nightly` and will be unhappy if they have to change their codes again!https://gitlab.mpcdf.mpg.de/ift/nifty/-/issues/180Use MPCDF's runners for continuous integration?2017-11-13T09:39:16ZMartin ReineckeUse MPCDF's runners for continuous integration?It seems that MPCDF now offers shared runners (http://www.mpcdf.mpg.de/about-mpcdf/publications/bits-n-bytes?BB-View=196&BB-Doc=187).
Should we try to use these instead of Theo's machine?It seems that MPCDF now offers shared runners (http://www.mpcdf.mpg.de/about-mpcdf/publications/bits-n-bytes?BB-View=196&BB-Doc=187).
Should we try to use these instead of Theo's machine?https://gitlab.mpcdf.mpg.de/ift/nifty/-/issues/194ResponseOperator._add_attributes_to_copy crashes2017-10-12T14:10:57ZChristoph LienhardResponseOperator._add_attributes_to_copy crashesWhen trying to run the log_normal_wiener_filter demo an error occurs:
line 103, in _add_attributes_to_copy copy = super(DiagonalOperator, self)._add_attributes_to_copy(copy,
TypeError: super(type, obj): obj must be an instance or subtyp...When trying to run the log_normal_wiener_filter demo an error occurs:
line 103, in _add_attributes_to_copy copy = super(DiagonalOperator, self)._add_attributes_to_copy(copy,
TypeError: super(type, obj): obj must be an instance or subtype of type
I guess the line should read:
copy = super(ResponseOperator, self)._add_attributes_to_copy(copy, **kwargs)https://gitlab.mpcdf.mpg.de/ift/IMAGINE/-/issues/2Add `Galaxy` class which carries constituents (e-, dust, B)2017-10-04T23:43:23ZTheo SteiningerAdd `Galaxy` class which carries constituents (e-, dust, B)Theo SteiningerTheo Steiningerhttps://gitlab.mpcdf.mpg.de/ift/nifty/-/issues/186TransformationCache re-uses FFTs in situations where it shouldn't2017-09-28T01:59:35ZMartin ReineckeTransformationCache re-uses FFTs in situations where it shouldn't(This is mostly a reminder ... the problem should go away automatically once the `byebye_zerocenter` branch is merged.)
Currently the TransformationCache for FFTs caches and re-uses transforms even when the harmonic base has changes in ...(This is mostly a reminder ... the problem should go away automatically once the `byebye_zerocenter` branch is merged.)
Currently the TransformationCache for FFTs caches and re-uses transforms even when the harmonic base has changes in the meantime, which leads to wrong results. This can be avoided by simply not changing the harmonic base during a run, but this approach seems impractical, since we violate this constraint already in test_fft_operator.py.
Apparently, the whole test environment is not torn down and set up again between individual tests. I verified this by printing the size of the transformation cache whenever its create() method is called (line 27 in transformation_cache.py) and then ran
`nosetests test/test_operators/test_fft_operator.py -s`
I would have expected the length of the cache to be 1 all the time, but it went up beyond 100.
This is possibly also the cause for the strange behaviour in `test_power_synthesize_analyze()`.
To verify this, I suggest running the tests on maste ran on `byebye_zerocenter` and compare the convergence behaviour.https://gitlab.mpcdf.mpg.de/ift/nifty/-/issues/187Field.dim returns 0 for fields without domain2017-09-28T01:37:34ZMartin ReineckeField.dim returns 0 for fields without domain```
import nifty as ift
f=ift.Field((),val=42)
print f.val
print f.dim
```
As expected, the Field contains a single value, but its `dim` property is 0, which seems incorrect and is also inconsistent with `numpy.ndarray`'s behavior for z...```
import nifty as ift
f=ift.Field((),val=42)
print f.val
print f.dim
```
As expected, the Field contains a single value, but its `dim` property is 0, which seems incorrect and is also inconsistent with `numpy.ndarray`'s behavior for zero-dimensional arrays.