ift issueshttps://gitlab.mpcdf.mpg.de/groups/ift/-/issues2024-02-27T15:08:14Zhttps://gitlab.mpcdf.mpg.de/ift/nifty/-/issues/403NIFTy operator in NIFTy.re2024-02-27T15:08:14ZJakob RothNIFTy operator in NIFTy.reIn the classic NIFTy we have the `JaxOperator` interfacing classic nifty with jax. I don't think it was extensively used, but it was certainly handy for some projects.
The new version of jax_linop (https://github.com/NIFTy-PPL/jax_linop...In the classic NIFTy we have the `JaxOperator` interfacing classic nifty with jax. I don't think it was extensively used, but it was certainly handy for some projects.
The new version of jax_linop (https://github.com/NIFTy-PPL/jax_linop) now also supports binding nonlinear functions to jax. Thus we could also build the reverse binding a `NiftyOperator` which takes a classic NIFTy operator and returns a Jax primitive. Of course, this operator won't be as performant as a native Jax implementation, but I think this would still be very handy, especially for projects that transition their code base to Jax, since with such an operator, it would be possible to gradually move to Jax and keep some legacy nifty code in the beginning.
Once jax_linop is stable, I could implement such an operator. @pfrank @gedenhof, what do you thinkhttps://gitlab.mpcdf.mpg.de/ift/nifty/-/issues/401Implement Wiener Filter method2024-02-01T11:21:52ZGordian EdenhoferImplement Wiener Filter methodImplement a method solving the Wiener Filter for a given likelihood. As to generalize to non-Gaussian likelihoods, make it optionally depend on the position. This could be implement by simply wrapping `jft.draw_linear_residual`.Implement a method solving the Wiener Filter for a given likelihood. As to generalize to non-Gaussian likelihoods, make it optionally depend on the position. This could be implement by simply wrapping `jft.draw_linear_residual`.https://gitlab.mpcdf.mpg.de/ift/nifty/-/issues/398Use ducc0 in NIFTy.re when available2023-12-19T11:09:31ZGordian EdenhoferUse ducc0 in NIFTy.re when availableWrap ducc0 functionality using https://gitlab.mpcdf.mpg.de/jroth/extending-jax-and-nifty and use it by default for the Hartley transformation in the CFM.
Related to #371 .Wrap ducc0 functionality using https://gitlab.mpcdf.mpg.de/jroth/extending-jax-and-nifty and use it by default for the Hartley transformation in the CFM.
Related to #371 .Gordian EdenhoferGordian Edenhoferhttps://gitlab.mpcdf.mpg.de/ift/nifty/-/issues/392Testing of re.optimize_kl2023-11-23T22:00:28ZPhilipp FrankTesting of re.optimize_klCurrently the `re.optimize_kl` and `re.OptimizeVI` features remain largely untested. Only the demos ensure that `optimize_kl` runs through as intended for one specific configuration. We should at least add tests verifying that the differ...Currently the `re.optimize_kl` and `re.OptimizeVI` features remain largely untested. Only the demos ensure that `optimize_kl` runs through as intended for one specific configuration. We should at least add tests verifying that the different configurations produce the intended outcomes and that the update rules behave as expected.Philipp FrankPhilipp Frankhttps://gitlab.mpcdf.mpg.de/ift/nifty/-/issues/382RFC Make all convergence criteria per DOF2023-11-16T16:06:28ZGordian EdenhoferRFC Make all convergence criteria per DOFInstead of doing tricks like `absdelta = 1e-4 * jnp.prod(jnp.array(dims))`. Make all convergence criteria to be per degree of freedom in the parameter space. WDYT @pfrank @jroth ?Instead of doing tricks like `absdelta = 1e-4 * jnp.prod(jnp.array(dims))`. Make all convergence criteria to be per degree of freedom in the parameter space. WDYT @pfrank @jroth ?https://gitlab.mpcdf.mpg.de/ift/nifty/-/issues/381Implement LogNormal CF2024-02-06T11:48:29ZGordian EdenhoferImplement LogNormal CFImplement a thin wrapper around an exponentiated CFM which converts the desired statistics for exp(CF) to parameters for the "normal" CFM @pfrank @jroth .Implement a thin wrapper around an exponentiated CFM which converts the desired statistics for exp(CF) to parameters for the "normal" CFM @pfrank @jroth .https://gitlab.mpcdf.mpg.de/ift/nifty/-/issues/380RFC: Make offset a tuple of mean and std. in CF2023-11-17T14:14:17ZGordian EdenhoferRFC: Make offset a tuple of mean and std. in CFWDYT about making the `offset` parameter of the CFM a tuple of a mean and a standard deviation akin to all other parameters of the CFM? @pfrank @jroth @veberle @matteani
I imagine the implementation would look something like `A[0] = zm...WDYT about making the `offset` parameter of the CFM a tuple of a mean and a standard deviation akin to all other parameters of the CFM? @pfrank @jroth @veberle @matteani
I imagine the implementation would look something like `A[0] = zm_std; cf += zm_mean` with `A` the amplitude/power-spectrum and `cf` the correlated field realization, i.e. we would learn the zero-mode via the zeroth excitation. I am well aware that this is already feasible right now by specifying a custom zero-mode operator. My proposal is to make the zero-mode a scalar by default without custom code.https://gitlab.mpcdf.mpg.de/ift/nifty/-/issues/379Sunset jax_expr in numpy NIFTy2023-11-29T19:43:48ZGordian EdenhoferSunset jax_expr in numpy NIFTyI think it is fair to say that `Operator.jax_expr` never got that much traction. Furthermore, it is not the kind of model building that we want to encourage. @all WDYT about removing `jax_expr`s from NIFTy operators again? It was a nice ...I think it is fair to say that `Operator.jax_expr` never got that much traction. Furthermore, it is not the kind of model building that we want to encourage. @all WDYT about removing `jax_expr`s from NIFTy operators again? It was a nice idea when I started developing NIFTy.re but it turned out to be an ineffective aproach.https://gitlab.mpcdf.mpg.de/ift/nifty/-/issues/377? RFC: Incorporate the data into likelihoods in such a way that jitting does ...2023-12-07T15:26:19ZGordian Edenhofer? RFC: Incorporate the data into likelihoods in such a way that jitting does not inline them (e.g. insert them patially e.g. via `jax.tree_util.Partial` and special-case partials in likelihood)https://gitlab.mpcdf.mpg.de/ift/nifty/-/issues/376? RFC: Pull out the forward model of the likelihood into its own dedicated at...2023-11-09T12:48:11ZGordian Edenhofer? RFC: Pull out the forward model of the likelihood into its own dedicated attribute of the likelihoodhttps://gitlab.mpcdf.mpg.de/ift/nifty/-/issues/375Parametrize likelihoods s.t. all variables that could be filled in are filled...2023-11-09T12:47:36ZGordian EdenhoferParametrize likelihoods s.t. all variables that could be filled in are filled in by default, i.e. set the mean of the Gaussian likelihood to zero etc.https://gitlab.mpcdf.mpg.de/ift/nifty/-/issues/373Implement a JIT-compileable minimizer2023-11-09T12:41:47ZGordian EdenhoferImplement a JIT-compileable minimizerSee !875.See !875.https://gitlab.mpcdf.mpg.de/ift/nifty/-/issues/372Implement constants for minimization (and optimize_kl)2023-11-09T12:41:03ZGordian EdenhoferImplement constants for minimization (and optimize_kl)Implement constants for NIFTy.re, i.e. parts of the pytree that are potentially sampled but *NOT* optimized.Implement constants for NIFTy.re, i.e. parts of the pytree that are potentially sampled but *NOT* optimized.https://gitlab.mpcdf.mpg.de/ift/nifty/-/issues/371Implement HEALPix CF in NIFTy.re2023-12-19T11:09:31ZGordian EdenhoferImplement HEALPix CF in NIFTy.reImplement a power distributor for HEALPix spheres akin to `get_fourier_mode_distributor`. While at it, we should probably refactor the `domain` variable in `nifty.re.correlated_field` into a `namedtuple`.
* [ ] Implement CPU-only versio...Implement a power distributor for HEALPix spheres akin to `get_fourier_mode_distributor`. While at it, we should probably refactor the `domain` variable in `nifty.re.correlated_field` into a `namedtuple`.
* [ ] Implement CPU-only version by wrapping ducc
* [ ] ? Done / Bind external GPU versionhttps://gitlab.mpcdf.mpg.de/ift/nifty/-/issues/366Potential waste of MPI communicators2023-06-19T11:33:54ZMartin ReineckePotential waste of MPI communicators@kjako observed a "too many MPI communicators" error in a calculation. I think this is caused by the constructor of `SampleListBase`, which unconditionally creates a new communicator and stores it in `self._active_comm`. When either too ...@kjako observed a "too many MPI communicators" error in a calculation. I think this is caused by the constructor of `SampleListBase`, which unconditionally creates a new communicator and stores it in `self._active_comm`. When either too many sampe lists are generated, or if the garbage collector does not recycle them quickly enough, MPI will run out of comunicators (typical limits are 2048 or 4096).
I don't know a really good solution for this, but we may need a global communicator cache so that we don't recreate the "same" communicator over and over.https://gitlab.mpcdf.mpg.de/ift/nifty/-/issues/364Encoding error in _report_to_logger_and_file, when using Windows2023-04-20T09:44:54ZAndreas PoppEncoding error in _report_to_logger_and_file, when using WindowsUnicodeEncodeError: 'charmap' codec can't encode character '\u03c7' prompted, when executing my own code, but also when executing NIFTY demo files, where results are writen in seperate files.
Beneath is the error, when executing my own ...UnicodeEncodeError: 'charmap' codec can't encode character '\u03c7' prompted, when executing my own code, but also when executing NIFTY demo files, where results are writen in seperate files.
Beneath is the error, when executing my own file for further clarification:
![charmap_error_for_chi](/uploads/6cf13fcf7770e6fbc44527e198b0f227/charmap_error_for_chi.png)https://gitlab.mpcdf.mpg.de/ift/nifty/-/issues/362Optimize KL Bug [initial pos=None, dry_run=True, transition]2023-03-06T14:48:41ZVincent EberleOptimize KL Bug [initial pos=None, dry_run=True, transition]# Initial Position, dry_run, transition
The mean is set accordingly to the initial position.
If initial pos == `None` it is first generated as something living on a empty domain. @pfrank do you know why? As far as I understand it is emp...# Initial Position, dry_run, transition
The mean is set accordingly to the initial position.
If initial pos == `None` it is first generated as something living on a empty domain. @pfrank do you know why? As far as I understand it is empty because later this will be populated by `_normal_initialize`
```python
if initial_position is None:
mean = full(makeDomain({}), 0.)
else:
mean = initial_position
del(initial_position)
```
This mean is used to generate a `single_value_sample_list`: Which is then also EMPTY.
`sl = _single_value_sample_list(mean, comm=comm(initial_index))`
Then the mean is set to the mean of the previous iteration or to the _transition(sl). The mean keys missing in the initial multifield get populated by standard gaussian distributed variables (0.1 std). (so all here)
```python
t = transitions(iglobal)
mean = mean if t is None else t(sl)
mean = _normal_initialize(mean, lh.domain)
```
Later in the minimization the sample_list gets overwritten.
## Now the Problem:
If `dry_run==True` is used:
- Sampling is skipped
- Minimization is skipped
- overwriting Sample_list is skipped
This means we keep the old empty sample_list.
So, as soon as we set
- the initial_pos!= None an empty sample list is created
- and `dry_run==True` (which means, that the list sample_list stays empty)
- any transition which trys to do something with the sample is called(e.g. calling a key() of the dictionary/Multifield)
ADDITION:
It also fails if the transition starts at the 0 global it and not initial pos is given
You get an error (missing key).
My suggestion is to use the func
tion `_normal_initialize` right after setting the mean to an empty domain (or not doing this anyways)
so that the sample is not empty.
Something like this:
```python
if initial_position is None:
mean = full(makeDomain({}), 0.)
mean = _normal_initialize(mean, likelihood_energy(iglobal=0).domain)
else:
mean = initial_position
del(initial_position)
sl = _single_value_sample_list(mean, comm=comm(initial_index))
```
On the other hand this can be easily fixed by the user by setting the initial_pos.
But we should address this in the near future. (I can do it next week, but let me know what you think)
@pfrank @gedenhof @jroth @mtrPhilipp FrankPhilipp Frankhttps://gitlab.mpcdf.mpg.de/ift/nifty/-/issues/360Trying to fix the Hartley convention in ducc02024-02-29T12:55:06ZMartin ReineckeTrying to fix the Hartley convention in ducc0I have a bit of a philosophical problem and would be happy about your opinion:
Nifty makes heavy use of `ducc0`'s Hartley transform. Unfortunately this implementation of the transform has the bug (or convention issue) that it computes
...I have a bit of a philosophical problem and would be happy about your opinion:
Nifty makes heavy use of `ducc0`'s Hartley transform. Unfortunately this implementation of the transform has the bug (or convention issue) that it computes
`Hartley(x) = FFT(x).real + FFT(x).imag`
instead of the canonical
`Hartley(x) = FFT(x).real - FFT(x).imag`
which is mentioned, e.g., at https://en.wikipedia.org/wiki/Hartley_transform.
I would like to fix that at some point, but this could lead to subtle breakage in Nifty (e.g. if you store a Hartley-transformed field with a version of Nifty that uses an old `ducc` version and load it again with a Nifty that uses a newer one). Practically all "normal" uses of the Hartley transform will continue to work.
Do you have suggestions how to deal with this?
Alternatives are
- just change the behavior, saying this is a bug fix (which it technically is) and deal with potential breakage as it appears (it shold be minimal)
- change the behaviour and rename `ducc0` to `ducc1`; this is probably the cleanest approach, but maybe too much trouble for this change
- add new function names for the correct Hartley transforms and keep the old ones around for some time
- anything else?
@pfrank, @gedenhof, @jroth, @veberlehttps://gitlab.mpcdf.mpg.de/ift/nifty/-/issues/359ambiguous wording [save_strategy:"last" ]2023-02-02T14:18:11ZVincent Eberleambiguous wording [save_strategy:"last" ]# Suggestions for rewording
As this docstring can be misunderstood easily I'd propose to change "last" into "latest".
Otherwise one could think, that the samples are only saved at the very end.
```python
save_strategy : str
...# Suggestions for rewording
As this docstring can be misunderstood easily I'd propose to change "last" into "latest".
Otherwise one could think, that the samples are only saved at the very end.
```python
save_strategy : str
If "last", only the samples of the last global iteration are stored. If
"all", all intermediate samples are written to disk. `save_strategy` is
only applicable if `output_directory` is not None. Default: "last".
```
@gedenhof, @jroth, @pfrank what do you think?Vincent EberleVincent Eberlehttps://gitlab.mpcdf.mpg.de/ift/nifty/-/issues/350Optimize_kl: if save_strategy="last" and the number of samples decreases the ...2022-02-25T17:34:40ZPhilipp Arrasparras@mpa-garching.mpg.deOptimize_kl: if save_strategy="last" and the number of samples decreases the superfluous old samples are not deletedPhilipp Arrasparras@mpa-garching.mpg.dePhilipp Arrasparras@mpa-garching.mpg.de