Checking for alias variables and variability

[nickbattle]

FMI Standard issue 2.0.1 included a clarification paragraph to explain the rules regarding the variability setting of collections of aliased variables. VDMCheck was enhanced to make this new check, and the following list of FMUs in the cross-check repo were found to violate the rules:

alias_errors.txt

See modelica/fmi-standard#436

[chrbertsch]

@nickbattle : Thanks!

IMHO this is a case where it is great to have a checker that is very strict to provide a warning, but we should not remove these FMUs from the FMI 2.0 XC repository, as the clarification came only in FMI 2.0.1

It is most important that the relevant tool vendor change this for the future.
If see it right: only Dymola/CATIA and OpenModelica are involved, right?
So I will forward this issue to Dassault (@KarlWernersson , @hv3ds) and OpenModelica (@sjoelund , @lochel)

Update: For OpenModelica I created: https://trac.openmodelica.org/OpenModelica/newticket#ticket and I have sent an Email to Dassault.

[nickbattle]

@chrbertsch OK, I'll downgrade the VDMCheck for this to be a warning (ie. if this is the only problem, it will report "No errors found"). Yes, I can confirm that it is only the three tools that you mentioned.

[nickbattle]

VDMCheck 0.0.2 build 191016 now treats the new 2.0.1 errors as warnings:

------------------------------- ./me/win64/CATIA/R2016x/ControlledTemperature/ControlledTemperature.fmu
2.2.7 Warning: aliases of reference 16777218/Real must all be <tunable>, because of "constantVoltage.V"
2.2.7 Warning: aliases of reference 100663309/Real must all be <continuous>
2.2.7 Aliases of reference 335544321/Real must all have same unit/baseUnits
2.2.7 Invalid ScalarVariable aliasing
2.2.1 Effective ScalarVariables invalid
Errors found.

https://github.com/INTO-CPS-Association/FMI2-VDM-Model/releases/download/0.0.2-1/vdmcheck-0.0.2-191016-distribution.zip

[t-sommer]

If we can agree on a hard rule, I will add it to CI.

@nickbattle, can you post the code you're using to detect the issue?

[nickbattle]

@t-sommer Well, it's not "code" exactly: it's a set of rules expressed in VDM-SL. But it's sufficiently code-like that you can hopefully make sense of it:

/*
 * 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.
 */
 let vars = { a.variability | a in set aliases } in
 	if exists a in set aliases & a.causality in set {<input>, <parameter>}
 	then
 		let a in set aliases be st a.causality in set {<input>, <parameter>} in
 			/* @OnFail("2.2.7 Warning: aliases of reference %s/%s must all be %s, because of %s",
				ref.#1, ref.#2, a.variability, a.name) */
			( vars = { a.variability } ) or true
 	else
 		let highest in set vars be st not exists v in set vars & v > highest in
			-- @OnFail("2.2.7 Warning: aliases of reference %s/%s must all be %s", ref.#1, ref.#2, highest)
 			( vars = { highest } ) or true

In English: vars is the set of variabilities of the aliases (which are a set of SVs of the same type and reference). If there is a special alias in the set that is "input" or "parameter", then the vars set must be a single value that is the same as the variability of that SV. If there is no special SV, "highest" is set to the most significant variability in the vars set (the ordering is defined for the type, so ">" works), and the vars set has to be identical to just that one highest value.

Note that earlier tests eliminate the case of having both "input" and "parameter" types in the alias set, because there is a rule that an alias set can only have one SV that is "settable" (rule 1 on p52).

The last test is rather literal from the standard. You could just say that the set of variabilities has to be a single value, but in the case of errors (where there are multiple variabilities) it's useful to tell the user what the highest is.

The @OnFail annotations produce output if the expression annotated is false. The "or true" clauses are to force this never to happen because these are warnings now.

[nickbattle]

@t-sommer PS. I hate to quibble, but these things come up when you express rules formally...

The rule 1, regarding settable aliases, excludes the case of having both "input" and "parameter" types in the alias set. But it says hte exclusion are variables that can be set with fmi2SetXXX. In the case of "parameter" types, this can mean that they are both "parameter" and "tunable" (rule 4 on p88 or rule 6 on p88, depending on the state).

So perhaps you could have a parameter that was not tunable and an input variable in the same alias group? In which case, what should be the variability of the group be: that of the "input" or that of the "parameter"? Or should the alias rule be for "tunable parameters" and inputs?

[HansOlsson]

I commented on the specification itself in modelica/fmi-standard#436

However, for the cross-checker the most important issue is that the variability-text (as far as I can tell) is non-normative, and thus not something we should reject models based on - even for 2.0.1.

[nickbattle]

@HansOlsson These checks have been downgraded to warnings only now, so they will not fail an FMU by themselves (in VDMCheck).

[lochel]

Update: For OpenModelica I created: https://trac.openmodelica.org/OpenModelica/newticket#ticket and I have sent an Email to Dassault.

@chrbertsch I cannot find the ticket you mentioned above. Can you please send me the ticket number?

[chrbertsch]

@chrbertsch I cannot find the ticket you mentioned above. Can you please send me the ticket number?

Thanks, I seem not to have sent the ticket mentioned above. I have done it now: https://trac.openmodelica.org/OpenModelica/ticket/5673
@lochel : Thanks in advance for looking into this; looking forward to see OpenModelica join the FMI XC effort ...