Deceptive crossings of condition thresholds

[SouthEndMusic]

The problem described here can be summarized as "what starts as an up-crossing does not have to end as an up-crossing".

Example

In the example below we look at the level of a basin trough time.

As the level crosses the upper threshold, a Pump flow rate is changed to bring the level to the setpoint (middle threshold). The VectorContinuousCallback detects the crossing of the upper threshold as an up-crossing, and so it is assumed that the condition

level > upper_threshold

is true just after the time when level = upper_threshold:

function discrete_control_affect_upcrossing!(integrator, condition_idx)
    discrete_control = integrator.p.discrete_control
    discrete_control.condition_value[condition_idx] = true

    discrete_control_affect!(integrator, condition_idx)
end

However, due to the change induced by control, this turns out not to be an up-crossing at al, but merely a 'touch' of the threshold.

This is a non-trivial problem, because only after the control change and a call of water_balance! is the direction of this crossing really clear, by the sign of the du of this basin.

Potential solution

At the moment it is quite expensive to get the du of a single basin (or the flow over a single edge for that matter, needed for flow conditions), because the implementation only supports computing all of them in one function call. It would be nice to have a way to only calculate the du of a single basin after a control state change (or the flow of a single edge), to have a relatively cheap way to infer the crossing type.

[SouthEndMusic]

Using DiscreteCallback does not have this problem but is less precise on the time of the control change, dependent on dt.