#3701 closed defect (fixed)
A regression
Reported by: | massimo ceraolo | Owned by: | Willi Braun |
---|---|---|---|
Priority: | normal | Milestone: | 1.9.4 |
Component: | Code Generation | Version: | v1.9.4-dev-nightly |
Keywords: | Cc: | Vitalij Ruge, Willi Braun |
Description
The attached "EV_DAEissue.mo" contains a model named EVbasic.
I could run this model (and a lot of more complex models based on this one) with OM.
This model runs well under OM 1.9.3 (release)
On the latest nightly build it does not run, and emits the following error:
[3] 09:53:16 Translation Error
[CodegenCFunctions.tpl: 5009:16-5009:16]: Template error: daeExpRelation {{0.0, 0.0}} <> {{0.0, 0.0}}
Attachments (3)
Change History (20)
by , 9 years ago
Attachment: | EV_DAEissue.mo added |
---|
comment:1 by , 9 years ago
Component: | *unknown* → Code Generation |
---|---|
Owner: | changed from | to
comment:2 by , 9 years ago
Same here, I can simulate the model fine with OpenModelica v1.9.4-dev.beta2-10-g4d534f7.
The error seems to be some comparison of tuples but there are none in the flattened code.
comment:3 by , 9 years ago
Maibe omeditcommunication.log can help. I enclose it.
I used the exe downloaded today: OpenModelica-v1.9.4-dev.beta2-15-g2dbe6e3.exe
by , 9 years ago
Attachment: | omeditcommunication.log added |
---|
comment:4 by , 9 years ago
This is strange, I just installed your version (the latest nightly build) loaded your model and simulated it and it still works fine for me:
stdout | OMEditInfo | <p>C:/Users/adrpo/AppData/Local/Temp/OpenModelica/OMEdit/EV_DAEissue.EVbasic.exe -port=39743 -logFormat=xml -override=startTime=0,stopTime=80,stepSize=0.1,tolerance=0.0001,solver=dassl,outputFormat=mat,variableFilter=.* -r=EV_DAEissue.EVbasic_res.mat -dasslJacobian=coloredNumerical -w -lv=LOG_STATS</p> LOG_STATS | info | <p>### STATISTICS ###</p> stdout | OMEditInfo | <p>Simulation process finished successfully.</p>
by , 9 years ago
Attachment: | ScreenShot.png added |
---|
follow-up: 7 comment:6 by , 9 years ago
Here are my steps to reproduce the issue:
1) load OMEdit
2) load (from OMEdit) "EV_DAEissue.mo"
3) select EVBasic
4) click on the "Simulate" button
A screenshot of the result is on the file "ScreeenShot.png"
comment:7 by , 9 years ago
Replying to ceraolo:
Here are my steps to reproduce the issue:
1) load OMEdit
2) load (from OMEdit) "EV_DAEissue.mo"
3) select EVBasic
4) click on the "Simulate" button
A screenshot of the result is on the file "ScreeenShot.png"
I do basically the same and the model builds fine. Do you have some special settings in OMEdit?
What Modelica library do you use?
comment:8 by , 9 years ago
Can you please do right click Instantiate Model on the model and attach the result here?
comment:9 by , 9 years ago
OK, if found the issue. You have the special flag +gDynOpt which causes the problem.
comment:10 by , 9 years ago
With this flag an equation of this form is generated:
3/3 (1): dragF.f.$pDERA.dummyVarA + -2.3907 * (mass.v ^ 2.0 * dragF.Sign.$pDERA.dummyVarA + 2.0 * mass.v * mass_vSeedA * dragF.Sign) = if dragF.locked then dragF.sa.$pDERA.dummyVarA else 2039.7832 * (if dragF.startForward then (if mass_vSeedA <> 0.0 then mass_vSeedA * $DER$$PModelica$PMath$PtempInterpol1(mass.v, {{0.0, 1.0}}, 2, 1.0, {{0.0, 0.0}}) else 0.0) + (if {{0.0, 0.0}} <> {{0.0, 0.0}} then {{0.0, 0.0}} else {{0.0, 0.0}}) else if dragF.startBackward then (-(if (-mass_vSeedA) <> 0.0 then (-mass_vSeedA) * $DER$$PModelica$PMath$PtempInterpol1(-mass.v, {{0.0, 1.0}}, 2, 1.0, {{0.0, 0.0}}) else 0.0)) - (if {{0.0, 0.0}} <> {{0.0, 0.0}} then {{0.0, 0.0}} else {{0.0, 0.0}}) else if pre(dragF.mode) == 1 then (if mass_vSeedA <> 0.0 then mass_vSeedA * $DER$$PModelica$PMath$PtempInterpol1(mass.v, {{0.0, 1.0}}, 2, 1.0, {{0.0, 0.0}}) else 0.0) + (if {{0.0, 0.0}} <> {{0.0, 0.0}} then {{0.0, 0.0}} else {{0.0, 0.0}}) else (-(if (-mass_vSeedA) <> 0.0 then (-mass_vSeedA) * $DER$$PModelica$PMath$PtempInterpol1(-mass.v, {{0.0, 1.0}}, 2, 1.0, {{0.0, 0.0}}) else 0.0)) - (if {{0.0, 0.0}} <> {{0.0, 0.0}} then {{0.0, 0.0}} else {{0.0, 0.0}})) [dynamic]
Which contains the problematic relation:
if {{0.0, 0.0}} <> {{0.0, 0.0}} then {{0.0, 0.0}} else {{0.0, 0.0}}.
comment:11 by , 9 years ago
Ah, thank you.
It was very difficult to find this (I did not at all).
Is there a way to warn the user somehow to avoid this?
Or maybe it is possible to avoid this conflict? I don't have this issue with 1.9.3 release even while having +gDynOpt active (on a Mac).
I believe (but I'm not absolutely sure) that I didn' have this issues on a Win PC with +gDynOpt.
comment:12 by , 9 years ago
Cc: | added |
---|
This for sure is a bug but I don't know to which person should I assign it, maybe Vitalij?
Lennart, what do you think?
follow-up: 14 comment:13 by , 9 years ago
Owner: | changed from | to
---|---|
Status: | new → assigned |
I will check that, since it seems to be an expression of the symbolic jacobian.
follow-up: 15 comment:14 by , 9 years ago
Replying to wbraun:
I will check that, since it seems to be an expression of the symbolic jacobian.
The bad expression seems to come from Differentiate.createPartialSum while differentiating Modelica.Math.tempInterpol1. It seems not to find Modelica.Math.tempInterpol1_der?
comment:15 by , 9 years ago
Replying to adrpo:
Replying to wbraun:
I will check that, since it seems to be an expression of the symbolic jacobian.
The bad expression seems to come from Differentiate.createPartialSum while differentiating Modelica.Math.tempInterpol1. It seems not to find Modelica.Math.tempInterpol1_der?
Ah, yes, is the jacobian calculation, not wrt time.
comment:16 by , 9 years ago
Resolution: | → fixed |
---|---|
Status: | assigned → closed |
fixed in d6e73f0/OMCompiler.
comment:17 by , 7 years ago
Milestone: | Future → 1.9.4 |
---|
I cannot reproduce the issue. For me the simulation just works fine. This is the script that I used for testing: