Opened 12 years ago

Closed 6 years ago

#2266 closed enhancement (fixed)

advanced support of homotopy(...)

Reported by: Lennart Ochel Owned by: Patrick Täuber
Priority: high Milestone: 1.13.0
Component: Run-time Version: trunk
Keywords: Cc: Bernhard Bachmann

Description

Advanced support of homotopy operator is still missing. Currently we are only using the actual expression.

Change History (22)

comment:1 by Lennart Ochel, 12 years ago

Status: newaccepted

I have already a first experimental implementation. It is working for the first examples, but it is still not tested very well. Probably I will commit it quite soon.

comment:2 by Martin Sjölund, 11 years ago

How soon is soon?

comment:3 by Lennart Ochel, 11 years ago

Cc: Bernhard Bachmann added

Soon, already is in the past. Anyway, a 'advanced' implementation is still missing.

comment:4 by Francesco Casella, 10 years ago

Type: defectenhancement

As far as I understand, the current status is that there is a basic implementation which solves the initial system of equations for values of lambda on an equidistand grid of N nodes using the results at the previous step as guess values. It can be activated by the simulation flag -ils=<no_of_nodes> (e.g. -ils=10.

The solution of the system for lambda = 0 does not take advantage of possible structural simplifications, so it is more fragile than it could be if the initial system was also processed by first substituting the simplified expressions and then performing all the symbolic processing. This could be a serious limitation of the currently implemented approach, because it could hamper the successful initialization of the system.

We'll soon add full scale power plant examples in ThermoPower (included in the 3d party library tested with every nightly build) that will very likely require this feature to converge successfully.

comment:5 by Francesco Casella, 10 years ago

See also #2864

comment:6 by Martin Sjölund, 9 years ago

Milestone: 1.9.31.9.4

Moved to new milestone 1.9.4

comment:7 by Martin Sjölund, 9 years ago

Milestone: 1.9.41.9.5

Milestone pushed to 1.9.5

comment:8 by Martin Sjölund, 9 years ago

Milestone: 1.9.51.10.0

Milestone renamed

comment:9 by Martin Sjölund, 8 years ago

Milestone: 1.10.01.11.0

Ticket retargeted after milestone closed

comment:10 by Martin Sjölund, 8 years ago

Milestone: 1.11.01.12.0

Milestone moved to 1.12.0 due to 1.11.0 already being released.

comment:11 by Francesco Casella, 7 years ago

Update: the separate solution for lambda = 0 was added some time ago, then removed in search for something better.

Current work in progress is reported here: https://github.com/OpenModelica/OMCompiler/projects/1

comment:12 by Francesco Casella, 7 years ago

I understand from @lochel that you are trying to avoid global homotopy.

Although the Modelica specification has no normative text on the topic (see section 3.7.2.4), the non-normative text is very clear that at least conceptually a global homotopy iteration should be carried out, otherwise use cases such as the one described there (ramping up the voltage generators of an electrical circuit from zero voltage via homotopy) won't work if one adopts a local approach, whereby the different blocks in the BLT are solved one by one with lambda going from 0 to 1 for each block separately. The global approach has always been the intention when we worked on this in the Modelica Design Meetings between 2006 and 2009. If the specification is not clear enough, we should try to improve it.

This was also very clear in Michael Sielemann's PhD work.

What we need instead is something equivalent from solving the entire BLT with the same value of lambda, going from 0 to 1 only once.

One option is the brute force one, which I understand was previously implemented, which just does that.

An optimized version could work like this:

  • analyze the (direct and indirect) dependency on lambda in the initial equation system
  • remove the equations that are not influenced by lambda
  • then, remove the equations that are not influencing implicit nonlinear equations in the BLT
  • solve what is left with global lambda iterations
  • solve everything else only once withouth homotopy using the solution of the global lambda iteration at lambda=1

The rationale here is that homotopy is only needed to help the convergence of nonlinear solvers. Equations which are not influenced by lambda can obviously only be solved once and for all, but also equations that depend on lambda but do not require an iterative solution can be solved directly at lambda = 1, as long as their result doesn't influence other nonlinear implicit equations to be solved iteratively. My proposal here (if I'm not mistaken) should address this goals.

Comments?

comment:13 by Lennart Ochel, 7 years ago

You are right; that was my fault. I am working on recovering the previous approach. Once that is done we can test and improve the homotopy approach. Your proposal sounds reasonable.

comment:14 by Francesco Casella, 7 years ago

I am a bit confused by the current situation with homotopy. With 1.11.0, the default was -ils=1, i.e. no homotopy at all; you could switch homotopy on by increasing the value of the -ils runtime flag.

Now I understand from the online documentation that the default is -ils=4 and a new flag -homotopyOnFirstTry has been added, with the following explanation:

If the model contains the homotopy operator, directly use the homotopy method to solve the initialization problem. If disabled, first try to solve without homotopy and only use homotopy as fallback option.

This means that the behaviour has fundamentally changed w.r.t. the past, when you just enabled homotopy by setting the -ils parameter. As this is non-backwards compatible, it would be nice to document this somewhere, e.g. here: https://openmodelica.org/doc/OpenModelicaUsersGuide/latest/omedit.html#simulating-a-model

The explanation of the new -homotopyOnFirstTry option is also a bit confusing, because it seems that you can somehow "disable" it by doing something. In fact, I understand you enable it by adding the -homotopyOnFirstTry flag, otherwise it is disabled by definition.

I would suggest to change the explanation of that flag to

If the model contains the homotopy operator, directly use the homotopy method to solve the initialization problem. Without this flag, the solver first tries to solve the initialization problem without homotopy and only use homotopy as fallback option.

@lochel, @ptaeuber, can you please post a comment on this ticket stating what is the current situation with homotopy and what are future plans for improvements, if any, and use it to track the developments?

Thanks!

comment:15 by Francesco Casella, 7 years ago

Last, but not least, once the situation with homotopy has stabilized, it would be good to give it first-class GUI support, as this can be an essential feature to successfully simulate a class of models with difficult initialization. One shouldn't be a master of obscure simulation or debug flags to take advantage of this feature.

comment:16 by Patrick Täuber, 7 years ago

@casella Yes, you are right, homotopy is now activated as fallback option by default. If you want to use it in the old way (directly, without trying without homotopy), you have to use the flag you mentioned. I will change the flag description to your suggested one.

The current status is, we have two different homotopy methods now. The local one and the global one. By using the local homotopy method, the homotopy iteration is only performed over the single strongly connected components, separately. Here, we have no additional lambda0 components, which could be simplified during compile time.

When using global homotopy (which is stated in the Modelica specification as the prefered way to handle homotopy) the homotopy iteration is currently performed over the whole DAE. Here, we have a separate lambda0 system again.

In both cases the lambda variable is not chosen by a homotopy solver but is increased in equidistant intervals.

So the next step we are working on is to specify the homotopy part of the DAE for the global method and only run the homtopy iteration over that part. The second step is to use the existing homotopy solver, which currently uses its own lambda, for the homotopy initialization process with the lambda from the model.

To the GUI point:
For now you can use the LOG_INIT flag which creates a csv-file with the homotopy path.

in reply to:  16 ; comment:17 by Francesco Casella, 7 years ago

Replying to ptaeuber:

The current status is, we have two different homotopy methods now. The local one and the global one. By using the local homotopy method, the homotopy iteration is only performed over the single strongly connected components, separately. Here, we have no additional lambda0 components, which could be simplified during compile time.

I understand the global method is currently used in the nightly build and also in the 1.12 beta. Can you please confirm that?

I see no flags to switch to the local approach, is it possible to get that as of today?

in reply to:  17 comment:18 by Patrick Täuber, 7 years ago

Replying to casella:

I understand the global method is currently used in the nightly build and also in the 1.12 beta. Can you please confirm that?

Yes, the global approach is currently used as the default one.

Another "new" global approach is in progress, which will use the homotopy solver implemented in the c runtime. With the new global approach the lambda parameter will be calculated by the solver.

I see no flags to switch to the local approach, is it possible to get that as of today?

You can switch to the local approach with this compiler flag:
--homotopyApproach=local

comment:19 by Francesco Casella, 7 years ago

Milestone: 1.12.0Future

The milestone of this ticket has been reassigned to "Future".

If you think the issue is still valid and relevant for you, please select milestone 1.13.0 for back-end, code generation and run-time issues, or 2.0.0 for front-end issues.

If you are aware that the problem is no longer present, please select the milestone corresponding to the version of OMC you used to check that, and set the status to "worksforme".

In both cases, a short informative comment would be welcome.

comment:20 by Francesco Casella, 7 years ago

Component: BackendRun-time
Milestone: Future1.13.0
Owner: changed from Lennart Ochel to Patrick Täuber
Status: acceptedassigned

@ptaeuber, can you please summarize the current status and the short-term plan?

I assigned this ticket to the 1.13.0 milestone, because I understand it is almost finished, feel free to move it to 2.0.0 if not,

comment:21 by Patrick Täuber, 7 years ago

Status: assignedaccepted

Yes, the implementation is almost finished. The are just some pending improvements for the homotopy solver. The next step will be testing (preferably with a homotopy library ;)) and after that activating one of the adaptive approaches by default.

You can test the current status yourself. To switch the methods you can use:
--homotopyApproach=equidistantLocal
--homotopyApproach=equidistantGlobal
--homotopyApproach=adaptiveLocal
--homotopyApproach=adaptiveGlobal

The adaptive approaches are quite sensitive to the different homotopy parameters that can be set by runtime flags (which is the main reason why it will need some testing before it can be used by default). You can identify the homotopy flags by the prefix hom, e.g. -homTauStart.

Please use the detailed flag description to find out the exact meaning of the flags. If you have any questions, feel free to ask me.

There will also be a talk about the homotopy status at the OpenModelica Workshop 2018.

comment:22 by Francesco Casella, 6 years ago

Resolution: fixed
Status: acceptedclosed

I understand there are now several options to make use of the homotopy operator in the solution, see the User Guide.

Note: See TracTickets for help on using tickets.