optimized zero crossings for cpp runtime

[Niklas Worschech]

Thus the cpp runtime can use the optimized zero crossings, that are zero crossings which could arise from combined relations like

((h)<=0)&&(v<=0))

additional information in the backend is needed.
At the moment all relations have an index in the backend which is used in the cpp code generation to replace the relations with condition variables

if(h<=0) 

is replaced with

if(condition_[index]) 

To use the optimized zero crossings, expressions for lbinary and lunary also needs this index to replace e.g

if(h<=0 && v<=0)

with

if(condition_[index]) 

during code generation

[Lennart Ochel]

I guess it's the same for the c runtime. I see no good reason to handle zero-crossings different for both runtime systems.

[Niklas Worschech]

The c runtime does not replace the relations in equations like the cpp runtime. Because of this the c runtime does not need this index.

[Lennart Ochel]

Well, I still see no reason to generate different data structures depending on the selected runtime system at this point. We should have a discussion about the preferable approach and use it for both (all) runtime systems.

[Niklas Worschech]

This is a simplified description of the cpp runtime approach for zero detection zero search and event handling.
If the solver detects a zero crossing the zero search method will start for the corresponding zero function. If the root of the zero function was found the condition is set to the value of the corresponding relation and the event iteration starts to handle all active events which conditions are true.
The system evaluation in each step only checks a condition it don't checks the relation. This is the case if the system is in a continuous mode.
During event iteration the system is in discrete mode which means the relations also are checked. The event iteration stops if no discrete variable and condition has changed.
Therefore we need the index for all relations, to replace the relations in the equations with condition variables.

[Willi Braun]

Yes, we have to encapsulate all zero crossings, to have more control on them, and be able to change them directly and use them also as inputs to algebraic system and also to jacobians. This is would also fix #2433 #2618 and #4254.

[Francesco Casella]

The milestone of this ticket has been reassigned to "Future".

If you think the issue is still valid and relevant for you, please select milestone 1.13.0 for back-end, code generation and run-time issues, or 2.0.0 for front-end issues.

If you are aware that the problem is no longer present, please select the milestone corresponding to the version of OMC you used to check that, and set the status to "worksforme".

In both cases, a short informative comment would be welcome.

[Christoph Buchner <buchner@…>]

Since this seems connected (https://trac.openmodelica.org/OpenModelica/ticket/4254#comment:9) to #4254, it seems proper to put it on the same milestone.

[Francesco Casella]

Rescheduled to 1.14.0 after 1.13.0 releasee

[Francesco Casella]

Releasing 1.14.0 which is stable and has many improvements w.r.t. 1.13.2. This issue is rescheduled to 1.16.0

[Francesco Casella]

Retargeted to 1.17.0 after 1.16.0 release

[Francesco Casella]

Retargeted to 1.18.0 because of 1.17.0 timed release.

[Francesco Casella]

Ticket retargeted after milestone closed