ift issueshttps://gitlab.mpcdf.mpg.de/groups/ift/-/issues2017-05-09T07:57:09Zhttps://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 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.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/118Physical Units for demos2017-05-28T06:56:12ZReimar H LeikePhysical Units for demosVerify that the demo correctly applies units, such that if the resolution is doubled the physical problem stays the same.Verify that the demo correctly applies units, such that if the resolution is doubled the physical problem stays the same.2017-05-19Reimar H LeikeReimar H Leikehttps://gitlab.mpcdf.mpg.de/ift/nifty/-/issues/162Fix class-docstrings for new operators2017-08-15T08:03:20ZTheo SteiningerFix class-docstrings for new operatorsThe docstrings for the following operators must be refactored (80-chars limit, complete missing entries, etc...)
- LaplaceOperator
- SmoothnessOperatorThe docstrings for the following operators must be refactored (80-chars limit, complete missing entries, etc...)
- LaplaceOperator
- SmoothnessOperator2017-07-12Jakob KnollmuellerJakob Knollmuellerhttps://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]: 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?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?2018-01-11Martin ReineckeMartin Reineckehttps://gitlab.mpcdf.mpg.de/ift/nifty/-/issues/100Tests: NIFTy config & logging2018-01-19T08:55:21ZTheo SteiningerTests: NIFTy config & logging2018-01-19https://gitlab.mpcdf.mpg.de/ift/nifty/-/issues/96Tests: Field class2018-01-19T08:55:09ZTheo SteiningerTests: Field class2018-01-19https://gitlab.mpcdf.mpg.de/ift/nifty/-/issues/91Docstring: NIFTy config & logging2018-01-19T08:54:57ZTheo SteiningerDocstring: NIFTy config & logging2018-01-19https://gitlab.mpcdf.mpg.de/ift/nifty/-/issues/65Profile Field.dot2018-01-19T08:55:37ZTheo SteiningerProfile Field.dotField.dot uses the DiagonalOperator in order to do dot products that only affect certain spaces of the partner. Maybe the fields are unnecessarily copied -> profiling is needed to ensure efficiency.Field.dot uses the DiagonalOperator in order to do dot products that only affect certain spaces of the partner. Maybe the fields are unnecessarily copied -> profiling is needed to ensure efficiency.2018-01-19Theo SteiningerTheo Steiningerhttps://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 explicitly coded pixel space operator. 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/227Renaming 'structured' and 'unstructered' domains.2018-04-06T11:24:55ZTheo SteiningerRenaming 'structured' and 'unstructered' domains.In my opinion the wording of 'structured' and 'unstructured' domains is misleading. The 'unstructured' domains can have plenty of structure, too, e.g. a vector-field. Mathematically, 'structured' domains are manifolds and 'unstructured' domains are fibers/Fasern that are defined on top of the product of all manifolds. Together, everything forms a fiber-bundle.
See, for reference:
https://en.wikipedia.org/wiki/Fiber_bundleIn my opinion the wording of 'structured' and 'unstructured' domains is misleading. The 'unstructured' domains can have plenty of structure, too, e.g. a vector-field. Mathematically, 'structured' domains are manifolds and 'unstructured' domains are fibers/Fasern that are defined on top of the product of all manifolds. Together, everything forms a fiber-bundle.
See, for reference:
https://en.wikipedia.org/wiki/Fiber_bundle2018-04-04https://gitlab.mpcdf.mpg.de/ift/nifty/-/issues/294Potential confusion in the direction of FFTs2020-05-13T11:23:26ZMartin ReineckePotential confusion in the direction of FFTsIn the current implementation of FFTOperator (https://gitlab.mpcdf.mpg.de/ift/nifty/-/blob/NIFTy_6/nifty6/operators/harmonic_operators.py#L76) we have the code:
```
if x.domain[self._space].harmonic: # harmonic -> position
func = fft.fftn
fct = 1.
else:
func = fft.ifftn
fct = ncells
```
where `x` is the input field.
This looks exactly the wrong way around.
@parras, @pfrank, @kjako, @reimar, @veberle, what do you think?
Switching the FFT direction breaks almost none of our tests (only one, which already has a FIXME :).In the current implementation of FFTOperator (https://gitlab.mpcdf.mpg.de/ift/nifty/-/blob/NIFTy_6/nifty6/operators/harmonic_operators.py#L76) we have the code:
```
if x.domain[self._space].harmonic: # harmonic -> position
func = fft.fftn
fct = 1.
else:
func = fft.ifftn
fct = ncells
```
where `x` is the input field.
This looks exactly the wrong way around.
@parras, @pfrank, @kjako, @reimar, @veberle, what do you think?
Switching the FFT direction breaks almost none of our tests (only one, which already has a FIXME :).2020-05-13https://gitlab.mpcdf.mpg.de/ift/nifty/-/issues/335CorrelatedFieldMaker amplitude normalization breaks fluctuation amplitude2021-08-02T22:45:03ZLukas PlatzCorrelatedFieldMaker amplitude normalization breaks fluctuation amplitudeIf one adds more than one amplitude operator to a `CorrelatedFieldMaker` and sets a very small/large offset standard deviation, the field fluctuation amplitude gets distorted.
This is because in `get_normalized_amplitudes()` every amplitude operator gets devided by `self.azm` and the results of this function are then multiplied with an outer product to create the joint amplitude operator.
In CFs with more than one amplitude operator, this results in the joint amplitude operator being divided by multiples of the zeromode operator and thus an incorrect output scaling behavior.
To demonstrate this effect, I created correlated field operators for identical 2d fields, but one with a single amplitude operator for `ift.RGSpace((N, N)` and one with two amplitude operators on `ift.RGSpace(N)`. From top to bottom, I varied the `offset std` setting passed to `set_amplitude_total_offset()` and in each case plotted a histogram of the sampled fields' standard deviation.
![output](/uploads/6779601e231148c36a77a91aa8e7fd62/bug.png)
One can clearly see the output fluctuation amplitude is independant from the `offset_std` for the 'single' case, as it should be, but not for the 'dual' case.
A fix for this is proposed in merge requests !669 and !670.
To reproduce, run the following code:
```
import nifty7 as ift
import matplotlib.pyplot as plt
fluct_pars = {
'fluctuations': (1.0, 0.1),
'flexibility': None,
'asperity': None,
'loglogavgslope': (-2.0, 0.2),
'prefix': 'flucts_',
'dofdex': None
}
n_offsets = 5
n_samples = 1000
dom_single = ift.RGSpace((25, 25))
dom_dual = ift.RGSpace(25)
fig, axs = plt.subplots(nrows=n_offsets, ncols=2, figsize=(12, 4 * n_offsets))
for i in range(n_offsets):
cfmaker_single = ift.CorrelatedFieldMaker(prefix='str(i)_')
cfmaker_dual = ift.CorrelatedFieldMaker(prefix='str(i)_')
cfmaker_single.add_fluctuations(dom_single, **fluct_pars)
cfmaker_dual.add_fluctuations(dom_dual, **fluct_pars)
cfmaker_dual.add_fluctuations(dom_dual, **fluct_pars)
offset_std = 10 ** -i
zm_pars = {'offset_mean': 0.,
'offset_std': (offset_std, offset_std / 10.)}
cfmaker_single.set_amplitude_total_offset(**zm_pars)
cfmaker_dual.set_amplitude_total_offset(**zm_pars)
cf_single = cfmaker_single.finalize(prior_info=0)
cf_dual = cfmaker_dual.finalize(prior_info=0)
samples_single = [cf_single(ift.from_random(cf_single.domain)).val.std() for _ in range(n_samples)]
samples_dual = [cf_dual(ift.from_random(cf_dual.domain)).val.std() for _ in range(n_samples)]
_ = axs[i, 0].hist(samples_single, bins=20, density=True)
_ = axs[i, 1].hist(samples_dual, bins=20, density=True)
axs[i, 0].set_title(f'offset_std = {offset_std:1.0e}, single')
axs[i, 1].set_title(f'offset_std = {offset_std:1.0e}, dual')
axs[i, 0].set_xlabel('sample std')
axs[i, 1].set_xlabel('sample std')
plt.tight_layout()
plt.show()
```
Any comments?If one adds more than one amplitude operator to a `CorrelatedFieldMaker` and sets a very small/large offset standard deviation, the field fluctuation amplitude gets distorted.
This is because in `get_normalized_amplitudes()` every amplitude operator gets devided by `self.azm` and the results of this function are then multiplied with an outer product to create the joint amplitude operator.
In CFs with more than one amplitude operator, this results in the joint amplitude operator being divided by multiples of the zeromode operator and thus an incorrect output scaling behavior.
To demonstrate this effect, I created correlated field operators for identical 2d fields, but one with a single amplitude operator for `ift.RGSpace((N, N)` and one with two amplitude operators on `ift.RGSpace(N)`. From top to bottom, I varied the `offset std` setting passed to `set_amplitude_total_offset()` and in each case plotted a histogram of the sampled fields' standard deviation.
![output](/uploads/6779601e231148c36a77a91aa8e7fd62/bug.png)
One can clearly see the output fluctuation amplitude is independant from the `offset_std` for the 'single' case, as it should be, but not for the 'dual' case.
A fix for this is proposed in merge requests !669 and !670.
To reproduce, run the following code:
```
import nifty7 as ift
import matplotlib.pyplot as plt
fluct_pars = {
'fluctuations': (1.0, 0.1),
'flexibility': None,
'asperity': None,
'loglogavgslope': (-2.0, 0.2),
'prefix': 'flucts_',
'dofdex': None
}
n_offsets = 5
n_samples = 1000
dom_single = ift.RGSpace((25, 25))
dom_dual = ift.RGSpace(25)
fig, axs = plt.subplots(nrows=n_offsets, ncols=2, figsize=(12, 4 * n_offsets))
for i in range(n_offsets):
cfmaker_single = ift.CorrelatedFieldMaker(prefix='str(i)_')
cfmaker_dual = ift.CorrelatedFieldMaker(prefix='str(i)_')
cfmaker_single.add_fluctuations(dom_single, **fluct_pars)
cfmaker_dual.add_fluctuations(dom_dual, **fluct_pars)
cfmaker_dual.add_fluctuations(dom_dual, **fluct_pars)
offset_std = 10 ** -i
zm_pars = {'offset_mean': 0.,
'offset_std': (offset_std, offset_std / 10.)}
cfmaker_single.set_amplitude_total_offset(**zm_pars)
cfmaker_dual.set_amplitude_total_offset(**zm_pars)
cf_single = cfmaker_single.finalize(prior_info=0)
cf_dual = cfmaker_dual.finalize(prior_info=0)
samples_single = [cf_single(ift.from_random(cf_single.domain)).val.std() for _ in range(n_samples)]
samples_dual = [cf_dual(ift.from_random(cf_dual.domain)).val.std() for _ in range(n_samples)]
_ = axs[i, 0].hist(samples_single, bins=20, density=True)
_ = axs[i, 1].hist(samples_dual, bins=20, density=True)
axs[i, 0].set_title(f'offset_std = {offset_std:1.0e}, single')
axs[i, 1].set_title(f'offset_std = {offset_std:1.0e}, dual')
axs[i, 0].set_xlabel('sample std')
axs[i, 1].set_xlabel('sample std')
plt.tight_layout()
plt.show()
```
Any comments?https://gitlab.mpcdf.mpg.de/ift/nifty/-/issues/334`MetricGaussianKL` changed its interface (there is not `.make`) but there is ...2021-07-01T15:34:54ZGordian Edenhofer`MetricGaussianKL` changed its interface (there is not `.make`) but there is no corresponding changelog entryhttps://gitlab.mpcdf.mpg.de/ift/resolve/-/issues/1Implement uniform weighting2021-06-30T17:12:22ZPhilipp Arrasparras@mpa-garching.mpg.deImplement uniform weightinghttps://gitlab.mpcdf.mpg.de/ift/nifty/-/issues/333New feature: Add flag to minisanity that disables terminal colors2021-06-24T13:10:19ZPhilipp Arrasparras@mpa-garching.mpg.deNew feature: Add flag to minisanity that disables terminal colorsPhilipp Arrasparras@mpa-garching.mpg.dePhilipp Arrasparras@mpa-garching.mpg.dehttps://gitlab.mpcdf.mpg.de/ift/nifty/-/issues/332Rename `Likelihood` -> `LogLikelihood`2021-06-10T10:44:36ZPhilipp Arrasparras@mpa-garching.mpg.deRename `Likelihood` -> `LogLikelihood`NIFTy7 releasehttps://gitlab.mpcdf.mpg.de/ift/nifty/-/issues/331Build html coverage report of both release and develop branch2021-06-09T15:51:21ZPhilipp Arrasparras@mpa-garching.mpg.deBuild html coverage report of both release and develop branchNIFTy7 releasehttps://gitlab.mpcdf.mpg.de/ift/nifty/-/issues/330Write guide how to define custom non-linearities2021-06-10T11:39:25ZPhilipp Arrasparras@mpa-garching.mpg.deWrite guide how to define custom non-linearitiesNIFTy7 releasehttps://gitlab.mpcdf.mpg.de/ift/nifty/-/issues/329Performance check (in ift.check_operator) broken for BernoulliEnergy2021-06-07T10:42:14ZLukas PlatzPerformance check (in ift.check_operator) broken for BernoulliEnergyThe operator performance check introduced in [`a50ec021`](https://gitlab.mpcdf.mpg.de/ift/nifty/-/commit/a50ec021e457dc8f4e199c6331c67167eec0fdb7) changes the operator test position [by a factor of two](https://gitlab.mpcdf.mpg.de/ift/nifty/-/blob/a50ec021e457dc8f4e199c6331c67167eec0fdb7/nifty6/extra.py#L146) for the 'application to a linearization' test. This breaks the test for the `BernoulliEnergy`, as it creates input values outside the interval of `[0, 1)`.
@reimar, since you coded this function: does the factor of two serve a valuable purpose, or can we safely delete it?The operator performance check introduced in [`a50ec021`](https://gitlab.mpcdf.mpg.de/ift/nifty/-/commit/a50ec021e457dc8f4e199c6331c67167eec0fdb7) changes the operator test position [by a factor of two](https://gitlab.mpcdf.mpg.de/ift/nifty/-/blob/a50ec021e457dc8f4e199c6331c67167eec0fdb7/nifty6/extra.py#L146) for the 'application to a linearization' test. This breaks the test for the `BernoulliEnergy`, as it creates input values outside the interval of `[0, 1)`.
@reimar, since you coded this function: does the factor of two serve a valuable purpose, or can we safely delete it?NIFTy7 releasehttps://gitlab.mpcdf.mpg.de/ift/nifty/-/issues/328What is the correct gradient at zero for `pointwise.unit_step`?2021-06-10T20:10:15ZLukas PlatzWhat is the correct gradient at zero for `pointwise.unit_step`?I just noticed that the gradient of the pointwise function `unit_step` [is set to be always zero](https://gitlab.mpcdf.mpg.de/ift/nifty/-/blob/4772fce8b032135e39702ffb4b52b33f5deefe20/src/pointwise.py#L91).
Is that correct, or should we return `np.nan` if the input is exactly zero, like for examples `sign` [does](https://gitlab.mpcdf.mpg.de/ift/nifty/-/blob/4772fce8b032135e39702ffb4b52b33f5deefe20/src/pointwise.py#L67)?I just noticed that the gradient of the pointwise function `unit_step` [is set to be always zero](https://gitlab.mpcdf.mpg.de/ift/nifty/-/blob/4772fce8b032135e39702ffb4b52b33f5deefe20/src/pointwise.py#L91).
Is that correct, or should we return `np.nan` if the input is exactly zero, like for examples `sign` [does](https://gitlab.mpcdf.mpg.de/ift/nifty/-/blob/4772fce8b032135e39702ffb4b52b33f5deefe20/src/pointwise.py#L67)?