Assert from within algorithm section during model check

[abuntrock]

Description

During work on our BRSL I found another peculiar thing, where I cannot wrap my head around. An assert from within an algorithm section is triggered when checking the model. But I assumed that such asserts are only checked when the model is simulated. I am not sure as how to describe this problem other than that this model does not produce the same problems in other Modelica tools (namely SimulationX and Dymola). If you do not have access to a BRSL version, where there is only one main package named Rexroth_BRSL, please let me know.

Steps to Reproduce

1. Consider the following package:
   AssertDuringCompilation.txt
2. The class AssertDuringCompilation.ModelWithFunctions throws the following error when being checked:

[AssertDuringCompilation: 103:5-103:110]: assert triggered: 
Error in AssertDuringCompilation.Function2:
The zero index must exist.

3. The model checks succesfully if one of the following things are changed (which is not possible/desired in our actual application). Maybe, this helps in finding a solution to my problem.
   3a. The extend statement in AssertDuringCompilation.ModelWithFunctions is removed, where flowTablePassed is used
   NoAssertDuringCompilation1.txt
   3b. The evaluate=true annotation of flowTablePassed in AssertDuringCompilation.ModelWithFunctions is removed
   NoAssertDuringCompilation2.txt
   3c. twoSided in NoAssertDuringCompilation3.Function1 is changed from a parameter input to an input. As a result, NoAssertDuringCompilation3.Function1 cannot be checked anymore but AssertDuringCompilation.ModelWithFunctions where the function is used checks successfully.
   NoAssertDuringCompilation3.txt

Expected Behavior

The error message does not appear when checking the model and the model can be used in simulations.

Version and OS

• OpenModelica Version: v1.22.0-dev-164-g35b2943a7c (64-bit)
• OS: Windows 10, 64 bit
• MSL 4.0.0 and BRSL 3.0.0 (same as 2.3.0)

Thanks for looking into this
Aaron Buntrock - Bosch Rexroth

[perost]

The reason why the assert triggers is because the compiler tries to evaluate the function while evaluating the binding of flowTablePassed.

So the question is whether the assert triggering is correct or not, which I'm not sure about. Can you use the model in a simulation if you do any of the changes you listed? I tried doing it myself, but I'm not sure how to actually use the model correctly in a simulation. If the assert triggers during a simulation too it's probably correct, otherwise there might be some issue with the function evaluation.

[abuntrock]

I added a testcase to two of the minimum examples above.
Here is the one with the assert. If you try to simulate AssertDuringCompilation.Testcase the above mentioned error occurs. The assert should not be triggered because in AssertDuringCompilation.Function2 zeroIndex equals 51 while sizeInputTable equals 101 and 51<101. ( The input to function2 in AssertDuringCompilation.ModelWithFunctions qNTableEasy has 101 rows and the only zero in the first coloumn appears at position 51.)
AssertDuringCompilation.txt

Here is the minimum example where I changed twoSided in NoAssertDuringCompilation3.Function1 from a parameter input to an input. The testcase NoAssertDuringCompilation3.Testcase simulates succesfully even though all inputs (and the results if I simulate both in Dymola) are the same as for the failing testcase. The results from this testcase in OMEdit are also the same as the ones from Dymola.
NoAssertDuringCompilation3.txt

[perost]

Fixed in #10836.

The issue was that the parameter inputs of the function confused the compiler and caused it to constant evaluate sizeFlowTablePos such that it was always 101.

However, variability prefixes on function inputs/outputs doesn't actually have any semantic meaning in Modelica, so declaring an input as parameter shouldn't have any effect. So the fix I implemented is to just remove such prefixes and treat them like normal inputs/outputs.

[abuntrock]

Thanks for the fix and the side lesson regarding the variability of function inputs