How to get a Modelica (Dymola) Simulation running, that fails because of: "Warning: Failed to solve nonlinear system using Newton solver."

Question

I am currently trying to rebuild the model presented in the paper "Strategies for a transition towards a solar district heating grid with integrated seasonal geothermal energy storage" (https://ideas.repec.org/a/eee/energy/v228y2021ics0360544221009117.html) but always run into the problem, that the simulation fails because Warning: Failed to solve nonlinear system using Newton solver.

For the model i am trying to use the MoSDH Library (https://github.com/MoSDH/MoSDH).

I can't upload my model in this forum, but i am happy to share it with everyone who is interested in looking into my problem.

I will add the last lines of the error message to give a better understanding of my problem.

Warning: Failed to solve nonlinear system using Newton solver.
  During initialization at time: 0
  Tag: simulation.nonlinear[27]
Homotopy reducing

Warning: Failed to solve nonlinear system using Newton solver.
  During initialization at time: 0
  Tag: simulation.nonlinear[27]
Error: Integrator failed to start model.

... Error message from dymosim

ERROR: The simulation of FormhalsModellNachbau.SolarThermalTest3 FAILED

I already tried the Dassl and Cvode solving cases, which are supposed to be the best working ones. Both reached the same problem.

Answer 1

That's a common issue in Modelica modelling/simulation projects.

The mathematically correct name for this "Nonlinear Systems" is implicit algebraic equation systems. If they exist your model is a so called DAE and not an ODE.

Usually Dymola solves the DAE by embedding Newton solvers for each algebraic system and exposing the resulting overall system to an ODE solver.

But this Newton iterations can fail, as you have experienced. I would recommend the follwing ways to solve it:

1. Get rid of the algebraic systems
2. Provide better start values for the iteration variables
3. Analyze residual functions and improve it (e.g. extrapolation, avoid zero slope)

Point 1 is the most important one. You need to understand and break the algebraic loops. Typical causes are:

• Flow reversal (stream connector) -> try to use inStream() instead of acutalStream()
• Direct coupling of sensor and actuator by the P-Part of a controller -> add sensor dynamics

We have published a Blog Article exactly about this topic.

Answer 2

First understanding the problem:

• In the translation log you can see the systems of equations, in particular their sizes - but you seem to have many so it may be complicated. (Setting Advanced.Translation.Log.NonLinearIterationVariables = true; before translation might give more - but the next item is more focused).
• Simulation>Setup>Debug>Nonlinear solver diagnostics has a number of settings to get more information. In particular
  • Detailed logging of failed nonlinear solutions
  • Details

Then fixing it.

There are roughly two possibilities: the equations don't have a solution, or there is one but Dymola couldn't find it:

• If there is no real solution (like x*x+1=0;) you will have to reformulate the equations. (See below.)
  • A special case is if the equation formally depends on x, but in practice doesn't (such as 0*x=10; - but hidden in some weird way.) That will generate a specific warning about singular row in Jacobian - try to understand why it occurs.
• If there is a solution, but Dymola couldn't find it there are two general possibilities for fixing it:
  • Better start-values. Make sure that all iteration variables at least have the right magnitude.
  • Use the homotopy operator. (See below.)

If the system of equations is scalar or small enough, it may be possible to see whether it has a solution or not.

Otherwise it is complicated, and the general strategy would be to see if you can simplify the model (ignore some parts - use linear relations instead of non-linear etc) to have a smaller system of equations, and if that can be solved.

If the simpler equation cannot be solved: fix that. If it can be solved, use it to generate start-values and/or have the homotopy-operator switch from this simpler model to the actual one.