ModelicaUtilities: Add ModelicaFatal and AssertionLevel.fatal

[modelica-trac-importer]

Reported by beutlich on 23 Jan 2017 11:33 UTC Ticket #1967 introduces ModelicaWarning for the ModelicaUtilities functions in v3.4. I would like to discuss the necessity of a ModelicaFatal function in ModelicaUtilities (and consequently as new assertion level for assert) for unrecoverable failures, since it is currently not possible to terminate a simulation without telling the solver not to try another evaluation.

This also goes together with #2099, where it probably is assumed that Modelica.Utilities.Streams.error raises a fatal error.

---

Migrated-From: https://trac.modelica.org/Modelica/ticket/2152

[modelica-trac-importer]

Modified by beutlich on 23 Jan 2017 11:34 UTC

[modelica-trac-importer]

Comment by hansolsson on 23 Jan 2017 12:25 UTC I can partially understand this - but to make it concrete we need actual use-cases for ModelicaFatal. Note that there are a number of cases where a ModelicaError will be unrecoverable in models (e.g. the calls occur during initialization/events and outside of any non-linear system of equations).

Note that we should also compare it to development in other languages, e.g. static asserts in C-like languages.

[modelica-trac-importer]

Comment by beutlich on 24 Jan 2017 11:56 UTC ModelicaFatal should be called on unrecoverable errors inside ctors of external objects, since otherwise if ModelicaError is called, the solver might try to call the ctor again, which is not allowed.

[modelica-trac-importer]

Comment by hansolsson on 24 Jan 2017 12:17 UTC Replying to [comment:3 beutlich]:

ModelicaFatal should be called on unrecoverable errors inside ctors of external objects, since otherwise if ModelicaError is called, the solver might try to call the ctor again, which is not allowed.

Can you clarify why it isn't allowed in general (I might have missed something)?

However, I don't see why the solver would try to call the constructor again in that case.

Normally functions are called again after trying to some remedy - like reducing the step-size, whereas constructors are normally called during initialization - and it seems a bit of a stretch to find a scenario where we can apply some remedy and call the constructor with different inputs.

If we don't apply a remedy and just call the constructor again it seems like the commonly quoted definition of insanity (doing the same thing over and over and expecting different results).

[modelica-trac-importer]

Comment by beutlich on 24 Jan 2017 14:06 UTC

Sorry, yes, the ctor can be called again, in case the previous call failed.

Can you clarify why it isn't allowed in general (I might have missed something)?

It also is legal to construct external objects in functions. If now the ctor fails with ModelicaError, the solver might apply some remedy, and call that function and thus the ctor again. This might not be the desired behavior. If the ctor fails with ModelicaFatal, then the simulation can just fail and terminate.

Thus, the scenario is not specific for external objects, but generic to external functions.

[modelica-trac-importer]

Comment by hansolsson on 1 Mar 2017 12:33 UTC Not clear when retry is really a problem; if the simulation fails it should not be a severe performance issue. Also consider #594.

[modelica-trac-importer]

Modified by beutlich on 15 Oct 2017 08:54 UTC

[modelica-trac-importer]

Modified by beutlich on 10 Jan 2018 08:23 UTC

[beutlich]

Why was this closed?

My suggestion is to differ between recoverable errors (ModelicaError), that can for example be recovered by reduction of the solver step size, and unrecoverable errors (ModelicaFatal), for example if a table input file is not available. Currently all errors are considered as recoverable errors which is an too optimistic assumption.

[henrikt-ma]

I can also see that there's a technical gap to be filled by non-recoverable errors, as we already make a lot of use of non-recoverable errors internally in System Modeler. It would make sense to expose that mechanism to user code.

Just like @beutlich, I don't find it satisfying to use a mechanism form recoverable errors when I detect garbage input to my functions, and this is the same for both normal Modelica functions and external functions. I want to be sure that the detected error unconditionally terminates the simulation, making the user aware of the problem, instead of the simulation trying to recover and then for whatever reasons don't do the garbage call on subsequent attempts.