-
Notifications
You must be signed in to change notification settings - Fork 0
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Specific start values should be used for categories of models #308
Comments
Just to understand properly, you mean that we should define some categories of models for which we have a default set of start values ? No problem to discuss that in a dedicated meeting |
Yes.
We should define categories so that one specific default value is good enough to guarantee convergence in most, if not all, cases.
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.
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 #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
And we set |
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.
The text was updated successfully, but these errors were encountered: