Some tests fail at runtime with v.3.3.0 due to wrong error management

[casella]

@jowr, I ran some tests of v.3.3.0-dev using Dymola 2021 under Windows 10 and Visual Studio 2017 Community edition, here are the results:

• Test.CoolProp.CO2.TestStatesSupercritical runs
• Test.CoolProp.CO2.TestStatesTranscritical runs
• Test.CoolProp.CO2.TestStatesSatSubcritical hangs at runtime
• Test.CoolProp.CO2.TestBasePropertiesExplicit runs
• Test.CoolProp.CO2.TestBasePropertiesImplicit hangs at runtime
• Test.CoolProp.CO2.TestBasePropertiesDynamic runs
• Test.CoolProp.CO2.TestBasePropertiesTranscritical runs

Failing tests report this error message on the simulation runtime command window: Press the Stop button in Dymola to end the simulation!, which is called either here or here.

This is very old and very crude code that aborted the simulation immediately in case any errors were reported from the called property computation functions - it was put there back in 2006 when Christoph Richter was experimenting with DLL libraries, which do not allow to call the ModelicaError function, because it was not visible from witin the DLL, but only if the library was statically linked with the generated code from the Modelica tool.

However, aborting the simulation as soon as an error is encountered is not a good idea in general. Many errors are caused by ODE solvers taking too bold steps, or by Newton solvers taking too large undamped steps, which cause the inputs of the setState_xx function to go beyond their range of validity. If the ModelicaError function is called in this cases, as done here, then the solver can retry with a smaller step, and in many cases it will eventually succeed.

I understand the library is statically linked as of today, so I am not sure if the old code meant for the DLL is called on purpose, or because of some mistake in how the CMake scripts set up the macros.

The idea is that, in case we are using static linking, we should always call ModelicaError. If we want to compile the library into a DLL, we should change the structure of the functions that can fail so that they simpy return an error code, and then have the ModelicaError function called by a thin, statically linked layer that will in turn call the DLL functions.

Can you please comment on this?

Thanks!

[dongkeun-oh]

As @casella referred me, please have a look at #27; at least Test.CoolProp.CO2.TestBasePropertiesImplicit would work on this modification, particularly, of setSate_ph. In addition, there is an attempt to build a DLL linking SimualtionRuntimeC and omcgc, which enables ModelicaError; however, I'm not sure whether it is safe. What's about that?

[jowr]

OK - here is the current status:

• Test.CoolProp.CO2.TestStatesSupercritical runs
• Test.CoolProp.CO2.TestStatesTranscritical runs
• Test.CoolProp.CO2.TestStatesSatSubcritical fails
• Test.CoolProp.CO2.TestBasePropertiesExplicit runs
• Test.CoolProp.CO2.TestBasePropertiesImplicit runs (with Modelica error messages)
• Test.CoolProp.CO2.TestBasePropertiesDynamic runs
• Test.CoolProp.CO2.TestBasePropertiesTranscritical runs

@casella, is this what you wanted to see? Can we close this issue?

[dongkeun-oh]

Hmm.. you (@jowr) said that "Test.CoolProp.CO2.TestStatesSatSubcritical fails".
Isn't "fails" a typo? Otherwise, what kind of issue does it have?
I just find that it works without a trouble.. So, I'm just curious..

[jowr]

Hm - it was not a typo:

Do you use the same old version of CoolProp or are you running your updated code?

[dongkeun-oh]

Uh-oh.. It's the version 6 (the latest one) with my update for REFPROP backend; the other part is the same.
And, it is running in OpenModelica.

[dongkeun-oh]

One more thing! The ExternalMedia library is also my updated one in PR #27. FYI!

[casella]

* Test.CoolProp.CO2.TestBasePropertiesImplicit runs (with Modelica error messages)

This is ok, I understand the implicit solver makes some attempts that call the property calculations outside their range, so if this is now handled correctly via calls to ModelicaError, that's the intended behaviour.

[casella]

This is a bit weird, I don't understand who is issuing this error message T is not a valid number, the string "is not a valid number" cannot be found in the Modelica and C source files.

@jowr, is this a known error message of CoolProp?

Then, there could be some issue with the solver that passes an invalid value to the CoolProp solver in the temperature field, e.g., NaN. No idea why, but we can investigate.

Could this be related to #34 in some way?

[casella]

@jowr, in any case, any such remaining issue is beyond the scope of this ticket. Please let me check with the CI binaries as soon as they're available, then I'll close this myself.

[jowr]

@casella did you check with the CI binaries? Can we close this issue?

[jowr]

OK - I consider this closed. Should we release v3.3.0?