Insufficient information about assertion violations

[Francesco Casella]

Apologies, the first issue of this ticket was wrong due to a typo in the code. I have modified it to reflect the actual status with the corrected code.

Please consider the attached test package, which demonstrates how OMC does not provide essential information to the user when handling asserts.

Simulate TestWarningConstant. You get the following warning message:

Warning: Variable x is probably too big

Unfortunately, the message doesn't tell you an essential piece of information, i.e., where in the model M has this error been triggered. Is it m1, m2 or m3? It also doesn't tell when the warning has been triggered

One option is to enhance the error message like this:

The following assertion has been violated at initialization:
m3.x < 5
Warning: Variable x is probably too big

Simulate TestWarningVariable. You get the same message as before

Warning: Variable x is probably too big

you should get something like:

The following assertion has been violated at time = 0.8333
m3.x < 5
Warning: Variable x is probably too big

Simulate TestWarningRecurring. You still get

Warning: Variable x is probably too big

According to the non-normative text of the Modelica Specification, Section 8.3.7, you should get something like

The following assertion has been violated at time = 0.1577
m3.x < 5
Warning: Variable x is probably too big

The following assertion is no longer violated at time = 0.3465
m3.x < 5
Warning: Variable x is probably too big

Simulate TestErrorConstant. Here you should see:

The following assertion has been violated at initialization:
m2.x < 10
Error: Variable x is too big

Simulate TestErrorVariable. The information here is quite confusing. What you should get here is

The following assertion has been violated at time = 0.25
m2.x < 5
Warning: Variable x is probably too big

The following assertion has been violated at time = 0.5
m2.x < 10
Error: Variable x is too big

Incidentally, I think the "Process crashed" final message in the last case is inappropriate. It seem to hint to the fact that some uncontrolled error has taken place, such as a memory access violation in some external function, which is definitely not the case here. Evertything here is under control and we have reported the reason for the simulation to stop. I would suggest to use "Process aborted", which seems more appropriate.

[Francesco Casella]

Library with test cases