Support nonlinear equations with non-real unknowns

[Francesco Casella]

The whole HelmholtzMedia library has been passing the new frontend 100% since the beginning of 2019, see ​report, but then about one third of the models fail in the backend with this error:

Warning: SimCodeUtil.makeSES_SIMPLE_ASSIGN failed for: 
HelmholtzMedia.Examples.MediaTestModels.ButaneTestModel_dT.Medium.ThermodynamicState(
  fixedMassFlowRate.medium.sat.liq.phase, 
  fixedMassFlowRate.medium.sat.liq.T, 
  fixedMassFlowRate.medium.sat.liq.p, 
  fixedMassFlowRate.medium.sat.liq.d, 
  fixedMassFlowRate.medium.sat.liq.u,
  fixedMassFlowRate.medium.sat.liq.h, 
  fixedMassFlowRate.medium.sat.liq.s) = $TMP_HelmholtzMedia_Examples_MediaTestModels_
       ButaneTestModel__dT_Medium_SaturationProperties74.liq
[OpenModelica/OMCompiler/Compiler/SimCode/SimCodeUtil.mo:6081:7-6081:46:writable]
Error: Internal error No support of solving not real variables with a
non-linear solver.
Equation:
HelmholtzMedia.Examples.MediaTestModels.ButaneTestModel_dT.Medium.SaturationProperties(
  fixedMassFlowRate.medium.sat.psat, 
  fixedMassFlowRate.medium.sat.Tsat,   
  HelmholtzMedia.Examples.MediaTestModels.ButaneTestModel_dT.
    Medium.ThermodynamicState(
      fixedMassFlowRate.medium.sat.liq.phase, 
      fixedMassFlowRate.medium.sat.liq.T, 
      fixedMassFlowRate.medium.sat.liq.p, 
      fixedMassFlowRate.medium.sat.liq.d,   
      fixedMassFlowRate.medium.sat.liq.u, 
      fixedMassFlowRate.medium.sat.liq.h, 
      fixedMassFlowRate.medium.sat.liq.s),    
    HelmholtzMedia.Examples.MediaTestModels.ButaneTestModel_dT.
      Medium.ThermodynamicState(
        fixedMassFlowRate.medium.sat.vap.phase
        fixedMassFlowRate.medium.sat.vap.T, 
        fixedMassFlowRate.medium.sat.vap.p, 
        fixedMassFlowRate.medium.sat.vap.d, 
        fixedMassFlowRate.medium.sat.vap.u, 
        fixedMassFlowRate.medium.sat.vap.h, 
        fixedMassFlowRate.medium.sat.vap.s)) =
  HelmholtzMedia.Examples.MediaTestModels.ButaneTestModel_dT.
    Medium.setSat_p(volume.medium.p) 
solve for {fixedMassFlowRate.medium.sat.vap.h,fixedMassFlowRate.medium.sat.vap.s,
fixedMassFlowRate.medium.sat.vap.p,
fixedMassFlowRate.medium.sat.liq.s,
fixedMassFlowRate.medium.sat.psat,
fixedMassFlowRate.medium.sat.vap.T,
fixedMassFlowRate.medium.sat.liq.phase,
fixedMassFlowRate.medium.sat.liq.h,
fixedMassFlowRate.medium.sat.liq.T,
fixedMassFlowRate.medium.sat.liq.p,
fixedMassFlowRate.medium.sat.Tsat,
fixedMassFlowRate.medium.sat.vap.phase,
fixedMassFlowRate.medium.sat.liq.u,
fixedMassFlowRate.medium.sat.vap.d,
fixedMassFlowRate.medium.sat.liq.d,
fixedMassFlowRate.medium.sat.vap.u}

We should implement a basic fixed point iteration scheme, whereby we fix the non-Real variables to the start value, solve for the other ones, then re-compute the non-Real variables, and iterate until they don't change after one iteration.

@Karim, @AnHeurmann, what do you think?

[Karim Adbdelhak]

Is this just an initialization issue? Generally all discrete variables should have been torn out by tearing methods. The new minimal tearing (--tearingMethod=minimalTearing) does nothing but extracting those discrete variables, i will test that tomorrow.

For the initialization problem tearing out the discrete variables results in exactly what you described, they get initialized with the start values and it iterates until they do not change. During simulation they should not change at all except for event iterations.

Seems like a bug in tearing.

[Andreas Heuermann]

I tried with --tearingMethod=minimalTearing but of course it fails also.
The problem is, that we can't tear fixedMassFlowRate.medium.sat.liq.phase and fixedMassFlowRate.medium.sat.vap.phase of type "Integer unreplaceable" from the equation.

Inside removeSimpleEquations

55: volume.medium.state.phase:DISCRETE(min = 0 max = 2 start = 0 )  "Phase of the fluid: 1 for 1-phase, 2 for two-phase, 0 for not known, e.g., interactive use" type: Integer

will be replaced by

55: $cse3.phase:DISCRETE(protected = true )  type: Integer unreplaceable

When disabling removeSimpleEquations and wrapFunctionCalls the model will fail after code generation.

So we should check what removeSimpleEquations and wrapFunctionCalls do with this variables and make sure they can be teared from the non-linear loop.

[Francesco Casella]

Can you take care of that (without urgency)?

[Karim Adbdelhak]

Replying to casella:

Can you take care of that (without urgency)?

We looked into it and might be a false error. It should be able to simulate as is, but we are not quite sure if we overlooked something and how to correctly remove the error case. We will keep this ticket up to date if we find something new!

[Francesco Casella]

OK, thanks for the analysis!

[matthis.thorade@…]

Since this commit
​https://github.com/OpenModelica/OpenModelica/commit/80ac1a491c0b0bc5c15e878636f0f0245295830d
most models are now compiling fine, and most also simulate, some fail during initialization:
​https://libraries.openmodelica.org/branches/newInst/HelmholtzMedia/HelmholtzMedia.html

[Francesco Casella]

Yes, I guess this ticket can now be closed.

Regarding the initialization failures, it may be due to #5770, you may want to wait until that is fixed.