Assignment to parameters

modelica-trac-importer commented 6 years ago

Reported by stefanv on 25 Apr 2011 14:37 UTC I believe the following are unwritten rules regarding assignment to parameters.

If p is a parameter or constant in a function, the assignment p := value is not allowed.
If and only if r is an output variable of type record R in a function, and p is a parameter in record type R, the assignment p.r := valueis allowed..

In plain English, assignment in parameters is not allowed, except for assignment to record parameter fields in functions that construct records.

This (or the correct version thereof if I am mistaken) needs to be clarified in the specification.

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

modelica-trac-importer commented 6 years ago

Comment by HansOlsson on 24 May 2011 11:52 UTC Language group:

Needs investigation - not needed for record constructor (see section 12.6). Seems as though there's a mismatch for parameter-variability for record constructors; should be investigated.

modelica-trac-importer commented 6 years ago

Modified by dietmarw on 30 May 2011 07:29 UTC

modelica-trac-importer commented 6 years ago

Comment by hansolsson on 1 Sep 2011 08:02 UTC Language group: What is really stated for parameters in function?

3.8.3. Expressions in functions behave as though they were discrete-time expressions. (meaning just that continuous-time expressions are not used). 12.4.4. Explicitly lists (protected) parameters in functions.

Problems with parameters in records in general, usually used for giving sizes of arrays in the records.

Issues to correct:

parameters should not be assignable in normal algorithms, 11.2.1;
- except for fixed=false parameters in initial algorithms
records containing parameters/constants need more investigation; should probably be allowed to be assigned - and treated as assert
11.1.3 references 12.4.4, but 12.4.4 does not define execution of algorithms in functions
11.1.2 should ensure that all variables assigned in an initial algorithm are initialized to their start-attribute (which is identical to pre(v) during initialization)

More work is needed.

modelica-trac-importer commented 6 years ago

Comment by hansolsson on 1 Sep 2011 08:49 UTC Language group:

Also 12.2 "Components of a function will inside the function behave as though they had discrete-time variability."

That seems to imply that parameters would become discrete-time variables and then we could assign to them. For #593 this would mean that the restriction on parameters for sizes would be meaningless.

General direction of where to go: parameters in function should not be assigneable (the ones in records need more work) and basically treated as fixed during each function computation

Favour: 6 Against: 0 Abstain: 1

Will need more time to formulate; but at least clear direction.

modelica-trac-importer commented 6 years ago

Comment by hansolsson on 2 Sep 2011 10:25 UTC Language group:

One possibility for parameters would instead be that parameters are treated as normal variables in function - and then treat Real work[lwork]; as just giving initial size of work - and not as an equation size(work, 1)=lwork. Basically ignoring "parameter" in functions. Not seen as good idea in group.

Another idea would be that inputs to functions are seen as parameters (since they are not changed in the function); that would imply that we could call them formal parameters. Seems good, but will need more work.

About parameters in records:

record LinSpace
   parameter Integer nx,nu,ny;
   Real A[nx,nx];
   Real B[nx,nu];
   Real C[ny,nx];
   Real D[ny,nu];
end LinSpace;

Problems are:

Have to pre-dimension the array for results.
What is legal for assignment
How to count equations (in models)?

Could we avoid having the parameters?

record LinSpace
   Real A[:,size(A,1)];
   Real B[size(A,1),:];
   Real C[:,size(A,1)];
   Real D[size(C,1),size(B,2)];
end LinSpace;

Problem is how to give size and that it looks unsymmetrical.

The other idea is that parameters (and constants) in records lead to assertions instead of assignments. Obviously the binding equation has to be treated specially.

So first variant: Binding - everything is assigned. Assignment - assert for parameters/constants in record on left-hand-side Equation - assert for variables in records that are parameters/constants in both lhs and rhs.

Issue with parameters in initial equations/initial algorithms: probably they should not be treated as parameters if they have fixed=false.

Conclusion: Sounds reasonable - but too early to add it. For Modelica 3.3 just add 'parameter' in MSL.

modelica-trac-importer commented 6 years ago

Modified by hansolsson on 1 Mar 2012 09:11 UTC

modelica-trac-importer commented 6 years ago

Comment by dietmarw on 17 Oct 2012 16:23 UTC Since not handled at the last meeting rescheduling to the next one.

modelica-trac-importer commented 6 years ago

Comment by hansolsson on 5 Dec 2012 15:15 UTC Not reasonable to add now; reschedule for next release.

modelica-trac-importer commented 6 years ago

Changelog removed by hansolsson on 5 Dec 2012 15:15 UTC

modelica-trac-importer commented 6 years ago

Comment by hansolsson on 15 Apr 2016 09:57 UTC Replying to [comment:5 hansolsson]:

So first variant: Binding - everything is assigned. Assignment - assert for parameters/constants in record on left-hand-side Equation - assert for variables in records that are parameters/constants in both lhs and rhs.

Issue with parameters in initial equations/initial algorithms: probably they should not be treated as parameters if they have fixed=false.

Conclusion: Sounds reasonable - but too early to add it. For Modelica 3.3 just add 'parameter' in MSL.

This issue still exists and it is not clear if the proposed solutions solves it - when we have both variables and more general expressions.

Assume we have (smaller record than entire LinSpace):

  record ParSmall
   parameter Integer nx;
   Real A[nx,nx];
  end ParSmall;
  record OtherSmall
     Integer nx;
     Real A[2,2];
  end OtherSmall;
  ParSmall p1;
  ParSmall p2;
  OtherSmall q1;
  OtherSmall q2;
  parameter OtherSmall qp1; 
  parameter Integer n;

We can then have equations such as (not all at once):

equation
  p1=p2;
  p1=qp1;
  q1=p1;
  q2=q1;
  q1=ParSmall(n, foo(time,n));
  p1=ParSmall(n, foo(0, n));
  p1=bar(n, time);

We want assertion for n in "p1=p2" and "p1=qp1", and equation for "q2=q1", "q1=p1", and "q1=ParSmall..".

The problems are "p1=ParSmall(...)" and "p1=bar(n, time);".

The possible rules for handling them are:

Only actual parameters in both sides generate assertions; so "p1=ParSmall(...)"; generate equations (which doesn't seem to generate expected results here).
Assertions also for other equations: a. If there are parameters/constants (declared with that variability attribute as sub-component of a record) and a general expression (not variable reference) in the other an assert is generated; so "p1=ParSmall()", "p1=bar(n,time);" generate assertions for "p1.n". b. Additionally a pragmatic solution is that we only look at variability in the left-hand-side. It isn't "nice" but works and is even easier to specify.
For an expression formal variability matters, i.e. "ParSmall(n, foo(0,n))" is a parameter expression and thus generate assert for "p1=... "- but "bar(time,n))" is a continuous-time expression so "p1=bar(time, n)" generate equation.
Formal variability matters, except that automatically generated record constructor is split to each component; so "p1=ParSmall(n, foo(time,n))" will also generate equation - not only "p1=ParSmall(n, foo(0,n))".
Formal variability matters - and also the variability of the components of the output from the function. This handles automatically generated record constructors, and also "p1=bar(time,n);" if bar is declared as having an output of "ParSmall" type.

As I understand it only 2a, 2b, 5, (and possibly 4) will work well for normal use-cases, and only options 1, 2 are straightforward to describe and understand. The issue that complicates (2) is to ensure that "constant Real zero=0; equation zero=foo(...)"; (and variants of this) generate equations, even if zero is a constant/parameter.

If we cannot find a good solution for this, we could go for the simplest solution (1 - or just always generate equations for record-equations) and require users to use algorithm/binding equation for other cases.

modelica-trac-importer commented 6 years ago

Comment by hansolsson on 27 Feb 2017 17:44 UTC Jesper: What does the different tools do today? Tool-vendors can add this in this ticket. Note that: p1=ParSmall(n, foo(time,n)); and q1=ParSmall(n, foo(0,n)); shall also be considered. Group to resolve this at the meeting: Carl, Jonathan, Hans (Henrik).

modelica-trac-importer commented 6 years ago

Comment by hansolsson on 28 Feb 2017 11:06 UTC Note that binding equations are not an issue (since it is clear that the parameter is bound), and connections generate assertions for parameters.

Note that these cases (except A1) are odd. Dymola 2017 FD01 seems to follow rule 2b and handles (A1, A3). JModelica.org does not do anything special (only A5 translates). OpenModelica does not do anything special (only A5 translates). MapleSim handles A1, A3, A4, A5 not A2. SimulationX handles A1, A2, A3, A4, A5.

To handle both A3, A5; you need to handle overdetermined systems of equations (as MapleSim). Not really an overdetermined initialization problem.

Simple to specify: Parameter variables in both lhs and rhs give assertions, everything else gives equations - but that will not handle function calls in the rhs. Can work around some cases by giving specific equations.

Need to investigate more.

modelica-trac-importer commented 6 years ago

Comment by hansolsson on 28 Feb 2017 11:12 UTC See also #1229 - i.e. if we have a function returning a record and then an equation for that record (containing a parameter) we need to say if each step is legal - and it should not modify the parameter (so an assert is good). If the record isn't used there is no problem, so an assert at the equation level seems likely to be correct.

modelica-trac-importer commented 6 years ago

Comment by hansolsson on 1 Mar 2017 14:48 UTC Henrik: One possibility is that it is MCP-material, and thus cannot be included in Modelica 3.4. Stefan: Used in libraries, so important - but seems we cannot resolve it for Modelica 3.4. Having an MCP is more likely to get a complete proposal with examples.

modelica / ModelicaSpecification

Assignment to parameters #535