Equation Structure depending on runtime evaluation

[modelica-trac-importer]

Reported by choeger on 5 Jul 2011 07:53 UTC In Modelica there is at least one possible kind of expressions that yield unknowns (one element of higher order models): Although unknowns are ususally named and directly referenced, the index expression in an array subscription might not be evaluated at compile time. Consider the following (extreme) example:

class ArrayTest

    function indexFoo
        input Integer i;
        output Integer j;
    external "C" _indexFoo(i);
    end indexFoo;

    Real[4] x;

    equation

    for i in 1:4 loop
        x[indexFoo(i)] = time * x[indexFoo(i)];
    end for;

end ArrayTest;

Depending on the function indexFoo, the body of the for equation contains different unknowns. The resulting system might be easily solvable (if, e.g. indexFoo was the identity function) or singular (if it was constant).

It is currently (in general) impossible to evaluate an index expression at compile time (external functions are just one simple example for the problem). On the other hand, the fact, that a Compile does not know the structure of every equation might yield all kinds of problems for usual optimizations (causalization, index reduction etc.).

Does anyone have an opinion on that topic?

---

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

[modelica-trac-importer]

Modified by choeger on 5 Jul 2011 09:18 UTC

[modelica-trac-importer]

Modified by hansolsson on 28 Sep 2011 13:08 UTC

[modelica-trac-importer]

Comment by choeger on 28 Sep 2011 19:31 UTC Maybe I fail to see what fixed the issue. Please do not close tickets without a comment about the fix.

[modelica-trac-importer]

Modified by stefanv on 28 Sep 2011 19:46 UTC

[modelica-trac-importer]

Comment by hansolsson on 29 Sep 2011 07:47 UTC Sorry, the closure of this one was a misclick.

It was on the list of tickets for spec 3.3 not handled by spec updates and that unresolved list includes (the names are not the official ones):

459 Parameter with no value start=…

552 Self connection should be forbidden.

480 Order of sections.

512 Binding of comment after a constraining class

559 Application of choices annotation on enumerations

594 Exception handling needed for embedded systems

588 Equation structure depending on runtime evaluation

597 Array dimensions and fixed=false

On the other hand the ones closed by the updates were:

172 spatialDistrubtion née transportDelay. Addition

351 Records in external C interface. Change

404 Binary/source for licensing. Minor addition

468 Ambiguity with redeclare as element. Clarification.

561 Selection of missing initial equations. Minor addition

590 Specification of inner/outer. Clarification

601 Events for min/max. Clarification

73 getInstanceName. Addition

81 Inner/outer inconsistency. Clarification

146 GenerateEvents annotation. Addition

178 Conditional connectors that are enabled must be connected. Change

182 Version vectors. Minor addition

187 Inverse trigonometric. Clarification

270 Picture flip. Clarification

350 Inner/outer between functions. Clarification

409 Function call with multiple outputs. Clarification

453 Short-cut for steam. Minor addition

454 Function parameter keyword. Clarification

458 Where is time available. Clarification

467 Non-standard experiment annotation. Minor addition

469 Type in example. Clarification

470 Something is missing from section 7.1. Clarification

479 Lexer and comments. Clarification

478 Specification unclear about rules for extends. Clarification

481 Clarification of when initial(). Clarification

489 What can be redeclared. Clarification

492 Redeclaration of dimensions. Clarification

493 What does a conditional attribute mean on redeclare. Clarification

497 Does “class extends” require replaceability. Clarification

499 Reductions on non-real scalars is not well defined. Clarification

503 Execution order of declaration assignments. Minor addition

514 Error in equation syntax. Clarification

515 ColorSelector. Addition

519 Inherited duplicate elements. Change

521 Class redeclaration using a non-short class definition. Change

522 External object example. Clarification

524 Inconsistency regarding generating events. Clarification

531 Can conditional attribute be used to remove equations? Clarification

533 Missing end if. Clarification

538 Argument names for Modelica.Math.* functions. Clarification

548 Incorrect reference link. Clarification

551 Vectorization of enumerations. Clarification

554 Adding flow variables during augmentation. Clarification

555 Remove ambiguities. Clarification

558 Clarification in Section 9.1.3 Expandable Connectors. Clarification

563 Typo? In 3.2 Spec. Clarification

574 Non-compatible enumerations. Clarification

592 Vectorization of reinit. Clarification

599 First argument of smooth. Clarification

[modelica-trac-importer]

Comment by hansolsson on 28 Feb 2012 11:51 UTC Language group: Toni: Example is bad.

Consider instead

  for i in 1:4 loop
        x[indexFoo(i)] = time*i;
    end for;

If indexFoo({1,2,3,4})={1,2,3,4} then x=time*{1,2,3,4} If indexFoo({1,2,3,4})={1,3,2,4} then x=time*{1,3,2,4} If indexFoo({1,2,3,4})={1,1,1,1} then no solution since

x[1]=time*1;
x[1]=time*2;
x[1]=time*3;
x[1]=time*4;

Could potentially also have index-reduction depending on the values of indexFoo (no example added for this yet).

Conclusion: State that tool is allowed to reject models if parameter expressions cannot be evaluated during translation.

[modelica-trac-importer]

Comment by dietmarw on 15 Aug 2012 08:22 UTC Left-over tickets from the now closed [milestone:ModelicaSpec3.3] milestone which basically means it should go into [milestone:ModelicaSpec3.4] right?

[modelica-trac-importer]

Comment by hansolsson on 30 Mar 2016 09:46 UTC Replying to [comment:6 hansolsson]:

Language group: Toni: Example is bad.

Consider instead

  for i in 1:4 loop
        x[indexFoo(i)] = time\*i;
    end for;

If indexFoo({1,2,3,4})={1,2,3,4} then x=time*{1,2,3,4} If indexFoo({1,2,3,4})={1,3,2,4} then x=time*{1,3,2,4} If indexFoo({1,2,3,4})={1,1,1,1} then no solution since

x[1]=time\*1;
x[1]=time\*2;
x[1]=time\*3;
x[1]=time\*4;

Could potentially also have index-reduction depending on the values of indexFoo (no example added for this yet).

Conclusion: State that tool is allowed to reject models if parameter expressions cannot be evaluated during translation.

Propose: In section 1.2 add: "In order to allow this structural analysis, a tool may reject simulating a model if parameters cannot be evaluated during translation - due to calls of external functions or initial equations/initial algorithms for fixed=false parameters. Accepting such models is a quality of implementation issue."

(The initial part is due to #588.)

This allows a tool to reject too many models, but without specifying the exact structural analysis it is difficult to be more specific. The "due to calls of external functions" was added so that tools may not reject every model.

In general it should only be "non-real parameter expressions" - but "if p>0 then" means that in order to evaluate the non-real parameter expression "p>0" we have to evaluate the real parameter "p". In addition "p*der(x)" means that we assume that "p" is (in most cases) non-zero.

[modelica-trac-importer]

Changelog removed by hansolsson on 30 Mar 2016 09:46 UTC

[modelica-trac-importer]

Comment by hansolsson on 1 Apr 2016 13:46 UTC See also #1811.

[modelica-trac-importer]

Comment by hansolsson on 20 Jun 2016 12:58 UTC Language group: In agreement by acclamation.

(Reference to #588 above is probably an error, will try to figure out which one it was.)

[modelica-trac-importer]

Comment by fcasella on 20 Jun 2016 17:52 UTC I have read section 10.5 of the Modelica Specification 3.3.r1 (Array Indexing), but I couldn't find any statement that the index of an array has to be an expression with parameter variability.

I tried out this model in Dymola and OpenModelica and obtained the same (expected) result.

model foo
  Real x[3](each fixed = true);
  Integer i;
equation 
  i = if time < 0.5 then 1 else 2;
  der(x[1]) = 1;
  der(x[2]) = -1;
  der(x[3]) = x[i];
end foo;

In this case, the model is well-posed because, once it has been causalized, the indexing expressions with discrete-time variability are on the right hand side of the assignments.

Is this model legal? What should the spec say in general about models with discrete-type variability expressions used for indexing?

[modelica-trac-importer]

Comment by sjoelund.se on 20 Jun 2016 19:21 UTC Replying to [comment:11 fcasella]:

  der(x[3]) = x[i];

Is this model legal? What should the spec say in general about models with discrete-type variability expressions used for indexing?

It is OK; the dependency is der(x[3]) depends on all of x[i] in the incidence matrix. x[i] would not be possible to put on the lhs (unknown what index i and it is scalar means we don't know which variable to assign to).

[modelica-trac-importer]

Comment by hansolsson on 23 Jun 2016 11:40 UTC Scheduled to be added to spec.

[modelica-trac-importer]

Comment by hansolsson on 23 Sep 2016 10:08 UTC Resolved in r9486