Open casella opened 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
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?
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...
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
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 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.