ift issueshttps://gitlab.mpcdf.mpg.de/groups/ift/-/issues2018-05-23T12:36:47Zhttps://gitlab.mpcdf.mpg.de/ift/nifty/-/issues/239Branch cleanup2018-05-23T12:36:47ZMartin ReineckeBranch cleanupI'd like to cleanup the branches which are no longer used. Could you please give me feedback which ones of your branches are still needed?
@reimar: easy_samples
Another question: should we merge the `working_on_demos` branch?I'd like to cleanup the branches which are no longer used. Could you please give me feedback which ones of your branches are still needed?
@reimar: easy_samples
Another question: should we merge the `working_on_demos` branch?https://gitlab.mpcdf.mpg.de/ift/nifty/-/issues/238extra.check_value_gradient_consistency does not work for MultiField2018-05-23T09:22:38ZJakob Knollmuellerextra.check_value_gradient_consistency does not work for MultiFieldextra.check_value_gradient_consistency calls Field.from_random, which does not support drawing random MultiFields.
Does it make more sense to remove the static Field.from_random, which always requires an additional domain, and instead introduce something like domain.random(random_type)? Alternatively one has to include checks for MultiField or regular Field.
Jakobextra.check_value_gradient_consistency calls Field.from_random, which does not support drawing random MultiFields.
Does it make more sense to remove the static Field.from_random, which always requires an additional domain, and instead introduce something like domain.random(random_type)? Alternatively one has to include checks for MultiField or regular Field.
Jakobhttps://gitlab.mpcdf.mpg.de/ift/nifty/-/issues/237Comparing Fields to floats2018-05-16T10:08:38ZPhilipp Arrasparras@mpa-garching.mpg.deComparing Fields to floatsIs the following behaviour intended?
```
import nifty4 as ift
f = ift.Field.full(ift.RGSpace(1), 1.)
if f == 0.:
print(f==0.)
```
Results in:
```
nifty4.Field instance
- domain = DomainTuple, len: 1
RGSpace(shape=(1,), distances=(1.0,), harmonic=False)
- val = array([False])
```Is the following behaviour intended?
```
import nifty4 as ift
f = ift.Field.full(ift.RGSpace(1), 1.)
if f == 0.:
print(f==0.)
```
Results in:
```
nifty4.Field instance
- domain = DomainTuple, len: 1
RGSpace(shape=(1,), distances=(1.0,), harmonic=False)
- val = array([False])
```https://gitlab.mpcdf.mpg.de/ift/IMAGINE/-/issues/3Long-term plans?2018-05-14T08:26:03ZMartin ReineckeLong-term plans?I expect that IMAGINE will continue to be used in the future.
Is the goal to adjust it to NIFTy 4 or to stick to NIFTy 3?
I can help with the migration if necessary.
In the current state the package is not installable, since setup.py tries to clone the "master" branch of NIFTy, which does not exist.I expect that IMAGINE will continue to be used in the future.
Is the goal to adjust it to NIFTy 4 or to stick to NIFTy 3?
I can help with the migration if necessary.
In the current state the package is not installable, since setup.py tries to clone the "master" branch of NIFTy, which does not exist.Theo SteiningerTheo Steiningerhttps://gitlab.mpcdf.mpg.de/ift/nifty/-/issues/236try except in InverseEnabler.draw_sample2018-05-02T08:01:18ZChristoph Lienhardtry except in InverseEnabler.draw_samplejust catching every error in the `draw_sample` function of the `InversionEnabler` class might shadow 'real' errors.
IMO only `ValueError`s should be excepted.
(just had a problem and only got the 'cannot draw from inverse of this operator', which is weird, if the InversionEnabler is on. Also I was not drawing from the inverse.
The reason was, that the `try` clause caught a completely different error jumped into `except` where it tried to draw a sample from the inverse of said operator, which was not implemented for that operator)just catching every error in the `draw_sample` function of the `InversionEnabler` class might shadow 'real' errors.
IMO only `ValueError`s should be excepted.
(just had a problem and only got the 'cannot draw from inverse of this operator', which is weird, if the InversionEnabler is on. Also I was not drawing from the inverse.
The reason was, that the `try` clause caught a completely different error jumped into `except` where it tried to draw a sample from the inverse of said operator, which was not implemented for that operator)https://gitlab.mpcdf.mpg.de/ift/nifty/-/issues/235Improved LOS response?2018-04-30T09:19:16ZMartin ReineckeImproved LOS response?@kjako mentioned some time ago that the current LOSResponse exhibits some artifacts. I suspect that they are caused by our method to compute the "influence" of lines of sight on individual data points.
Currently, the influence of a line of sight on a data point is simply proportional to the length of its intersection with the cell around the data point. It doesn't matter whether the LOS cuts the cell near the edges or goes straight through the center. This also implies that tiny shifts of a line of sight may lead to dramatic changes of its influences on data points, which is probably not desirable.
I propose to use an approach that is more similar to SPH methods:
- each data point has a sphere of influence with a given R_max (similar to the cell distances)
- it interacts with all lines of sight that intersect its sphere of influence
- the interaction strength scales with the integral along the line of sight over a function f(r) around the data point, which falls to zero at R_max.
My expectation is that this will reduce grid-related artifacts.
@ensslint, @kjako: does this sound worthwhile to try?@kjako mentioned some time ago that the current LOSResponse exhibits some artifacts. I suspect that they are caused by our method to compute the "influence" of lines of sight on individual data points.
Currently, the influence of a line of sight on a data point is simply proportional to the length of its intersection with the cell around the data point. It doesn't matter whether the LOS cuts the cell near the edges or goes straight through the center. This also implies that tiny shifts of a line of sight may lead to dramatic changes of its influences on data points, which is probably not desirable.
I propose to use an approach that is more similar to SPH methods:
- each data point has a sphere of influence with a given R_max (similar to the cell distances)
- it interacts with all lines of sight that intersect its sphere of influence
- the interaction strength scales with the integral along the line of sight over a function f(r) around the data point, which falls to zero at R_max.
My expectation is that this will reduce grid-related artifacts.
@ensslint, @kjako: does this sound worthwhile to try?https://gitlab.mpcdf.mpg.de/ift/nifty/-/issues/234Documentation for our volume factor approach?2018-06-27T15:54:46ZMartin ReineckeDocumentation for our volume factor approach?Do we have a short document describing why (and how) our approach with almost no volume factors works?
Vanessa Boehm asked me for an explanation, which I can't give, and I expect more requests of that sort.
@reimar, would it be possible to add something to our documentation?Do we have a short document describing why (and how) our approach with almost no volume factors works?
Vanessa Boehm asked me for an explanation, which I can't give, and I expect more requests of that sort.
@reimar, would it be possible to add something to our documentation?https://gitlab.mpcdf.mpg.de/ift/nifty/-/issues/233Incorrect Energy.curvature() call in minimizers/conjugate_gradient.py?2018-04-20T13:47:34ZLukas PlatzIncorrect Energy.curvature() call in minimizers/conjugate_gradient.py?In [minimization/conjugate_gradient.py, line 76](https://gitlab.mpcdf.mpg.de/ift/NIFTy/blob/NIFTy_4/nifty4/minimization/conjugate_gradient.py#L76) there is a call to 'energy.curvature(d)'.
However all energies defined in NIFTy only have argument-less curvature methods.
Still, the ConjugateGradient Class is usable without error messages. What am I missing?In [minimization/conjugate_gradient.py, line 76](https://gitlab.mpcdf.mpg.de/ift/NIFTy/blob/NIFTy_4/nifty4/minimization/conjugate_gradient.py#L76) there is a call to 'energy.curvature(d)'.
However all energies defined in NIFTy only have argument-less curvature methods.
Still, the ConjugateGradient Class is usable without error messages. What am I missing?https://gitlab.mpcdf.mpg.de/ift/nifty/-/issues/232Random seed in extra/tests2018-04-26T15:01:09ZPhilipp Arrasparras@mpa-garching.mpg.deRandom seed in extra/testsIf one calls tests like `nifty4.extra.consistency_check(op)` the random seed afterwards is different. Would it be sensible to reset the numpy random seed?If one calls tests like `nifty4.extra.consistency_check(op)` the random seed afterwards is different. Would it be sensible to reset the numpy random seed?https://gitlab.mpcdf.mpg.de/ift/nifty/-/issues/231draw_sample() definition2018-03-28T13:42:23ZChristoph Lienharddraw_sample() definitionthe `draw_sample()` function for linear operators seems to lack a precise definition.
Whereas in the case of a curvature C the `draw_sample` function draws a sample from the corresponding Gaussian approximation of the underlying probability distribution with said curvature (i.e. exp(-0.5 x^+ Cx) ), in the case of a `DiagonalOperator` D it seems to use the distribution wrt the inverse of it (i.e. exp(-0.5 x^+ D^-1 x) )
I propose changing the latter to match the former for consistency.
The curvature definition is more likely to be the one that someone actually wants (at least for the curvature case. For the diagonal operator case one could start arguing, but ... consistency!). Also the `draw_sample` function for the `DiagonalOperator` class is not that hard to change.the `draw_sample()` function for linear operators seems to lack a precise definition.
Whereas in the case of a curvature C the `draw_sample` function draws a sample from the corresponding Gaussian approximation of the underlying probability distribution with said curvature (i.e. exp(-0.5 x^+ Cx) ), in the case of a `DiagonalOperator` D it seems to use the distribution wrt the inverse of it (i.e. exp(-0.5 x^+ D^-1 x) )
I propose changing the latter to match the former for consistency.
The curvature definition is more likely to be the one that someone actually wants (at least for the curvature case. For the diagonal operator case one could start arguing, but ... consistency!). Also the `draw_sample` function for the `DiagonalOperator` class is not that hard to change.https://gitlab.mpcdf.mpg.de/ift/nifty/-/issues/230Generalized DOFDistributor2018-03-23T15:45:22ZMartin ReineckeGeneralized DOFDistributorIf we extend the `DOFDistributor` to allow for an optional set of weights, it becomes much more powerful.
For example, such an enhanced `DOFDistributor` can be used to describe a line-of-sight response, so we don't need a dedicated operator for this any more.
(The complicated task of computing the appropriate mappings and weights does not go away of course, but it is now separated from the distribution operation itself, which is good.)
@ensslint, @kjako, @reimar, @pfrank, @parras, would this be a way to go forward?If we extend the `DOFDistributor` to allow for an optional set of weights, it becomes much more powerful.
For example, such an enhanced `DOFDistributor` can be used to describe a line-of-sight response, so we don't need a dedicated operator for this any more.
(The complicated task of computing the appropriate mappings and weights does not go away of course, but it is now separated from the distribution operation itself, which is good.)
@ensslint, @kjako, @reimar, @pfrank, @parras, would this be a way to go forward?https://gitlab.mpcdf.mpg.de/ift/D2O/-/issues/25Meta-issue: how to deal with open D2O issues?2018-03-20T14:57:13ZMartin ReineckeMeta-issue: how to deal with open D2O issues?@theos, @ensslint:
There are currently 22 open issues in D2O, and I don't expect that Theo will have the time to work on them. Unfortunately, no one else has the necessary knowledge.
Any suggestions how to proceed here?@theos, @ensslint:
There are currently 22 open issues in D2O, and I don't expect that Theo will have the time to work on them. Unfortunately, no one else has the necessary knowledge.
Any suggestions how to proceed here?https://gitlab.mpcdf.mpg.de/ift/nifty/-/issues/229Allow redirection of NIFTy's console output2018-03-14T18:56:03ZMartin ReineckeAllow redirection of NIFTy's console outputNIFTy still prints to the console occasionally (via the dobj.mprint() method). It should be possible to redirect this output to arbitrary file handles (or /dev/null) on user request.NIFTy still prints to the console occasionally (via the dobj.mprint() method). It should be possible to redirect this output to arbitrary file handles (or /dev/null) on user request.https://gitlab.mpcdf.mpg.de/ift/nifty/-/issues/228diagonal Operator with zeros2018-03-13T12:41:15ZReimar H Leikediagonal Operator with zerosCurrently the DiagonalOperator always has the capability of inverse_times. However, this is only legal if there are no zeros on the diagonal. One should either document that a non-zero diagonal is expected or change the properties of the operator dependent on the input.Currently the DiagonalOperator always has the capability of inverse_times. However, this is only legal if there are no zeros on the diagonal. One should either document that a non-zero diagonal is expected or change the properties of the operator dependent on the input.https://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/226Minimizers don't work reliably on nonlinear problems2019-02-01T08:36:45ZMartin ReineckeMinimizers don't work reliably on nonlinear problemsWe are seeing quite a lot of strange problems in our minimizations, typically when nonlinearities are involved.
So far I have not found any real bugs in our minimizers, so my suspicion is that we have to add constraints to our fields of unknowns, to prevent them wandering into regions where energy values are too high, gradients too small etc. Our current attempts to clip the nonlinearities or to manually reset the positions whenever they move out of the accepted area do not work well, so I suggest trying algorithms like SciPy's 'L-BFGS-B', 'COBYLA', etc., which have native support for constraints.
If that turns out to work well, we can try to add constraints also to our own solvers.We are seeing quite a lot of strange problems in our minimizations, typically when nonlinearities are involved.
So far I have not found any real bugs in our minimizers, so my suspicion is that we have to add constraints to our fields of unknowns, to prevent them wandering into regions where energy values are too high, gradients too small etc. Our current attempts to clip the nonlinearities or to manually reset the positions whenever they move out of the accepted area do not work well, so I suggest trying algorithms like SciPy's 'L-BFGS-B', 'COBYLA', etc., which have native support for constraints.
If that turns out to work well, we can try to add constraints also to our own solvers.https://gitlab.mpcdf.mpg.de/ift/nifty/-/issues/225broken link in Readme2018-02-22T13:00:52ZSilvan Streitbroken link in ReadmeThe link to the informal introduction in https://gitlab.mpcdf.mpg.de/ift/NIFTy#first-steps is broken.The link to the informal introduction in https://gitlab.mpcdf.mpg.de/ift/NIFTy#first-steps is broken.https://gitlab.mpcdf.mpg.de/ift/nifty/-/issues/224Add kwargs to plotting2018-03-01T20:29:55ZPhilipp Arrasparras@mpa-garching.mpg.deAdd kwargs to plottingCan we add `linewidth` and `alpha` to the kwargs supported by 1d-plotting routines? If so, I can do it.
Are there perhaps additional kwargs you guys need?Can we add `linewidth` and `alpha` to the kwargs supported by 1d-plotting routines? If so, I can do it.
Are there perhaps additional kwargs you guys need?https://gitlab.mpcdf.mpg.de/ift/nifty/-/issues/223power_synthesize() vs. draw_sample()2018-02-21T21:11:06ZMartin Reineckepower_synthesize() vs. draw_sample()Are there any fundamental differences between
- calling `power_synthesize(f)`, and
- calling `DiagonalOperator(diagonal=f).draw_sample()`?
I think we have some duplicate code here, which could be cleaned up.
Related question: does `draw_sample()` work if the operator has complex values on the diagonal?
@reimar, @kjako, @parras, any comments?Are there any fundamental differences between
- calling `power_synthesize(f)`, and
- calling `DiagonalOperator(diagonal=f).draw_sample()`?
I think we have some duplicate code here, which could be cleaned up.
Related question: does `draw_sample()` work if the operator has complex values on the diagonal?
@reimar, @kjako, @parras, any comments?https://gitlab.mpcdf.mpg.de/ift/nifty/-/issues/222Bug in LaplaceOperator2018-02-21T21:21:01ZMartin ReineckeBug in LaplaceOperatorThe current version of `LaplaceOperator` has a bug that causes the input field to be modified whenever its `adjoint_times()` method is called.
The fix is trivial and will be applied in a few minutes.
@kjako, @reimar, @parras, @pfrank, @dpumpe, please check if this maybe fixes any mysterious problems you have encountered!The current version of `LaplaceOperator` has a bug that causes the input field to be modified whenever its `adjoint_times()` method is called.
The fix is trivial and will be applied in a few minutes.
@kjako, @reimar, @parras, @pfrank, @dpumpe, please check if this maybe fixes any mysterious problems you have encountered!