The NF incorrectly infers the variability of a function call in Modelica.Media

[Francesco Casella]

Please check ​Modelica.Media.Examples.ReferenceAir.MoistAir1. The NF fails with

[Modelica 3.2.3/Media/package.mo:4985:5-4989:75:writable] Error: 
Component h_default of variability constant has binding 
'Modelica.Media.Examples.ReferenceAir.MoistAir1.Medium.specificEnthalpy_pTX(Medium.p_default, Medium.T_default, Medium.X_default)'
of higher variability parameter.

The offending code is found ​here:

    constant SpecificEnthalpy h_default=specificEnthalpy_pTX(
            p_default,
            T_default,
            X_default)

Obviously, if all the inputs to the function are constant, so should be its output.

[Per Östlund]

As discussed in the developer meeting this is due to #5133 where impure functions are considered to have at least parameter variability to avoid evaluating them, #6030 which considers functions that call impure functions to be impure themselves, and the assumption that external functions which are not marked pure/impure are impure.

Since Modelica.Streams.error isn't marked as pure in MSL 3.2.3 (something which has been fixed in MSL 4.0.0) it's considered to be impure by the NF, which causes specificEnthalpy_pTX to also end up being impure and thus a parameter expression.

So several things needs to be fixed:

1. Impure functions should be able to be constant expressions.
2. Impure calls should not be evaluated. We currently try to achieve this with various workaround, but a better solution would be to determine not only the variability but also the purity of expressions. This would also be beneficial for things like iterators that could be considered impure.
3. Assuming that external functions are impure if not marked otherwise is deprecated in Modelica 3.3, and external functions are required to be marked pure/impure. The NF should give a warning if that's not the case. We need to change how the pure/impure prefix is stored for this since it's currently a Boolean, which means we can't distinguish between pure and no prefix.

This won't be fixed anytime soon due to vacations, so in the meantime I've temporarily fixed the issue by hard coding the ModelicaError external call to be pure (which it's supposed to be anyway) in d15abc5.

[Francesco Casella]

Replying to perost:

Since Modelica.Streams.error isn't marked as pure in MSL 3.2.3 (something which has been fixed in MSL 4.0.0) it's considered to be impure by the NF, which causes specificEnthalpy_pTX to also end up being impure and thus a parameter expression.

I double-checked the release notes. MSL 3.2.3 is meant to be compatible with Modelica 3.2 revision 2. However, I understand what Modelica 3.3 introduced was to make it compulsory to explicitly declare external functions as pure or impure, but you could do it anyway even in Modelica 3.2 rev2, right?

If that is the case, you can open a PR on MSL 3.2.3 maintenance branch and add the required pure markers. I already pushed several other bug fixes to MSL 3.2.3 maintenance to improve the coverage, and we already pick our MSL 3.2.3 version from the the maintenance branch, so that would work even before we officially release MSL 3.2.3+build.5

@perost, what do you think?

This won't be fixed anytime soon due to vacations, so in the meantime I've temporarily fixed the issue by hard coding the ModelicaError external call to be pure (which it's supposed to be anyway) in d15abc5.

That's good, in the meantime we'll get our figures to improve anyway :)

[Per Östlund]

Replying to casella:

Replying to perost:

Since Modelica.Streams.error isn't marked as pure in MSL 3.2.3 (something which has been fixed in MSL 4.0.0) it's considered to be impure by the NF, which causes specificEnthalpy_pTX to also end up being impure and thus a parameter expression.

I double-checked the release notes. MSL 3.2.3 is meant to be compatible with Modelica 3.2 revision 2. However, I understand what Modelica 3.3 introduced was to make it compulsory to explicitly declare external functions as pure or impure, but you could do it anyway even in Modelica 3.2 rev2, right?

No, the pure/impure prefixes were added in MSL 3.3. And MSL 3.2.3 says that it's Modelica 3.2 rev2 compliant as you say, so it should not use those prefixes.

[Francesco Casella]

OK, now I remember that. Section 12.3 was not really clear, and that lead to all the pure/impure stuff in Modelica 3.3.

I guess the ModelicaError hack is here to stay for a while :)

[Francesco Casella]

Should still be fixed properly, but no longer a blocker for 1.16.0