I would prefer if we instead encouraged tools to consistently include such information in the assert-messages, instead of manually patching every assert-call.

I would prefer if we instead encouraged tools to consistently include such information in the assert-messages, instead of manually patching every assert-call.

In that case #4482 could have been labeled tool-issue. But it was not.

Meanwhile, it does not hurt to print the values already in the assert message. I also tested in Dymola 2024 R1 where it now looks better (with the patch applied).

I would prefer if we instead encouraged tools to consistently include such information in the assert-messages, instead of manually patching every assert-call.

In that case #4482 could have been labeled tool-issue. But it was not.

Meanwhile, it does not hurt to print the values already in the assert message. I also tested in Dymola 2024 R1 where it now looks better (with the patch applied).

No, we can't both encourage tools to include the information and at the same time explicitly embedding the information in the messages.

If we are serious about encouraging tools, on the other hand, these are some asserts that should be reformulated in order to not come out ugly with tools that also provide details of the failed assert condition:

        assert(uMax >= uMin, "Limiter: Limits must be consistent. However, uMax (=" + String(uMax) +
                             ") < uMin (=" + String(uMin) + ")");

        assert(uMax >= uMin, "DeadZone: Limits must be consistent. However, uMax (=" + String(uMax) +
                             ") < uMin (=" + String(uMin) + ")");

    assert(index >= 1 and index <= nin,
      "The input index (=" + String(index) + ") is out of range.");

            assert(table[i] > table[i-1],
              "Time values of table not strict monotonically increasing: table["
               + String(i - 1) + "] = " + String(table[i - 1]) + ", table[" +
              String(i) + "] = " + String(table[i]));

and many, many more.

There is also this kind of message, which doesn't embed values, but which will still not look great with a tool that displays the failed assert condition (giving context to the automatically provided values):

    assert(limit1 >= limit2, "Input signals are not consistent: limit1 < limit2");

No, we can't both encourage tools to include the information and at the same time explicitly embedding the information in the messages.

In that case #4482 could have been labeled tool-issue. But it was not.

There is also this kind of message, which doesn't embed values, but which will still not look great with a tool that displays the failed assert condition (giving context to the automatically provided values):

    assert(limit1 >= limit2, "Input signals are not consistent: limit1 < limit2");

See again. This is exactly the assert message this PR was about.

Anyway, closing.

See #4399 for the general issue.

See #4399 for the general issue.

Thanks for reminding. Citing your comments from there:

Use more digits in the message, by using String(T, 11) or so

That's exactly what I did in this PR.

Make the assert-text even simpler (perhaps "Temperature is not in the allowed range") and leave the debugging messages to the tools ...

I consider this just as a small side note but not yet as general advice on tool-vendors to improve there debugging messages on assertions. If it would already be the case then #4482 had not been reported.

So questions are

• update MSL in either one way or the other to have it at least no longer such inconsistent as reported by @henrikt-ma
• improve tools independent of the decision how to adapt MSL.