4

I have some test simulations that, when run, do not follow the exact same solution path when run in Dymola 2021x and Dymola 2022. Thus, my system that checks to make sure my test simulations are running properly indicates that they are in fact not running properly. It appears that the simulations are still within +/-2*tolerance of each other. I am attempting to learn why it would be that the solutions are not numerically identical if they inputs and models are identical. Nothing in the update release indicated that there were any solution method changes.

Dmmikkel
  • 61
  • 1
  • 1
    I did not use either versions of Dymola. But I would compare both automatically generated simulation input files, dsin.txt. This may hint what is being different. Also you did not say anything about the numerical solver you are using. Is it a particular solver? or are the numerical differences associated with any solver? – Atiyah Elsheikh Jul 27 '21 at 12:44
  • I think you could ignore it if the result is acceptable – Jack Aug 04 '21 at 13:41
  • Can you tell if one solution is more accurate than the other? – Dag B Aug 26 '21 at 13:40

1 Answers1

4

From the Dymola 2022 Release Notes, one possible explanation could be in the different Modelica Language Specifications (3.4 in Dymola 2021x, 3.5 in Dymola 2022), either affecting the models directly (MSL 4.0.0 is compliant with the Language Specification 3.4, for example), or the way the models are handled during translation.

You mention you have a system in place that checks your simulation. Is it implemented in Modelica, that is, might it be affected by the different Language Specifications?

Personally, I tend to expect in each release minor changes/improvements in the translation algorithms and in the solvers; even though they might not be mentioned in the release notes. Perhaps this attitude only works because my models are rather coarse, so I cannot really say whether such a change in the computed solution (+-2*tolerance, tolerance=0.1% in my case) is bringing me closer or farther away from the real solution.

  • indeed, any simple change or algorithmic update that results in even a so tiny modification how e.g. formulas are symbolically manipulated or evaluated naturally leads to numerically different results. In XogenyTest library, such numeric differences should not lead to e.g. violating a unit test – Atiyah Elsheikh Jul 29 '21 at 15:53
  • Are the initial values identical? Check the translation log if both version use the same selection of states and/or are setting the same initital values to zero if no start value has been given. – Imke Krueger Jul 30 '21 at 10:45
  • I will look into the Modelica Language Specifications, that seems most plausible. We use a Python script that checks for the relative error and if it is above a threshold, we consider the test "failed". I will look into them. Our largest errors appear to be near the initialization points, so maybe I will find something new in how the language specifications treat that time. This is the first new Dymola release that we've had an issue with. – Dmmikkel Aug 04 '21 at 15:57
  • Even a change of C compiler may cause numerical differences if the model is very sensitive. – Dag B Aug 26 '21 at 13:39