modelica
Check usage of Modelica.Constants.{eps, inf, small}
Since the definitions of Modelica.Constants.{eps, inf, small} has changed, the usage of these constants has to be checked in the MSL. These constants are referring to ModelicaServices, where only a suggestion is provided. Tool vendors are supposed to provide their own implementation according to the above mentioned definition. In some cases, using these constants for comparison is correct. @HansOlsson you explained an example - could you shortly describe it here? In other cases, using these constants for comparison is dangerous with respect to giving different results with different tools. However, we should provide a note in the documentation of Modelica.Constants to inform users.
@AHaumer, based on our testing there were apparently no bad consequences of those changes in the MSL, except the Spice3 case discussed in #13010, which can be considered as a tool issue (kind of).
Today I found an interesting regression in the Buildings library, when using MSL 4.1.0 instead of MSL 4.0.0, see the discussion in OpenModelica/OpenModelica#13960. As far as I understand, the same regression should be also observed in Dymola and WSM, @HansOlsson @henrikt-ma please confirm. Not entirely trivial to debug, took me a couple of hours to figure out.
Having a custom flag in tools to restore the previous MSL 4.0.0 behaviour while using MSL 4.1.0, as proposed by @HansOlsson, kind of solves the problem, but it's a hackish, tool dependent approach, since we have no tool-independent annotation to enforce this. This can lead to models that may or may not work in different tools for very subtle reasons, as demonstrated by the above-mentioned case. Which goes against the idea of a Modelica Standard Library.
The root cause of all this is that the change in #4042 was not backwards compatible. It's as simple as that. This was really not a wise decision, IMHO. It should have been delayed to the next major revision.
Too late to change that, alas. We'll live with the consequences. Hopefully, it will only be a few corner cases.
As far as I understand, the same regression should be also observed in Dymola and WSM
Yes, we reported this to the library developers here and here, and as mentioned in https://github.com/OpenModelica/OpenModelica/issues/13960#issuecomment-2920444241 it was fixed in IBPSA and Buildings.
@AHaumer, based on our testing there were apparently no bad consequences of those changes in the MSL, except the Spice3 case discussed in #13010, which can be considered as a tool issue (kind of).
Today I found an interesting regression in the Buildings library, when using MSL 4.1.0 instead of MSL 4.0.0, see the discussion in OpenModelica/OpenModelica#13960. As far as I understand, the same regression should be also observed in Dymola and WSM, @HansOlsson @henrikt-ma please confirm. Not entirely trivial to debug, took me a couple of hours to figure out.
Having a custom flag in tools to restore the previous MSL 4.0.0 behaviour while using MSL 4.1.0, as proposed by @HansOlsson, kind of solves the problem, but it's a hackish, tool dependent approach, since we have no tool-independent annotation to enforce this. This can lead to models that may or may not work in different tools for very subtle reasons, as demonstrated by the above-mentioned case. Which goes against the idea of a Modelica Standard Library.
Well, even if I recognize those issues, as I see it there are advantages with that solution even from the MAP-Lib perspective:
- It makes it easy to check whether that change was indeed the problem (if you have Dymola :-) ); so users will spend less time investigating other potential issues.
- It is also easier to check that it has been corrected in your models (just turn off the flag and re-test).
- Users are more likely to upgrade to 4.1.0 when we have a solution for potential issues.
The risk would be that users don't correct the models, but keep relying on the flag. I agree that outcome would be unfortunate, but I don't find the risk that large - and without the flag there would be a severe risk that users would stay on MSL 4.0.0 forever. And, if that risk materializes the next step would be to introduce some form of conversion for the constants to make it easier to upgrade the models.
We can, of course, relitigate https://github.com/modelica/ModelicaStandardLibrary/pull/4042 but remember that it contained two changes that can be considered separately:
- Change in the description text to be compatible with the C-standard, instead of having our own less clear definitions (de-normalized numbers, rounding for half-eps etc).
- Change of the values in the default ModelicaServices. As I understand it some tools already had different values in their version of ModelicaServices, so instead of tool-differences by default they are now on a flag.
