Models amenable to cross-compilation with different Modelica tools should have fully specified initial conditions

[casella]

The situation with ClaRa_dev testing in OMC is starting to get reasonable, as far as simulation success ratio is concerned; currently, this is at 90%, which is not too bad.

Verification success is much lower, around 38%. I checked some results, as I understand a certain number of failures is due not completely specified initial conditions.

For example, check the compilation log of ClaRa.Components.FlueGasCleaning.Desulfurization.Check.Test_FlueGasCleaning. At some point it reports:

Warning: Assuming fixed start value for the following 56 variables:
         deSO_ideal_L1_1.bulk.h:VARIABLE(start = deSO_ideal_L1_1.h_start unit = "J/kg" fixed = true nominal = 1000.0 stateSelect=StateSelect.prefer )  "Specific enthalpy" type: Real
         deSO_ideal_L1_1.bulk.xi[1]:VARIABLE(min = 0.0 max = 1.0 start = deSO_ideal_L1_1.xi_start[1] unit = "1" fixed = true nominal = 1.0 stateSelect=StateSelect.prefer )  "Mass fraction" type: Real [9]
         deSO_ideal_L1_1.bulk.xi[2]:VARIABLE(min = 0.0 max = 1.0 start = deSO_ideal_L1_1.xi_start[2] unit = "1" fixed = true nominal = 1.0 stateSelect=StateSelect.prefer )  "Mass fraction" type: Real [9]
...

This happens because there are not enough fixed = true attributes or initial equations to completely specify the initialization problem, so the tool uses some heuristics to add them to the model. The heuristics used by Dymola are not published, so it is likely that other tools (including OMC) choose different ones. Or even that the heuristics of a given tool change over time with different versions of the software.

In order to test ClaRa properly across tools, it is really necessary to make sure that the models have fully specified initial conditions. You may do so by manually setting fixed = true on the variables that Dymola automatically sets to fixed = true, or use other options of your library for determining initial equations. The important thing is that the choice of these initial equations is not left to the tool, otherwise it's fairly likely that you get different results.

[AlesVojacek]

If I look at the comparison e.g. of the mentioned Tester: https://[libraries.openmodelica.org/branches/master/ClaRa_dev/files/ClaRa_dev_ClaRa.Components.FlueGasCleaning.Desulfurization.Check.Test_FlueGasCleaning.diff.html](https://libraries.openmodelica.org/branches/master/ClaRa_dev/files/ClaRa_dev_ClaRa.Components.FlueGasCleaning.Desulfurization.Check.Test_FlueGasCleaning.diff.html)

I see mentionable error only for variables deNOx.bulk.h and deNOx.bulk.h. However, when I simulate it in OpenModelica, the results of these variables are comparable to the reference (Dymola), in another words the actual values (OM) of the variables deNOx.bulk.h and deNOx.bulk.h plotted in the report seems to be wrong. Can someone look at it? Maybe that could be the case for more reports and likely we will see more examples to pass.

In any case, In ClaRa library there are different ways to initialize the models, e.g. for the VLE (vapor-liquid equilibrium) or Gas models with volumes (, which are used in mentioned tester above) and where p (pressure), h (enthalpy), xi (mass fraction) are states we have following options:

NoInit: imposing no initial equations (default) (initOption==0) Steady p and Steady h (initOption==208) Steady p (initOption==201) Steady h (initOption==202)

And for all these options we set the start values fixed = false.

I observed so far is that OpenModelica cannot initialize many of the ClaRa testers, unless one set NoInit, i.e. setting no fixed=true to the states. Maybe setting much better initial start values.

Another true is that we have not considered adding an option of having fixed = true. However, there one would need to be careful, because depending on the boundary condition of the tester, one can run into over specified initialization problem.

[casella]

If I look at the comparison e.g. of the mentioned Tester: https://[libraries.openmodelica.org/branches/master/ClaRa_dev/files/ClaRa_dev_ClaRa.Components.FlueGasCleaning.Desulfurization.Check.Test_FlueGasCleaning.diff.html](https://libraries.openmodelica.org/branches/master/ClaRa_dev/files/ClaRa_dev_ClaRa.Components.FlueGasCleaning.Desulfurization.Check.Test_FlueGasCleaning.diff.html)

I see mentionable error only for variables deNOx.bulk.h and deNOx.bulk.h.

There are also errors in the beginning for other variables, e.g. e_Filter_dynamic.bulk.h.html

However, when I simulate it in OpenModelica, the results of these variables are comparable to the reference (Dymola), in another words the actual values (OM) of the variables deNOx.bulk.h and deNOx.bulk.h plotted in the report seems to be wrong. Can someone look at it? Maybe that could be the case for more reports and likely we will see more examples to pass.

I'm not sure why you claim that the results are comparable. I just ran ClaRa.Components.FlueGasCleaning.Desulfurization.Check.Test_FlueGasCleaning with Dymola 2023 and OpenModelica 1.23.0-dev-151, and I obtained the following results for deNOx.bulk.h:

The blue curve is Dymola's result, while the red curve is OpenModelica's. This is perfectly consistent with what we get on our CI

As far as I understand, the problem here is precisely that the initial condition which is automatically picked by OpenModelica is different from the one picked by Dymola, apparently because it applies fixed = true to a variable that has the default 0 start attribute.

Please note, this automatic picking feature is not specified in the Modelica standard, so different tools can legitimately obtain different results.

Another true is that we have not considered adding an option of having fixed = true. However, there one would need to be careful, because depending on the boundary condition of the tester, one can run into over specified initialization problem.

If you want the same results across tools, and particularly if you want the verification tests of the OSMC CI to be reliable indicators of the quality of OMC on your library, the only way to get it to set fixed = true attributs in the code as Dymola did automatically. You don't need to do it in the library models, you can do it in the specific runnable models by adding suitable modifiers.

In fact, we could even come up with a feature in OMEdit that does it automatically for you, as long as you pass it a textual list of the variables that have fixed = true set automatically, such as the one you get from the Dymola diagnostics. Please let us know if you are interested in that.

I'm afraid there is no other way to fix this issue, given the current status of the Modelica standard 😅 .

[AlesVojacek]

That is interesting. I just ran ClaRa.Components.FlueGasCleaning.Desulfurization.Check.Test_FlueGasCleaning with Dymola 2022x and also Dymola 2023x and OpenModelica v1.23.0-dev-142-g37638a79d6 (64-bit), and I obtained the following results for

deNOx.bulk.h: Dymola (red), OM (blue)

and here comparison of deNOx.outlet.T_outflow: Dymola (red), OM (blue)

How I undestand the comparison reported in https://libraries.openmodelica.org/branches/master/ClaRa_dev/files/ClaRa_dev_ClaRa.Components.FlueGasCleaning.Desulfurization.Check.Test_FlueGasCleaning.diff.deNOx.bulk.h.html is that "Actual" is from OM and "Reference" are the results that we provided to you and they were simulated by Dymola. Or did I get it wrong?

Anyway, I am definitely interested for a feature in OMEdit that does automatically write fixed=true for variables from a list. Can we try it on this example? What I need to provide? If I look in Dymola log in translation tab I see following: The initial conditions are not fully specified.

Dymola has selected default initial conditions. Assuming fixed start value for the continuous states: deNOx.bulk.h(start = deNOx.h_start) deNOx.bulk.xi[] deSO_ideal_L1_1.bulk.h(start = deSO_ideal_L1_1.h_start) deSO_ideal_L1_1.bulk.xi[] e_Filter_dynamic.bulk.h(start = e_Filter_dynamic.h_start) e_Filter_dynamic.bulk.xi[] e_Filter_dynamic1.bulk.h(start = e_Filter_dynamic1.h_start) e_Filter_dynamic1.bulk.xi[] e_Filter_dynamic2.bulk.h(start = e_Filter_dynamic2.h_start) e_Filter_dynamic2.bulk.xi[] pipeFlowGas_L4_Simple.h[] pipeFlowGas_L4_Simple.p[]

That is what you meant? I see here that for the arrays it did not show assigned values, i.e. there should be something like pipeFlowGas_L4_Simple.h[]=pipeFlowGas_L4_Simple.h_start[] and similar for p_start and xi_start.

[AlesVojacek]

I think what needs to be also done is to update the results from Dymola, since I had to change the initialization in many ClaRa testers from "steady state" to "noInit" otherwise OM could not solve the initialization problem. Now we are comparing incomparable. We will upload the new results from Dymola.

[casella]

Sure. I guess in most cases Dymola's selection will then be the same as OMC's. But not necessarily all of them. We'll see.

[casella]

BTW, if you want to have steady-state initialization and it fails in OMC, we should figure out why this happens and fix it, rather than switch to NoInit.

[casella]

Also, I previously messed up my comment: the result of my simulations are Dymola's in blue and OMC's in red.

How I undestand the comparison reported in https://libraries.openmodelica.org/branches/master/ClaRa_dev/files/ClaRa_dev_ClaRa.Components.FlueGasCleaning.Desulfurization.Check.Test_FlueGasCleaning.diff.deNOx.bulk.h.html is that "Actual" is from OM and "Reference" are the results that we provided to you and they were simulated by Dymola. Or did I get it wrong?

It's correct.

[casella]

What I don't get is how did you get the simulation of deNOX.bulk.h to start from 782 kJ/kg. What I get is a transient that starts from zero. Maybe something changed between 1.23.0-dev.142 (that you used) and 1.23.0-dev.151 (that I'm using). One more reason to state fixed=true explicitly.

[AlesVojacek]

I have now downloaded the latest version OpenModelica v1.23.0-dev-168-gbc70ded451 (64-bit) and the results are the same as for OpenModelica v1.23.0-dev-142-g37638a79d6 (64-bit). I have just open OMEdit, load the latest ClaRa-offcial and simulated. I did not change any settings. Could be that you use different flags, or so? But, you seems to have the same results as in https://libraries.openmodelica.org/branches/master/ClaRa_dev/files/ClaRa_dev_ClaRa.Components.FlueGasCleaning.Desulfurization.Check.Test_FlueGasCleaning.diff.html. I do not understand it. What is also interesting that I have successful simulation for some of the testers, e.g. ClaRa.Basics.ControlVolumes.GasVolumes.Check.TestFlueGasCell_N_cv (sim) or ClaRa.Basics.ControlVolumes.Fundamentals.Check.Test_SmoothedDeltaTmean_log (sim),but in the reports https://libraries.openmodelica.org/branches/master/ClaRa_dev/ClaRa_dev.html it fails. And I could not reproduce the fails.

As for the change of the initialization in testers from "steady state" to "noInit" that I have introduced: For me it is okay to initialise with "noInit". It has a benefit that reduces non-linear systems at initialization, which can be sometimes quite big. For some small testers, Dymola can usually handle it, but OM usually fails. From my little experience, I have so far learned that one need to be much careful in OM, i.e. having proper structure: a volume + dp + volume + dp....., reduce non-linear systems as much as possible etc. (This is of course a case for Dymola, but it seems to be more robust at the moment). Which on hand is good that OM is more stricter, but it can become frustrating. Anyway, I have opened up an issue here on that: https://github.com/OpenModelica/OpenModelica/issues/11667