Opened 12 years ago

Closed 12 years ago

Last modified 7 years ago

#2204 closed defect (fixed)

OMC should warn about iteration variables with default zero start attribute

Reported by: Francesco Casella Owned by: Lennart Ochel
Priority: high Milestone: 1.9.4
Component: Backend Version: trunk
Keywords: Cc: Lennart Ochel

Description

Initialization problem often involve nonlinear equations, which must be solved by iterative methods. Initial guesses for the involved iteration variables are taken from the variables' start attribute.

In many cases, the start attribute for a certain variable is not set anywhere, so its default value (i.e., zero) is taken. In many cases this is a very bad choice, that can lead to errors such as division by zero, logarithm of zero, square root of negative number, etc.

When translating a model for simulation, OMC should optionally warn about iteration variables of the initialization problem having the default zero start value. The warning should mandatorily be issued in case the initialization fails, as setting the missing start attributes to reasonable initial guesses is often necessary in order to achieve convergence, so this is a key information for troubleshooting.

Change History (13)

comment:1 by Lennart Ochel, 12 years ago

Cc: Lennart Ochel added

comment:2 by Francesco Casella, 12 years ago

Owner: changed from probably noone to Lennart Ochel
Status: newassigned

You can test this featue with this simple test model

model foo
  parameter Real p = 1e2;
  parameter Real q = 1e3;
  Real x(start =0.98e3);
  Real r;
  Real s;
  Real u;
equation
  r = (x^2 + 1)/(1+(x/p)^4); 
  s = p*(q - x)/(1+((q-x)/p)^4);
  u = r+s;
  u = 0;
  // x = 4*q*(time-0.5);
end foo;

Assuming that x is selected as tearing variable, the residual of u = 0 is a badly nonlinear function, with a root for x = q = 1e3. This function can be visualized by commenting u = 0 and uncommenting the last equation.

The model can be succesfully initialized by OMC, thanks to the start attribute. If you now try to solve the same model without the start attribute, the solver fails. The error message should clearly point out that there is a nonlinear system to be solved by an iterative method, and that the start attribute has not been set for all the iteration variables, so the default zero start value is used, which is a possible cause of the failure.

comment:3 by Lennart Ochel, 12 years ago

Almost done.

comment:4 by Lennart Ochel, 12 years ago

I have already added this warning to the simulation. If you run your model without any start value, you get the following message:

stdout            | warning | Error in initialization. Storing results and exiting.
|                 | |       | Use -lv=LOG_INIT -w for more information.
"

If you pass „-w“ (-lv LOG_INIT is not really necessary) to the simulation, you get the following output:

LOG_NLS           | warning | nonlinear system fails: Nonlinear function (residualFunc3, size 2) at t=0
|                 | |       | | proper start-values for some of the following iteration variables might help
|                 | |       | | | [1] Real r(start=0, nominal=1)
|                 | |       | | | [2] Real x(start=0, nominal=1)
LOG_NLS           | warning | Error solving nonlinear system Nonlinear function (residualFunc8, size 2) at time 0
stdout            | warning | Error in initialization. Storing results and exiting.
|                 | |       | Use -lv=LOG_INIT -w for more information.

I will add also a warning during compilation (probably later on today).

comment:5 by Lennart Ochel, 12 years ago

The flag –w is passed per-default to the simulation using OMEdit. So you should already get this kind of message if you are using OMEdit :-).

comment:6 by Lennart Ochel, 12 years ago

Resolution: fixed
Status: assignedclosed

fixed in r16433.

getErrorString() gives the following output using +d=initialization:

Warning: Iteration variables with default zero start attribute in equation system:
Warning:   x:VARIABLE() .foo, .Real type: Real
Warning:   r:VARIABLE() .foo, .Real type: Real

comment:7 by Francesco Casella, 12 years ago

Resolution: fixed
Status: closedreopened

This is already quite good, but if one doesn't know about the flag (or cannot set it, e.g. with current OMEdit) then this information is lost.

Is it possible to get it no matter what the settings are, when initialization fails?

comment:8 by Lennart Ochel, 12 years ago

Well, I won’t show this message without any flag, because often there are no explicit given start values but the system can be solved.
There is already a message that shows which system cannot be solved in the case that the initialization fails (see above). Should I add a hint into that message, that it is possible to get even more information using +d=initialization?
Anyway, currently it is not possible to activate this flag in OMEdit. But this should be fixed soon (see #2252).
Other ideas?

in reply to:  8 comment:9 by Francesco Casella, 12 years ago

Replying to lochel:

Well, I won’t show this message without any flag, because often there are no explicit given start values but the system can be solved.

Sure. This is the expected behaviour.

There is already a message that shows which system cannot be solved in the case that the initialization fails (see above). Should I add a hint into that message, that it is possible to get even more information using +d=initialization?

Yes.

Anyway, currently it is not possible to activate this flag in OMEdit. But this should be fixed soon (see #2252).

OK.

Other ideas?

We might support this kind of workflow: if everything goes fine, no verbose warnings at all. If something goes wrong, show the relevant warnings automatically, without the need of setting any flag. This holds for many other cases, not only start values.

comment:10 by Lennart Ochel, 12 years ago

I have added a notification for suppressed warnings of the initialization (while compilation). I guess we should close this ticket finally.
I agree that we need a consistent handling of warnings/errors for compilation as well as for simulation. This should include OMEdit and command line usage of OpenModelica. In my opinion it would be the best to create a new ticket to discuss this further.

comment:11 by Francesco Casella, 12 years ago

Resolution: fixed
Status: reopenedclosed

comment:12 by Dietmar Winkler, 9 years ago

Milestone: Futurepre1.9.4

It doesn't make sense to keep closed ticket in the "Future" milestone that were simply forgotten to assign to the correct milestone in the past.

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

Milestone: pre1.9.41.9.4

Removing the pre1.9.4 milestone in favor of 1.9.4.

Note: See TracTickets for help on using tickets.