Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Equation Structure depending on runtime evaluation #588

Closed
modelica-trac-importer opened this issue Nov 3, 2018 · 15 comments
Closed

Equation Structure depending on runtime evaluation #588

modelica-trac-importer opened this issue Nov 3, 2018 · 15 comments
Assignees
Labels
discussion Indicates that there's a discussion; not clear if bug, enhancement, or working as intended

Comments

@modelica-trac-importer
Copy link
Collaborator

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 modelica-trac-importer added the discussion Indicates that there's a discussion; not clear if bug, enhancement, or working as intended label Nov 3, 2018
@modelica-trac-importer
Copy link
Collaborator Author

Modified by choeger on 5 Jul 2011 09:18 UTC

@modelica-trac-importer
Copy link
Collaborator Author

Modified by hansolsson on 28 Sep 2011 13:08 UTC

@modelica-trac-importer
Copy link
Collaborator Author

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
Copy link
Collaborator Author

Modified by stefanv on 28 Sep 2011 19:46 UTC

@modelica-trac-importer
Copy link
Collaborator Author

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
Copy link
Collaborator Author

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
Copy link
Collaborator Author

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
Copy link
Collaborator Author

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
Copy link
Collaborator Author

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

@modelica-trac-importer modelica-trac-importer removed this from the ModelicaSpec3.4 milestone Nov 3, 2018
@modelica-trac-importer
Copy link
Collaborator Author

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

@modelica-trac-importer
Copy link
Collaborator Author

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
Copy link
Collaborator Author

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
Copy link
Collaborator Author

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
Copy link
Collaborator Author

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

@modelica-trac-importer modelica-trac-importer added this to the ModelicaSpec3.4 milestone Nov 3, 2018
@modelica-trac-importer
Copy link
Collaborator Author

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

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
discussion Indicates that there's a discussion; not clear if bug, enhancement, or working as intended
Projects
None yet
Development

No branches or pull requests