ChangeLog 6.25 KB
 Martin Reinecke committed Dec 06, 2019 1 2 ``````Changes since NIFTy 5: `````` Martin Reinecke committed May 17, 2020 3 4 5 6 ``````Minimum Python version increased to 3.6 ======================================= `````` Martin Reinecke committed May 08, 2020 7 8 9 10 11 12 13 ``````FFT convention adjusted ======================= When going to harmonic space, NIFTy's FFT operator now uses a minus sign in the exponent (and, consequently, a plus sign on the adjoint transform). This convention is consistent with almost all other numerical FFT libraries. `````` Martin Reinecke committed Apr 26, 2020 14 15 16 ``````Interface change in EndomorphicOperator.draw_sample() ===================================================== `````` Philipp Arras committed May 14, 2020 17 ``````Both complex-valued and real-valued Gaussian probability distributions have `````` Martin Reinecke committed May 14, 2020 18 ``````Hermitian and positive endomorphisms as covariance. Just by looking at an `````` Philipp Arras committed May 14, 2020 19 20 21 22 23 24 ``````endomorphic operator itself it is not clear whether it is viewed as covariance for real or complex Gaussians when a sample of the respective distribution shall be drawn. Therefore, we introduce the method `draw_sample_with_dtype()` which needs to be given the data type of the probability distribution. This function is implemented for all operators which actually draw random numbers (`DiagonalOperator` and `ScalingOperator`). The class `SamplingDtypeSetter` acts `````` Martin Reinecke committed May 14, 2020 25 ``````as a wrapper for this kind of operators in order to fix the data type of the `````` Philipp Arras committed May 14, 2020 26 27 28 29 30 31 32 33 34 35 36 37 38 39 40 41 42 43 44 ``````distribution. Samples from these operators can be drawn with `.draw_sample()`. In order to dive into those subtleties I suggest running the following code and playing around with the dtypes. ``` import nifty6 as ift import numpy as np dom = ift.UnstructuredDomain(5) dtype = [np.float64, np.complex128][1] invcov = ift.ScalingOperator(dom, 3) e = ift.GaussianEnergy(mean=ift.from_random('normal', dom, dtype=dtype), inverse_covariance=invcov) pos = ift.from_random('normal', dom, dtype=np.complex128) lin = e(ift.Linearization.make_var(pos, want_metric=True)) met = lin.metric print(met) print(met.draw_sample()) ``` `````` Martin Reinecke committed Apr 26, 2020 45 `````` `````` Philipp Arras committed Mar 23, 2020 46 47 48 49 50 51 ``````MPI parallelisation over samples in MetricGaussianKL ==================================================== The classes `MetricGaussianKL` and `MetricGaussianKL_MPI` have been unified into one `MetricGaussianKL` class which has MPI support built in. `````` Martin Reinecke committed Mar 23, 2020 52 53 54 55 56 57 58 59 60 ``````New approach for random number generation ========================================= The code now uses `numpy`'s new `SeedSequence` and `Generator` classes for the production of random numbers (introduced in numpy 1.17. This greatly simplifies the generation of reproducible random numbers in the presence of MPI parallelism and leads to cleaner code overall. Please see the documentation of `nifty6.random` for details. `````` Philipp Arras committed Mar 11, 2020 61 62 63 64 65 66 67 68 69 70 71 72 73 74 75 76 77 ``````Interface Change for non-linear Operators ========================================= The method `Operator.apply()` takes a `Linearization` or a `Field` or a `MultiField` as input. This has not changed. However, now each non-linear operator assumes that the input `Linearization` comes with an identity operator as jacobian. Also it is assumed that the `apply()` method returns a `Linearization` with the jacobian of the operator itself. The user is not in charge anymore of stacking together the jacobians of operator chains. Something like `x.jac` should not appear in any self-written `apply()` methods. The method `Operator._check_input` tests if this condition is met. The same goes for the metric. There is no need anymore to call `SandwichOperator` in an `apply()` method when implementing new energies. This change should not lead to unexpected behaviour since both `Operator._check_input()` and `extra.check_jacobian_consistency()` tests for the new conditions to be fulfilled. `````` Martin Reinecke committed Mar 11, 2020 78 79 80 81 82 83 84 85 86 87 88 89 ``````Special functions for complete Field reduction operations ========================================================= So far, reduction operations called on Fields (like `vdot`, `sum`, `integrate`, `mean`, `var`, `std`, `prod` etc.) returned a scalar when the reduction was carried out over all domains, and otherwise a `Field`. Having the data type of the returned value depend on input parameters is extremely confusing, so all of these reduction operations now always return a Field. We also introduced another set of reduction operations which always operate over all subdomains and therefore don't take a `spaces` argument; they are named `s_vdot`, `s_sum` etc. and always return a scalar. `````` Philipp Arras committed Dec 06, 2019 90 91 92 93 94 95 96 97 98 99 100 101 102 103 104 105 ``````Updates regarding correlated fields =================================== The most commonly used model for homogeneous and isotropic correlated fields in nifty5 has been `SLAmplitude` combined with `CorrelatedField`. This model exhibits unintuitive couplings between its parameters and as been replaced by `CorrelatedFieldMaker` in NIFTy 6. This model aims to conceptionally provide the same functionality. However, internally it works quite differently. Therefore, specific classes for `SLAmplitude` like `LogRGSpace`, `QHTOperator`, `ExpTransform`, `SlopeOperator`, `SymmetrizingOperator`, `CepstrumOperator`, `CorrelatedField` and `MfCorrelatedField` are not needed anymore and have been removed. In general, `CorrelatedFieldMaker` feels to be better conditioned leading to faster convergence but it is hard to make explicit tests since the two approaches cannot be mapped onto each other exactly. We experienced that preconditioning in the `MetricGaussianKL` via `napprox` breaks the inference scheme with the new model so `napprox` may not be used here. `````` Martin Reinecke committed Dec 06, 2019 106 `````` `````` Lukas Platz committed Dec 06, 2019 107 108 ``````Removal of the standard MPI parallelization scheme: =================================================== `````` Martin Reinecke committed Dec 06, 2019 109 110 111 112 113 114 115 116 117 118 119 120 121 122 123 124 125 `````` When several MPI tasks are present, NIFTy5 distributes every Field over these tasks by splitting it along the first axis. This approach to parallelism is not very efficient, and it has not been used by anyone for several years, so we decided to remove it, which led to many simplifications within NIFTy. User-visible changes: - the methods `to_global_data`, `from_global_data`, `from_local_data` and the property `local_data` have been removed from `Field` and `MultiField`. Instead there are now the property `val` (returning a read-only numpy.ndarray for `Field` and a dictionary of read-only numpy.ndarrays for `MultiField`) and the method `val_rw()` (returning the same structures with writable copies of the arrays). Fields and MultiFields can be created from such structures using the static method `from_raw` - the functions `from_global_data` and `from_local_data` in `sugar` have been replaced by a single function called `makeField` - the property `local_shape` has been removed from `Domain` (and subclasses) and `DomainTuple`.``````