Template error generated by omc

[Alexander Täschner <A.Taeschner@…>]

Trying to find a workaround for bug #3089 for the HelmholtzMedia library, I slightly changed the inner structure of the model (see ​https://github.com/AlexanderTaeschner/HelmholtzMedia/tree/omc for the changes). With this changes omc can flatten the HeliumTestModel example, but the model does not simulate. The error message is

Error: Template error: A template call failed (a call with 2 parameters: dladdr failed: not available on Windows). One possible reason could be that a template imported function call failed (which should not happen for functions called from within template code; templates preserve pure 'match'/non-failing semantics).

It is possible, that this issue is related to (or an duplicate of) ticket 3662.
To replicate the problem you can use the added mos script on the save total file.

Testing was done using the current nightly for Windows.

[Alexander Täschner <A.Taeschner@…>]

Save total file of the model

[Alexander Täschner <A.Taeschner@…>]

Script file used for testing

[Alexander Täschner <A.Taeschner@…>]

The issue had nothing to do with ticket 3662, since it is not fixed in the current Windows nightly (OpenModelica-v1.9.4-dev.beta1-120-g27d2f60.exe).

[lochel]

In this case the error message on Windows is not very helpful. On linux one gets at least the name of the failing template call:

Error: Template error: A template call failed (a call with 2 parameters: libOpenModelicaCompiler.so: omc_CodegenC_translateModel). One possible reason could be that a template imported function call failed (which should not happen for functions called from within template code; templates preserve pure 'match'/non-failing semantics).

[Alexander Täschner <A.Taeschner@…>]

Using the flag +d=execstat I could narrow the error down to the code generation stage (last reported performance time is "Performance of SimCode"). If I use --simCodeTarget=None the error indeed disappears. Using --simCodeTarget=Cpp the error message changes to "[...]A template call failed (a call with 1 parameter)[...]".

[sjoelund.se]

Milestone pushed to 1.9.5

[sjoelund.se]

Milestone renamed

[Alexander Täschner <A.Taeschner@…>]

Beginning from windows nightly OpenModelica-v1.10.0-dev-143-ge8ad8a3.exe the template error disappeared for the C target (for the Cpp target it is still there), but the generated code cannot be compiled due to several undefined variables (see attached log file).

[Alexander Täschner <A.Taeschner@…>]

Log file showing undefined variable errors

[anonymous]

Seems to be related to constants not being evaluated.

[Alexander Täschner <A.Taeschner@…>]

The bug is still present in the newest windows nightly (OpenModelica-v1.10.0-dev-479-g3c320a0-64bit.exe).
Looking at the places where the undefined variable errors occured, most of them occure
at a place where the variable is checked to be not null before an division, e.g.:

  tmp1 = _MM;
  if (tmp1 == 0) {throwStreamPrint(threadData, "Division by zero %s", "8.314472 / MM");}
  tmp2 = _d_crit;
  if (tmp2 == 0) {throwStreamPrint(threadData, "Division by zero %s", "d / d_crit");}
  tmp3 = _T;
  if (tmp3 == 0) {throwStreamPrint(threadData, "Division by zero %s", "T_crit / T");}
  _f1._MM = 0.004002602;
  _f1._R = (8.314472) / tmp1;

[Alexander Täschner <A.Taeschner@…>]

Using the newest Windows nightly new template errors, like

[CodegenCFunctions.tpl:4316:14-4316:14:writable] Error: Template error: Unknown expression: <EMPTY(scope: Modelica.Media.Examples.Tests.Components.FixedAmbient$ambient.Medium, name: fluidConstantsHelium.triplePointTemperature, ty: Real(Real min PARAM DAE.EQBOUND(1.0, SOME(1.0), C_PARAM, [DEFAULT VALUE]), Real max PARAM DAE.EQBOUND(10000.0, SOME(10000.0), C_PARAM, [DEFAULT VALUE]), Real nominal PARAM DAE.EQBOUND(300.0, SOME(300.0), C_PARAM, [DEFAULT VALUE]), Real start PARAM DAE.EQBOUND(300.0, SOME(300.0), C_PARAM, [DEFAULT VALUE]), String quantity PARAM DAE.EQBOUND("ThermodynamicTemperature", SOME("ThermodynamicTemperature"), C_PARAM, [DEFAULT VALUE]), String unit PARAM DAE.EQBOUND("K", SOME("K"), C_PARAM, [DEFAULT VALUE]), String displayUnit PARAM DAE.EQBOUND("degC", SOME("degC"), C_PARAM, [DEFAULT VALUE])) origin: .Modelica.Media.Interfaces.Types.Temperature)>.

appeared in addition to the undefined variables.

[Alexander Täschner <A.Taeschner@…>]

Test log generated using Windows nightly OpenModelica-v1.10.0-dev-527-g39b1854-64bit

[adrpo]

I'm pretty much sure this is a front-end issue, not a Codegen one.
Most likely the front-end cannot evaluate some expression and generates "empty" expressions.
The fact the front-end passes is wrong and in the flatten model you probably get expressions using components which are not present in the flattened code. That's why this is only seen at during code generation.

[Alexander Täschner <A.Taeschner@…>]

Any news on solving this bug?

[Alexander Täschner <A.Taeschner@…>]

The bug is still present in the current Windows nightly (OpenModelica-v1.11.0-dev-44-gc709213-64bit.exe). Is there any roadmap for a fix - I think that it would be really important to have a native Modelica Library for fluid properties (e.g. for helium or nitrogen) which can be used in OpenModelica?

[sjoelund.se]

Ticket retargeted after milestone closed

[sjoelund.se]

Milestone moved to 1.12.0 due to 1.11.0 already being released.

[Matthis Thorade <m.thorade@…>]

The division by zero (or, MM not having a value) seems to be related to the way how the record f is initialized!?

Here is the definition of the class:
​https://github.com/thorade/HelmholtzMedia/blob/master/HelmholtzMedia/Interfaces/PartialHelmholtzMedium/EoS/HelmholtzDerivs.mo

and then it gets instantiated here:
​https://github.com/thorade/HelmholtzMedia/blob/master/HelmholtzMedia/Interfaces/PartialHelmholtzMedium/package.mo#L139-L140

[casella]

Replying to Alexander Täschner <A.Taeschner@…>:

The bug is still present in the current Windows nightly (OpenModelica-v1.11.0-dev-44-gc709213-64bit.exe). Is there any roadmap for a fix - I think that it would be really important to have a native Modelica Library for fluid properties (e.g. for helium or nitrogen) which can be used in OpenModelica?

We have been working for more than a year now on the new front-end, which is completely restructured and should solve all problems related to the wrong flattening of Modelica models. You can follow the progress here: #4138.

We are no longer fixing issues in the old back-end, because that would basically be a waste of time, as the new front end will most likely be phased out in 2018.

I'm not sure if the new front end is already capable of handling your test case, you can try it out with the debug flag -d=newInst. If the model is translated then please check that the results are correct and report here, otherwise you need to wait for all the required features to be implemented. Please check regularly. We plan to have a beta of the new front end in a few months.

I'll make this ticket a blocker for release 2.0.0, which will be the first one based entirely on the new front end, see also the project roadmap.

[casella]

Status update: we are making good progress with the new font-end, see ​here and ​here, though it is taking a bit longer than expected.

You can check the status of HelmholtzMedia with OMC ​here. In fact, almost none of the models are working because of known issues of the new front-end, particularly #4918 and #4910. Once these are fixed, we can check if there are any remaining HelmoholtzMedia-specific issues.

[matthis.thorade@…]

Thanks for the update, I am checking every couple of weeks.
The division by zero error due to the way how MM is initialized is also happening in other tools, so I expect that has to be changed in the library.

[casella]

I guess the original problem has been solved in the new front end a long time ago and this ticket is now completely obsolete.

The HelmholtzMedia library is still mostly failing with the new front-end, but due to other problems, feel free to open up-to-date tickets that refer to issues reported from ​this report