ift issueshttps://gitlab.mpcdf.mpg.de/groups/ift/-/issues2020-05-13T11:23:26Zhttps://gitlab.mpcdf.mpg.de/ift/nifty/-/issues/294Potential confusion in the direction of FFTs2020-05-13T11:23:26ZMartin ReineckePotential confusion in the direction of FFTsIn the current implementation of FFTOperator (https://gitlab.mpcdf.mpg.de/ift/nifty/-/blob/NIFTy_6/nifty6/operators/harmonic_operators.py#L76) we have the code:
```
if x.domain[self._space].harmonic: # harmonic -> position
func = fft.fftn
fct = 1.
else:
func = fft.ifftn
fct = ncells
```
where `x` is the input field.
This looks exactly the wrong way around.
@parras, @pfrank, @kjako, @reimar, @veberle, what do you think?
Switching the FFT direction breaks almost none of our tests (only one, which already has a FIXME :).In the current implementation of FFTOperator (https://gitlab.mpcdf.mpg.de/ift/nifty/-/blob/NIFTy_6/nifty6/operators/harmonic_operators.py#L76) we have the code:
```
if x.domain[self._space].harmonic: # harmonic -> position
func = fft.fftn
fct = 1.
else:
func = fft.ifftn
fct = ncells
```
where `x` is the input field.
This looks exactly the wrong way around.
@parras, @pfrank, @kjako, @reimar, @veberle, what do you think?
Switching the FFT direction breaks almost none of our tests (only one, which already has a FIXME :).2020-05-13https://gitlab.mpcdf.mpg.de/ift/nifty/-/issues/296Releasing NIFTy 6?2020-05-22T07:46:13ZMartin ReineckeReleasing NIFTy 6?I have the impression that we have enough new features to justify a NIFTy 6 release.
Does anyone have feature suggestions which should go into the code before the release?I have the impression that we have enough new features to justify a NIFTy 6 release.
Does anyone have feature suggestions which should go into the code before the release?https://gitlab.mpcdf.mpg.de/ift/nifty/-/issues/283Reduce licensing boilerplate2020-05-13T11:36:01ZGordian EdenhoferReduce licensing boilerplateIf we really feel the need to put licensing boilerplate in every source file, let's at least make it concise by e.g. using https://spdx.org/ids.If we really feel the need to put licensing boilerplate in every source file, let's at least make it concise by e.g. using https://spdx.org/ids.https://gitlab.mpcdf.mpg.de/ift/nifty/-/issues/299Add possibility to log energies2020-05-19T12:51:06ZPhilipp Arrasparras@mpa-garching.mpg.deAdd possibility to log energiesI have implemented a method to log energies inside a IterationController such that they can be analyzed afterwards. @mtr how do you like this implementation? Do you think we could/should make this part of nifty? Or do you have other ideas how to approach the problem?
https://gitlab.mpcdf.mpg.de/ift/papers/rickandresolve/-/commit/8b0e15dc4a533dfba17f29361345309e336dfb8a
(Since this is part of an unpublished project, this link is only visible for ift group members. Sorry!)
@veberle @mtrI have implemented a method to log energies inside a IterationController such that they can be analyzed afterwards. @mtr how do you like this implementation? Do you think we could/should make this part of nifty? Or do you have other ideas how to approach the problem?
https://gitlab.mpcdf.mpg.de/ift/papers/rickandresolve/-/commit/8b0e15dc4a533dfba17f29361345309e336dfb8a
(Since this is part of an unpublished project, this link is only visible for ift group members. Sorry!)
@veberle @mtrhttps://gitlab.mpcdf.mpg.de/ift/nifty/-/issues/290Data types for the Grand Unification2020-04-08T18:20:48ZMartin ReineckeData types for the Grand Unification```
Space:
structured or unstructured set of points (current NIFTy's "Domain")
SpaceTuple:
external product of zero or more Spaces (current NIFTy's "DomainTuple")
SpaceTuple = (Space, Space, ...)
SpaceTupleDict:
dictionary (with string keys) of one or more SpaceTuples
SpaceTupleDict = {name1: SpaceTuple1, name2: SpaceTuple2, ...}
(current NIFTy's "MultiDomain")
Domain:
This is an abstract concept. Can currently be represented by SpaceTuple or SpaceTupleDict
Special domains:
ScalarDomain: empty SpaceTuple
Operator:
- Operators take an Operand defined on an input domain, transform it in some way
and return a new Operand defined on a (possibly different) target domain.
- Operators can be concatenated, as long as the domains at the interface are
identical. The result is another Operator.
Operand:
- Operand objects represent fields and potentially their Jacobians and metrics.
- an Operand object can be asked for its "value" and (if configured accordingly)
its Jacobian. If the target domain of an Operand object is scalar, a metric
may also be available.
- Applying an Operator to an Operand object will always return another Operand object.
class Operator(object):
@property
def domain(self):
# return input domain
@property
def target(self):
# return output domain
def __call__(self, other):
# if isinstance(other, Operand) return an Operand object
# else return an Operator object
def __matmul__(self, other):
return self(other)
class LinearOperator(Operator):
# more or less analogous to the current LinearOperator
class Operand(object):
# this unifies current NIFTy's Field, MultiField, and Linearization classes
@property
def domain(self):
# if no Jacobian is present, return None, else the Jacobian's domain.
@property
def target(self):
# return the domain on which the value of the Operand is defined. This is
# also the Jacobian's target (if a Jacobian is defined)
@property
def val(self):
# return a low level data structure holding the actual values (currently numpy.ndarray
# or dictionary of numpy.ndarrays. Read-only.
def val_rw(self):
# return a writeable copy of `val`
def fld(self):
# return am Operand that only contains the value content of this object. Its Jacobian and
# potential higher derivatives will be `None`.
@property
def jac(self):
return a Jacobian LinearOperator if possible, else None
@property
def want_metric(self):
return True or False
@property
def metric(self):
if self.jacobian is None, raise an exception
if self.target is not ScalarDomain, raise an exception
if not self.want_metric, raise an exception
if metric cannot be computed, raise an exception
return metric
```
```
Space:
structured or unstructured set of points (current NIFTy's "Domain")
SpaceTuple:
external product of zero or more Spaces (current NIFTy's "DomainTuple")
SpaceTuple = (Space, Space, ...)
SpaceTupleDict:
dictionary (with string keys) of one or more SpaceTuples
SpaceTupleDict = {name1: SpaceTuple1, name2: SpaceTuple2, ...}
(current NIFTy's "MultiDomain")
Domain:
This is an abstract concept. Can currently be represented by SpaceTuple or SpaceTupleDict
Special domains:
ScalarDomain: empty SpaceTuple
Operator:
- Operators take an Operand defined on an input domain, transform it in some way
and return a new Operand defined on a (possibly different) target domain.
- Operators can be concatenated, as long as the domains at the interface are
identical. The result is another Operator.
Operand:
- Operand objects represent fields and potentially their Jacobians and metrics.
- an Operand object can be asked for its "value" and (if configured accordingly)
its Jacobian. If the target domain of an Operand object is scalar, a metric
may also be available.
- Applying an Operator to an Operand object will always return another Operand object.
class Operator(object):
@property
def domain(self):
# return input domain
@property
def target(self):
# return output domain
def __call__(self, other):
# if isinstance(other, Operand) return an Operand object
# else return an Operator object
def __matmul__(self, other):
return self(other)
class LinearOperator(Operator):
# more or less analogous to the current LinearOperator
class Operand(object):
# this unifies current NIFTy's Field, MultiField, and Linearization classes
@property
def domain(self):
# if no Jacobian is present, return None, else the Jacobian's domain.
@property
def target(self):
# return the domain on which the value of the Operand is defined. This is
# also the Jacobian's target (if a Jacobian is defined)
@property
def val(self):
# return a low level data structure holding the actual values (currently numpy.ndarray
# or dictionary of numpy.ndarrays. Read-only.
def val_rw(self):
# return a writeable copy of `val`
def fld(self):
# return am Operand that only contains the value content of this object. Its Jacobian and
# potential higher derivatives will be `None`.
@property
def jac(self):
return a Jacobian LinearOperator if possible, else None
@property
def want_metric(self):
return True or False
@property
def metric(self):
if self.jacobian is None, raise an exception
if self.target is not ScalarDomain, raise an exception
if not self.want_metric, raise an exception
if metric cannot be computed, raise an exception
return metric
```
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 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.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/250[post Nifty6] new design for the `Field` class?2019-12-02T20:58:52ZMartin Reinecke[post Nifty6] new design for the `Field` class?I'm wondering whether we can solve most of our current problems regarding fields and multifields by introducing a single new `Field` class that
- unifies the current `Field` and `MultiField` classes (a classic field would have a single dictionary entry with an empty string as name)
- is immutable
- can contain scalars or array-like objects to describe field content (maybe even functions?)
If we have such a class we can again demand that all operations on fields require identical domains, and we can still avoid writing huge zero-filled arrays by writing scalar zeros instead.
@reimar, @kjako, @parras please let me know what you think.I'm wondering whether we can solve most of our current problems regarding fields and multifields by introducing a single new `Field` class that
- unifies the current `Field` and `MultiField` classes (a classic field would have a single dictionary entry with an empty string as name)
- is immutable
- can contain scalars or array-like objects to describe field content (maybe even functions?)
If we have such a class we can again demand that all operations on fields require identical domains, and we can still avoid writing huge zero-filled arrays by writing scalar zeros instead.
@reimar, @kjako, @parras please let me know what you think.https://gitlab.mpcdf.mpg.de/ift/nifty/-/issues/337Possible error in assert_equal and assert_allclose for MultiFields2021-09-24T08:03:42ZPhilipp FrankPossible error in assert_equal and assert_allclose for MultiFieldsIn their current form, both methods `assert_equal` and `assert_allclose` only perform a one sided test for `MultiFields`. This leads to some unexpected behaviour when comparing two Fields which are only equal one some sub-domain. In particular the following test
```
import nifty8 as ift
d = ift.RGSpace(10)
d = ift.MultiDomain.make({'a' : d, 'b' : d})
f = ift.from_random(d)
fp = f.extract_by_keys(['a',])
ift.extra.assert_equal(fp, f)
```
will pass, but
```
ift.extra.assert_equal(f, fp)
```
produces an error, as only the keys of the first input are looped over. The same goes for `assert_allclose`.
This does not look like an intended behaviour to me. @mtr, @parras, am I missing something here?In their current form, both methods `assert_equal` and `assert_allclose` only perform a one sided test for `MultiFields`. This leads to some unexpected behaviour when comparing two Fields which are only equal one some sub-domain. In particular the following test
```
import nifty8 as ift
d = ift.RGSpace(10)
d = ift.MultiDomain.make({'a' : d, 'b' : d})
f = ift.from_random(d)
fp = f.extract_by_keys(['a',])
ift.extra.assert_equal(fp, f)
```
will pass, but
```
ift.extra.assert_equal(f, fp)
```
produces an error, as only the keys of the first input are looped over. The same goes for `assert_allclose`.
This does not look like an intended behaviour to me. @mtr, @parras, am I missing something here?https://gitlab.mpcdf.mpg.de/ift/resolve/-/issues/2Bug: calibrator flux is probably computed incorrectly (log10 vs ln vs log2)2021-09-08T11:14:27ZPhilipp Arrasparras@mpa-garching.mpg.deBug: calibrator flux is probably computed incorrectly (log10 vs ln vs log2)Connected to https://github.com/caracal-pipeline/caracal/issues/1354Connected to https://github.com/caracal-pipeline/caracal/issues/1354https://gitlab.mpcdf.mpg.de/ift/nifty/-/issues/336Sampling dtypes in sandwich operators2021-09-22T08:26:46ZPhilipp Arrasparras@mpa-garching.mpg.deSampling dtypes in sandwich operatorsI think (but I am not sure), that it is relatively important to fix the FIXME that @pfrank has put here:
https://gitlab.mpcdf.mpg.de/ift/nifty/-/blob/NIFTy_8/src/operators/sandwich_operator.py#L77I think (but I am not sure), that it is relatively important to fix the FIXME that @pfrank has put here:
https://gitlab.mpcdf.mpg.de/ift/nifty/-/blob/NIFTy_8/src/operators/sandwich_operator.py#L77https://gitlab.mpcdf.mpg.de/ift/nifty/-/issues/335CorrelatedFieldMaker amplitude normalization breaks fluctuation amplitude2021-08-24T10:52:00ZLukas PlatzCorrelatedFieldMaker amplitude normalization breaks fluctuation amplitudeIf one adds more than one amplitude operator to a `CorrelatedFieldMaker` and sets a very small/large offset standard deviation, the field fluctuation amplitude gets distorted.
This is because in `get_normalized_amplitudes()` every amplitude operator gets devided by `self.azm` and the results of this function are then multiplied with an outer product to create the joint amplitude operator.
In CFs with more than one amplitude operator, this results in the joint amplitude operator being divided by multiples of the zeromode operator and thus an incorrect output scaling behavior.
To demonstrate this effect, I created correlated field operators for identical 2d fields, but one with a single amplitude operator for `ift.RGSpace((N, N)` and one with two amplitude operators on `ift.RGSpace(N)`. From top to bottom, I varied the `offset std` setting passed to `set_amplitude_total_offset()` and in each case plotted a histogram of the sampled fields' standard deviation.
![output](/uploads/6779601e231148c36a77a91aa8e7fd62/bug.png)
One can clearly see the output fluctuation amplitude is independant from the `offset_std` for the 'single' case, as it should be, but not for the 'dual' case.
A fix for this is proposed in merge requests !669 and !670.
To reproduce, run the following code:
```
import nifty7 as ift
import matplotlib.pyplot as plt
fluct_pars = {
'fluctuations': (1.0, 0.1),
'flexibility': None,
'asperity': None,
'loglogavgslope': (-2.0, 0.2),
'prefix': 'flucts_',
'dofdex': None
}
n_offsets = 5
n_samples = 1000
dom_single = ift.RGSpace((25, 25))
dom_dual = ift.RGSpace(25)
fig, axs = plt.subplots(nrows=n_offsets, ncols=2, figsize=(12, 4 * n_offsets))
for i in range(n_offsets):
cfmaker_single = ift.CorrelatedFieldMaker(prefix='str(i)_')
cfmaker_dual = ift.CorrelatedFieldMaker(prefix='str(i)_')
cfmaker_single.add_fluctuations(dom_single, **fluct_pars)
cfmaker_dual.add_fluctuations(dom_dual, **fluct_pars)
cfmaker_dual.add_fluctuations(dom_dual, **fluct_pars)
offset_std = 10 ** -i
zm_pars = {'offset_mean': 0.,
'offset_std': (offset_std, offset_std / 10.)}
cfmaker_single.set_amplitude_total_offset(**zm_pars)
cfmaker_dual.set_amplitude_total_offset(**zm_pars)
cf_single = cfmaker_single.finalize(prior_info=0)
cf_dual = cfmaker_dual.finalize(prior_info=0)
samples_single = [cf_single(ift.from_random(cf_single.domain)).val.std() for _ in range(n_samples)]
samples_dual = [cf_dual(ift.from_random(cf_dual.domain)).val.std() for _ in range(n_samples)]
_ = axs[i, 0].hist(samples_single, bins=20, density=True)
_ = axs[i, 1].hist(samples_dual, bins=20, density=True)
axs[i, 0].set_title(f'offset_std = {offset_std:1.0e}, single')
axs[i, 1].set_title(f'offset_std = {offset_std:1.0e}, dual')
axs[i, 0].set_xlabel('sample std')
axs[i, 1].set_xlabel('sample std')
plt.tight_layout()
plt.show()
```
Any comments?If one adds more than one amplitude operator to a `CorrelatedFieldMaker` and sets a very small/large offset standard deviation, the field fluctuation amplitude gets distorted.
This is because in `get_normalized_amplitudes()` every amplitude operator gets devided by `self.azm` and the results of this function are then multiplied with an outer product to create the joint amplitude operator.
In CFs with more than one amplitude operator, this results in the joint amplitude operator being divided by multiples of the zeromode operator and thus an incorrect output scaling behavior.
To demonstrate this effect, I created correlated field operators for identical 2d fields, but one with a single amplitude operator for `ift.RGSpace((N, N)` and one with two amplitude operators on `ift.RGSpace(N)`. From top to bottom, I varied the `offset std` setting passed to `set_amplitude_total_offset()` and in each case plotted a histogram of the sampled fields' standard deviation.
![output](/uploads/6779601e231148c36a77a91aa8e7fd62/bug.png)
One can clearly see the output fluctuation amplitude is independant from the `offset_std` for the 'single' case, as it should be, but not for the 'dual' case.
A fix for this is proposed in merge requests !669 and !670.
To reproduce, run the following code:
```
import nifty7 as ift
import matplotlib.pyplot as plt
fluct_pars = {
'fluctuations': (1.0, 0.1),
'flexibility': None,
'asperity': None,
'loglogavgslope': (-2.0, 0.2),
'prefix': 'flucts_',
'dofdex': None
}
n_offsets = 5
n_samples = 1000
dom_single = ift.RGSpace((25, 25))
dom_dual = ift.RGSpace(25)
fig, axs = plt.subplots(nrows=n_offsets, ncols=2, figsize=(12, 4 * n_offsets))
for i in range(n_offsets):
cfmaker_single = ift.CorrelatedFieldMaker(prefix='str(i)_')
cfmaker_dual = ift.CorrelatedFieldMaker(prefix='str(i)_')
cfmaker_single.add_fluctuations(dom_single, **fluct_pars)
cfmaker_dual.add_fluctuations(dom_dual, **fluct_pars)
cfmaker_dual.add_fluctuations(dom_dual, **fluct_pars)
offset_std = 10 ** -i
zm_pars = {'offset_mean': 0.,
'offset_std': (offset_std, offset_std / 10.)}
cfmaker_single.set_amplitude_total_offset(**zm_pars)
cfmaker_dual.set_amplitude_total_offset(**zm_pars)
cf_single = cfmaker_single.finalize(prior_info=0)
cf_dual = cfmaker_dual.finalize(prior_info=0)
samples_single = [cf_single(ift.from_random(cf_single.domain)).val.std() for _ in range(n_samples)]
samples_dual = [cf_dual(ift.from_random(cf_dual.domain)).val.std() for _ in range(n_samples)]
_ = axs[i, 0].hist(samples_single, bins=20, density=True)
_ = axs[i, 1].hist(samples_dual, bins=20, density=True)
axs[i, 0].set_title(f'offset_std = {offset_std:1.0e}, single')
axs[i, 1].set_title(f'offset_std = {offset_std:1.0e}, dual')
axs[i, 0].set_xlabel('sample std')
axs[i, 1].set_xlabel('sample std')
plt.tight_layout()
plt.show()
```
Any comments?https://gitlab.mpcdf.mpg.de/ift/nifty/-/issues/334`MetricGaussianKL` changed its interface (there is not `.make`) but there is ...2021-07-01T15:34:54ZGordian Edenhofer`MetricGaussianKL` changed its interface (there is not `.make`) but there is no corresponding changelog entryhttps://gitlab.mpcdf.mpg.de/ift/resolve/-/issues/1Implement uniform weighting2021-06-30T17:12:22ZPhilipp Arrasparras@mpa-garching.mpg.deImplement uniform weightinghttps://gitlab.mpcdf.mpg.de/ift/nifty/-/issues/333New feature: Add flag to minisanity that disables terminal colors2021-08-05T12:39:13ZPhilipp Arrasparras@mpa-garching.mpg.deNew feature: Add flag to minisanity that disables terminal colorsPhilipp Arrasparras@mpa-garching.mpg.dePhilipp Arrasparras@mpa-garching.mpg.dehttps://gitlab.mpcdf.mpg.de/ift/nifty/-/issues/332Rename `Likelihood` -> `LogLikelihood`2021-06-10T10:44:36ZPhilipp Arrasparras@mpa-garching.mpg.deRename `Likelihood` -> `LogLikelihood`NIFTy7 releasehttps://gitlab.mpcdf.mpg.de/ift/nifty/-/issues/331Build html coverage report of both release and develop branch2021-06-09T15:51:21ZPhilipp Arrasparras@mpa-garching.mpg.deBuild html coverage report of both release and develop branchNIFTy7 releasehttps://gitlab.mpcdf.mpg.de/ift/nifty/-/issues/330Write guide how to define custom non-linearities2021-06-10T11:39:25ZPhilipp Arrasparras@mpa-garching.mpg.deWrite guide how to define custom non-linearitiesNIFTy7 releasehttps://gitlab.mpcdf.mpg.de/ift/nifty/-/issues/329Performance check (in ift.check_operator) broken for BernoulliEnergy2021-06-07T10:42:14ZLukas PlatzPerformance check (in ift.check_operator) broken for BernoulliEnergyThe operator performance check introduced in [`a50ec021`](https://gitlab.mpcdf.mpg.de/ift/nifty/-/commit/a50ec021e457dc8f4e199c6331c67167eec0fdb7) changes the operator test position [by a factor of two](https://gitlab.mpcdf.mpg.de/ift/nifty/-/blob/a50ec021e457dc8f4e199c6331c67167eec0fdb7/nifty6/extra.py#L146) for the 'application to a linearization' test. This breaks the test for the `BernoulliEnergy`, as it creates input values outside the interval of `[0, 1)`.
@reimar, since you coded this function: does the factor of two serve a valuable purpose, or can we safely delete it?The operator performance check introduced in [`a50ec021`](https://gitlab.mpcdf.mpg.de/ift/nifty/-/commit/a50ec021e457dc8f4e199c6331c67167eec0fdb7) changes the operator test position [by a factor of two](https://gitlab.mpcdf.mpg.de/ift/nifty/-/blob/a50ec021e457dc8f4e199c6331c67167eec0fdb7/nifty6/extra.py#L146) for the 'application to a linearization' test. This breaks the test for the `BernoulliEnergy`, as it creates input values outside the interval of `[0, 1)`.
@reimar, since you coded this function: does the factor of two serve a valuable purpose, or can we safely delete it?NIFTy7 releasehttps://gitlab.mpcdf.mpg.de/ift/nifty/-/issues/328What is the correct gradient at zero for `pointwise.unit_step`?2021-08-16T16:58:38ZLukas PlatzWhat is the correct gradient at zero for `pointwise.unit_step`?I just noticed that the gradient of the pointwise function `unit_step` [is set to be always zero](https://gitlab.mpcdf.mpg.de/ift/nifty/-/blob/4772fce8b032135e39702ffb4b52b33f5deefe20/src/pointwise.py#L91).
Is that correct, or should we return `np.nan` if the input is exactly zero, like for examples `sign` [does](https://gitlab.mpcdf.mpg.de/ift/nifty/-/blob/4772fce8b032135e39702ffb4b52b33f5deefe20/src/pointwise.py#L67)?I just noticed that the gradient of the pointwise function `unit_step` [is set to be always zero](https://gitlab.mpcdf.mpg.de/ift/nifty/-/blob/4772fce8b032135e39702ffb4b52b33f5deefe20/src/pointwise.py#L91).
Is that correct, or should we return `np.nan` if the input is exactly zero, like for examples `sign` [does](https://gitlab.mpcdf.mpg.de/ift/nifty/-/blob/4772fce8b032135e39702ffb4b52b33f5deefe20/src/pointwise.py#L67)?https://gitlab.mpcdf.mpg.de/ift/nifty/-/issues/327Improvement: Simplify for const could be more potent2021-05-30T17:20:04ZPhilipp Arrasparras@mpa-garching.mpg.deImprovement: Simplify for const could be more potentThe following script demonstrates that the `simplify_for_const` machinery is not able to efficiently deal with partially constant `MultiField`s.
```python
import nifty7 as ift
import numpy as np
dom = ift.RGSpace(10)
e = ift.VariableCovarianceGaussianEnergy(dom, "a", "b", np.float64)
fa = ift.FieldAdapter(dom, "a")
fb = ift.FieldAdapter(dom, "b")
e1 = e(fa.adjoint@fa + fb.adjoint@fb)
print(e1)
inp = ift.from_random(fa.domain)
print(e1.simplify_for_constant_input(inp))
```The following script demonstrates that the `simplify_for_const` machinery is not able to efficiently deal with partially constant `MultiField`s.
```python
import nifty7 as ift
import numpy as np
dom = ift.RGSpace(10)
e = ift.VariableCovarianceGaussianEnergy(dom, "a", "b", np.float64)
fa = ift.FieldAdapter(dom, "a")
fb = ift.FieldAdapter(dom, "b")
e1 = e(fa.adjoint@fa + fb.adjoint@fb)
print(e1)
inp = ift.from_random(fa.domain)
print(e1.simplify_for_constant_input(inp))
```