Definition of "elementary relation" is too strict

[modelica-trac-importer]

Reported by choeger on 14 Nov 2016 11:44 UTC Section 3.5 contains the definition of the term "elementary relation":

Relations of the form v1 rel_op v2, with v1 and v2 variables and rel_op a relational operator are called elementary relations.

(emphasis mine)

This is obviously problematic, since the example from section 8.5 (x > 2) would be wrong. Due to the operational requirements on root-finding, we cannot allow arbitrary expressions on either side (since this would allow for nested events and I am pretty confident that no solver could handle them). Therefore I propose to change the definition to include literal values on either side (the case of literal values on both sides does no harm IMO).

---

Migrated-From: https://trac.modelica.org/Modelica/ticket/2114

[modelica-trac-importer]

Comment by hansolsson on 14 Nov 2016 12:34 UTC Replying to [ticket:2114 choeger]:

Section 3.5 contains the definition of the term "elementary relation":

Relations of the form v1 rel_op v2, with v1 and v2 variables and rel_op a relational operator are called elementary relations. (emphasis mine)

This is obviously problematic, since the example from section 8.5 (x > 2) would be wrong. Due to the operational requirements on root-finding, we cannot allow arbitrary expressions on either side (since this would allow for nested events and I am pretty confident that no solver could handle them). Therefore I propose to change the definition to include literal values on either side (the case of literal values on both sides does no harm IMO).

I say that we should just remove the variable-requirement. I hadn't noticed that it was formally there. Using x+y>2 or (if p then x else y)>0 doesn't cause any problems.

There is a problematic nesting case but it is explicitly forbidden in 3.8.3: if noEvent(x>0) then x>1 else true the problem is that the crossing function for x>1 will become active between events.

[modelica-trac-importer]

Comment by choeger on 14 Nov 2016 19:14 UTC How about: x > (if x > 1 then 2 else 1): This event can occur both at x > 1 and x > 2. The solver might steer the solution close to the left of the zero-crossing, then the right-hand-side evaluates to 1, it might also cross that point a little bit and fail the iteration because the guard is essentially not a continuous function.

I just do not think that it is a good idea to have events inside events, of course algebraic relations are fine in principle, but I cannot come up with a syntactical criterion to rule out nested events. It might also be possible to order nested events hierarchically, to circumvent the problem, but I do not know how to do that either.

[modelica-trac-importer]

Comment by hansolsson on 15 Nov 2016 09:02 UTC Replying to [comment:2 choeger]:

How about: x > (if x > 1 then 2 else 1): This event can occur both at x > 1 and x > 2. The solver might steer the solution close to the left of the zero-crossing, then the right-hand-side evaluates to 1, it might also cross that point a little bit and fail the iteration because the guard is essentially not a continuous function.

I don't see a problem. Since if x>1 then 2 else 1 is unconditional we could always introduce Real y=if x>1 then 2 else 1; and look at x>y instead.

I'm not saying that it is best solution - just that it works, and shows that this nesting is harmless. If it had been if x>1 then x>a else x>2 we could have introduced a number of variables:

  Boolean b=x>1;
  Real x2=(if b then x-a else 0);
  Boolean b2=x2>0;
  Real x3=(if b then 0 else x-2);
  Boolean b3=x3>0;
equation
  ... if b then b2 else b3...

(or possibly some other transformation).

Crossing functions don't have to be nice continuous functions, but it certainly helps.

Only if the outer condition involves noEvent does this become impossible.

[modelica-trac-importer]

Comment by hansolsson on 30 Nov 2016 13:46 UTC The suggestion to handle this would be:

Relations of the form v1 rel_op v2, with v1 and v2 variables and rel_op a relational operator are called elementary relations. -> Relations of the form v1 rel_op v2, with v1 and v2 scalar expressions and rel_op a relational operator are called elementary relations.

[modelica-trac-importer]

Comment by hansolsson on 12 Dec 2016 17:52 UTC Discussion: Relations of the form e1 rel_op e2, with e1 and e2 expressions and rel_op a relational operator are called elementary relations. -after discussion Relations of the form e1 rel_op e2, with e1 and e2 expressions and rel_op a relational operator, and at least one of e1 and e2 is a sub-type of Real and not both e1 and e2 are discrete-time expressions is called event-generating relation.

Conclusion: Use "event-generating expression" for relations generating events and the special functions; and remove "elementary relations".

In section 3.5 only write: Relational operators can generate events, see section 3.8.3.

In 3.8.3 replace div, mod etc by reference to section 3.7.1.1; or just replace everything by event-generating expression. In 3.7.1.1 replace "state events" by "events" since "div(time, 2)" could in theory generate a "time-event".

Define more clearly in 8.5 (including more than relational operator) - or sub-section thereof - and thus reference 8.5 instead in the other places. -- Agreement (the exact text is not clear - but the direction). Put proposal here first.

[modelica-trac-importer]

Comment by hansolsson on 3 Feb 2017 08:53 UTC When trying to write this text a minor issue was detected. The functions rem and mod generates events, but are not discrete-time expressions. I tried to handle that below - but it would be possible to make it even clearer by having rem and mod in a special list, and being careful about which list we refer to.

Proposed text for 8.5:

The integration is halted and an event occurs whenever a Real elementary relation, e.g. “x > 2”, changes its value. The value of such a relation can only be changed at event instants [in other words, Real elementary relations induce state or time events]. The relation which triggered an event changes its value when evaluated literally before the model is processed at the event instant [in other words, a root finding mechanism is needed which determines a small time interval in which the relation changes its value; the event occurs at the right side of this interval]. Relations in the body of a when-clause are always taken literally. During continuous integration a Real elementary relation has the constant value of the relation from the last event instant.

->

The integration is halted and an event occurs whenever an event generation expression, e.g. x > 2 or floor(x), changes its value. The value of an event generation expression can only be changed at event instants. The expression which triggered an event changes its value when evaluated literally before the model is processed at the event instant [in other words, a root finding mechanism is needed which determines a small time interval in which the expression changes its value; the event occurs at the right side of this interval]. During continuous integration event generation expression has the constant value of the expression from the last event instant.

Note: It would be possible to describe it in more detail. We can discuss that further. -- In section 3.5 only write: Relational operators can generate events, see section 3.8.3.

In 3.7.1.1 replace "state events" by "events" since "div(time, 2)" could in theory generate a "time-event".

And add "These expression for div, ceil, floor, and integer are event generating expression. The event generating expression for mod(x,y) is floor(x/y), and for rem(x,y) it is div(x,y) - i.e. events are not generated when mod or rem changes continuously in an interval, but when they change discontinuously from one interval to the next."

In 3.8.3: Unless inside noEvent: Ordered relations (>,<,>=,<=) if at least one operand is a subtype of Real and the event generating functions div, ceil, floor, and integer (see section 3.7.1.1 and note that rem and mod generate events but are not discrete-time expressions). These will generate events if at least one subexpression is not a discrete-time expression. [In other words, relations inside noEvent(), such as noEvent(x>1), are not discrete-time expressions]. --

[modelica-trac-importer]

Comment by hansolsson on 8 Feb 2017 11:31 UTC Corrected in r9630 (together with spelling and grammar corrections).

The idea was to have a complete specification to review. However, one major cleanup issue is still missing: using consistent names of grammar productions as indicated in #1033. -- However, not closing these tickets yet.

[modelica-trac-importer]

Comment by hansolsson on 27 Feb 2017 13:58 UTC Design meeting: Ordered relations (>,<,>=,<=) if at least one operand is a subtype of Real and the event generating functions div, ceil, floor, and integer (see section 3.7.1.1 and note that rem and mod generate events but are not discrete-time expressions). These will generate events if at least one subexpression is not a discrete-time expression.

Change to: Ordered relations (>,<,>=,<=) and the event generating functions div, ceil, floor, and integer (see section 3.7.1.1), if at least one argument is non-discrete time expression and subtype of Real. [These will generate events, see section 8.5. Note that rem and mod generate events but are not discrete-time expressions.]

(Note: Reviewed that consistent with #524.) Agreement by acclamation.

[modelica-trac-importer]

Comment by hansolsson on 27 Feb 2017 14:14 UTC The value of an event generation expression can only be changed at event instants. The expression which triggered an event changes its value when evaluated literally before the model is processed at the event instant [in other words, a root finding mechanism is needed which determines a small time interval in which the expression changes its value; the event occurs at the right side of this interval].

->

An event generating expression has an internal buffer, and the value of the expression can only be changed at event instants. If the evaluated expression is inconsistent with the buffer, that will trigger an event and the buffer will be updated with a new value at the event instant.

Agreement by acclamation.

[modelica-trac-importer]

Comment by hansolsson on 27 Feb 2017 15:14 UTC Resolved in r9663.