Optimization module removeEqualFunctionCalls needs to update EventInfo

[Willi Braun]

At least BackendDAE.EventInfo.whenClauses needs to be updated while removeEqualFunctionCalls is performed, otherwise the function findZeroCrossings can't match equal zero-crossings and generate too many of them for actually the same ones, this can lead to too many events. Anyway it's not consistent, so it needs to be fixed. But for the current implementation of WHEN_CLAUSES I don't see an efficient way, since we would need to traverse all of them to replace where required.

In my option we should get rid of uniontype WhenOperator and the WHEN_CLAUSES at all and merge the functionality into uniontype WhenEquation.

What do you think?

[Jens Frenkel]

As far as i understood WHEN_EQ.condition and WHEN_CLAUSE.condition have the same source
from the when equation condtion.

For when equations with more than one equation in the body the function findZeroCrossings have to merge all the WHEN_CLAUSE.condition with the same when equation condition.

True?

If true a first step could be to use not the condition in the WHEN_CLAUSE but an unique index. Each when equation get such an unique index.

Another approach could be to add the WHEN_CLAUSE of a when equation to the WHEN_EQ and seperate them not in a own list.

[Willi Braun]

Of course they have the same source, but in whenClause we have all the operations (reinit, assert, terminate, noreturn function calls) which are not really equations, in the sense of equations, where always an variable is associated, they have no associated variable.

Also this is the actually reason for this separation as far as I see, since we can't handle them currently while the matching. Also there is not always an corresponding when equation to an when clauses. This means your first suggestion will not work.

The second suggested solution might need really many modification to hide this equations as not real "equations" while the matching and for the other modules.

Additional, this issue might effects more postOpt modules, which runs after it at least it effects also encapsulateWhenConditions, which also generated one additional variable for a when-clause which also is an when-equation.

Maybe encapsulateWhenConditions could do the job if we pop up it to the preOpt-modules.
Lennart, what do you think?

Before I forgot an good example for the described effects is the /testsuite/simulation/modelica/equatinos/BouncingBall.mos model. There you can observe both effects we introduce an additional zero-crossing (by findZeroCrossings) and one additional whenCondition (by encapsulateWhenConditions) and both are needless, even worse they might effect the simulation results a lot.

[Jens Frenkel]

Whe moved in the past encapsulateWhenConditions in the preOptPhase, but then we got in trouble because it is no easy to keep the right variables in removeSimpleEquations.

I guess the source of the problem is the doubling of the when conditions. Each solution which avoid this will be fine and work.

I don't think it is hard to manage the issues with the matching. The most pain full job is to change the record type and replace it in the code.

[Willi Braun]

Replying to jfrenkel:

the source of the problem is the doubling of the when conditions. Each solution which avoid this will be fine and work.

True.

Replying to jfrenkel:

I don't think it is hard to manage the issues with the matching. The most pain full job is to change the record type and replace it in the code.

You mean something like that:

public
uniontype WhenEquation "- When Equation"
  record WHEN_EQ
    .DAE.Exp condition                "the when-condition" ;
    .DAE.ComponentRef left            "left hand side of equation" ;
    .DAE.Exp right                    "right hand side of equation" ;
    Option<WhenEquation> elsewhenPart "elsewhen equation with the same cref on the left hand side.";
  end WHEN_EQ;
  record WHEN_STMTS
   .DAE.Exp condition                "the when-condition" ;
   list<WhenOperator> whenStmtLst;
   Option<WhenEquation> elsewhenPart "elsewhen equation with the same cref on the left hand side.";   
  end WHEN_STMS;
end WhenEquation;

public
uniontype WhenOperator "- Reinit Statement"
  record REINIT
    .DAE.ComponentRef stateVar "State variable to reinit" ;
    .DAE.Exp value             "Value after reinit" ;
    .DAE.ElementSource source "origin of equation";
  end REINIT;
[...]  
end WhenOperator;

What's about pushing them just into an algorithm section with when statements?
This should work proper and we can get rid of the uniontype WhenClause and the uniontype WhenOperator will handled in algorithms.

[Martin Sjölund]

Postponed until 1.9.1

[Martin Sjölund]

This ticket was not closed for 1.9.1, which has now been released. It was batch modified for milestone 1.9.2 (but maybe an empty milestone was more appropriate; feel free to change it).

[Martin Sjölund]

Milestone changed to 1.9.3 since 1.9.2 was released.

[Willi Braun]

Fixed at least in 45e4f5066c.