#5260 closed defect (wontfix)
Incompatibility between OM & Dymola on some variable initializations
Reported by: | Owned by: | Adeel Asghar | |
---|---|---|---|
Priority: | high | Milestone: | 1.14.0 |
Component: | OMEdit | Version: | v1.12.0 |
Keywords: | Cc: | audrey.jardin@… |
Description
Hello,
Please load in OM the attached file temp.mo that perfectly runs under Dymola.
Check the model TestRealTransmission (located in temp.Basic.Tests): there is an error given by OM on variable ud1.
To avoid this error open the model RealTransmission (in temp.Basic.Operators) and:
- uncomment the two lines defining the variables ud1 & ud2 without the starting value from variable u
- comment the two lines defining the variables ud1 & ud2 with the starting value from variable u
Now the check is ok and the model TestRealTransmission can run.
But unhappily the results are not correct.
To see that please compare the input variable sine.y and the output variable realTranmission.y[3]: the starting value of these two variables should be the same.
Ideally, the syntax accepted by Dymola should also be accepted by OM.
Best.
Attachments (2)
Change History (4)
by , 6 years ago
comment:1 by , 6 years ago
Resolution: | → wontfix |
---|---|
Status: | new → closed |
by , 6 years ago
comment:2 by , 6 years ago
Hum... I updated the model as you proposed in order to initialize variables ud1 & ud2 with the variable u.
Now right the model can run and the results are correct.
Nevertheless when I change the value of parameter samplingPeriod in class realTransmission of model TestRealTransmission to get the default value (zéros(nR))the model cannot run.
I give you the updated model temp2.mo.
We are sorry, but OpenModelica implements the Modelica standard, not other dialects implicitly defined by other tools. The main reason against doing this is that the expected behaviour outside the Modelica specification is not specified clearly anywhere; besides, reverse-engineering commercial tools is not allowed.
The start attribute needs to be a parameter in Modelica, it can't be a variable, see the Modelica specification, Sect. 4.8.1.
If you need to use the initial value of a variable as a start attribute for another variable, you may use this kind of construct
Of course this only works if structural analysis of the system reveals that the initial value of
x
can be computed before computing the initial value ofy
, but I guess this is the case in your example if Dymola can handle it.