Add Safeguards to EulerCore to reduce undefined behavior for SDE models

[nijawa]

Motivation / Current Behaviour

As of now SDE models have to implement checks for whether flows/derivatives result in overflows in the compartments (negative compartments or compartments greater than population size). The current implementation can also result in undefined behavior by floating point operations (see Issue #1009)

Enhancement description

Adapting the EulerCore (potentially writing a EulerMaruyamaCore) one can use vectorized functions to add those safeguards and other modifications into the core. Potential modifications are:

• Clipping compartments to the intervall [0, population_size]
• Setting compartments below some threshhold to zero
• Rescaling compartments in case clipping changed total population size

Additional context

No response

Checklist

• Attached labels, especially loc:: or model:: labels.
• Linked to project

[nijawa]

I have proposed a possible "new" EulerCore in the linked branch, before opening a pull request I would like to discuss whether this should be moved into a new core

[mknaranja]

@reneSchm any expert opinion how Nils could proceed?

[reneSchm]

I assume you mean NaNs in simulation results by "undefined behaviour"? While they are not great, these NaNs are perfectly well defined behaviour in our case.

I am not convinced that the IntegratorCore is a suitable place for this. The main issues I see are:

• Placing these safeguards in the IntegratorCore mixes responsibilities and creates more interdependence. The Integrator is perfectly fine with negative values, and will not produce any unless they come from the model (or more accurately, the integrand aka. DerivFunction).
• I am not sure that it is desirable to rescale integration results. It seems to me like a band-aid fix to an issue with the Model/DerivFunction, that may cause issues when used with different models later.
• Does your EulerCore work with flow models? The flows (used as yt) are initialised as 0, so if I read this correctly, the integration result will be const. 0.

An alternative may be to use a new DerivFunction to compute the stochastic component from each flow and add it to that flow, as well as applying the safeguards. This DerivFunction can be used by a new Simulation class, or we can discuss adding it in some form to the FlowSimulation.

I have a experimental branch here. It does not have your safeguards yet, but I think they can be added around the calculation of m_pop or around the compuation of the stochastic components. Can you maybe try to use this with a model that is currently causing issues, so we can try and discuss fixes? That is, can you implement the "get_flow_denoised" function, which just returns the flows without clamping or adding a stochastic component.