ift issueshttps://gitlab.mpcdf.mpg.de/groups/ift/-/issues2017-07-11T08:00:28Zhttps://gitlab.mpcdf.mpg.de/ift/nifty/-/issues/158Change or rename hermitian_decomposition()2017-07-11T08:00:28ZMartin ReineckeChange or rename hermitian_decomposition()I'm opening this as a separate issue, because it is design-related, not code-related.
In my opinion, the name "hermitian_decomposition" is misleading for the operation that the Space and Field methods currently perform. Of any data arra...I'm opening this as a separate issue, because it is design-related, not code-related.
In my opinion, the name "hermitian_decomposition" is misleading for the operation that the Space and Field methods currently perform. Of any data array there is exactly one hermitian decomposition, and it therefore cannot depend on the value of additional flags like "preserve_gaussian_variance". I suggest to move the necessary manipulations for variance preservation into a separate routine.
Alternatively the method name could be changed, but I can't think of anything convincing.https://gitlab.mpcdf.mpg.de/ift/nifty/-/issues/159Bug in Field._hermitian_decomposition?2017-07-08T16:23:19ZMartin ReineckeBug in Field._hermitian_decomposition?The beginning of this method looks like this:
```
@staticmethod
def _hermitian_decomposition(domain, val, spaces, domain_axes,
preserve_gaussian_variance=False):
# hermitianize for the fi...The beginning of this method looks like this:
```
@staticmethod
def _hermitian_decomposition(domain, val, spaces, domain_axes,
preserve_gaussian_variance=False):
# hermitianize for the first space
(h, a) = domain[spaces[0]].hermitian_decomposition(
val,
domain_axes[spaces[0]],
preserve_gaussian_variance=preserve_gaussian_variance)
# hermitianize all remaining spaces using the iterative formula
for space in xrange(1, len(spaces)):
(hh, ha) = domain[space].hermitian_decomposition(
h,
domain_axes[space],
preserve_gaussian_variance=False)
(ah, aa) = domain[space].hermitian_decomposition(
a,
domain_axes[space],
preserve_gaussian_variance=False)
```
Why is `preserve_gaussian_variance` hardwired to `False` for all spaces other than the first?https://gitlab.mpcdf.mpg.de/ift/nifty/-/issues/160VL_BFGS minimizer doesn't like HPSpace and LMSpace2017-07-09T23:04:22ZMatevz, Sraml (sraml)VL_BFGS minimizer doesn't like HPSpace and LMSpaceThe VL_BFGS minimizer has problems with the minimization of HPSpace and LMSpace. If we take a quadratic potential
`
np.random.seed(0)
N_dim = 500
#x_space = HPSpace(N_dim)
x_space = LMSpace(N_dim)
x =...The VL_BFGS minimizer has problems with the minimization of HPSpace and LMSpace. If we take a quadratic potential
`
np.random.seed(0)
N_dim = 500
#x_space = HPSpace(N_dim)
x_space = LMSpace(N_dim)
x = Field(x_space, val=np.random.rand(N_dim))
N = DiagonalOperator(x_space, diagonal = 1.)
class QuadraticPot(Energy):
def __init__(self, position, N):
super(QuadraticPot, self).__init__(position)
self.N = N
def at(self, position):
return self.__class__(position, N = self.N)
@property
def value(self):
H = 0.5 *self.position.dot(self.N.inverse_times(self.position))
return H.real
@property
def gradient(self):
g = self.N.inverse_times(self.position)
return_g = g.copy_empty(dtype=np.float)
return_g.val = g.val.real
return return_g
@property
def curvature(self):
return self.N
minimizer = VL_BFGS(iteration_limit=1000,convergence_tolerance=1E-4, convergence_level=3)
energy = QuadraticPot(position=x , N=N)
print energy.value
(energy, convergence) = minimizer(energy)
print energy.value
`
it doesn't converge to 0. For an example in this case above, the energy of the system is only reduced to a half of the starting energy. I think I'm lacking a piece of knowledge to understand this problem.https://gitlab.mpcdf.mpg.de/ift/nifty/-/issues/161Rework methods taking an "axes" keyword2017-08-15T08:03:13ZMartin ReineckeRework methods taking an "axes" keywordAt the moment, there are a lot of routines which take an "axes" keyword, and in many of these, it could be avoided altogether or reduced to an integer.
Example 1: the "weight" method of DomainObject and derived classes
Here, `axes` is ...At the moment, there are a lot of routines which take an "axes" keyword, and in many of these, it could be avoided altogether or reduced to an integer.
Example 1: the "weight" method of DomainObject and derived classes
Here, `axes` is mostly used to determine, which particular axes in a `Field` belong to the space. In principle, all of this could be avoided if this method simply returned an array with one weight per pixel (or a scalar if all weights are equal), and leave all the juggling with array indices to Field.weight().
As things are, there are various alternative implementations of the re-shaping task (look for example at the `weight` methods of `PowerSpace` and `GLSpace`).
My suggestion is to simplify `DomainObject`'s `weight` method to:
```
def volfactor(self):
""" Returns an array containing the object's volume factors.
The array must be broadcastable to the space's dimensions
(useful if the volume factors are uniform in a direction, e.g. for GLSpace).
Alternatively, if all volume factors are equal, returns a scalar.
"""
```
... and leave all the operations involving powers, reshaping etc. to the calling `Field.weight` method.
Example 2: `Space.hermitianize_decomposition`():
Here the `axes` variable always contains a tuple with as many entries as the space has dimensions, and the entries take the form `i`, `i+1`, `i+2`, ... I suggest to pass a scalar integer with the name `first_axis` instead, which should be less error-prone.
If there is agreement to go into this direction, there are more cases, but we can discuss them later :)https://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/163Descent minimizers: stopping criterion is broken2017-09-28T01:18:15ZMartin ReineckeDescent minimizers: stopping criterion is brokenCurrently, descent_minimizer.py contains the following lines:
```
elif delta < self.convergence_tolerance:
convergence += 1
self.logger.info("Updated convergence level to: %u" %
...Currently, descent_minimizer.py contains the following lines:
```
elif delta < self.convergence_tolerance:
convergence += 1
self.logger.info("Updated convergence level to: %u" %
convergence)
```
The problem is that `delta` never goes down far enough for the algorithms to stop in there, even though the energy is tiny compared to the starting energy (example below).
This can't be a valid stopping criterion.
```
VL_BFGS: DEBUG: Iteration:00000001 step_length=3.7E+01 delta=1.4E+00 energy=5.1E+01
VL_BFGS: DEBUG: Iteration:00000002 step_length=7.5E+00 delta=1.5E+00 energy=4.6E+00
VL_BFGS: DEBUG: Iteration:00000003 step_length=2.6E+00 delta=1.9E+00 energy=6.5E-01
VL_BFGS: DEBUG: Iteration:00000004 step_length=1.4E+00 delta=3.4E+00 energy=2.3E-02
VL_BFGS: DEBUG: Iteration:00000005 step_length=3.1E-01 delta=5.2E+00 energy=8.8E-03
VL_BFGS: DEBUG: Iteration:00000006 step_length=1.1E-01 delta=2.9E+00 energy=2.3E-04
VL_BFGS: DEBUG: Iteration:00000007 step_length=1.5E-02 delta=2.5E+00 energy=5.0E-05
VL_BFGS: DEBUG: Iteration:00000008 step_length=1.3E-02 delta=6.7E+00 energy=1.2E-06
VL_BFGS: DEBUG: Iteration:00000009 step_length=2.4E-03 delta=6.4E+00 energy=6.2E-07
VL_BFGS: DEBUG: Iteration:00000010 step_length=9.0E-04 delta=3.0E+00 energy=1.5E-08
VL_BFGS: DEBUG: Iteration:00000011 step_length=1.2E-04 delta=2.7E+00 energy=2.7E-09
VL_BFGS: DEBUG: Iteration:00000012 step_length=8.7E-05 delta=7.7E+00 energy=9.6E-11
VL_BFGS: DEBUG: Iteration:00000013 step_length=1.9E-05 delta=6.2E+00 energy=1.4E-11
VL_BFGS: DEBUG: Iteration:00000014 step_length=5.5E-06 delta=3.9E+00 energy=1.3E-12
VL_BFGS: DEBUG: Iteration:00000015 step_length=1.4E-06 delta=3.2E+00 energy=6.4E-14
VL_BFGS: DEBUG: Iteration:00000016 step_length=2.5E-07 delta=4.3E+00 energy=1.4E-14
VL_BFGS: DEBUG: Iteration:00000017 step_length=2.2E-07 delta=1.0E+01 energy=1.8E-16
VL_BFGS: DEBUG: Iteration:00000018 step_length=1.6E-08 delta=3.6E+00 energy=1.4E-17
VL_BFGS: DEBUG: Iteration:00000019 step_length=3.3E-09 delta=1.7E+00 energy=3.5E-18
VL_BFGS: DEBUG: Iteration:00000020 step_length=3.2E-09 delta=4.8E+00 energy=9.6E-20
VL_BFGS: DEBUG: Iteration:00000021 step_length=6.2E-10 delta=4.6E+00 energy=3.0E-20
VL_BFGS: DEBUG: Iteration:00000022 step_length=2.0E-10 delta=3.6E+00 energy=1.0E-21
VL_BFGS: DEBUG: Iteration:00000023 step_length=3.3E-11 delta=2.6E+00 energy=2.0E-22
VL_BFGS: DEBUG: Iteration:00000024 step_length=2.6E-11 delta=6.8E+00 energy=6.3E-24
VL_BFGS: DEBUG: Iteration:00000025 step_length=5.8E-12 delta=8.6E+00 energy=4.5E-24
VL_BFGS: DEBUG: Iteration:00000026 step_length=1.0E-12 delta=1.5E+00 energy=1.7E-24
VL_BFGS: DEBUG: Iteration:00000027 step_length=1.6E-12 delta=3.6E+00 energy=2.4E-26
VL_BFGS: DEBUG: Iteration:00000028 step_length=1.5E-13 delta=4.8E+00 energy=5.9E-27
VL_BFGS: DEBUG: Iteration:00000029 step_length=1.5E-13 delta=1.1E+01 energy=3.0E-29
VL_BFGS: DEBUG: Iteration:00000030 step_length=7.0E-15 delta=3.2E+00 energy=4.3E-30
VL_BFGS: WARNING: Reached iteration limit. Stopping.
```https://gitlab.mpcdf.mpg.de/ift/nifty/-/issues/164Another Field.vdot() bug...2017-07-11T08:18:02ZMartin ReineckeAnother Field.vdot() bug...```
from nifty import *
import numpy as np
s=RGSpace((10,))
f1=Field.from_random("normal",domain=s,dtype=np.complex128)
f2=Field.from_random("normal",domain=s,dtype=np.complex128)
print f1.vdot(f2)
print f1.vdot(f2,spaces=0)
``````
from nifty import *
import numpy as np
s=RGSpace((10,))
f1=Field.from_random("normal",domain=s,dtype=np.complex128)
f2=Field.from_random("normal",domain=s,dtype=np.complex128)
print f1.vdot(f2)
print f1.vdot(f2,spaces=0)
```https://gitlab.mpcdf.mpg.de/ift/nifty/-/issues/165Critical power energy doesn't work for product spaces2017-08-02T21:20:47ZTheo SteiningerCritical power energy doesn't work for product spacesIn principle it is no problem to port the existing code to product-space functionality. The biggest thing is that we then would need a n-dimensional SmoothnessOperator. Any volunteers?In principle it is no problem to port the existing code to product-space functionality. The biggest thing is that we then would need a n-dimensional SmoothnessOperator. Any volunteers?https://gitlab.mpcdf.mpg.de/ift/nifty/-/issues/166MPI-enabled tests2017-07-29T11:50:06ZMartin ReineckeMPI-enabled testsMostly for fun, I enabled MPI nosetests in out continuous integration, and it seems that many tests actually continue to work!
But unfortunately I think I managed to freeze the test VM, so the pipeline is stuck now :(Mostly for fun, I enabled MPI nosetests in out continuous integration, and it seems that many tests actually continue to work!
But unfortunately I think I managed to freeze the test VM, so the pipeline is stuck now :(https://gitlab.mpcdf.mpg.de/ift/nifty/-/issues/167Field data types must be enforced consistently2017-08-15T08:05:09ZMartin ReineckeField data types must be enforced consistentlyI'm trying to debug the line searching algorithm and noticed that some of the input quantities have complex type.
This is not really acceptable, because there are no useful comparison operators defined for complex numbers, and the code ...I'm trying to debug the line searching algorithm and noticed that some of the input quantities have complex type.
This is not really acceptable, because there are no useful comparison operators defined for complex numbers, and the code does lots of comparisons. I don't understand why no exceptions are thrown; pure Python immediately complains if complex numbers are compared via <,>, etc., but numpy somehow doesn't.
We really need strict enforcement that search positions, gradients and energy values have real type.https://gitlab.mpcdf.mpg.de/ift/nifty/-/issues/168Bugs in line_search_strong_wolfe2017-08-16T12:25:13ZMartin ReineckeBugs in line_search_strong_wolfeThere are several strange "features" in the line search algorithm:
- if the _zoom procedure does not converge, the outer minimization loop repeats the (failing) _zoom search in identical fashion until it reaches its own iteration limit....There are several strange "features" in the line search algorithm:
- if the _zoom procedure does not converge, the outer minimization loop repeats the (failing) _zoom search in identical fashion until it reaches its own iteration limit. This can't be intentional.
- The Wolfe conditions look a bit different to the ones mentioned in Wikipedia.
Do we have a reference paper for this implementation?https://gitlab.mpcdf.mpg.de/ift/nifty/-/issues/169destroying distribution_strategy2017-07-26T08:27:00ZJakob Knollmuellerdestroying distribution_strategyHi,
I am currently trying to get my code running using the full capabilities of d2o, but some things in nifty seem to destroy the distribution_strategy, namely the InvertibleOperatorMixin and power_analyze (I tracked it down to the pind...Hi,
I am currently trying to get my code running using the full capabilities of d2o, but some things in nifty seem to destroy the distribution_strategy, namely the InvertibleOperatorMixin and power_analyze (I tracked it down to the pindex.bincount, see the example)
[minimal_example.py](/uploads/95bab8b0159517babf98330ce2a9ae5c/minimal_example.py)
Another problem is in the InvertibleOperatorMixin:
If no initial guess x0 is specified it is set to
x0 = Field(self.target, val=0., dtype=x.dtype)
setting the distribution to the default of "not" so the result also has this distribution, I would suggest setting
x0 = Field(self.target, val=0., dtype=x.dtype, distribution_strategy=x.distribution_strategy)
Jakobhttps://gitlab.mpcdf.mpg.de/ift/nifty/-/issues/170CriticalPowerEnergy has incomplete at() method2017-07-19T11:57:02ZMartin ReineckeCriticalPowerEnergy has incomplete at() methodThe `at()` method in `CriticalPowerEnergy` does not pass the `logarithmic` property to the newly built object, which results in a (potentially) different T inside that object.
What's the best solution to fix this? Store `logarithmic` ex...The `at()` method in `CriticalPowerEnergy` does not pass the `logarithmic` property to the newly built object, which results in a (potentially) different T inside that object.
What's the best solution to fix this? Store `logarithmic` explicitly to have it available in the `at()` method?
@kjako, any preferences?https://gitlab.mpcdf.mpg.de/ift/nifty/-/issues/171create_power_operator() returns operator with incorrect data type2017-08-15T08:17:02ZMartin Reineckecreate_power_operator() returns operator with incorrect data typeIf I understood the purpose of `create_power_operator()` correctly, it should produce a `DiagonalOperator` which imprints the supplied power spectrum onto a given field in harmonic space.
I would expect that this returned operator conta...If I understood the purpose of `create_power_operator()` correctly, it should produce a `DiagonalOperator` which imprints the supplied power spectrum onto a given field in harmonic space.
I would expect that this returned operator contains values of real type, but its data type is complex, even if I explicitly ask for real numbers:
```
from nifty import *
import numpy as np
s=RGSpace(10,harmonic=True)
def ps(x): return x
x=create_power_operator(s,ps,dtype=np.float64)
print x.diagonal().dtype
```
What am I missing?https://gitlab.mpcdf.mpg.de/ift/nifty/-/issues/172Overflow using lognormal2017-08-14T22:05:30ZMatevz, Sraml (sraml)Overflow using lognormalIn my project I use constantly lognormal model and since the normalization of the gradient in the SteepestDescent was removed I get overflow. I fix that with normalizing my gradient.
The overflow can be reproduced with this:
[test.py](...In my project I use constantly lognormal model and since the normalization of the gradient in the SteepestDescent was removed I get overflow. I fix that with normalizing my gradient.
The overflow can be reproduced with this:
[test.py](/uploads/5f5ce380ae65b699b5e350fd54ba8b18/test.py)https://gitlab.mpcdf.mpg.de/ift/nifty/-/issues/173Remove one of the WienerFilter demos2017-08-15T08:09:44ZPhilipp Arrasparras@mpa-garching.mpg.deRemove one of the WienerFilter demosWas ist der Unterschied zwischen den beiden Wiener Filter demos?
`demos/wiener_filter_via_curvature.py` macht Folgendes:
```
wiener_curvature = WienerFilterCurvature(S=S, N=N, R=R_harmonic)
m = wiener_curvature.inverse_times(j)
```
`de...Was ist der Unterschied zwischen den beiden Wiener Filter demos?
`demos/wiener_filter_via_curvature.py` macht Folgendes:
```
wiener_curvature = WienerFilterCurvature(S=S, N=N, R=R_harmonic)
m = wiener_curvature.inverse_times(j)
```
`demos/wiener_filter_via_hamiltonian.py` macht:
```
m0 = Field(h_space, val=.0)
energy = WienerFilterEnergy(position=m0, d=d, R=R, N=N, S=S, inverter=inverter)
D0 = energy.curvature
m0 = D0.inverse_times(j)
```
Soweit ich das verstehe, ist der einzige Unterschied zwischen den beiden Demos, dass bei der Zweiten eine Position und ein Invertierer definiert werden, die dann aber gar nicht verwendet werden (weil `energy.curvature` nur R, N und S braucht und keine Position).https://gitlab.mpcdf.mpg.de/ift/nifty/-/issues/174More zerocenter weirdness...2017-08-15T00:50:33ZMartin ReineckeMore zerocenter weirdness...```
from nifty import *
s=RGSpace(3,zerocenter=True)
f=Field(s,val=[0.,1.,2.])
op=FFTOperator(s)
print "op domain:", op.domain[0]
print "op target:", op.target[0]
print "op times real field", op.times(f).val
```
This prints
```
op doma...```
from nifty import *
s=RGSpace(3,zerocenter=True)
f=Field(s,val=[0.,1.,2.])
op=FFTOperator(s)
print "op domain:", op.domain[0]
print "op target:", op.target[0]
print "op times real field", op.times(f).val
```
This prints
```
op domain: RGSpace(shape=(3,), zerocenter=(True,), distances=(0.33333333333333331,), harmonic=False)
op target: RGSpace(shape=(3,), zerocenter=(True,), distances=(1.0,), harmonic=True)
op times real field [-0.33333333+0.j -0.16666667+0.8660254j 0.16666667+0.8660254j]
```
What I don't understand: if the target domain of the operator is zero-centered, why is the first value of the result real-only, and not the middle one?https://gitlab.mpcdf.mpg.de/ift/nifty/-/issues/175Indexing bug in Laplace operator2017-08-17T23:22:06ZMartin ReineckeIndexing bug in Laplace operatorI'm running the following test case on current master:
```
from nifty import *
s_space = RGSpace([256,256])
FFT = FFTOperator(s_space)
h_space = FFT.target[0]
p_space = PowerSpace(h_space, logarithmic=True, distribution_strategy='not')...I'm running the following test case on current master:
```
from nifty import *
s_space = RGSpace([256,256])
FFT = FFTOperator(s_space)
h_space = FFT.target[0]
p_space = PowerSpace(h_space, logarithmic=True, distribution_strategy='not')
t0 = Field(p_space, val=log(0.1/(1+p_space.kindex)**3))
sop = SmoothnessOperator(p_space)
#print t0.val.get_full_data()
print t0.vdot(sop(t0))
#print t0.val.get_full_data()
print t0.vdot(sop(t0))
```
This produces the output:
```
0.645594411887
139746.578501
```
which is definitely incorrect, since the same number should be reported twice.
Things become even weirder. If I remove the commenting "#" from the first print statement, I get:
```
[ -2.30258509 -4.38202663 -4.94670585 -5.75181152 -6.49001612
-7.17883085 -8.05624052 -8.99425111 -9.93125436 -10.87947582
-11.85503513 -12.85994974 -16.24599361]
2.93684941121
139746.578501
```
So the print statement changes the result of the next statement?!
Removing the next "#" as well produces:
```
[ -2.30258509 -4.38202663 -4.94670585 -5.75181152 -6.49001612
-7.17883085 -8.05624052 -8.99425111 -9.93125436 -10.87947582
-11.85503513 -12.85994974 -16.24599361]
2.93684941121
[ -2.30258509 -4.38202663 -4.94670585 -5.75181152 -6.49001612
-7.17883085 -8.05624052 -8.99425111 -9.93125436 -10.87947582
-11.85503513 -12.85994974 -16.24599361]
2.93684941121
```
First question: can anyone reproduce this, or is it a bug in my local Python installation?
If this is reproducible, it definitely needs to be fixed quickly, but I'm completely at my wits' end ...https://gitlab.mpcdf.mpg.de/ift/nifty/-/issues/176mpi crashes with power_analyze2017-08-14T22:04:56ZJakob Knollmuellermpi crashes with power_analyzeCalling power_analyze of a fftw distributed field crashes the mpirun. I attached a minimal example:
[minimal_example.py](/uploads/3253d1e327fb18e6ec1c6326779cea6f/minimal_example.py)
I run it with:
mpirun -n 2 python minimal_example.py ...Calling power_analyze of a fftw distributed field crashes the mpirun. I attached a minimal example:
[minimal_example.py](/uploads/3253d1e327fb18e6ec1c6326779cea6f/minimal_example.py)
I run it with:
mpirun -n 2 python minimal_example.py
and I get:
```
[MainThread][ERROR ] root Uncaught exception
Traceback (most recent call last):
File "minimal_example.py", line 22, in <module>
pp=sh.power_analyze()
File "/usr/local/lib/python2.7/dist-packages/ift_nifty-3.0.4-py2.7.egg/nifty/field.py", line 377, in power_analyze
for part in parts]
File "/usr/local/lib/python2.7/dist-packages/ift_nifty-3.0.4-py2.7.egg/nifty/field.py", line 413, in _single_power_analyze
axes=work_field.domain_axes[space_index])
File "/usr/local/lib/python2.7/dist-packages/ift_nifty-3.0.4-py2.7.egg/nifty/field.py", line 439, in _calculate_power_spectrum
axes=axes)
File "/usr/local/lib/python2.7/dist-packages/ift_nifty-3.0.4-py2.7.egg/nifty/field.py", line 469, in _shape_up_pindex
semiscaled_local_data = local_data.reshape(semiscaled_shape)
ValueError: cannot reshape array of size 131072 into shape (64,64,64)
-------------------------------------------------------
Primary job terminated normally, but 1 process returned
a non-zero exit code.. Per user-direction, the job has been aborted.
-------------------------------------------------------
--------------------------------------------------------------------------
mpirun detected that one or more processes exited with non-zero status, thus causing
the job to be terminated. The first process to do so was:
Process name: [[12289,1],0]
Exit code: 1
--------------------------------------------------------------------------
```https://gitlab.mpcdf.mpg.de/ift/nifty/-/issues/119tests for spaces2017-08-17T23:25:49ZReimar H Leiketests for spacesCreate more tests for all spaces. Especially tests for content are needed, that tests if the methods of spaces do what they should do on a numerical level.Create more tests for all spaces. Especially tests for content are needed, that tests if the methods of spaces do what they should do on a numerical level.