Opened 11 years ago

Closed 10 years ago

#2404 closed enhancement (fixed)

Iteration variables with default zero

Reported by: Christian Schubert Owned by: Lennart Ochel
Priority: high Milestone: 1.9.0
Component: Backend Version: trunk
Keywords: warning iteration variables Cc:

Description

Here is a small system which has a block of type 'Jacobian Time varying', i.e. a linear system.

model Test
  Real x, y, z;
equation
  z = sin(time);
  z*x + y = 2;
  x - z*y = 2; 
end Test;

When I simulate this model, I get the following warning:

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

I do not think that this warning is necessary for linear systems. Although the jacobian is time varying, it does not depend on x and y. Therefore the start values of x and y should not influence the solution.
It is a different story, if the system was nonlinear.

Change History (6)

comment:1 by Lennart Ochel, 11 years ago

Status: newaccepted

comment:2 by Lennart Ochel, 11 years ago

Resolution: fixed
Status: acceptedclosed

fixed in r17606

(a test was added in r17602)

Last edited 11 years ago by Lennart Ochel (previous) (diff)

comment:3 by Christian Schubert, 11 years ago

Resolution: fixed
Status: closedreopened

I've just run the testsuite with +d=doLinearTearing. Then as we know torn linear systems are treated as nonlinear systems internally. Thus many tests fail because the warning

Warning: There are iteration variables with default zero start attribute. Use +d=initialization for more information.

pops up.

I would like to question this warning in general. Looking from an end-user perspective. Why should I care about this warning if the nonlinear solver manages to find a solution?

Ideally, if a nonlinear system could not be solved during initialization, this should be made clear along with this warning and all iteration variables plotted immediately.
That would be a great benefit in my opinion.

comment:4 by Lennart Ochel, 11 years ago

Resolution: fixed
Status: reopenedclosed

Well, that is correct. I guess we should enforce that we handle torn linear system as linear systems :-)

The issue with nonlinear systems is that they may have multiple solutions. Thus it is not only about finding any solution but the expected one. Thus start-values are necessary and a good hint for end users if something goes wrong – even if the nonlinear system get solved.

Anyway, we should improve messages. You can create a new ticket for error/warning messages for the nonlinear solver. But in addition we will keep this warning.

Last edited 11 years ago by Lennart Ochel (previous) (diff)

comment:5 by Christian Schubert, 11 years ago

Resolution: fixed
Status: closedreopened

I spoke to Willi and we agreed on the following:

The problem is that nonlinear systems may have more than one solution. If all iteration variables are zero, the risk is that the solution found by the nonlinear solver is arbitrary and possibly the wrong one.

The message as it is implemented now, is not helpful at all, because:

  • This warning comes in almost every case, a nonlinear system is present
  • Every warning that pops up too often gets ignored and just annoys people
  • If the nonlinear solver finds the correct solution. No one cares about zero iteration variables. In my experience this applies to 95% of the cases.
  • If it does not (which can only be seen by the modeler from the simulation results), the modeler needs help to find ways how he can influence the solution

Then he (or she) has to run omc with a special flag (for example +d=initialization) which gives that warning along with all iteration variables it applies to.

My resolution would be:

  • Never display that warning by default
  • Display it along with the corresponding iteration variables, when given special flag, e.g. +d=initialization

comment:6 by Lennart Ochel, 10 years ago

Resolution: fixed
Status: reopenedclosed

The message were changed sometime in the past. There is no message for the model above anymore (even if +tearingMethod=noTearing is used).

Note: See TracTickets for help on using tickets.