Attributes of aliased variables

[modelica-trac-importer]

Reported by pharman on 4 Oct 2011 15:59 UTC

561 raised the issue of start attributes for aliased variables:

... problem is how to deal with the start attributes of alias variables, which is also critical when such start attributes are used as initial guesses for nonlinear algebraic equations. The current specification doesn't say anything about this. ... (there are typically at least 4 or 5 aliases for a given pressure in a Fluid model).

Prior to this the only mention of "alias" regarding variables in the specification was in 17.6 regarding annotations for unassigned variables:

A declaration may have the following annotations:annotation(unassignedMessage = "message"); ``... ``[When using BLT partitioning, this means if a variable “a” or one of its aliases “b = a”, “b = -a”, cannot be assigned, the message is displayed. This annotation is used to provide library specific error messages.]

So while the specification acknowledges that variables become aliases of each other, it does not state what is allowable. I'd like to raise the issue of other attributes for aliased variables, for most of these I have put my own assumptions:

_Type**

According to the decision regarding types of colours in #400, it is ok for an Integer and Real to be aliases. This fits with the specification for expressions, from 6.6:

If A is an Integer expression then B must be a Real or Integer expression and the type compatible expression is Real or Integer (same as B).

In this case, a Real variable that is set equal to an Integer variable should internally change it's type to Integer, something that certainly isn't clear in the specification. If aliased variables were subject to being Interface Compatible then a Real could not be equal to an Integer according to 6.3

_Variability**

The combined variability of two aliased variables is the least-varying of the two: continuous+discrete->discrete discrete+parameter->parameter etc__**_

_Causality**

If we define "normal" as neither input nor output, then the following rules should apply: _normal + normal -> normal input + normal -> input output + normal -> output input + output -> inputoutput___

_Attributes**

fixed

A variable with a fixed start condition should make any alias variables fixed.

start

The overriding start value is that highest in the model hierarchy as defined by #561.

stateSelect

StateSelect.always + StateSelect.never should be an error.

min

min of the combined variables should be the maximum of all min attributes of the variables.

max

max of the combined variables should be the minimum of all max attributes of the variables.

nominal

The overriding nominal value is that highest in the model hierarchy as defined by #561.

quantity

It is an error if the quantity attributes are incompatible. (But possibly tool-specific how this is handled?)

displayQuantity

Not combined, since each variable could be displayed independently.

---

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

[modelica-trac-importer]

Comment by hansolsson on 5 Oct 2011 10:33 UTC This is mixing two different things: aliases and type-compatibility. They should not be mixed: Everything needed about aliases is that it is an allowed optimizations as given in section 3.3 - nothing else should be added regarding aliases.

Aliases are basically two distinct variables that the tool figures out that they are identical - what a tool treats as being identical should not be specified as it is a tool-specific optimization. This allows a tool to handle simplified cases e.g. for Ohm's law:

parameter Resistance R=1; equation v=R*i

by having an alias between 'v' and 'i' in the generated code. Obviously the variables have different units - but it might not matter for the code-generation.

This is similar to a C-compiler storing two different local variables in the same register; we do not require that the generated assembly language should be type-correct.

-- A completely different issue is to require compatibility in equations, e.g., making 'v=i' illegal since we are comparing voltage and current. That is done by specifying compatibility restrictions for equations (e.g. unit-correctness) and does not involve alias-handing.

-- Obviously the same equations are both type-checked and then used for aliases; but even though there is overlap the alias-handling and compatibility-test should not be mixed.

[modelica-trac-importer]

Comment by pharman on 5 Oct 2011 10:55 UTC Yes I was wrong to put "quantity" in there, that isn't relevant.

Regarding the other attributes however, if there is a specification for "start" I see no reason why there shouldn't be a specification for other attributes. While the specification isn't there to document optimisations, which some of these (such as ensuring the lowest variability) are, the fact remains that if I define two variables and set them to being equal then it is down to the tool to decide what attributes are used. And since these are mostly pretty obvious they might as well be documented. If not we should remove references to aliasing of variables, if it is solely up to the compiler developer then there is no need for it to be mentioned in the specification.

[modelica-trac-importer]

Comment by anonymous on 5 Oct 2011 12:27 UTC I don't have anything to add on the technical point here. But I want to point out that I think it is very important that we find some resolution to this issue. Modelica needs to have some kind of test suite for verification of the standard library and this issue (along with others like "filling in" missing initial equations) prevent us from doing such testing because the answers we get vary to much from tool to tool. I can accept that different numerical methods and symbolic manipulation techniques will lead to slight variations. But start attributes and initial equations have a very significant impact on the ultimately solution found by the tool.

In summary, whether or not this mixes aliases and type-compatibility...it is an issue for users (and us) and we should figure out a way to resolve it.

[modelica-trac-importer]

Comment by mtiller on 5 Oct 2011 12:30 UTC Last comment was me, BTW.

[modelica-trac-importer]

Comment by hubertus on 5 Oct 2011 12:53 UTC I strongly agree here. Tool dependent heuristics are involved in both selection of alias variables, and state selection. In combination with the fact that the initialization problem very often is under-specified (in the case of N states, there are normally fewer than N initial conditions with either der(anyState) = 0.0 or anyState(start=x0, fixed=true)), this leads to different initialization results for different tools. In MSL, we could/should fix this by making sure that all initialization problem specifications are complete, and not depending on Dymola's specific heuristics for choosing aliases, states, and start values. For (partial) steady-state initialization, alias choice even has an influence if fixed=false, because different start values can then lead to different solutions (if there is more than one solution), or failure.

[modelica-trac-importer]

Comment by hansolsson on 5 Oct 2011 13:24 UTC Mike - I agree that there are important issues, but in order to do that we need to look at the actual issues. The actual issues involve type-compatibility etc, they should not specify special rules for aliases.

On the other hand aliases are important for efficient code-generation; but we should work on making the models such that they do not depend on these heuristics and that is best done by writing the specification so that the model is well-defined prior to alias-elimination.

Thus the resolution for #561 discusses priority of start-values in general - it is not limited to start-values that are overdetermined due to aliases.

The only use of aliases between model variables in the specification is in non-normative text explaining the annotation unassignedMessage. It would be possible to rewrite that text to not involve aliases, but to me there are more important issues to improve in the spec.

--

An additional reason we should not look at aliases can be found by looking at the concrete proposals in this ticket. Many do not make sense, e.g.:

• Variability. The variability discussed in the specification is the declared one; just because a time-varying variable happens to be alias to a parameter we should not be allowed to use it as a parameter.

In practice a variable might vary less than the declared variability; that is outside the scope of the specification. This is especially true of (discrete) real variables.

• Having stateSelect.never and StateSelect.always for variables that are alias to each other makes perfect sense. E.g. you want the state in the shaft and not in the sensor - that they are alias to each other does not matter.

Thus it seems best to not discuss aliases in the specification; but instead focus on specifying the semantics as has been done for start-values (#561). That is hard work; and it would be nice if aliases would provide convenient short-cuts, but unfortunately that is not the case.

[modelica-trac-importer]

Comment by pharman on 5 Oct 2011 14:57 UTC that is outside the scope of the specification

Yes, the specification states in 1.2 what the scope is. It then goes on to talk about mapping to execution environments, relationship between certain functions and ODE/DAE solvers, use of BLT algorithms, and annotations that relate to generating code or editing models, so what is actually within the scope seems as open to interpretation as the specification itself.