-
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
[FEATURE] Add homotopy where relevant #313
Comments
homotopy is not easy to be implemented and requires an accurate preliminary design... we can organize a call to discuss about it. |
I'd say it is very easy to implement homotopies, less easy to implement ones that actually work :) I'm also in favour of a live discussion. Some possibly useful strategies are listed in this paper. |
From Francesco's last email added here for traceability :
|
@casella, @AndreaBartolini, just to properly understand homotopy, if I replace : T_sensor.T = T; // T is an output By T_sensor.T = homotopy(T, T_0); // T is an output, T_0 is a parameter Does it add an equation to the system ? For the first homotopy iteration, is it equivalent to solving the same system but with |
As far as I know the homotopy oprator doesn't "add" equations but "substitute" the "actual" model with a linear combination of "simplified" and "actual" models during the initialization phase only. From the paper cited above: is expanded to During the initialization phase the λ coefficient goes from 0 to 1 in a number of steps that can be set by the following simulation flag in OpenModelica -ils=value or -ils value |
But then, in your example, if |
I ran a first test, with homotopy as done in branch
|
|
To deal with homotopy is not easy, no surprise if it doesn't work at the first tentative... let us some days to investigate your examples... |
No problem, tell me when you will have the time to look at it ! |
@pierre-eliep-met we first analyzed MetroscopiaNPPP_reverse. The cause of failure in this case is articulated. The lambda = 0 homotopy process starts and then fails with
Unfortunately for some reason the function calling stack is not present in the error message. However, a quick search in the flat model shows that 1.94e6 is the value of
This is a very rare case in which a bad initial guess (HPT_P_out_sensor.h = 500000, P_cond_sensor.h = 500000) doesn't cause the Newton solver to fail, but rather to converge to a completely bogus solution:
i.e., by computing completely unreasonable values for some of the unknowns (e.g. an isentropic efficiency of -235), the solver miraculously manages to get the residual to 2.3e-17. The problem is, the solver is completely agnostic regarding the physical meaning of these unknowns, so it accepts the solution without a hiccup. But then, the enthalpy value 1564 J/kg at 19.4 bar is too low (probably ice around 0.3 °C or something) so the solution process stops. In case this was accepted, the value HP_extract.h_in = -47044.389 would have broken the calculation later on anyway, not to mention the negative eta_is. There are two fundamental issues here. The first, as specified in the old homotopy paper is that the specific enthalpy vs. temperature relationship is not too nonlinear, provided the initial guess is in the right phase region, otherwise all hell breaks loose with the Newton solver. The problem here is that 500,000 J/kg is likely too low a value for the slightly humid vapour at the outlet of the HPT, since water at such enthalpy and 19.4 bars is heavily subcooled liquid at 120 °C. Ditto for So, it is not important to have precise start values for those enthalpies, but you have to be careful that they fall in the right region to avoid these problems. The second issue is that the specific enthalpy type that you are using for the water/steam medium is SI.specificEnthalpy, where you changed the start and nominal attribute. Hence, it does not have any min/max attribute, as the medium-specific WaterIF97.SpecificEnthalpy type instead does. If a specific enthalpy type with min = 40000 (corresponding to liquid water at about 10 °C) was used, then this bogus solution would have generated an error or at least a warning with a proper message (too low specific enthalpy) instead of continuing until a function call to specificEnthalpy_ph broke in a later computation. So, either you use the WaterIF97-specific types, or you should add appropriate min/max attributes to your custom-defined types. This also applies to the The general idea is always the same: the solver is agnostic, the modeller can make it less so, by adding extra information that the modeller is aware of, e.g. in terms of min/max bounds, order of magnitude (nominal), etc. Last, but not least, the fact that Please try to implement these improvements and then re-run this test case, we'll see if there are other problems that were masked by these ones, or if you get a solution straight out of the box. |
We also checked This means that If you look into the nonlinear system of equations, the simplified energy balance with Q_0 instead of Q shows up:
This homotopy can be a bit dangerous in some cases, so I would suggest to try avoid using it and see what happens with this test case. |
More analysis on The iteration variable The iteration variable I would then suggest to switch off using |
In the turbine, all enthalpies have an appropriate start value. extends MetroscopeModelingLibrary.Partial.BaseClasses.FlowModel(
Q_0=1500,
P_in_0=60e5,
P_out_0=55e5,
h_in_0 = 2.7e6,
h_out_0= 2.6e6,
...
)
Utilities.Units.SpecificEnthalpy h_real(start=h_out_0); // Enthalpy after real decompression
Utilities.Units.SpecificEnthalpy h_is(start=h_out_0/0.8); // Enthalpy after isentropic decompression For the So I don't really understand this start value or bound issue, since we already implemented that |
The problem is not in the turbine but in the pressure sensor downstream the turbine (HPT_P_out_sensor). |
@pierre-eliep-met, @valentind-met we analyzed this issue more in depth. One of the problems here is probably in the handling of start attributes for alias variables. When generating code from a Modelica modular model, it is often the case that many variables end up in the flat model that are equal to each other (up to a minus sign), e.g. because of connector variables. Modelica tools, including OMC, use alias elimination algorithms to remove the trivial equations and replace all instances of variables from the alias set with just one representative variable. In most cases, one of these variables has a carefully selected start attribute, which is meant to be used in order to achieve convergence during initialization, while other ones (e.g. connector variables, or sensor variables in this case) have generic default start attributes. The question then is, how to retain the carefully selected value among the set of alias variables. This is a well-known problem, that has plagued the community of Modelicans doing thermo-fluid system models since the early 2000's. The problem was first addressed in 2012 by adding section 8.6.2 to the language specification, which proposed a criterion for priority ranking for start values in alias sets. That criterion was revised in October 2021 (see modelica/ModelicaSpecification#3008) and is now included in the 3.6 version of the language specification, which is in the final approval and voting phase. This criterion is implemented in Dymola, where apparently it does its job quite well. Unfortunatetly, it is still not implemented in OpenModelica, see OpenModelica/OpenModelica#5813. We will make some further enquiries, and if it turns out that start attribute priority is actually the problem preventing the successful simulation of non-trivial Metroscopia model in OMC, then it will become essential to provide to the implementation of the latest rules there. At that point, you may discuss some arrangement with the OSMC to get that done, e.g. a DFD contract. I guess the effort should be limited, around 1 person-month. |
Thanks for the details. Yes I had the same idea of the problem. To try to tackle that we have defined all the start values parameters in all components of the metroscopia models, so all variables should now have an appropriate start value, and there should now be appropriate values for all equations of simplified models through homotopy. I'll test that asap and keep you updated, but I must say I don't really have the time at the moment, I hope I will next week or the one after. |
Actually I took the time to rerun simulations on metroscopia NPP direct and reverse which now have start values parameters everywhere, and it works better in dymola (less errors for direct model) but nothing has changed in OMEdit... my changes are on branch |
And even the MetroscopiaNPP_direct_with_StartValues does not simulate, while all variable start values are good, and all init parameters used in homotopy simplified models are close to solution... |
In fact, there is another issue with the MetroscopiaNPP_direct model. If you compile it with a recent nightly build (as we do, so we get the latest improvements of the software), we get the following notification:
Indeed, the LHS of eq. 3 is the sum of the LHS of equations 1., 2., and 4., so the system is indeed structurally singular. Equations 1., 2., and 4. clearly stem from mass balance equations at connection points, as it is also reported by the declarative debugger, e.g.: Unfortunately, we couldn't really figure out where eq. 3. comes from, because the debugger doesn't show any significant symbolic transformation chain, nor it points to any line in the original Modelica code. We need to investigate this issue further; Dymola does not report any structural singularity, so I guess something goes wrong in OMC in this respect. There are also two further issues with the system structure, which may be related to the previous point. The backend further reports:
This is quite strange: adding Even more strange is what is reported afterwards:
after adding 7 extra initial equations, the backend removes 7 other equations, that are declared to be "redundant" but really don't seem redundant at all to me. Small wonder the model cannot be initialized even with all start values in place 😅. Can we share this model with @kabdelhak, which is currently responsible for the OMC backend development, so he can have a look and figure out what is going wrong? Thanks! |
No problem to share that with them, but they also have to signe the license contract, as well as you had done before (I'm going to send it to you by email), sorry for the inconvenience, I'm looking forward to full open source publication... |
@pierre-eliep-met, @AndreaBartolini, I think I have a clue on what the root cause of this problem is, see OpenModelica/OpenModelica#10497. I hope we can solve the issue in OMC with the simple MWEs reported there, without the need of actually sharing the Metroscopia models. |
@casella and @AndreaBartolini I guess for now there has not been any change on the issue linked above ? Just to know if we can investigate some new things or still need to wait. |
The Osmc are still investigating the problem. It is better to wait that the OpenModelica/OpenModelica#10497 issue will be solved. |
Is your feature request related to a problem? Please describe.
For model convergence, we know that adding homotopy is a good thing, but where is it best to add it without having to go through everything ?
I am thinking of the heat exchange equations, maybe th W variable in flow model because it adds non linearity absolutely everywhere, maybe in
T = state.T
what else ?
The text was updated successfully, but these errors were encountered: