Efficient handling zero-crossing surfaces

[masoud-najafi]

In the current FMI-3 specification, as well as in FMI-1 and FMI-2, in order to find and handle the state-events, the integrator monitors the zero-crossing surfaces during the numerical integration using the fmiXGetEventIndicators function in the continuous-time mode. Once the integrator finds a crossing, integration is stopped and the FMU is pushed into the Event mode to handle the state-event.
In the event-mode, the FMU should evaluate and compare its zero-crossing surfaces and find crossed surfaces and trigger the correspoding state event.
In many cases, due to numerical errors, this procedure is troublesome and errornous, and the simulator or the FMU needs to introduce a small threshold to avoid or reduce the effects of numerical errors.

What is proposed here is to give the integrator (simulator) the right to pass the vector of crossed zero-crossings to the FMU. In this way, the FMU need not reevluate the surfaces and numerical errors will be avoided. This is more important when state-events are linked to clock ticks.

What is needed is just a new API to pass crossed surfaces as well as their direction into the FMU:

if ticket (#587) is accepted for FMi-3, this API is good:
fmi3Status fmi3SetStateEvent(fmi3Component c,
const fmi3ValueReference vr[], size_t nvr,
const fmi3Int8 direction[], size_t nDirections);

otherwise this API should be used:
fmi3Status fmi3SetStateEvent(fmi3Component c, const fmi3Int8 direction[], size_t nzc); // size of direction is nz (number of zero-crossings)

[chrbertsch]

Regular design webmeeting:

Christian: What are the values for directions?
Massoud: +1, -1, 0; with the new approach we do not need the ones which are not crossed
In some cases due to numerics, the solver and the FMU "disagree" if a zero-crossing happened
Pierre: Why is the solver doing zero-crossing detection? Why not let the FMU do it? Or am I missing somthing?
Andreas J: Inputs change at events.
Pierre: Why can the FMU not just return the information, that a zero-crossing happened?
Torsten S: this boils down to just just extending the existing function call
Pierre: i.e., let the FMU detect the information
Torsten S.: Would this be sufficient for you, Massoud? Adding this information to the existing getEventIndicators function?
Pierre: Change GetEventIndication to GetChangedEventIndicator? Put the event detection to the FMU. Not sure if this really works.
Torsten S.: In CVODE we could not change the existing way of doing it. We could make the detection in the FMU optional.
Pierre: optional makes no sense. Then we should follow the proposal of Masoud.
Pierre: one should talk with numerical solver experts.
Torsten S.: We should ask Karl. @masoud-najafi : could you motivate your change with an example?
Pierre: I will try to write something about "who" should detect the crossing.

[chrbertsch]

@KarlWernersson : What is your opinion on this?

[jbernalr]

It this like the master telling a co-simulation FMU when the ball is going to bounce?

• because the FMU is incapable of telling exactly when (even with the new hybrid co-sim capabilites)
• or because we think the master can be much more efficient finding the event?

In my opinion, FMUs used to contain specialized "know how" in terms of model and solvers. So for me this is like taking some resposibility from the exporting tool to fully support the simulation of a given phenomena and makes end user more dependent on the features of a "master".

[masoud-najafi]

The main motivation behind this proposal is to avoid state-event detection conflict between the solver and the FMU. As a very simple example, suppose that an event-indicator (with previous positive value) becomes negative or almost zero withing this condition Abs(EI(i))<=EPS1 where EPS1 is the epsilon used by the solver to declare a state-event. If this condition happens, the solver considers this as a state-event and pushes the FMU into the event mode.
In the event mode, the FMU needs to find the state-event ITSELF AGAIN by evaluating the zero-crossing surfaces. But the condition Abs(EI(i))<EPS2 may not be fulfilled inside the FMU, if EPS2<EPS1, where EPS2 is the epsilon used by the FMU to declare a state-event.
This may cause chattering or sliding mode.

An important point to notice is that this proposal is just an EXTRA INFORMATION delivered by the solver to the FMU and creates no backward incompatibility.

[HansOlsson]

I agree that there can be an issue, and we need to have a good solution.

As indicated in #587 I believe we need to be sure how to handle the "event state" of the FMU (referred to as "with previous positive value"). Note that I don't see any issue if the event-indicator becomes almost zero. I believe the FMU should be responsible for maintaining that state.

Above there was some discussion whether the FMU could just reported if the event had occurred (and internalize the event indicator). The answer is that it doesn't work well - for efficient detection the master need to find the exact event points - and for efficiency reasons that requires interpolation of a smooth function, and a binary signal isn't smooth. I don't think the FMU has enough information to interpolate on its own.

[chrbertsch]

Regular design meeting:
Torsten B.: this is a new feature
Christian B.: How much is the gain?
Massoud: FMI 1.0 and 2.0 work, so this is a minor gain.

Decision : Move to future.

[clagms]

After a quick read of #1042, I'd say the proposal by @masoud-najafi here might be solution that removes the ambiguities in the cause of entering event move.

In model exchange, it is the importer that's doing that, so there can be no ambiguity. It shouldn't be guesswork for the FMU to redo the work of the importer and detect events (at least those happening in continuous time mode).

As @jbernalr mentioned, a co-simulation FMU is responsible for doing the state event detection, so there's no ambiguity there.

My 2 cents is that if the flags get removed (as they should be, proposed in #1042), then this extra function should be introduced for model exchange.

[clagms]

PS - The example in modelica/Reference-FMUs#229 currently uses the flags as a way of knowing that a clock has to be activated. This is unambiguous because the FMU only has one event, and one clock. If the FMU had two clocks (and two event indicators), then the FMU's implementation would have to be more complex to resolve the ambiguity when entering event mode.

So, should this new function go forward, we could extend the above example to exemplify this.

[andreas-junghanns]

Please keep the discussion in #1739 - this issue has the proper title and milestone.
Also, issue #1739 is about more and about less than this issue here.