Clarification of alias variables (and variability)
Closed this issue · 14 comments
Reported by christian.winther on 6 Jun 2018 15:53 UTC
Question about alias variables. Say that I have two ScalarVariables that have the same value reference and the same type and thus are alias variables. Is it then legal for the two variables to have different variability?
I've been looking through the specification (both 1.0 and 2.0) and cannot see anything that specifically says it is illegal and also the compliance checker does not currently report an error for it but to me it seems that it should be illegal.
Migrated-From: https://trac.fmi-standard.org/ticket/436
I would not say that its good practice, but the most simple solution would be to assume and define the highest variability in that case, i.e continuous>discrete>tunabel>fixed.
Since they are a subset of each other this should not be an issue.
If one wants to be super safe at import they could assume the lowest variability.
Decision: move to 3.0
FMI Design meeting Regensburg:
First paragraph on p51. of FMI 2.0 spec says that this would not be problem.
Third paragraph creates confusion. Should be clarified.
@KarlWernersson : Could you have look at it and come up with a proposal? If necessary please create a new ticket for FMI 3.0
So section 3 talks about variablity, and section 1 talks about causality so i dont see the crash.
Basicaly you can only have multiple aliases between local, output and calcualted parameters, A set of aliases can include maximum of one parameter or input.
if you have an input or a parameter, in the set of aliases, the variability must be controlled by the variability of the parameter/input.
If you dont have any input/parameter in the alias group then you can only retrieve values. Then the variability must be governed by the highest variability in this set of aliases, as this would be the lest intrusive option. (since it is always allowed to call get on any variability)
Start Values are coverd by section2.
So new normative text.
In case of different variability among the set of alias variables,
and that set of aliases do not contain a input or parameter,
the variability should be the highest of the variables in the set, e.g. continuous > discrete > tunable >fixed.
If the set includes a parameter or input the aliases will have the stated variability of that parameter or input
Closing as included in PR #579
This rule is now verified in VDMCheck, given that this has appeared in the 2.0.1 standard, Quite a few FMUs in the cross-check repository have issues (unless I have misinterpreted the rules), for example:
------------------------------- ./me/win64/Dymola/2017/CoupledClutches/CoupledClutches.fmu
2.2.7 Aliases of reference 16777252/Real must all be <fixed>, because of "fixed.phi0"
2.2.7 Aliases of reference 637534234/Real must all be <continuous>
2.2.7 Invalid ScalarVariable aliasing
Here, "fixed.phi0" is a fixed parameter, so all its aliases must be, and 637534234/Real aliases are both discrete and continuous, and so should all be continuous.
Looks like 125 of 692 FMUs have some sort of aliasing issue here. The results have been updated on the VDMCheck release page.
Correction: 175 FMUs have errors (the 125 is just for Real aliases, but there are other types).
@t-sommer Are these FMUs also candidates for the "notCompliantWithLatestRules" treatment?
@t-sommer Are these FMUs also candidates for the "notCompliantWithLatestRules" treatment?
Potentially, yes. Please open an issue on modelica/fmi-cross-check.
I think we should revisit this issue for two reasons:
Looking at the new text it says (as non-normative text - so I don't see that it should be checked at all):
"In case of different variability among the set of alias variables, and if that set of aliases does not contain an input or parameter, the variability should be the highest of the variables in the set, e.g. continuous > discrete > tunable >fixed. If the set includes a parameter or input the aliases will have the stated variability of that parameter or input."
I believe this should be reconsidered and reformulated, because:
- For variables produced by the FMI it should be the least variable that defines the actual variability. The reason is that even though a continuous variable is allowed to change all the time, it doesn't have to change between external events. So if a continuous variable and a tunable are aliases both are consistent with the value not changing between external events, i.e. it is as if it were tunable.
- The generating tool can, of course, change the variability of these variables, e.g. to make them consistent. If the intention is that all of the alias-variable should have the same variability (which I find excessive - but what the cross-checker seem to check) then the tools should likely also choose the lowest variability - and the specification should just say that all aliases should have the same variability.
superseded by #807