Convolution

[henrikjacobsenfys]

Implements convolution of SampleModels and Components with each other, including detailed balancing. The code is based on the SampleModel branch, not develop.

I have very extensive tests of the convolutions. Many of them were written a long time ago, and so they can probably be improved. However, before doing that, a review of the main code would be very useful.

[henrikjacobsenfys]

Sigh, fine, offset doesn't have to live in Convolution. Removing it will be cleaner.

[henrikjacobsenfys]

There is one potential issue: if users add components to the sample model it doesn't update correctly. e.g.

sample_model=SampleModel()
conv=Convolution(sample_model=sample_model)
conv.sample_model.add_component(Gaussian(...))

Not sure if and how to tackle this. The "correct" way to do it is to do

sample_model.add_component(...)
conv.sample_model=sample_model

[rozyczko]

A few minor issues raised

[rozyczko]

The error message says must be a SampleModel or ModelComponent but the validation only checks for SampleModel. This will reject valid ModelComponent instances

[henrikjacobsenfys]

Whoops

[rozyczko]

Does np.zeros_like work with scipp's sc.Variable here?

[henrikjacobsenfys]

It seemed to work, but changed it to self.energy.values, since self.energy should always be a sc.Variable

[rozyczko]

_build_convolution_plan() sets self._convolution_plan_is_valid = True and calls self._set_convolvers().
If any of those operations set an attribute in _invalidate_plan_on_change, this could cause unexpected re-triggering. The commented-out line suggests this was a concern.

Consider using a guard

def __setattr__(self, name, value):
    super().__setattr__(name, value)
    if (
        getattr(self, "_reactions_enabled", False)
        and name in self._invalidate_plan_on_change
        and not getattr(self, "_building_plan", False)
    ):
        self._building_plan = True
        try:
            self._build_convolution_plan()
        finally:
            self._building_plan = False

[henrikjacobsenfys]

Whoops, this was not quite right. This is also the part of the code that is most likely to need changing. The point is that the convolution plan needs to update if things change, e.g. if the sample model or energy change. However, it's a mess if this happens during init, hence the _reactions_enabled. I may want a brief chat about possible better solutions to this. For now, I've updated the code to do what I actually wanted it to do.

[rozyczko]

Will energy_sense always have at least 2 elements? Maybe check the length

[henrikjacobsenfys]

Huh good point. Although if people don't use enough points there is no guarantee that the convolution will give the correct results

[rozyczko]

The docstring mentions resolution_component but the parameter is resolution_model. Also, the first parameter is clearly a DeltaFunction (expected type), not a general ModelComponent.

[henrikjacobsenfys]

Whoops, too much copy/paste

[rozyczko]

Consider moving these constants to class-level constants for easier configuration and testing.

[henrikjacobsenfys]

Good point

[damskii9992]

There is one potential issue: if users add components to the sample model it doesn't update correctly. e.g.

sample_model=SampleModel()
conv=Convolution(sample_model=sample_model)
conv.sample_model.add_component(Gaussian(...))

Not sure if and how to tackle this. The "correct" way to do it is to do

sample_model.add_component(...)
conv.sample_model=sample_model

Just disable the sample_model attribute getter on the Convolution? Then users can't do conv.sample_model, effectively getting rid of your problem.