search

Metroscope-dev / metroscope-modeling-library

Modelica library to build physical models of nuclear and combined cycle gas power plants. Based on ThermoSysPro library
https://www.metroscope.tech/
Other
23 stars 0 forks source link

Specific start values should be used for categories of models #308

Open casella opened 1 year ago

casella commented 1 year ago

Default start values for pressures, enthalpies, temperatures, and flows are defined in completely generic base classes, such as, e.g., Partial.BaseClasses.FlowModel. These values are then not specialized to categories of models extending the base class, leading to situation with really poor start values that hinder the convergence of the Newton algorithm.

Consider, for example, MetroscopeModelingLibrary.Tests.Multifluid.HeatExchangers.HXmoistAirWater_reverse. When attempting to run it with OpenModelica, the following error is obtained:

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  = 190
  u_max  = 647
  fa = f(u_min) = -584794
  fb = f(u_max) = -106908
fa and fb must have opposite sign which is not the case
Process crashed

The reason of this failure is articulated, and also partially depends on OpenModelica/OpenModelica#9681, but the root cause is the start value of hXmoistAirWater.hot_side_pipe.h_in, which is still set to the default value of 5e5. This value is completely unreasonable for humid air, as it corresponds to a temperature in excess of 400 °C, and causes the out-of-bound error shown above.

If one adds to MetroscopeModelingLibrary.MoistAir.Pipes.Pipe the modifier h_0 = 1e5 to the extends clause, setting a more reasonable default for moist air, the HXmoistAirWater_reverse model runs fine also in OpenModelica.

The fundamental issue is that the current library design has too generic default start values, which are then patched on a case-by-case basis (e.g. cold_side(h_in(start = 9e3)) in the case at hand), depending on failures experienced with Dymola. This is not a portable approach, not even among different versions of Dymola, that may use different solution strategies, choices of tearing variables, etc.

A better design would make sure that each category of models gets an appropriate default, thereby guaranteeing fool-proof convergence and avoiding case-by-case, tool-dependent fixes. The questions are:

This should be discussed with Metroscope in a live meeting.

pierre-eliep-met commented 1 year ago

Just to understand properly, you mean that we should define some categories of models for which we have a default set of start values ? Like having a base WaterSteam medium, and then extend it with a MainSteam and a FeedWater, both mediums in different part of the power plant ? But we would still need to go through all the components and correct the startvalues, right ?

No problem to discuss that in a dedicated meeting

casella commented 1 year ago

Just to understand properly, you mean that we should define some categories of models for which we have a default set of start values ?

Yes.

Like having a base WaterSteam medium, and then extend it with a MainSteam and a FeedWater, both mediums in different part of the power plant ?

We should define categories so that one specific default value is good enough to guarantee convergence in most, if not all, cases.

But we would still need to go through all the components and correct the startvalues, right ?

No, that's precisely the point of doing that. No need to put specific start values in the component instances, you would always rely on the category's default.

No problem to discuss that in a dedicated meeting

Can you please se up a doodle poll or something for that?

pierre-eliep-met commented 1 year ago

Just thinking about this categorization with @valentindrou, we realized that currently the model MetroscopiaNPP_direct without start values (but with many start values parameters set) did not simulate. To me this is weird because I don't see a lot of start values that should be given in the model since we almost gave everything already...

What do you think ?

By the way, this is probably related to https://github.com/Metroscope-dev/metroscope-modeling-library/issues/223 : the faulty model inherits from this direct model, it fails to simulate while almost everything has a correct start value...

pierre-eliep-met commented 1 year ago

Getting back to this proposition, do you think it would be doable with a record imported in all components, something like

And we set Q_0 = start_values.main_steam.HP.main_line.Q in components That way we would have a standard definition, and appropriate start values everywhere @valentind-met ? It would mean less code duplication and checks as we currently have to do with #269 and #399