Clarify event semantics for AssertionLevel.error

[henrikt-ma]

#1520 raised very relevant questions regarding event generation of assert with AssertionLevel.error, but I still think that the outcome of the discussion hasn't really made it into the specification.

The text regarding AssertionLevel.warning that says that the condition shall be treated with implicit noEvent is still non-normative. A side effect of this being non-normative nature is that this also makes it less clear what is actually the rule in the AssertionLevel.error case.

Then, there is also non-normative text for AssertionLevel.error saying that it can be used to avoid evaluating a model outside its limits of validity, but it doesn't mention that one would need to explicitly wrap the condition in noEvent in order to to avoid risk of event hysteresis handling allowing the condition to be violated by a small amount before triggering the assert.

[HansOlsson]

I agree that we need to reconsider this.

Either make noEvent implicit - or state that it is required; for both values of AssertionLevel.

An additional complication is that the assertion-level could be a parameter expression, so it's not good if different assertion-level have different semantics regarding noEvent - i.e. we should ideally have the same semantics for both of them.

[HansOlsson]

The proposals are thus:

• Require noEvent for both values of AssertionLevel when needed to allow error recovery.
• Implicit noEvent for both values of AssertionLevel
• Require noEvent for AssertionLevel.error and implicit noEvent for AssertionLevel.warning (which seems to be current text but non-normative).

Note that many uses of assert in MSL are parametric or in functions and thus this is not relevant.

In other cases it is relevant - but it is not clear that error recovery allowed by noEvent is helpful in practice:
Consider a medium where we have a min-temperature of 200K. I would guess that in most cases this assertion triggers it is a fundamental model issue and taking smaller steps will not help.
Thus I would favor requiring the noEvent - in the cases it is useful.

[henrikt-ma]

Let's not forget the reason why (I think) the implicit noEvent was added for warnings in the first place. Removing the implicit noEvent will lead to zero crossings that will have an effect on the simulation result. For a more clean design without so many hidden noEvent, I'd be willing to accept that even a warning could have an impact on the simulation result, knowing that explicit wrapping with noEvent should remove this impact.

[gkurzbach]

For me, it would be important that asserts for warnings have no influence on the simulation results. So I would keep the implicit noEvent in this case.
In the case of asserts for errors, the question is whether the behavior to determine discontinuities in the argument is the same as that needed to control the solver to prevent the model from leaving its validity range. However, because the handling might be tool dependent and because after a failed assert no event iteration follows during integration anyway, it might be better to describe the behavior of assert independently of noEvent.
So the implementation of the described behavior of assert with error is always tool dependent and it doesn't matter whether there is an implicit noEvent or not.

So it could be possible to say that there is a implicit noEvent in both cases, but describe the expected behavior and the possible influence on the simulation clearly.

[HansOlsson]

Poll:

• Implicit noEvent for assert (if you want crossing function create a boolean variable). Gerd, Martin, Adrian, Stefan
• Nothing implicit - require noEvent if you don't want a crossing function. Henrik, Filippo, Quentin, Hans

Not conclusive

Christoff, Markus, Axel abstain
Dag