Hi Victor,
Comments inline...
Víctor Martínez-Moll wrote:
Hi all,
I've been playing for some time with OpenModelica and, on the one hand,
I'm very impressed with the flexibility and ease of use of Modelica and
some very nice features of OpenModelica itself like the OmNotebook.
These features made me think that OM could be terrific tool to use in an
introductory course on Mechanics. But, on the other hand, I found very
disappointing that I can not predict in any reasonable way when a model
is going to work or not.
We are working on fixing this. We have a plan in work for a better
solver interface which should support additional solvers and give
meaningful error messages back to the user.
For example solving position problems for bar
mechanisms only worked when only one angle was unknown, and even then I
get some weird behaviors like the following:
This model works fine:
model PistonMovement
constant Real pi=3.1415926535897932384626433832795;
parameter Real l1=3., l2=5., omega=1., th3=pi;
Real th1,th2(start=5.639684198386), x(start=4.);
equation
th1=time*omega+pi/2.;
l1*cos(th1)+l2*cos(th2)+x*cos(th3)=0;
l1*sin(th1)+l2*sin(th2)+x*sin(th3)=0;
end PistonMovement;
But this one yields wrong results:
model PistonMovement2
constant Real pi=3.1415926535897932384626433832795;
parameter Real l1=3., l2=5., omega=1.;
Real th1,th2(start=5.639684198386), x(start=4.);
equation
th1=time*omega+pi/2.;
l1*cos(th1)+l2*cos(th2)-x=0;
l1*sin(th1)+l2*sin(th2)=0;
end PistonMovement2;
I think this is a bug in the simulation code generation
as far as I could debug it myself.
In the first example it solves a non-linear system made
of the last 2 equations, but in the second it considers
only the second equation for solving which gives wrong
results.
I will add this to the bug list:
http://openmodelica.ida.liu.se:8080/cb/proj/tracker/browseTracker.do?tracker_id=1
As you can see in the first model th3 is a constant equal to PI and, in
the second one I only suppressed th3 and replaced cos(th3) by -1 and
sin(th3) by 0.
I simulated both models with the command:
simulate(Name of each model, stopTime=10.)
And I'm using OMNotebok 3.0 for OpenModelica 1.4.4 on Windows Vista.
Another problem I found is that many elements from the Standard Modelica
Library do not work.And I'm not talking about the multibody library or
others that are not supported. I'm talking about those parts of the
library included with OpenModelica and that are supposed to work fine
like the Mechanical.Translational one.
In the following example, If I use the SlidingMass component the model
works fine, but if I define the same simple model using the Stop
component there is no way (that I know) to make it work.
The good one:
model prova
import Tra = Modelica.Mechanics.Translational;
Tra.Force forca(f=1.);
Tra.SlidingMass massa(m=1.);
equation
connect(forca.flange_b, massa.flange_a);
end prova;
The bad one:
model prova
import Tra = Modelica.Mechanics.Translational;
Tra.Force forca(f=1.);
Tra.Stop massa(m=1., L=0., smax=1000., smin=-1000., v_small=0.001,
F_prop=.00001, F_Coulomb = .0001, F_Stribeck = .0002, fexp=2.);
equation
connect(forca.flange_b, massa.flange_a);
end prova;
I tried many different values for the Stop parameters with the same result.
The Stop model uses when in algorithm sections which we don't support
yet in OpenModelica. The second prova model doesn't reach the code
generation as it doesn't pass the flattening process.
My question to the forum is: Are those problems due to the OpenModelica
solver, that it is not able to solve problems with several nonlinear
transcendental equations or manage highly nonlinear components of the
library like the Stop component, or it is something I'm doing wrong? (or
that I could do better?) And If so, does anybody have any hints on what
would be the right way to do it?
OpenModelica has roughly 3 parts:
- the flattener which gets rid of the object orientation
and generates flat mModelica (i.e. instantiateModel(Model))
- the code generator which generates code from a flattened model
that is then linked with the simulation runtime to generate
an executable.
- the simulation runtime contains low level implementation of
the Modelica functionality (events, builtin functions, etc)
and the solvers needed for the numerical integration.
I would say most of our problems are right now in the flattening part
as some of the parts in the Modelica specification are not implemented.
Thanks in advance for your attention (and for your responses)
Victor
Cheers,
Adrian Pop/
_____________________________________________________________________
Adrian Pop | PhD
Department of Computer Science | http://www.ida.liu.se/~adrpo
Linköping University | phone:+46 13 285781/+46 76 2343499
S-581 83 Linköping, Sweden | fax: +46 13 142231
LiU/IDA/PELAB | office: 3B:478
