Fixed with commit 4c49398.

Actually, I expected a release before this summer, but my feeling is it will delay to end of summer or autumn.

Hi,

FMI is quite imported, so we will try to fix it for the release of 1.13.
Thank you reporting the issue.

so long.
Willi

Okay, it would be nice if you would open a ticket with a link to the related model.

Tthe question is which version did you use before?
The issue is we would need the model to sort things out, would it possible to share your model or parts of it?
Yes, it sounds like something that worth a ticket.

Unfortunately, OMOptim is a bit outdated and there is currently nobody, who is maintaining it.

Maybe you have more luck with an older version of OpenModelica. OMOptim was included in
2012, with the release 1.8.1, but maybe also the 1.9 and 1.9.1 probably have a better working
connection of OMOptim to OpenModelica.

Hello and welcome to the OpenModelica forum,

What kind of linear solver are you planning to integrate?

We use linear solvers for several purposes, therefore we have different modules at different places.

On one hand there is the implementation of SUNDIALS/IDA, which has it's own interface to integrate
different linear solvers. Here the user can choose between internal linear solver, LAPACK, KLU,
SUPERLU and some more iterative solvers. Here is OpenModelica the user.
Currently we interfacing from IDA: KLU and LAPACK .

On the other Hand we need to solve, so called linear "algebraic loops" to obtain the RHS for the integrator.
Here we are also interfacing different external solver e.g. KLU, UMFPACK, LAPACK, but we have also
some own implementations like the totalpivot solver.

As far as I understand you want to integrate your linear solver into the IDA integrator, then it's enough
to add it under 3rdParty/sundials/idas and interfacing it in SimulationRuntime/c/simulation/ida_solver.c,
that you do not need to use "linearSystem" module.

Do you have your code on github? Then you could probably start a Pull-Request and we can further see
what you have done how it would fit into the project.

so long.
WIlli

adamLange wrote:

Is this right?:
  - there are different tolerances for the integration step and for the non-linear solver. 
  - there is a default tolerance applied to the non-linear solver.
  - an appropriate simulation flag must be passed to override the non-linear solver tolerance.

Yes, and you found already the correct simulation flags to tune this tolerance.

Hello,

you can further debug the timings with "-d=execstat", this enabled debug flag execstat, that dumps the time spend in each module.
Based on that analysis it's probably possible to change the configuration, so that the compiler performs better.

so long.
Willi

OpenModelica is able to generate FMU from specific models. This FMU can than accessed via FMI (https://www.fmi-standard.org/) from a custom libraries, maybe  also interesting a FMIL(http://www.jmodelica.org/FMILibrary).

Dave wrote:

Code:

Real y(start=5);

Real y_dot(start=0);

Any reason why I am getting this error?

Since without fixing the start value by the fixed attribute (fixed=true) this are just initial guess and not initial conditions.

watkipet wrote:

Are omega_0 and delta actually variables? They kinda look like parameters. What happens when you add the parameter keyword?

Yes, omega_0 and delta are variables, but are treated like parameters while the compile process. The difference is that this variable as parameters are changeable after the compile process.

Are you using omc flag

-d=initialization

?
If so and you don't get an useful error message, please consider to add a ticket with your model to our trac .

But on what should the rising depend on?

You can have an input:

model linearEquation

  parameter Real a=2;

  parameter Real b=1;

  input Real u;

  Real x(start=0);

  Real y;

equation

   x = u;

   y = a*x+b;

   annotation(experiment(StopTime = 10));

end linearEquation 

Or depending on time in a different order:

model linearEquation

  parameter Real a=2;

  parameter Real b=1;

  Real x(start=0);

  Real y;

equation

   der(x) = if x>=10 then 0 else 1;

  y = a*x+b;

  annotation(experiment(StopTime = 10));

end linearEquation 

so long.
Willi

Maybe like that:

model linearEquation

  parameter Real a=2;

  parameter Real b=1; 

  Real x = time;

  Real y;

equation

  y = a*x+b;

  annotation(experiment(StopTime = 10));

end linearEquation

so long.
Willi

JoakimSandin wrote:

I have a continuous Real variable h and I need to use the previous value of that variable in an equation.
[...]
Is there a way to use the pre() operator without using a when clause or is a when clause the safest way?

A previous values exist only at event point. Basically the pre() operator request the left limit of a variable, while
the variable represents the right limit. The values are different only at event point and an event iteration is performed
until the values are equal. So this is the reason why you are only allowed you pre inside of
discrete-time expression, and not in continuous-time expression.

JoakimSandin wrote:

About the error message, is this a bug in OMEdit?

Actually, we have already a ticket related to this issue, see:
https://trac.openmodelica.org/OpenModelica/ticket/4158

so long.
Willi

Hi,

if OM needs to differentiate an equations for the index reduction purpose it is done by symbolically.
In case the specific equation contains an external function call the user may provide derivative information
via annotations. Otherwise OM has no chance and will fail, currently.

so long.
Willi

Do you have spaces in the path, where the model is saved?

Could you try to provide a more complete example, I can't reproduce it.

Hi,

which version of OpenModelica do you use?
It seems that a similar issue has been fixed last week see this Ticket.

so long.
Willi

Hey,

hm, without the model to play with, I'm not sure where to search.
So would it be possible for you to provide your model
(perhaps in private via email.)

so long.
Willi

Hey,

hm, without the model to play with, I'm not sure where to search.
So would it be possible for you to provide your model
(perhaps in private via email.)

so long.
Willi

How  about something like that:

[code]
model EX
   Real a, b;
equation
  a = if initial() then 0 else 1;
  when initial() then
   b = a;
  end when;
end EX;
[\code]
Variable b is just there to see that variable a is really in initial point in time 0.

so long.
Willi

Hello pppsco,

pppsco wrote:

I have identified the time where the first mismatch occurs.  If I run the simulation starting just before the first mismatch (with the appropriate initial conditions so it comparable), the problem doesn't occur.  See the attached plots which show the difference between the two simulations for the region of interest, with the top plot working as expected.  Notice in the bottom plot how E doesn't change.

It seems there are some events missed. Are other variable, which may influence the events also the same?

pppsco wrote:

When I turn on LOG_SOLVER for the dassl I get:

|                 | |       | | solver: DASSL
|                 | |       | | | 84457 steps taken
|                 | |       | | | 110857 calls of functionODE
|                 | |       | | | 51853 evaluations of jacobian
|                 | |       | | |  4631 error test failures
|                 | |       | | |     0 convergence test failures

Are the "error test failures" anything to be worried about?  I seem to get them in both simulations (the broken long one and the short working one).

The "error test failures" is related to the step size control algorithm and just state that the algorithm has chosen 4631 times a step size which was too large to stay with the trajectory within the given tolerances.  So that is nothing to worry about, as long as the number is not too large. If it would get too large it's just an indicator for performance issues.

Could you try to run the model with Dassl and deactivate internal root finding algorithm, then a external root finding will be used. (There is check box)

so long.
Willi

Drawing is only possible with pre-modeled components or models.
So if you want a custom model you have to model first  the
sub-componentens by your own.

Also cosider to take a look into a modelica book, e.g. http://book.xogeny.com/,
Then you will also know how the initial conditions are set in the model.

Please cosider therefore the theory of Ordinary Differential Equation.

Yes, please do it so.

Hi,

we have a model in our testsuite that demonstrates that issue:

model CheckSqrt

 Real x(start=1);

 Real y(start=1);

 Real u = 1 - time;

 parameter Real c = 1;

equation

 // this equation should cause a model error sqrt(u) and u < 0

 der(x) = if (u>0) then -c*sqrt(u) else 0;

 // this should be ok

 der(y) = if (noEvent(u>0)) then -c*sqrt(u) else 0;

end CheckSqrt;

So in general it works well.

Can you post your model or just send it to me?

so long.
Willi

mkobierski wrote:

This leads to a three-part question:
  1. Why is the conditional flattened when a default parameter is provided, as in case 1 above?
  2. Why are parameters zero-initialized (overwriting any fmiSetxxx) in 06inz.c if no default values are provided?
  3. Is the use of (fixed=false) here the right solution for the desired behaviour?

1. I guess it's connected to Ticket #3108.
2.  If we really overwrite any fmiSetXXX setting than it's a new new ticket.
3.  Actually I guess it's not, since a parameter with fixed=false and without any default value demands for an additional equation for initialization.

so long.
Willi

You can change the step dize of the rungekutta method by chnaging the numberOfIntervals.

Hello  Raph85,

which OM version do you use?

In the currect trunk it seem that the issue can occurs in some cases, because of the following bug ticket:
https://trac.openmodelica.org/OpenModelica/ticket/3062

In general this error means you have a discrete variable or relation, which changes it's value on every iteration.
For example look at the following model:

model A

  Real x(start=1);

  Integer i;

  Boolean b1,b2;

equation

  der(x) = x;

  when {x>1.5,pre(b1),pre(b2)} then

    i = pre(i) + 1;

    b2 = not pre(b2);

  end when;

  when {pre(b1),pre(b2)} then

    b1 = not pre(b1);

  end when;

end A;

There it's the case that if the first when equation is evaluated the b2 changes and that causes the evaluation of the second when equation which changes b1, what again activates the first when equation and so on.
So in general it's an modelling issue like the one above.

so long.
Willi

It's a bug see ticket #3058.

As work-a-round you can copy the function
and comment the line with

H := fill(0.0,0,0);

since that's the one that, cause the issues.

so long.
Willi

Yes, there is no debug flag any more that is called "lineraize".

It's now a config option and can be set with:
setCommandLineOptions({"+generateSymbolicLinearization"})

Or if you are using OMNotebook or OMShell you can also use
the linearize api call.
( see also https://build.openmodelica.org/Document … rize.html)

Hi,

how did you do it?
Did you used the the compiler flag: "+generateSymbolicLinearization"

so long.
Willi

FelixB wrote:

Do you have an idea what might cause this problem?
How do I get debug information when the simulation does not finish?

Too many events, stiff system, hard non-linear systems,
long initialization run, etc. there are a lot of things that might
cause performance issues.

You can run the simulation application with some debug flags:

-lv LOG_SOLVER -> [additional information about solver process]
-lv LOG_EVENTS -> [additional information during event iteration]
-lv LOG_INIT          -> [additional information during initialization]
-lv LOG_SOTI        -> [final solution of the initialization]

so long.
Willi

It's not as bad as all that.
We have just forgot to cast some assignments, but
that is done by the c compiler anyway.

so long.
Willi

Hi,

in the solver statistic the value "error test failures"
just means that in the  "DASSL" integrator an internal
error test has failed and that results in a new
calculation of the current step with a reduced internal
step size.
So if the number is quite high the solver
will be quite slow and it indicates that your problem
is quite stiff.
However, the simulation is successful as long you don't
get other messages that indicate a failing simulation.

so long.
Willi

Yes, that's correct.

Hi,

as far as I see the solution in DrModelica there is wrong, since
the variables k is discrete and next is continuous. That means
they are treated different when the algorithm is initialized
(see Modelica Specification: 11.1.2).

So these both variables should treated the same.
I suggest  to change all variables to the same variability:

class SumCalculation

  constant Real e = 0.000001;

  Real sum(start = 0);

  Real next(start = 1.0);

  Real k(start = 1);

  Real posneg(start = 1);

algorithm

  while noEvent(abs(next) >= e) loop

    sum := sum + next;   

    k := k + 1;           

    posneg := - posneg;

    next := posneg/(k*k);

end while;

end SumCalculation; 

Also the noEvent() operator should applied
to the whole relation, since abs(v) is expanded to
noEvent(if v >= 0 then v else –v).
But actually the noEvent is not needed there at all, but
that a bug(see ticket #2618)  in OpenModelica.

Actually we should detect the error for the first model while compile time(I added a ticket therefor #2620.

The following model is not valid according to the specification:

model M

  Real x

equation

  x = pre(x) +1;

end M;

x is a continuos variable, so it's not allowed to use pre of x outside when.

The model:

model M

 Integer cpt (start=0);

equation

  cpt = if time <= 10 then pre(cpt) + 1 else pre(cpt);

end M;

fails, since every time the tool execute the code pre(cpt) != cpt, so we need to perform an further event iteration.

Please, see Modelica Specification page 27 ff:
3.7.3
Event-Related Operators with Function Syntax

so long.
Willi

Hey,

how does your model looks like?
Since when it's small and already in ODE form the xml output will not change.

so long.
Willi

Hi,

I assume you have done something like that:

loadModel(Modelica);



loadString("

package p

model vdp

  Real x1,x2(start=1);

  parameter Real lambda = 1;

  Modelica.Blocks.Interfaces.RealInput u;

equation

  der(x1) = x2;

  der(x2) = lambda*(1-x1^2)*x2-x1;

end vdp;



model test

   vdp a;

   Modelica.Blocks.Sources.Sine sine1;

equation

  connect(sine1.y, a.u);

end test;



end p;

");

getErrorString();



simulate(p.test, stopTime=10);

getErrorString();

What works fine for me. Please add your code if you have still issues.

so long.
Willi

Hi,

perhaps you could start with a tutorial by Peter Fritzson:
https://www.openmodelica.org/images/doc … itzson.pdf

For visualization follow the steps in: https://build.openmodelica.org/Document … ica3D.html
If you use OMEdit, simply add ModelicaServices of version "3.2.1 modelica3d" to the list of libraries to load on startup.

so long.
Willi

Hello,

yes, please provide the model you used, we can't help
without an example that causes the issue.

so long.
Willi

It's hard to tell somthing, if the model is not available.

Actually the right postion of noEvent should help.
Also a propoer solution for such effects is to insert a hysteresis for
the switch parts.

so long.
Willi

Hello Alex,

alesiem wrote:

Therefore I would like to know the exact step the solver has decided to take after evaluating the system of equations multiple times, and force an final evaluation in this step in order to store the correct data. I also need to set a maximum time step length for the solver.

Is that possible in OpenModelica?

If your function has just the time and other _parameters_ as input your function should just called once at the output points. The output points are depending on numberOfIntervals and the start- and stop time. This implies also you can set the maximum step size with this options.

so long.
Willi

Hello Romaric,

Romaric wrote:

PROBLEM 1:

Now that I have increased the size of my model, I get an error at the step 2, with OpenModelica:

“Process crashed WARNING OpenModelica interface (150200): Instance not connected to the co-simulation bus…
WARNING OpenModelica interface (150201): Cannot initialize the control thread.”

In fact, the error appends just at the end or just after the compilation of the model. The progress bar of the simulation appears, but it crash at the beginning.
So, I don’t know if the problem came from OpenModelica or from the interface between OpenModelica and CosiMate.

Are you able to simulate your model just with OpenModelica?
If not, probably the problem came from OpenModelica.
Then you should add a bug report with your model or at least
the problematic parts.

so long.
Willi

Hey Paul,

paul wrote:

The first thing is, why are 'stop' and 'x' initialized as they are (true and 1)?

This model has no initial equations, so the initialization step basically just
execute the model equation once and the result of that is (true and 1).

paul wrote:

And then, even more intriguing, if it is so, why the 'if'-part is executed anyway (as you say)?
Given that everything is as said, and 'x' is set to 0 at the beginning of the execution of the algorithm, then still 1 should be added later on, shouldn't it?

In modelica an algorithm is basically just a function call with (lhs1,lhs2,...) := algorithm_function(nonLhs1,nonLhs2,...).
So the not the 'if'-part is execute instead the whole algorithm_function is executed and the modelica specification
say in "11.1.2 Execution of an algorithm in a model" how variables are initialized when an algorithm
is executed.

paul wrote:

Given that everything is as said, and 'x' is set to 0 at the beginning of the execution of the algorithm, then still 1 should be added later on, shouldn't it?

No, since the variable stop is true, so the true-branche of the algorithm is never executed again.
The variable stop is implicit an discrete variable, because it's boolean.

paul wrote:

One more thing: what's the difference between start- and initialize-values?

The start-value is an attribute of every variable. (e.g Real v(start=1); ).
The initialize-value is the value of a variable at the beginning of the simulation.


so long.
Willi

Hi,

it seems to be a bug, I've added an ticket for that
https://trac.openmodelica.org/OpenModelica/ticket/2282

The numberOfIntervals parameter determines the number of steps
that are emitted to the result file. Also the dynamic state selection,
which seems to fail here, is deciding at that level which states we
should use.

so long.
Willi

Hi,

the issue here is the algorithm specification, which says that every continues variable on the left side, needs to intialized with it' s start value( in this case =0).
So after the intialization the stop variable is true, but the algorithm is executed anyway and while this exection x is set to it's start value ( = 0).
That's also the point were the spec is unclear, maybe we need to overwrite the startvalues with the initialize values.

For that specific model it world help to declare x as an discrete variable.

model Why

  discrete Real x;

  Boolean stop;

algorithm

  if not stop then

    x:=x + 1;

    stop:=true;

  else



  end if;

end Why;

so long.
Willi

Hello Gilles,

actually there is no flag to get the symbolic expressions,
since we are calculation the matrixes with an generic
directional derivative. Even more we don't differentiate
with respect to parameters.
But you can have a look at that directional derivative
with the debug flag: +d=dumpindxdae
Then you get for example for the VanDerPol model followinig
output:

Variables (2)

========================================

1:  $DER$Py$pDERA$PdummyVarA:STATE_DER()  type: Real 

2:  $DER$Px$pDERA$PdummyVarA:STATE_DER()  type: Real 





Equations (2, 2)

========================================

1/1 (1): $DER$Py$pDERA$PdummyVarA = lambda * (-2.0 * x$pDERA$Px * x * y + (1.0 - x ^ 2.0) * y$pDERA$Py) - x$pDERA$Px

2/2 (1): $DER$Px$pDERA$PdummyVarA = y$pDERA$Py

Where the equation represent directional derivative you can obtain
the columns of the Matrix A, by replacing the vector:
{ y$pDERA$Py, x$pDERA$Px}
by {1,0} and {0,1}.

I hope that helps a bit.
so long.
Willi

Blister wrote:

i think SimForge don't recognize package.mo from Modelica 3.2.1

What can i do?

You can use OMEdit.

It's just dassl.
The solver method "dassl2" was just a develompent version of the currect "dassl" solver method.

so long.
Willi

Hi,

could you provide an example model therefore?

so long.
Willi

Hi,

Yes, you are right! It's not need to reduce a system with a differential index 1.
The ODE system of an index 1 DAEs are just the equations, which are needed
to determine the differetiated states.

The error above just says that a part of the whole system can't be solve onsistent
and this system has internally the index 22, as Jens pointed out already.
This part is a mixed equation system of Boolean and Real varibales which are
needs to be solved at once. Do you have still issue with that could you provied
your model?

so long.
Willi

is fixed in r13555

This issue is related to the intervals, where the solver checks for events.
The solver checks for events only at output points, so if you increase the
numberOfIntervals the model will work proper.

What really happens there, is that in the step where the Ball falls through
the ground the  solver misses that the speed was while the last step less
than 0.05, but at  the next output point the speed is again bigger then 0.05
and then the event don't occurs again and the Ball falls further.

But with the current trunk version your example work proper, since we now check in
every step of dassl for events. That means for the solver dassl the event that are found
depends on the step sizes done by dassl and not any more on the numberOfIntervals.

Of course, for the other solvers it depends still on the output intervals(numberOfIntervals).

so long.
Willi

As far as I can tell you can't use them from OMEdit, or even not in OMShell.
Use the omc in a terminal:

omc +help

omc +help=debug

omc  +s <filename.mo> +d=dumpindxdae,backenddaeinfo

omc  +s <filename.mo> +d=tearing

so long.
Willi

Hi,

some notes to the second question.

The import function shoupd be used as following:

importFMU("DAEexample.fmu");

Now a Modelica model ist created that is called:
DAEexampleFMUImport.mo


So if you want to simulate it you need to load that file.

loadFile("DAEexampleFMUImport.mo");

That file contain a package that is called "FMUImport_DAEexample"
and this package contain a FMUBlock that can be simulated.

simulate(FMUImport_DAEexample.FMUBlock);

I hope that help a bit.

so long.
Willi

Hello patrik,


Yes, the omc is applying the BLT by default.

A version of tearing is implemented, but not activated by default, because it hasn't currently the robustness and high performance to activated it by default.
As far as I know there is somebody who has currently started to work on that algorithms. You can tested it with the debug flag "+d=tearing".

For further information about the transformation process you can also activate the following debug flags:
dumpdaelow -   Dumps the equation system before the transformation.
dumpindxdae - Dumps the equation system after index reduction and optimisation.
backenddaeinfo - Dumps more summerized information about the model.

with omc +help=debug you can see all available debug flags.

so long.
Willi

is fixed in r10543.

so long.
Willi

Hello dcasner,

which version of OpenModelica do you use?
If I linearize your model with the current trunk, I get following linear model:

model linear_Systeme_MRA3

  parameter Integer n = 4; // states 

  parameter Integer k = 2; // top-level inputs 

  parameter Integer l = 2; // top-level outputs 

  parameter Real x0[4] = {0,0,0,0};

  parameter Real u0[2] = {0,0};

  parameter Real A[4,4] = [0,0,1,0;

0,0,0,1;

-0.06666666666666667,0.025,-19.16666666666667,8.333333333333334;

0.04285714285714286,-0.04285714285714286,14.28571428571429,-14.28571428571429];

  parameter Real B[4,2] = [0,0;0,0;

-0.008333333333333333,0.008333333333333333;

0.01428571428571429,0];

  parameter Real C[2,4] = [1,0,0,0;0,1,0,0];

  parameter Real D[2,2] = [0,0;0,0];

  Real x[4](start=x0);

  input Real u[2](start= u0);

  output Real y[2];



  Real x_Px1 = x[1];

  Real x_Px2 = x[2];

  Real x_Px3 = x[3];

  Real x_Px4 = x[4];

  Real u_Pu1 = u[1];

  Real u_Pu2 = u[2];

  Real y_Py1 = y[1];

  Real y_Py2 = y[2];

  

equation

  der(x) = A * x + B * u;

  y = C * x + D * u;

end linear_Systeme_MRA3;

so long.
Willi

Hi,

yes, you need set input and output variables for the top-level variables.
actually, parameter couldn't be input or output. you need to select some variable.
Maybe you need also to add additional variables for that.

so long.
Willi

Hi,

Actually, you can just generate a linearize model of your OpenModelica model on every point in time you want.
The only thing is that it isn't activated by default, so you need to activate a flag.
You can do it like that:

setCommandLineOptions("+d=linearization");

loadFile("VanDerPol.mo");

buildModel(VanDerPol);

system("./VanDerPol -l 0");

With that code you will get a linearized model to point in time "0" in your directory.
The model will called "linear_VanDerPol.mo".
This model could be loaded to OpenModelica and used for your controller.

Regarding your Scilab issues I have no idea.


so long.
Willi

Currently OMOptim does not work on Ubuntu 11.04 neither 10.10 at least for me. I've created a bug report for that issue: http://openmodelica.ida.liu.se:8080/cb/issue/1565

On Windows it does work well. To get familiar with OMOptim try to optimize a really small model with only few variables and parameters. 

so long.
Willi

First you need to transform this equation in differential equation by differentiate it with respect to k and tau. They you get a partial differential equation that you can discretise appropriately to get an ODE System.
Maybe just one way to solve that.

so long.
Willi

ah, sorry I have set the peak parameter of the bearingfriction not on the same values as you, so I get other results.
But the Modelica model for the bearingfriction say that the minimum value for the peak is = 1, so you maybe break the model if you set if to =0.5.
Actually the compiler or at least the simulation has to come up with an assertion. That's a bug in openmodelica.

so long.
Willi

Which version of the omc do you use?
Since for me neither the position of the inertia nor the speed of the inertia negative at the beginning of the movement.
Please consider me results.

Please note that I have changed some of the parameters to have one scaling for the results.

Sorry but your result images are so small to recognise something.

Hi,

as far as I can see is the model not consist. The token is jumping at time 0 from place1 to place2 and visa vice.
I think you need something like an delay when your transitions are ready to fire.

so long.
Willi

Hi,

no your are not missing something. It seems to be a bug in OMEdit, so that OMEdit doesn't allow to change parameters of the models add by extends and redeclare components. Please add a bug report.
Anyway you can add your own modification in the textual view like that:

  Modelica.Electrical.Analog.Sources.StepVoltage stepvoltage1( V=1, offset=1, startTime=1)

so long.
Willi

I am not sure, but I believe that the visualization is disabled, since version 1.5.0..

so long.
Willi

Hello Thomas,

I can't say much to the physics of the model, but as far as I can see our results are ok, at least they are the same as the results of  Dymola.
Maybe the models between sim20 and Modelica differ a bit.

so long.
Willi

Hi,

the problem in your model are not PI controllers, but rather the modifier for the positionSensors. The initialisation problem is overdetermined if you set a  "fixed" start value for the positionSensors and for the SpringDamper. Just change the properties of the positionSensor.
Form

Code:

Modelica.Mechanics.Translational.Sensors.PositionSensor positionSensor(s(start = 0, fixed = true))

Modelica.Mechanics.Translational.Sensors.PositionSensor positionSensor1(s(start = 0, fixed = true))

to

Modelica.Mechanics.Translational.Sensors.PositionSensor positionSensor 

Modelica.Mechanics.Translational.Sensors.PositionSensor positionSensor1 

then the model works fine.

so long.
Willi

Hello Lisa,

this is now fixed in rev9119.

so long.
Willi

Hello rajivsingh,

at first this branch isn't really up to date.
We are currently working to add these things to the trunk and this should happen in the next days.
But I have just checked this branch and this error didn't appear for me.
I think the only way  to cause this error message is that you don't use the omc generated from this branch. Maybe you used the release version of the omc instead.
Please check which omc is used to generate your code. Maybe you have to change the environment variable OPENMODELICAHOME to use the omc from this branch.

so long.
Willi