Issues with Modelica.Media.Examples.SolveOneNonlinearEquation.InverseIncompressible_sh_T at t=1

[JohannesKrauseGitH]

The model Modelica.Media.Examples.SolveOneNonlinearEquation.InverseIncompressible_sh_T (MSL 4.0 and MSL4.1) fails to simulate with some solvers of SimulationX at t=1:

Error: Help: Modelica.Assert
 
in function Modelica.Utilities.Streams.error
The arguments u_min and u_max provided in the function call
    solveOneNonlinearEquation(f,u_min,u_max)
do not bracket the root of the single non-linear equation 0=f(u):
  u_min  = 243.15
  u_max  = 373.15
  fa = f(u_min) = -477465
  fb = f(u_max) = -3.49246e-10
fa and fb must have opposite sign which is not the case

I have noticed that this issue has already be reported (and fixed) some time ago, see #401 and 42f8091.

Apparently, that fix is not used in the MSL4 anymore. The fixed function (replaceable function solve) has been moved to ObsoleteModelica4.mo and the new function, solveOneNonlinearEquation in Modelica.Math.Nonlinear does not have that fix.

[HansOlsson]

That's not good, but since it "just" a test-case in MSL it's not critical (see also below).

As far as I can see the reason was that we originally had two solve-variants (one weird with packages due to restrictions in the language/tools and one good one with function-argument) and the original correction was only applied to the weird one, and when the restrictions were removed and we switched to the better structured solve-variant we forgot those improvements.

To me there are some conclusions (in addition to just fixing the issue):

• It's a common problem for duplicated code, where patches are only applied to one of them; so be careful in such cases.
• Any bug-fix like 42f8091 should ideally contain some test-case that would trigger without the bug-fix to reduce the risk of the bug re-appearing. Since this issue depends on the solver (which is tool-dependent), one possibility is to consider how to have tool-specific tests in ModelicaTest - another is to explicitly introduce numerical noise in the test.
• Testing the entire MSL with multiple tools and solver is good, and I understand that LTX is working on that for tools (for continuous testing - not only for releases); but we might extend it to other solvers as well.
• To me the testing-structure in the package Modelica.Media.Examples.SolveOneNonlinearEquation is fragile. If we want to ensure that we go from min to max and not leave that range I think we should replace

  SI.SpecificEnthalpy h1(start=h_min, fixed=true) 
    "Pre-defined specific enthalpy";
  SI.SpecificEntropy s1(start=s_min, fixed=true) "Pre-defined specific entropy";
equation
  // Define specific enthalpy and specific entropy
  der(h1) = if time < 1.0 then 1/timeUnit*(h_max - h_min) else 0.0;
  der(s1) = if time < 1.0 then 1/timeUnit*(s_max - s_min) else 0.0;

by something like:

  SI.SpecificEnthalpy h1 "Pre-defined specific enthalpy";
  SI.SpecificEntropy s1 "Pre-defined specific entropy";
protected
  Real fraction(final start=0, fixed=true);
equation 
  // Define specific enthalpy and specific entropy
  der(fraction)=1/timeUnit;
  h1=h_min+(h_max-h_min)*min(1, fraction);
  s1=s_min+(s_max-s_min)*min(1, fraction);

(One could have fraction=time/timeUnit as well, but then use min(1, max(0, fraction)) - and even possibly have saturation in the fraction definition: fraction=min(1, max(0, time/timeUnit)) , but I see some benefits in having as a state. One could keep the if-statement for der(fraction) - but it shouldn't matter.)

Note that I referenced the entire package, since this is another case of duplicated code (for 3 of the 4 models), and there's already a state-less variant in Modelica.Media.Examples.ReferenceAir.Inverse* (with asserts!).

[maltelenz]

For the record, System Modeler shows similar behavior (error) as SimulationX.

Edit:

since it "just" a test-case in MSL it's not critical

While I can understand that it may not cause errors in user models, it isn't exactly good marketing if not even the examples work :)