Opened 5 years ago

Closed 5 years ago

#5602 closed enhancement (fixed)

Improved diagnostics to avoid nonlinear solver failures

Reported by: Francesco Casella Owned by: Karim Adbdelhak
Priority: critical Milestone: 1.14.0
Component: Backend Version:
Keywords: Cc:

Description

The success of iterative nonlinear solvers depends on the quality of the initial guess values, which are given by the start attributes.

To this purpose, we already issue a warning if there are iteration variables which have a default zero value, which may be problematic in some cases.

It turns out, not all iteration variables are equally important. In fact, the convergence only depends on those variables that directly or indirectly affect the Jacobian of the system. In some problems (e.g. power system models) there are often large amounts of linear equations, whose variables do not affect the Jacobian - taking care of giving them good initial guesses is a complete waste of time, as it is poring over their actual initial guesses upon debugging.

I would then suggest to implement some features that will really help to pinpoint the causes of failure of nonlinear solvers much easier than it is possible now:

  1. Make available a dump of the tearing variables of each nonlinear system of equations that have an influence on the values of the jacobian matrix.
  1. When dumping the values of iteration variables during solver iterations (LOG_NLS_V), print a separate list of values of the the sets of point 1, so that it becomes much faster to scan them and to look for potentially dangerous values.
  1. Suppress the warning "Iteration variables with default zero start attribute in equation system with analytic Jacobian" for variables not belonging to the sets of point 1, as they cannot do any harm.

Later on, these information will be integrated into the debugger, together with the SVD analysis of the Jacobian, to provide user-friendly information to pinpoint the causes of nonlinear solver failures. I need these three features to start experimenting with some ideas and to come up with a prototype of the more advanced debugger features.

Change History (14)

comment:1 by Francesco Casella, 5 years ago

@Karim, one additional interesting piece of information, besides knowing which iteration, variables affect the Jacobian, is to know for each of them which are the affected equations. Is this information already available, and can it be dumped easily?

in reply to:  1 comment:2 by Karim Adbdelhak, 5 years ago

Replying to casella:

Andreas and I already have a branch on this particular dumping update.

  1. Make available a dump of the tearing variables of each nonlinear system of equations that have an influence on the values of the jacobian matrix.

We added a warning for the relevant variables with default zero start attribute, it should be easy to have all accessible via a dumping flag.

  1. When dumping the values of iteration variables during solver iterations (LOG_NLS_V), print a separate list of values of the the sets of point 1, so that it becomes much faster to scan them and to look for potentially dangerous values.

This might be harder to do since the information about nonlinear variables is currently not present during runtime. I am not quite sure if the effort is worth it, but i will have a look at this.

  1. Suppress the warning "Iteration variables with default zero start attribute in equation system with analytic Jacobian" for variables not belonging to the sets of point 1, as they cannot do any harm.

The previous dumping still has to be removed.

@Karim, one additional interesting piece of information, besides knowing which iteration, variables affect the Jacobian, is to know for each of them which are the affected equations. Is this information already available, and can it be dumped easily?

It is not jet available, but i think it can easily be added. We would just have to update the dependency check of the jacobian to also store relevant equations. Could take some time to implement but is viable.

I will keep you updated on this!

Last edited 5 years ago by Karim Adbdelhak (previous) (diff)

comment:3 by Karim Adbdelhak, 5 years ago

I created a pull request, but i guess a lot of tests have to be updated so it will take a while to merge and check everything. I solved 1. and 3. Furthermore, i added the dumping of relevant nonlinear equations. Regarding 2. i will have a look at it with Andreas, but as i already mentioned it might be hard to do.

comment:4 by Francesco Casella, 5 years ago

Regarding 2., I'd say it's not worth spending time to add this information to the runtime, at least for the time being. The selection should be done a posteriori by the GUI. The only case in which this feature could be really useful is very large models, where it could substantially reduce the (huge) size of the log file. I'd say this is not urgent at the moment.

I would give higher priority to the dumping of which element of the Jacobian is influenced by which iteration variable. This information could be very useful to pinpoint the wrong start values that are possibly causing the failure of the Newton-Raphson solver.

comment:5 by Karim Adbdelhak, 5 years ago

The PR is pushed. Regular warnings now look like this:

Warning: There are nonlinear iteration variables with default zero start attribute found in NLSJac0. For more information set -d=initialization. In OMEdit Tools->Options->Simulation->OMCFlags, in OMNotebook call setCommandLineOptions("-d=initialization").

Using -d=initialization produces output similar to this:

Nonlinear iteration variables with default zero start attribute in NLSJac0. (1)
========================================
1: x2:VARIABLE() type: Real

Relevant nonlinear equations in NLSJac0. (1)
========================================
1/1 (1): -4.0 + x1 ^ 2.0 + 4.0 * x2 ^ 4.0 = 0.0 [dynamic |0|0|0|0|]

Info: Only non-linear iteration variables in non-linear eqation systems require start values. All other start values have no influence on convergence and are ignored. Use "-d=dumpLoops" to show all loops. In OMEdit Tools->Options->Simulation->OMCFlags, in OMNotebook call setCommandLineOptions("-d=dumpLoops").

Unrelevant start values of linear iteration variables are also reported.

comment:6 by Francesco Casella, 5 years ago

Thanks Karim!

I'm writing a draft paper on this topic in my spare time, I'll get back to you with this as soon as I have some results.

comment:7 by Karim Adbdelhak, 5 years ago

Replying to casella:

Thanks Karim!

I'm writing a draft paper on this topic in my spare time, I'll get back to you with this as soon as I have some results.

Unfortunately i realized that there are some issues with dumping the equations. I will update that tomorrow but the other information is just fine.

Since i only analyzed the jacobian of the torn system i don't have the information about the inner equations (where the actual nonlinearity could be). Should not be that hard to update, but maybe some more fixing for the testsuite is needed.

in reply to:  7 ; comment:8 by Francesco Casella, 5 years ago

Replying to Karim.Abdelhak:

Since i only analyzed the jacobian of the torn system i don't have the information about the inner equations (where the actual nonlinearity could be).

I'm not sure I understand what you mean, because I don't know exactly how you compute the Jacobian in case of torn equations. Consider this example

x + y = 10;
y + 3*z = 0;
y*z = 10;

assuming x is picked as tearing variable, the system is solved as

y := 10 - x;
z := -y/3;
y*z = 10;

Now, the residual does not depend directly on x, but it does through the two assignments. If you add the differentiated equations, you get the following procedure

y := 10 - x;
dy := -dx;
z := -y/3;
dz := -dy/3
y*z = 10;
d(y*z) = dy*z+dz*y

Now, this can be used to compute the Jacobian (in fact, the directional derivatives) of the residual functions numerically. I understand you should also keep track of the dependencies, so that you get:

y := 10 - x; // y depends on x
dy := -dx;    
z := -y/3;   // z depends on y
dz := -dy/3
y*z = 10;
d(y*z) = dy*z+dz*y // z depends on y which depends on x, y depends on x, so d(y*z) depends on x
Last edited 5 years ago by Francesco Casella (previous) (diff)

in reply to:  8 comment:9 by Karim Adbdelhak, 5 years ago

Replying to casella:

y := 10 - x; // y depends on x
dy := -dx;    
z := -y/3;   // z depends on y
dz := -dy/3
y*z = 0;
d(y*z) = dy*z+dz*y // z depends on y which depends on x, y depends on x, so d(y*z) depends on x

In this case i guess the equation to report would be

y*z = 10;

I changed your system of equations to:

x^2 + y = 10;
3*z + x = 0;
y + z = 10;

So that it is nonlinear in x in a different way. (choosing x would not be optimal, just to showcase this we do it nevertheless)

Do you want to be reported about the actual residual used to compute the jacobian, which indirectly depends on x:

y*z = 10;

Or the inner equations where the nonlinearity originates from:

x^2 + y = 10;

Or do you want both?

Last edited 5 years ago by Karim Adbdelhak (previous) (diff)

comment:10 by Francesco Casella, 5 years ago

The most important information is to understand which iteration variables influence directly or indirectly the jacobian of the residuals.

Regarding which nonlinear equations are affected by which iteration variables, I thought again about it. It may be interesting if tearing is not used, but in the case of torn equations I'm actually not yet sure if and how this information can actually provide meaningful feedback to the end user. Let's skip that for the time being, sorry for wasting your time.

in reply to:  10 comment:11 by Karim Adbdelhak, 5 years ago

Replying to casella:

The most important information is to understand which iteration variables influence directly or indirectly the jacobian of the residuals.

Regarding which nonlinear equations are affected by which iteration variables, I thought again about it. It may be interesting if tearing is not used, but in the case of torn equations I'm actually not yet sure if and how this information can actually provide meaningful feedback to the end user. Let's skip that for the time being, sorry for wasting your time.

No problem! I removed the dumping of equations and some unused functions that were used before to detect iteration variables with default start value. Now the dumping should work fine!

comment:12 by Francesco Casella, 5 years ago

Ok, thanks! I'll report as soon as I have some time to test this

comment:13 by Francesco Casella, 5 years ago

Please see the last comment to commit 85d96360c, there are about 300 regressions in the libraries testsuite that need to be fixed.

Thanks!

comment:14 by Francesco Casella, 5 years ago

Resolution: fixed
Status: newclosed

The regressions were fixed in the meantime, see e.g. report

Note: See TracTickets for help on using tickets.