Opened 9 years ago
Closed 7 years ago
#3674 closed defect (fixed)
Template error generated by omc
Reported by: | Owned by: | Per Östlund | |
---|---|---|---|
Priority: | blocker | Milestone: | 2.0.0 |
Component: | New Instantiation | Version: | v1.11.0 |
Keywords: | Cc: |
Description
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.
Attachments (4)
Change History (25)
by , 9 years ago
Attachment: | HeliumTestModelTotal.mo added |
---|
comment:1 by , 9 years ago
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).
comment:2 by , 9 years ago
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).
comment:3 by , 9 years ago
Component: | *unknown* → Code Generation |
---|---|
Owner: | changed from | to
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)[...]".
comment:5 by , 9 years ago
Version: | v1.9.4-dev-nightly → v1.9.5-dev-nightly |
---|
comment:7 by , 9 years ago
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).
comment:9 by , 9 years ago
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;
comment:10 by , 9 years ago
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.
by , 9 years ago
Attachment: | test_527.log added |
---|
Test log generated using Windows nightly OpenModelica-v1.10.0-dev-527-g39b1854-64bit
comment:11 by , 9 years ago
Owner: | changed from | to
---|---|
Status: | new → accepted |
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.
comment:12 by , 9 years ago
Component: | Code Generation → Frontend |
---|
follow-up: 18 comment:14 by , 8 years ago
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?
comment:16 by , 8 years ago
Milestone: | 1.11.0 → 1.12.0 |
---|
Milestone moved to 1.12.0 due to 1.11.0 already being released.
comment:17 by , 7 years ago
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
comment:18 by , 7 years ago
Milestone: | 1.12.0 → 2.0.0 |
---|---|
Priority: | critical → blocker |
Version: | v1.10.0-dev-nightly → v1.11.0 |
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.
comment:19 by , 7 years ago
Component: | Frontend → New Instantiation |
---|---|
Owner: | changed from | to
Status: | accepted → assigned |
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.
comment:20 by , 7 years ago
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.
comment:21 by , 7 years ago
Resolution: | → fixed |
---|---|
Status: | assigned → closed |
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
Save total file of the model