- Index
- » Users
- » baharev
- » Profile
Posts
Posts
No, unfortunately. You are the first one to react to my post.
I am trying to get the topological information of Modelica models (connections of the blocks, how the blocks are nested hierarchically, etc). It turns out that almost everything can be fairly easily reconstructed from the modelDescription.xml; I already have a Python prototype that works reasonably well for easier models.
All my models are causal. The difficulty is that the input and output information on the connectors seem to be lost.
I have attached a simple model:
inout-omedit.mo
To flatten the model, I simple clicked Export > Export.xml in OMEdit. I expected the causality attributes in the modelDescription.xml to be "input" and "output" accordingly but they are "internal".
What am I doing wrong? Would it be possible to somehow tell the OpenModelica compiler to write this information (input or output on connectors) to the modelDescription.xml?
As a related question: Can I somehow disable all simplification by the compiler except constant folding (constant propagation) when exporting to xml?
A quite hackish workaround to get the input-output information is to manually tag the connectors in the .mo file with "in" and "out" (see the attached file); then I get these strings in the description attribute. This gives me a workaround for the time being but it is obviously not a solution.
Many thanks,
Ali
I will try it, thanks for the advice.
For some reason I did not get a notification in e-mail (or accidentaly deleted with the junk mail).
Dear Jens, dear Patrik,
Thanks for the response, for some reason I did not get a notification in e-mail (or accidentaly deleted with the junk mail).
Thanks for the response, for some reason I did not get a notification in e-mail (or accidentaly deleted with the junk mail).
Anyhow, what should I do now?
The above code compiles nicely with the JModelica compiler and the correct equations are generated.
I would greatly appreciate any help to get this work in OpenModelica.
With the InOutArray.mo I get:
Error: Variable m.x[1] is not referenced in any equation (possibly after symbolic manipulations).
However if I make it scalar instead of an array, everything works fine, try that with InOut.mo.
The InOutArray.mo is a simplified version of a complicated model that is why it looks awkward and silly. With the complicated model I get either
Error: Internal error BackendDAETransform.selectDummyState: no state to select
or
Error: An independent subset of the model has imbalanced number of equations (3) and variables (2).
depending on how I change that complicated model.
Any help is greatly appreciated.
---------------------
For some reason I cannot attach files, it says "Upload error"
InOutArray.mo giving the error:
package InnerOuter
constant Integer C=1;
partial class Equations
inner Real x[C];
inner Real y[C];
replaceable class FirstEq = Eq1;
replaceable class SecondEq = Eq2;
FirstEq eq1;
SecondEq eq2;
end Equations;
partial class Eq1
outer Real x[C];
outer Real y[C];
end Eq1;
partial class Eq2
outer Real x[C];
outer Real y[C];
end Eq2;
class EqA
extends Eq1;
equation
x[1] + y[1] = 1;
end EqA;
class EqB
extends Eq2;
equation
x[1]*x[1] + y[1]*y[1] = 1;
end EqB;
end InnerOuter;
model InOut
import InnerOuter.*;
class Main
extends Equations;
redeclare class FirstEq = EqA;
redeclare class SecondEq = EqB;
end Main;
Main m;
end InOut;
-----------
InOut.mo, basicly the same as above but this one works:
package InnerOuter
partial class Equations
inner Real x;
inner Real y;
replaceable class FirstEq = Eq1;
replaceable class SecondEq = Eq2;
FirstEq eq1;
SecondEq eq2;
end Equations;
partial class Eq1
outer Real x;
outer Real y;
end Eq1;
partial class Eq2
outer Real x;
outer Real y;
end Eq2;
class EqA
extends Eq1;
equation
x + y = 1;
end EqA;
class EqB
extends Eq2;
equation
x*x + y*y = 1;
end EqB;
end InnerOuter;
model InOut
import InnerOuter.*;
class Main
extends Equations;
redeclare class FirstEq = EqA;
redeclare class SecondEq = EqB;
end Main;
Main m;
end InOut;
New equations involving division are introduced when I pass +d=tearing,dumpindxdae,backenddaeinfo to the compiler.
Unfortunately I get division by zero errors.
I tried setting start=1 on the critical variables so no division by zero occurs. Unfortunately my attemps have no effect and I do not know why.
How can I ask the compiler to do as much symbolic simplification as it can but avoid dangerous ones?
Many thanks!
As understand this, the OpenModelica compiler performs symbolic manipulation during the generation of the code.
How can I get the number of variables / equations of the model after this transformation?
What flags should I pass to compiler in OMEdit so that my model is reasonably well reduced?
I tried
+d=tearing,dumpindxdae,backenddaeinfo
but I cannot interpret the results.
Many thanks!
Thank you very much, it works!
What is the rationale behind the behavior that caused me the problem? Why is that confusing behavior useful?
Aims: all the derived classes should inherit some default equations from their base class. When the default equation is not valid for a derived class then it should redeclare it.
Here is a somewhat silly minimalistic example.
Code:
package Pkg
class Equations
Real x;
end Equations;
class DefaultEquations
extends Equations;
equation
x = 0.0;
end DefaultEquations;
class Base
replaceable DefaultEquations equations extends Equations;
end Base;
end Pkg;
model DuplicateEquations
import Pkg.*;
class CustomizedClass
extends Base;
redeclare Equations equations;
equation
equations.x = 3;
end CustomizedClass;
CustomizedClass customized;
end DuplicateEquations;
For some mysterious reason, the default equation is not overriden:
Code:
omc Test.mo Package.mo
class DuplicateEquations
Real customized.equations.x;
equation
customized.equations.x = 0.0;
customized.equations.x = 3.0;
end DuplicateEquations;
Why is this happening? Why are both x=0 and x=3 generated?
If I comment out the package declaration I get only the expected x=3 equation.
I cannot delete my post. Anyhow, I will come up with a simpler code example showing my problem. Sorry for the annoyance.
- Index
- » Users
- » baharev
- » Profile