Fix #4312

[HansOlsson]

Avoid chattering in Modelica.Fluid.Examples.TraceSubstances.RoomCO2WithControls
This should correct the issue in #4312 while keeping the improvements.

It would be better if we could understand the original paper - a concern is that we are adding layer upon layers of extras.

[HansOlsson]

Closes #4312

[maltelenz]

Using WSM, not only does this change not fix RoomCO2WithControls, it also breaks these (in either simulation or correctness checking) which work without the change:

Modelica.Fluid.Examples.AST_BatchPlant.BatchPlant_StandardWater
ModelicaTest.Fluid.TestComponents.Vessels.TestMixingVolumesPressureStates
ModelicaTest.Fluid.TestPipesAndValves.BranchingPipes16

I didn't dig closer (only ran our existing tests).

I would be interested in OpenModelica effects (or any other tool) for all Fluid-related tests with this change.

[HansOlsson]

Using WSM, not only does this change not fix RoomCO2WithControls, it also breaks these (in either simulation or correctness checking) which work without the change:

Modelica.Fluid.Examples.AST_BatchPlant.BatchPlant_StandardWater
ModelicaTest.Fluid.TestComponents.Vessels.TestMixingVolumesPressureStates
ModelicaTest.Fluid.TestPipesAndValves.BranchingPipes16

I didn't dig closer (only ran our existing tests).

I can also see differences in the results for these models (as indicated I didn't test it that completely).
So, instead of adding layer upon layer of work-arounds it may be that we should remove one of them - specifically the if-clause below:

      if abs(theta0 - c) < 1e-6 then
        // Slightly reduce c in order to avoid ill-posed problem
        c := (1 - 1e-6)*theta0;
      end if;
      rho := 3*(Delta0 - c)/(theta0 - c);

This seems to be causing the problems further down - in the original problem we had:

Delta=0.001
theta=0.00100053333
c=0.00099973333

and now we change c0 to 0.001005323 to allegedly avoid an ill-posed problem, causing rho to change from practically 1 to -1596.

Basically we are trying to increase the difference between c and theta0 - but end up decreasing it!

[HansOlsson]

I changed to use a relative test, matching the fact that we do a relative decrease - and removed the other code.
(As it in some sense guarded against this bad intermediate result.)

As far as I could see RoomCO2WithControls, and the three regressions all run with correct results - and the original problem causing the change is also gone.

A potential down-side of using a relative test is that if c is zero it will never trigger, but:

• Either theta0 is also zero and the code will cause a division by zero with and without this change (I believe previous tests avoid that).
• or theta0 is not zero in which case using c:=0.999999*theta0; instead of zero would make it more - not less - ill-posed.

However, I don't know if this (updated) test is actually useful, but it seems less harmful.

[maltelenz]

Again running tests without digging deeply, for WSM, the newest iteration:

• Fixes RoomCO2WithControls
• Fixes ModelicaTest.Fluid.TestComponents.Fittings.TestMultiPortTraceSubstances (we used to get results not matching the reference)
• Makes ModelicaTest.Fluid.TestPipesAndValves.BranchingPipes18 go from a simulation failure because of event jittering, to a correctness failure

So looks more promising than the first round.

[maltelenz]

• Makes ModelicaTest.Fluid.TestPipesAndValves.BranchingPipes18 go from a simulation failure because of event jittering, to a correctness failure

This was just a sampling issue, so this also went from simulation being stuck to completely fixed.

I don't know anything about the function being changed, nor do I have any experience in fluid modeling, but from the point of view of working tests in System Modeler, this change is great.

Let me know if you want me to leave an approving review, although it would be better if the library officers did that.

[casella]

@HansOlsson, @maltelenz thanks for working on this, and sorry for the delay in giving feedback, last two weeks have been horribly busy.

Before checking this PR I made some further analysis of the chattering @HansOlsson, @maltelenz, thanks for working on this.

Before looking into this PR, I made some further analysis on the RoomCO2WithControls model. The chattering was caused by ductIn.m_flows[3] behaving badly around zero dp/zero flow, where that variable is computed by a function call

ductIn.m_flows[3] :=
  Modelica.Fluid.Examples.TraceSubstances.RoomCO2WithControls.ductIn.flowModel.WallFriction.massFlowRate_dp_staticHead(
  ductIn.flowModel.dps_fg[3], ductIn.flowModel.rhos[3], ductIn.flowModel.rhos[4], ductIn.flowModel.mus[3], 
  ductIn.flowModel.mus[4], 1.25, ductIn.dimensions[2], ductIn.flowModel.g * ductIn.flowModel.dheights[3],
  ductIn.crossAreas[2], ductIn.roughnesses[2], ductIn.flowModel.dp_small / 3.0, 4000.0)

that internally relies on regfun3. As I already commented earlier on, e.g. here, the Modelica.Fluid code uses functions that are supposed to smooth things out around potentially critical points, e.g. zero flow, zero dp, transition from small to non-small dp, transition from laminar to turbulent, etc. If the smoothing doesn't work, then the model won't work either.

Reviewing the implementation of regfun3 would probably take me one or two full days of work, and I really cannot afford that now. It seems to me that @HansOlsson knows what he's doing, so I trust him that is fix is good, at least in principle.

I checked RoomCO2WithControls in OpenModelica with the fixes provided by this PR and the simulation went through fine. I also checked the models that @maltelenz mentioned, and they worked fine.

I would suggest to merge this fix on master, so we can see what happens when testing the whole library. If we don't get any bad surprises, we can back-port this PR to 4.1.0 and close this issue for good.

[casella]

@maltelenz please approve the PR so we can move forward. Thanks!

[maltelenz]

Approving as requested.

[casella]

Let's see what happens when testing the master branch in OpenModelica tonight. Results will be available in these reports:

• Modelica - compare with Modelica_trunk test using OpenModelica.zip
• ModelicaTest - compare with Modelica_trunk test using OpenModelica.zip

[casella]

The relevant regression report of OpenModelica is available here. Modelica_trunk (i.e. the version of Modelica on the master branch) shows Modelica.Fluid.Examples.TraceSubstances.RoomCO2WithControls going from Compile to Verify, which means the fix allowed to successfully simulate and verify the model against the reference results.

No regressions of sort are visible in Modelica_trunk, which means that the fix to regfun3 had no bad side effects.