Issue with wrong variability of function output in NF

[Francesco Casella]

Please check ​Modelica.Media.Examples.ReferenceAir.Inverse_sh_T. The following error is reported:

[OMCompiler/build/lib/omlibrary/Modelica 3.2.2/Media/package.mo:4454:5-4455:33:writable]
Error: Component nS of variability constant has binding 
'size(Modelica.Media.Air.ReferenceAir.Medium.substanceNames, 1)' 
of higher variability parameter.

The arguments of the size() function are all constants, so the output variabiliy should be constant too, not parameter.

[Per Östlund]

Fixed in 1769e702, at least in a way I consider the reasonable way to handle this situtation (see ​Modelica ticket #2240). I.e. size(A, j) uses the variability of dimension j of A when deciding the variability of the size expression, instead of the variability of A itself.

This means that size will only be a constant expression if both j and dimension j of A (regardless of the variability of A itself) is constant, but this does seem to be the case in the MSL at least.

[anonymous]

I am seeing the same error here:
​https://libraries.openmodelica.org/branches/newInst/HelmholtzMedia/files/HelmholtzMedia_HelmholtzMedia.Examples.MediaTestModels.ButaneTestModel_dT.err

The function f_r is here:
​https://github.com/thorade/HelmholtzMedia/blob/master/HelmholtzMedia/Interfaces/PartialHelmholtzMedium/EoS/f_r.mo
And the value arrays are defined e.g. here:
​https://github.com/thorade/HelmholtzMedia/blob/master/HelmholtzMedia/HelmholtzFluids/Ethanol/package.mo

So, the array is final constant, and the second input to size() is an integer literal.
Should this work?

[Francesco Casella]

I guess so, @perost?

[Per Östlund]

I don't know if that should work or not, since as mentioned size is poorly specified. But it's also unclear what variability function parameters actually have. They can be declared with a variability prefix whose semantics is unspecified, but the input arguments could also be considered constant in the scope of the function, etc. Dymola doesn't seem to care about variability inside functions at all, and we should possibly do the same.

[Francesco Casella]

If the specification is silent on the topic and a tolerant (i.e. Dymola-like) approach is not difficult to implement, I would go for that.

If the model breaks because of modelling issues that could be detected by a stricter variability analysis, blame the model developer. Otherwise people will blame OMC for not running models that run in Dymola :)