Calling impure function print from equation section in Inverse_sine example

[MarkusOlssonModelon]

I have found an issue with Modelica.Media.Examples.SolveOneNonlinearEquation.Inverse_sine. It contains a call to Modelica.Utilities.Streams.print directly in the equation section. Since print is an impure function this is not allowed.

I suggest adding an initial equation section and moving the call to print there.

[HansOlsson]

I have found an issue with Modelica.Media.Examples.SolveOneNonlinearEquation.Inverse_sine. It contains a call to Modelica.Utilities.Streams.print directly in the equation section. Since print is an impure function this is not allowed.

Note that there is an exception for print so it is deprecated behavior without any required diagnostics.

I suggest adding an initial equation section and moving the call to print there.

That wouldn't be ideal for me, as it makes the model harder to understand.

Basically x_zero is solved in a normal equation - and then the result printed.
Added: I'm not saying that we should leave it as is, but we have to think more about the change.

If the result is printed in an initial equation, you will sort of have to jump back and forth in the code to understand it, and also think more to realize that x_zero doesn't change after the initialization and thus printing it once suffices.

One possibility would be to declare x_zero as a parameter with fixed=false and replace the entire equation section by an initial equation section; as it is then ordered in the same way and it is somewhat clear that x_zero is only computed once.
Another possibility would be declare parameter x_zero=Modelica.Math.Nonlinear.solveOneNonlinearEquation(...) and then have an initial equation directly following that.

The benefit with the second possibility is that it would correspond to how you normally use solveOneNonlinearEquation that is in algorithmic context where you directly want the value and not in an equation section where it is normally better to just write the actual equation instead (that is equation f_nonlinear(u=x_zero, A=A, w=w, s=-y_zero)=0; )

[MarkusOlssonModelon]

Note that there is an exception for print so it is deprecated behavior without any required diagnostics.

Is that how it is supposed to be interpreted? The way I read the specification print is only excepted from the diagnostics when using the deprecated semantics in a simulation model, not the restrictions on calling impure functions. Except for the function Modelica.Utilities.Streams.print, diagnostics must be given if called in a simulation model.

One possibility would be to declare x_zero as a parameter with fixed=false and replace the entire equation section by an initial equation section; as it is then ordered in the same way and it is somewhat clear that x_zero is only computed once.
Another possibility would be declare parameter x_zero=Modelica.Math.Nonlinear.solveOneNonlinearEquation(...) and then have an initial equation directly following that.

I am OK with either.

[HansOlsson]

Note that there is an exception for print so it is deprecated behavior without any required diagnostics.

Is that how it is supposed to be interpreted? The way I read the specification print is only excepted from the diagnostics when using the deprecated semantics in a simulation model, not the restrictions on calling impure functions. Except for the function Modelica.Utilities.Streams.print, diagnostics must be given if called in a simulation model.

I read it as print is 'excepted' from the diagnostics of calling an impure function in a simulation in the 'wrong' place (as print is an impure function that is often called in a simulation model in situations like this); and that is also consistent with my recollection of why it was added.

[henrikt-ma]

I agree with @MarkusOlssonModelon that the specification text as currently written would not allow the impure function print to be called unless it was impure according to the deprecated semantics of not using purity prefixes. However, if it was impure according to the deprecated semantics, it would not have been required to give diagnostics.

That is, a short term fix could be to remove the impure prefix for print, but then the question that remains would be what to do in the long term as we don't want to rely on deprecated behavior.

[thorade]

Is printing to stdout also impure, or only printing to a file?
Would it be an option to have a pure print that prints to stdout only, and an impure print for printing to file?

Another option I see would be to change asserts to have more levels than just warning and error, e.g. add levels info and verbose?

[HansOlsson]

Is printing to stdout also impure, or only printing to a file? Would it be an option to have a pure print that prints to stdout only, and an impure print for printing to file?

In both cases it is a side-effect that makes it impure.
If we are more practical one reason for avoiding this is that it will be called an unknown number of times, which is a bit of a nuisance for testing.

As previously suggested transforming both the equation and print into initial equations would be a possibility.

A second solution would be to wrap it (either the print or both the print and equation) into a when-clauses, something like:

when terminal() then
  print("x_zero = " + String(x_zero) + ", y_zero = " + String(y_zero) +
    ", A*sin(w*x_zero) = " + String(A*Modelica.Math.sin(w*x_zero)));
end when;

The difference compared with the previous idea of moving it to an initial equation is that it still reads in the natural order.

The simplest solution is, of course, to just remove the print-out.

Another option I see would be to change asserts to have more levels than just warning and error, e.g. add levels info and verbose?

That would just be cheating, assert (especially with error) is different.