Start value for final parameters with fixed=false is ignored

[Francesco Casella]

Consider the following model (also attached)

model TestInitStart
  final parameter Real p(start = p_start, fixed = false);
  parameter Real p_start = -2;
initial equation
 (p - 1)*p*(p+2) = 0;
annotation(__OpenModelica_simulationFlags(lv=LOG_NLS_V));
end TestInitStart;

The Newton solver log clearly shows that the iterations start at p = 0, not at p = -2 as expected, leading the convergence to the wrong solution.

This issue is preventing me to initialize in steady-state the big power plant model that I will present at the OpenModelica Workshop next week, so fixing this issue is currently top priority to show that OpenModelica can handle such real-life, complex models effectively.

[Francesco Casella]

Update: I just found a workaround: if I add -d=evaluateAllParameters, then the model works as expected.

Maybe gives you some clues so as to how to fix the issue.

Unfortunately I cannot use this workaround of the big model because it causes a new frontend failure related to homotopy. Life's hard.

[Karim Adbdelhak]

It seems like the compiler drops all fixed=false start values. That is correct for general initialization (in the sense that no initial equation is generated) but not for solving loops in the initialization problem.

I have a pretty good idea where to look!

[Lennart Ochel]

This might be synchronized with the OpenModelica FMI 2.0 export. There are strict rules for start values defined. Sounds bad to implement it twice.

[Karim Adbdelhak]

I prepared a fix that is not the best solution but better than what we got now. ​PR700 Hopefully Jenkins does not reject these changes.

Start values for calculated parameters will be evaluated. They won't have any influence unless the parameter will be evaluated in a nonlinear loop. Unfortunately changing p_start after compilation will not change the start value of p because they have been decoupled. To keep this coupling we would need to change how the _init.xml is accessed. Possible but quite a lot of work.

Long story short: It should work always if the model is compiled from scratch. Influencing the values of parameters that influence start values after compilation might not always work out as expected.

Maybe i will add a warning for now.

[Karim Adbdelhak]

Replying to lochel:

This might be synchronized with the OpenModelica FMI 2.0 export. There are strict rules for start values defined. Sounds bad to implement it twice.

I actually slightly modified your code for my changes, maybe you want to have a look.

[Vitalij Ruge]

Replying to Karim.Abdelhak:

Start values for calculated parameters will be evaluated. They won't have any influence unless the parameter will be evaluated in a nonlinear loop. Unfortunately changing p_start after compilation will not change the start value of p because they have been decoupled. To keep this coupling we would need to change how the _init.xml is accessed. Possible but quite a lot of work.

Maybe #2207 is interesting.

[Francesco Casella]

Local workaround:

model TestInitStart
  final parameter Real p(start = p_start, fixed = false);
  parameter Real p_start = -2 annotation(Evaluate=true);
initial equation
 (p - 1)*p*(p+2) = 0;
annotation(__OpenModelica_simulationFlags(lv=LOG_NLS_V));
end TestInitStart;

[Francesco Casella]

Unfortunately this doesn't work on the big test case. If I switch on -d=evaluateAllParameters, the front end gives me

final parameter Real Plant.u_Tin_RHA(unit = "1", start = -0.24, fixed = false);

so the start value parameter has been evaluated to the literal value -0.24, but then the nonlinear solver still fails and the run-time diagnostic message still gives

proper start-values for some of the following iteration variables might help
...
[329] Real Plant.u_Tin_RHA(start=?, nominal=?)
...

as it did before when i did not evaluate the parameter containing the start value.
No idea where these question marks come from and what they mean. The LOG_NLS_V output shows an initial guess of zero, which badly breaks the convergence.

[Francesco Casella]

See ​comment in PR 700 on how to fix this.

[Karim Adbdelhak]

Possible fix in ​PR744. Works for the minimal model and does not seem to break anything i tried.

[Karim Adbdelhak]

One test fails with an assertion at initialization: ThermoPower.Test.DistributedParameterComponents.TestWaterFlow1DFV2ph

If have to look deeper into it to know what is happening.

[Karim Adbdelhak]

The test is fixed. To shortly summarize what i did in pseudo code:

Usually each iteration variable of a nonlinear loop is initialized with the corresponding value:

 iter_var[0] = realParam[3] /* p */
 iter_var[1] = realParam[0] /* tank.y */
  ...

These values have been set before by the init_xml file for initialization and in all other cases they grab the previous value of the variable to initialize the solver. If the start value could not be evaluated to a constant, there is no value in the init_xml and therefore it will be initialized with 0.

I changed it such that for the very first call during initialization, the generated loop grabs the start expression, if it could not be evaluated to be constant. E.g. the start value of p could be p_start.

 iter_var[0] = realParam[4] /* p_start */ 
 iter_var[1] = realParam[0] /* tank.y */
  ...

Note that only the very first call should be like this, so if there is a lambda_0 system for homotopy it has to be done there and the regular initial system has to grab the regular variable as described (this was the error for ThermoPower.Test.DistributedParameterComponents.TestWaterFlow1DFV2ph).

I am just tackling one last problem which is just an OS problem to push everything. Should be done by tomorrow.

[Francesco Casella]

Excellent, I'm looking forward to this. BTW, we still have many initialization failures in our testsuite, maybe this helps fixing other issues.

[Karim Adbdelhak]

It introduced some problems with the Chemical library. Hopefully fixed with ​PR746

[Francesco Casella]

OK, thanks! Just started the ​ripper newInst job. If everything works fine I'll make a windows nightly build and check with the FlexiCaL model

[Karim Adbdelhak]

Replying to casella:

OK, thanks! Just started the ​ripper newInst job. If everything works fine I'll make a windows nightly build and check with the FlexiCaL model

Did the build crash?

[Francesco Casella]

Yes, unfortunately @sjoelund.se's attempted fix to the problem of no longer operational daeMode tests didn't work properly, see ​https://github.com/OpenModelica/OpenModelicaLibraryTesting/commit/02329a8cfe974319003e011b1df5c01455c00973#commitcomment-37507759.

[Karim Adbdelhak]

How did the tests go? Are there still regressions? I lost the trace, original problem should be solved!

[Francesco Casella]

The original problem was solved, now I can get this to run correctly without setting evaluateParameters = true.

I am currently unable to test the FlexiCaL model due to lack of time, I will reopen this ticket if necessary.

Thanks!