Solved by specifying omc flag --tearingmethod=noTearing

Whilst compiling the C code of a closed loop multibody problem I encounter the following errors:

"""
MOP01_d_stable_and_shifted_and_2rods.Platform_03lsy.c:8890:51: error: use of undeclared identifier 'MOP01_d_stable_and_shifted_and_2rods_Platform_initialAnalyticJacobianNLSJac159'
  linearSystemData[0].initialAnalyticalJacobian = MOP01_d_stable_and_shifted_and_2rods_Platform_initialAnalyticJacobianNLSJac159;
                                                                                                                                  ^
MOP01_d_stable_and_shifted_and_2rods.Platform_03lsy.c:8902:50: error: use of undeclared identifier 'MOP01_d_stable_and_shifted_and_2rods_Platform_functionJacNLSJac160_column'
  linearSystemData[1].analyticalJacobianColumn = MOP01_d_stable_and_shifted_and_2rods_Platform_functionJacNLSJac160_column;
                                                                                                                                    ^
MOP01_d_stable_and_shifted_and_2rods.Platform_03lsy.c:8903:51: error: use of undeclared identifier 'MOP01_d_stable_and_shifted_and_2rods_Platform_initialAnalyticJacobianNLSJac160'
  linearSystemData[1].initialAnalyticalJacobian = MOP01_d_stable_and_shifted_and_2rods_Platform_initialAnalyticJacobianNLSJac160;
                                                                                                                                ^
MOP01_d_stable_and_shifted_and_2rods.Platform_03lsy.c:8915:50: error: use of undeclared identifier 'MOP01_d_stable_and_shifted_and_2rods_Platform_functionJacNLSJac161_column'
  linearSystemData[2].analyticalJacobianColumn = MOP01_d_stable_and_shifted_and_2rods_Platform_functionJacNLSJac161_column;
                                                                                                                                   ^
MOP01_d_stable_and_shifted_and_2rods.Platform_03lsy.c:8916:51: error: use of undeclared identifier 'MOP01_d_stable_and_shifted_and_2rods_Platform_initialAnalyticJacobianNLSJac161'
  linearSystemData[2].initialAnalyticalJacobian = MOP01_d_stable_and_shifted_and_2rods_Platform_initialAnalyticJacobianNLSJac161;
                                                                                                                                    ^
6 errors generated.
"""

Apparently, the Jacobian initialization variables are undeclared. Playing with different DASSL Jacobian settings or changing the integration method (e.g. Radau5) makes no difference. Apparently, it's model related...  Help much appreciated.

henk wrote:

Solved ...

One problem remains though: simulation stability with closed-loop (stiff DAE) multibody problems. After a certain simulation time (within OMEdit or with the executable from the commandline), with all available solvers in OMEdit c.q. OpenModelica, numerical noise creeps in the acceleration components, causing the solution to blow up rather than to converge to a stationary (energy dissipated) solution. I'd hoped by exporting to FMI and using PyFMI to have access to Assimulo's Radau5ODE integrator, but apart from PyFMI's default CVode I can't use anything else...

Also solved: Setting enforceStates=true in both body objects allowed the default dassl integrator to do a perfect stable simulation!

Solved by carefully reading Otter, Elmqvist and Mattson's article "The New Modelica Multibody Library" (2003). Very impressed with the thorough work; thanks!

One problem remains though: simulation stability with closed-loop (stiff DAE) multibody problems. After a certain simulation time (within OMEdit or with the executable from the commandline), with all available solvers in OMEdit c.q. OpenModelica, numerical noise creeps in the acceleration components, causing the solution to blow up rather than to converge to a stationary (energy dissipated) solution. I'd hoped by exporting to FMI and using PyFMI to have access to Assimulo's Radau5ODE integrator, but apart from PyFMI's default CVode I can't use anything else...

In order to built op my Modelica multibody modeling skills, I try to get the following simple multibody problem working (mass under dual parallel springs) -- it contains a planar, kinematic loop (can be straight loaded in OMEdit):

model MultibodyDAE

  inner Modelica.Mechanics.MultiBody.World world(label2 = "y", n = {0,-1,0}) annotation(Placement(visible = true, transformation(origin = {-66.7694,62.4183}, extent = {{-12,-12},{12,12}}, rotation = 0)));

  Modelica.Mechanics.MultiBody.Parts.FixedTranslation fixedtranslation1(r = {1,0,0}) annotation(Placement(visible = true, transformation(origin = {-14.1176,62.1849}, extent = {{-12,-12},{12,12}}, rotation = 0)));

  Modelica.Mechanics.MultiBody.Forces.Spring spring1(c = 1, s_unstretched = 1) annotation(Placement(visible = true, transformation(origin = {-26.5546,36.9748}, extent = {{-12,12},{12,-12}}, rotation = -90)));

  Modelica.Mechanics.MultiBody.Parts.Body body1(r_CM = {0,1,0}, r_0(start = {0,-1,0}, fixed = true), m = 1, I_11 = 1, I_22 = 1, I_33 = 11) annotation(Placement(visible = true, transformation(origin = {-15.7983,-1.0084}, extent = {{-12,12},{12,-12}}, rotation = -90)));

  annotation(experiment(StartTime = 0.0, StopTime = 10.0, Tolerance = 0.000001));

  Modelica.Mechanics.MultiBody.Sensors.AbsoluteAngles body1Angles annotation(Placement(visible = true, transformation(origin = {27.8992,10.4202}, extent = {{-12,-12},{12,12}}, rotation = 0)));

  Modelica.Mechanics.MultiBody.Forces.Spring spring2(c = 1, s_unstretched = 1) annotation(Placement(visible = true, transformation(origin = {-2.01681,36.6387}, extent = {{-12,12},{12,-12}}, rotation = -90)));

equation

  connect(fixedtranslation1.frame_b,spring2.frame_a) annotation(Line(points = {{-2.1176,62.1849},{-2.01681,62.1849},{-2.01681,48.6387},{-2.01681,48.6387}}));

  connect(spring2.frame_b,body1.frame_a) annotation(Line(points = {{-2.01681,24.6387},{-1.68067,24.6387},{-1.68067,10.9916},{-15.7983,10.9916}}));

  connect(body1.frame_a,body1Angles.frame_a) annotation(Line(points = {{-15.7983,10.9916},{16.4706,10.9916},{16.4706,10.4202},{15.8992,10.4202}}));

  connect(spring1.frame_b,body1.frame_a) annotation(Line(points = {{-26.5546,24.9748},{-26.8908,24.9748},{-26.8908,10.9916},{-15.7983,10.9916}}));

  connect(fixedtranslation1.frame_a,spring1.frame_a) annotation(Line(points = {{-26.1176,62.1849},{-26.2185,62.1849},{-26.2185,48.9748},{-26.5546,48.9748}}));

  connect(world.frame_b,fixedtranslation1.frame_a) annotation(Line(points = {{-54.7694,62.4183},{-25.8824,62.4183},{-25.8824,62.1849},{-26.1176,62.1849}}));

end MultibodyDAE;

The 3 degrees of freedom are the body's x,y-translations and it's z-rotation (r_CM under frame_a). As is, the problem won't simulate and stops after a fraction of a second.

I've read about index reduction, and how the "overdetermined DAE -> ODE" translation in (Open)Modelica can be helped (stateSelect) to get the desired result. My understanding however is still partial. Some guidance is much welcomed!

Simulation in OMEdit of a closed-loop multibody system with dopri5 integration routine is numerically unstable (i.e. doesn't converge) and blows up after a certain time. However,  using "omc +s <modelica files>" with exactly the same model (followed by "make -f <model>.makefile" ) from the Linux console (with dopri5 specified in the _init.xml file) shows a perfectly stable simulation. Confusing, isn't it...?! What could be different?

-- Henk

yzh89 wrote:

Did u change the parameter of MIMO? There is a parameter for number of input arguments and output arguments. I don't see the problem you described above. u also comes with a index when you do the connection.

That's true when instantiating the pure MIMO Interface. When instantiating implementations of the MIMO interface (e.g. Modelica.Blocks.Continuous.StateSpace) then the dialogue asking for the j-index (i.e. which input u[j] must be connected to) disappears... So the mystery remains...

-- Henk

MIMO is the base (partial) class for general m-input to n-output mappings. I want to connect the output of an AbsoluteSensor to a specialized MIMO block (specialized by inheritance to operate on vector input u, i.e. y=f(u)). Trying to connect the sensor output to the MIMO imput the dialogue asks me to specify the integer i so that "r[i] is connected to u"; I had expected a dialogue to specify integers (i,j) so that "r[i] is connected to u[j]". Thus, I concluded the r[i] must be assembled first into a vector that matches the size of u by using a Blocks.Routing.Muliplex class. Having done so, also this doesn't work... Any idea how to make the connection described? Thanks.

-- Henk

sjoelund.se wrote:

How you keep getting p1=p2=0.0 I do not know (since I get the correct values).

The correct values you get, are they 'flattened in' (i.e. statically assigned), or the result of a (intended) function call? (my zeros initialization are 'flattened in', i.e. the function call is bypassed/eliminated all together -- it only happens when using as argument to the C-function a modelica record/C-struct, it doesn't happen with a Real[2]).

sjoelund.se wrote:

But if you do not want the call evaluated during flattening, you need to tell the compiler that it is impure, because all functions are assumed to be pure.

annotation(__OpenModelica_Impure=true) in the function should do the trick.

OK, now my code is:

record Parameters

  Real p1=0,p2=0;

end Parameters;



function twovals "Function with output arguments passed through python;"

  annotation(__OpenModelica_Impure=true);           // <<=== Impure ANNOTATION inserted

  //output Real p[2];

  output Parameters p;

  //external "C" C_twovals_reals(p) annotation(Library="initpar.o");  // arg p is Real[2]

  external "C" C_twovals_struct(p) annotation(Library="initpar.o");   // arg p is record (C-struct)

end twovals;



class DAE05

  Real x(start=0.9);

  Real y;

  //parameter Real[2] p = twovals();

  parameter Parameters p = twovals();                                    // line 17 (where variability error happens)

equation

  //der(y)+(1+p[1]*sin(y))*der(x) = sin(time);

  //x - y = exp(-p[2]*x)*cos(y);

  der(y)+(1+p.p1*sin(y))*der(x) = sin(time);

  x - y = exp(-p.p2*x)*cos(y);

end DAE05;

where initpar.c is:

/* initpar.c */



void import_twovals()

{ 



    /* module is loaded only once. */

    printf("Importing twovals module!\n");

    import_twovals_py2c();

};



struct Parameters {

    double p1,p2;

};



void C_twovals_struct(struct Parameters *p)   /* flattened out, doesn't return proper initialization values, i.e p.{p1,p2} stay {0.0,0.0} */ 

{

    p->p1 = 1.0;

    p->p2 = 2.0;

};



void C_twovals_reals(double p[2])    /* flattened out, yet returns proper initialization values */ 

{

        p[0] = 1.0;

        p[1] = 2.0;

};

Now I obtain a variability error message:

omc +s DAE05.mo

Error processing file: DAE05.mo

[DAE05.mo:17:3-17:38:writable] Error: Component p of variability PARAM has binding initpars() of higher variability VAR.

Any idea?

-- Henk

sjoelund.se wrote:

Are you sure? I get:

Code:

class DAE05

  Real x(start = 0.9);

  Real y;

  parameter Real p.p1 = 1.0;

  parameter Real p.p2 = 2.0;

equation

  der(y) + (1.0 + p.p1 * sin(y)) * der(x) = sin(time);

  x - y = exp((-p.p2) * x) * cos(y);

end DAE05;

...   

You're right, but it also shows the problem: in this trivial example the external function call (setting values for the Modelica record) is eliminated (parsed out) during the flattening stage (which doesn't happen when the argument is an Real array). My intention is to use a bit less trivial record initialization routine (that shouldn't be flattened out), but the external function call combined with a record argument is systematically parsed out.

I believe the problem may have to do with the fact that in OMC a record is 'systematically' (or not...?!) transformed into a record initialization function; at least that's what I believe when I see the flattened file:

function Parameters "Automatically generated record constructor for Parameters"  <<<=== a "function"!

  input Real p1 = 0.0;

  input Real p2 = 0.0;

  output Parameters res;

end Parameters;



function twovals                                               <<<=== not used at all!

  output Parameters p;



  external "C" C_initpar(p);

end twovals;



class DAE05

  Real x(start = 0.9);

  Real y;

  parameter Real p.p1 = 0.0;                                      <<<=== result of flattening

  parameter Real p.p2 = 0.0;                                      <<<=== result of flattening 

equation

  der(y) + (1.0 + p.p1 * sin(y)) * der(x) = sin(time);

  x - y = exp((-p.p2) * x) * cos(y);

end DAE05;

To state my basic desire briefly: how can I return multiple values from a single external function call (and not, as is the case with arrays, to have multiple indexed calls...)? Thanks.

-- Henk

I have a problem with using a struct as a return type for an external fucntion. E.g. none of the following external function calls work:

record Parameters
  Real p1=0,p2=0;
end Parameters;

function twovals
  output Parameters p;
    // external "C" C_initpar(p) annotation(Library="initpar.o");    // doesn't work
    external "C" p = C_initpar() annotation(Library="initpar.o");   // doesn't work either
end twovals;

class DAE05
   Real x(start=0.9);
   Real y;
     parameter Parameters p = twovals();      // call parameter initialization
equation
   der(y)+(1+p.p1*sin(y))*der(x) = sin(time);
    x - y = exp(-p.p2*x)*cos(y);
end DAE05;

...where initpar.c is:


struct Parameters {
    double p1,p2;
};

void C_initpar(struct Parameters *p)
{
    p->p1 = 1.0;  /* actually, will be read from external. */
    p->p2 = 2.0; /* idem */
};

Actually, the omc compiler completely bypasses initpar.c and makes in the flattened modelica the straightaway assignment:

"""
parameter Real p1 = 0.0;
parameter Real p2 = 0.0;
"""

where both values are taken straight away from the default record initialization (?!)

I had it working this way with a modelica array, i.e. Real[2],...; how about using a struct (i.e. the above situation)? Thanks.

-- Henk

henk wrote:

sjoelund.se wrote:

+a is an experimental flag that is not supported by the OpenModelica backend

"Experimental" here apparently means 'supported by the OpenModelica frontend only'. Does it also mean that it will be supported by the backend sometime, and if so, is there any idea when?.

Found that problem is linked to: Bug [# 1575] Really bad code generation for parameter arrays set via a function call...

Is work on its solution in sight? If not, is there a 'cleaner' alternative (than indexing multiple calls) to return arrays from external functions?

-- Henk

sjoelund.se wrote:

+a is an experimental flag that is not supported by the OpenModelica backend

"Experimental" here apparently means 'supported by the OpenModelica frontend only'. Does it also mean that it will be supported by the backend sometime, and if so, is there any idea when? (I can see the difficulty of how to handle arrays in a symbolic context...).

-- Henk

Compilation of the following simple test.mo file ("omc +a +s +showErrorMessages test.mo")

class Test
    parameter Integer p[2] = {1,2};
end Test;

causes the error message:

class Test
  parameter Integer p[1:2] = {1,2};
end Test;
{"Error: Internal error BackendDAEUtil.traverseBackendDAEExps failed", "TRANSLATION", "Error", "63"}
Error processing file: test.mo
Error: Internal error BackendDAEUtil.traverseBackendDAEExps failed

# Error encountered! Exiting...
# Please check the error message and the flags.

Execution failed!

I've studied the Language Specification intensively, yet cannot see what I do wrong... Help appreciated! Thanks.

-- Henk

I'm using MultiBody from the MSL. How can I create/attach an extra frame that is rigidly connected to an inertial part/component? (I need these extra frames in order to introduce forces/torques acting on the inertial component in a physically meaningful way).

Thanks, Henk

Two questions puzzle me:

1) Why can't the omc compiler compile a flattened file that itself has created? I found the following language aspects (in the flattened file) causing parsing errors:

1. Qualified (i.e. dot-separated) variable names;


2. Multi quote annotations (e.g. "anno_1" "anno_2"


3. Unresolved "+ -" arithmetic constructs


4. <matrix> constructs (what are these..., I can't find information on this Modelica language feature..>?)