ift issueshttps://gitlab.mpcdf.mpg.de/groups/ift/-/issues2017-12-09T14:10:49Zhttps://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/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/43field.smooth on rg_space produces non-sensible results on multiple spaces2018-04-02T09:42:38ZTheo Steiningerfield.smooth on rg_space produces non-sensible results on multiple spaces from nifty import *
x = rg_space((8,))
f = field((x,x), val=1)
f.val[3] = 10
f.smooth(spaces=0, sigma=0.0001).val
The result of the last operation does not make sense, as the columns are
<distributed_da... from nifty import *
x = rg_space((8,))
f = field((x,x), val=1)
f.val[3] = 10
f.smooth(spaces=0, sigma=0.0001).val
The result of the last operation does not make sense, as the columns are
<distributed_data_object>
array([ 1.00000104, 0.99999867, 1.00000355, 5.49999423, 1.00000607,
5.49999423, 1.00000355, 0.99999867])
instead of
<distributed_data_object>
array([ 1.00000104, 0.99999822, 1.00000607, 9.99999023, 1.00000607,
0.99999822, 1.00000104, 0.99999911])
https://gitlab.mpcdf.mpg.de/ift/nifty/-/issues/282FieldZeroPadder2020-02-19T16:45:27ZVincent EberleFieldZeroPadderFieldZeropadding.adjoint doesn't work in 2 dimensions.FieldZeropadding.adjoint doesn't work in 2 dimensions.Philipp FrankPhilipp Frankhttps://gitlab.mpcdf.mpg.de/ift/nifty/-/issues/323Final steps for release2021-06-11T19:59:51ZPhilipp Arrasparras@mpa-garching.mpg.deFinal steps for release- [x] Check documentation generation for warnings and errors -> !636
- [x] Check pytest output for warnings -> #329 + !635, !634
- [x] Run `isort` on whole repository
```sh
find . -type f -name '*.py' | xargs isort
```
- [x] Update aut...- [x] Check documentation generation for warnings and errors -> !636
- [x] Check pytest output for warnings -> #329 + !635, !634
- [x] Run `isort` on whole repository
```sh
find . -type f -name '*.py' | xargs isort
```
- [x] Update author list again
```sh
git shortlog -s origin/NIFTy_6..origin/NIFTy_7 | cut -f2-
```
- [x] Fast-forward `NIFTy_8` to `origin/NIFTy_7` branch
- [x] Rename nifty7 -> nifty8 on NIFTy_8 branch
```sh
rm nifty7
ln -s src nifty8
find . -type f -exec sed -i 's/nifty7/nifty8/g' {} \;
find . -type f -exec sed -i 's/NIFTy_7/NIFTy_8/g' {} \;
find . -type f -exec sed -i 's/NIFTy7/NIFTy8/g' {} \; # Only partially!
```
- [x] Rename NIFTy_6 -> NIFTy_7 in `.gitlab-ci.yml` (for doc generation)
- [x] NIFTy_8 subsection in `README.md` in contributors section
- [x] NIFTy_7 section in `ChangeLog.md`
- [x] Make NIFTy_7 the default branch of the gitlab repository
- [x] Add daily pipeline schedule for `NIFTy_8` branch and remove the one for `NIFTy_6`NIFTy7 releasePhilipp Arrasparras@mpa-garching.mpg.dePhilipp Arrasparras@mpa-garching.mpg.dehttps://gitlab.mpcdf.mpg.de/ift/nifty/-/issues/127Find good convergence criterion for DescentMinimizer2017-07-11T08:26:57ZTheo SteiningerFind good convergence criterion for DescentMinimizerAt the moment the `convergence number` is defined as `delta = abs(gradient).max() * (step_length/gradient_norm)`
Are there better measures? For a simple quadratic potential, this definition of `delta` causes a steepest descent to not tr...At the moment the `convergence number` is defined as `delta = abs(gradient).max() * (step_length/gradient_norm)`
Are there better measures? For a simple quadratic potential, this definition of `delta` causes a steepest descent to not trust the (actual true) minimum.
A good measure should be independent of scale and initial conditions.
Some possible candidates are:
* `(new_energy.position - energy.position).norm()`
* `(new_energy.position - energy.position).max()`
* `((new_energy.position - energy.position)/(1+energy.position)).norm()`
* `((new_energy.position - energy.position)/(1+energy.position)).max()`
* `step_length`
* `step_length / energy.position.norm()`
* `gradient.norm()`Martin ReineckeMartin Reineckehttps://gitlab.mpcdf.mpg.de/ift/nifty/-/issues/308Fisher test for VariableCovarianceGaussianEnergy not sensitive2021-04-09T12:56:45ZPhilipp Arrasparras@mpa-garching.mpg.deFisher test for VariableCovarianceGaussianEnergy not sensitiveOn the branch `metric_tests` I have introduced a breaking factor (949578182c660faee1ea7344d79993d9d1b35310) and the test does not break. I am not sure how to fix it. Is it even possible to fix it in this case? Do we need two test cases, ...On the branch `metric_tests` I have introduced a breaking factor (949578182c660faee1ea7344d79993d9d1b35310) and the test does not break. I am not sure how to fix it. Is it even possible to fix it in this case? Do we need two test cases, one where the mean is sampled and one where the variance is sampled?Reimar 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
- SmoothnessOperatorJakob KnollmuellerJakob Knollmueller2017-07-12https://gitlab.mpcdf.mpg.de/ift/nifty/-/issues/156fixed points in harmonic RGSpace2017-07-08T16:23:01ZMartin Reineckefixed points in harmonic RGSpaceWhen looking at _hermitianize_correct_variance in rg_space.py, I wondered whether the determination of fixed points is correct. Assuming a 1D case, the code determines two fixed points: one at 0, and one at N/2. But as far as I understan...When looking at _hermitianize_correct_variance in rg_space.py, I wondered whether the determination of fixed points is correct. Assuming a 1D case, the code determines two fixed points: one at 0, and one at N/2. But as far as I understand, the one at N/2 is only a fixed point if N is an even number.
Please let me know if I'm confusing different things here!https://gitlab.mpcdf.mpg.de/ift/nifty/-/issues/40Fix gl_space.check_codomain function2017-01-20T00:43:54ZGhost UserFix gl_space.check_codomain functions = gl_space(nlat=8,nlon=8 );s.check_codomain(s.get_codomain())
returns false
Although gl_space warns at creation that parameters are un-recommended it doesn't warn that they wont work. It should at least recognize it's own codomain.s = gl_space(nlat=8,nlon=8 );s.check_codomain(s.get_codomain())
returns false
Although gl_space warns at creation that parameters are un-recommended it doesn't warn that they wont work. It should at least recognize it's own codomain.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/404Gauss-Makrov on GPU2024-03-05T16:54:12ZPhilipp HaimGauss-Makrov on GPUThe the loop in the general gm-process introduced in [this](%) commit leads to significant performance degradation of the correlated field on the GPU. Changing the loop to a `cumsum` (at least for the correlated field) should fix this is...The the loop in the general gm-process introduced in [this](%) commit leads to significant performance degradation of the correlated field on the GPU. Changing the loop to a `cumsum` (at least for the correlated field) should fix this issue.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 opera...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/nifty/-/issues/278Getting rid of standard parallelization?2019-12-09T12:50:25ZMartin ReineckeGetting rid of standard parallelization?The default way of parallelizing large tasks with MPI is currently to distribute fields over MPI tasks along their first axis. While it appears to work (our tests run fine with MPI), it has not been used during the last few years, and ot...The default way of parallelizing large tasks with MPI is currently to distribute fields over MPI tasks along their first axis. While it appears to work (our tests run fine with MPI), it has not been used during the last few years, and other parallelization approaches seem more promising.
If there is general agreement, I propose to remove this parallelization from the code, which would make NIFTy much smaller and easier to use and maintain.https://gitlab.mpcdf.mpg.de/ift/nifty/-/issues/44gl_space.vol2017-01-20T00:37:49ZTheo Steiningergl_space.volThe gl_space inherits the vol property from (point)space, which uses np.prod(self.distances). As gl_space stores some condensed information in self.distances, gl_space.vol produces wrong results. The correct result can be constructed by ...The gl_space inherits the vol property from (point)space, which uses np.prod(self.distances). As gl_space stores some condensed information in self.distances, gl_space.vol produces wrong results. The correct result can be constructed by weighting a ones-field and then summing up all the entries. Maybe there is a faster way to do this.
The default volume is somehow normalized to 12.5657994...Theo SteiningerTheo Steiningerhttps://gitlab.mpcdf.mpg.de/ift/nifty/-/issues/214Gradients of all PowerEnergy classes and NoiseEnergy seem to be broken2018-01-30T20:41:01ZPhilipp Arrasparras@mpa-garching.mpg.deGradients of all PowerEnergy classes and NoiseEnergy seem to be brokenI was curious why my minimizations often produce overflows during the power spectrum estimation. Therefore, I wrote (partly together with @reimar) tests which compare the gradient with finite differences. It turns out that something is m...I was curious why my minimizations often produce overflows during the power spectrum estimation. Therefore, I wrote (partly together with @reimar) tests which compare the gradient with finite differences. It turns out that something is massively broken unless I overlook something.
In order to reproduce this phenomenon just check out the branch `energy_tests` and run `nosetests test/test_energies`. The mismatch is in one example -2.421884e+12 vs 48303.217449. That doesn't look good.
Since you have implemented the energies, @kjako, do you have any ideas what possibly goes wrong here?
The curvatures are not even tested yet...https://gitlab.mpcdf.mpg.de/ift/nifty/-/issues/293[GU] Simplify point-wise Field operations2020-04-14T06:46:41ZMartin Reinecke[GU] Simplify point-wise Field operationsCurrently, point-wise operations on Nifty objects are not really implemented in a beautiful way: they are injected via some nasty Python tricks into `Field`, `MultiField`, `Operator` and the `sugar` module, and a slightly more complicate...Currently, point-wise operations on Nifty objects are not really implemented in a beautiful way: they are injected via some nasty Python tricks into `Field`, `MultiField`, `Operator` and the `sugar` module, and a slightly more complicated variant is added to `Linearization`.
My plan is to have a single method in `Field`, `MultiField`, `Linearization` and `Operator`, which is called `ptw` (or `pointwise`), which takes a string describing the requested pointwise operation (like "sin", "exp", "one_over" etc.). Implementation of the actual operations would be fairly trivial via a dictionary mapping these names to their `numpy` equivalents, and also describing their derivatives via `numpy` or custom functions where necessary.
If we like, we can leave the global pointwise functions injected into `sugar.py` unchanged for aesthetic reasons :)
Opinions?https://gitlab.mpcdf.mpg.de/ift/nifty/-/issues/183Harmonize ConjugateGradient with other minimizers?2017-09-28T01:17:59ZMartin ReineckeHarmonize ConjugateGradient with other minimizers?In principle, ConjugateGradient is not fundamentally different from our descent minimizers, but its interface (including the form of the callbacks) is very different.
Wouldn't it be helpful to adjust it in a way that it also takes an `E...In principle, ConjugateGradient is not fundamentally different from our descent minimizers, but its interface (including the form of the callbacks) is very different.
Wouldn't it be helpful to adjust it in a way that it also takes an `Energy` object for minimization and passes its current energy to the callback in the same way the descent minimizers do? Then we could, for example, replace `ConjugateGradient` objects with, say, `VL_BFGS` ones and experiment much more flexibly with different minimizers.
Of course, `ConjugateGradient` would need a special subclass of `Energy` to work properly: it would, for example, need to invoke the linear operator within this energy directly. But that should be no fundamental problem ... after all, we already have some energy classes that provide `curvature` and some that don't.
I would be very interested to hear feedback!https://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/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?