Has anyone used UTP inside Modelica:DeviceDrivers to exchange data between two PCs?

What I could do successfully:
- run the UDP exampes included in thModelica_DeviceDriivers.
- use two instances of OpenModelica, one that sends UDP data the other that receives it, both on the same PC.

What I could not do:
When I connect two PCS through an ethernet switch and try to send from an OM instance on the first PC to an OM instance in the second one (both through the same unique port) the receiving PC does not receive anything.

If anyone succeeded in transferring data across PCs using UDP his help (and a working example) is very much welcome,

Thank you in advance.

This won't do the job, since it hides extrapolation from the final user.
I want the final user to be able to choose which extrapolation to apply.

Excellent!
I did as you recommended and solved my issue.

But your solution requires the definition of a new variable. Smart tools can drop it from the equations considering that its defining equation is trivial.
But probably better is defining isOne as a parameter (here I use the name dummy):

  parameter Modelica.Blocks.Types.Extrapolation myExtrapolation = Modelica.Blocks.Types.Extrapolation.LastTwoPoints "Extrapolation of data outside the definition range";
protected
  parameter Boolean dummy( fixed=false);
public
[...]
initial equation
  if myExtrapolation == Modelica.Blocks.Types.Extrapolation.HoldLastPoint then
    dummy = true;
  end if;

I have a model "Driver" which uses a CombiTable "table".

In Driver I defined
parameter Modelica.Blocks.Types.Extrapolation myExtrapolation

that I pass to table.

For OpenModelica extrapolation in CombiTables is structural, and therefore cannot be changed for re-runs.

However, when run Driver, from OMEdit myExtrapolation appears to be modifiable. If I modify it, however, the simulation does not change because the table does not accept changes in its extrapolation when re-simulating.

Is there a way allowing to avoid myExtrapolation to appear modifiable from OMEdit plotting perspective?

Thanks

OM in Mac Systems 1.13.6 seems to be non-working (see ticket #5607, comment 16).
Therefore, I tried to use Oracle's Virtual Box and the OM pre-built VM.
I did as follows:
- downloaded and installed VirtualBox 6.1.10 for Mac
- downloaded https://build.openmodelica.org/omc/buil … dev.02.vdi and put it into my desktop
- from within VirtualBox I tried do "Add" that VM, but the file appears greyed and therefore cannot be added as a VM.

What's my mistake? What should I do?
Thanks.

OM has improved a lot since when I posted this message, so I'm surprised that similar issues are sill there.
I suggest:
1) try installing the most recent nightly build if you have an old version
2) if the problem persists post a detailed bug report on

https://trac.openmodelica.org/OpenModelica/timeline


OM developers read carefully  tickets posted there and frequently solve them within days.

Ah, thank you.
This is rather limiting for teaching.

For teaching we change models continuously, and therefore savings in time during compilation make classrooms much better.
According to a few simple tests,  with O0 I have 20% time savings as an average, which is very significant in a classroom of students.
It seems that today to have O0 you must:
- set the C/C++ compiler flag for a model and, simultaneously simulate (if you set it for a given model thinking to simulate later you lose it)
- for any new model you must add that flag manually
- this flag is not saved into models, so are not retained between sessions.
It is too complicated to be used with students.

Do you think there is a simple way to add somewhere the possibility to set optimisation level for all models, all simulations?
Maybe I'm not the only one having this need, and therefore I plan to set a ticket on this. Beforehand, I will make some other speed tests.

it worked, thank you.
I've seen that for me it is best to use nearly always -O0. Is there a way to make this the default choice?
Thanks again.

I would like to compare compiling and execution speeds of some of my models using the O0, O1, O2, O3 flags.
How can I select these flags from OMEdit?
I looked at the documentation but could not find the answer.
Thanks

Starting from a few months ago, OMEdit's variable browser has started to carry very large buttons: rewind, play, pause, as well as Time and Speed edits.
I understand that they are needed only when array of values are computed over time and, probably, when 3d visualisation of multibody models are required.

This meas that in a huge category of models, those without multibody and without arrays these buttons, which occupy a large amount of precious Variable Browser space, are unneeded.
However it seems to me that they cannot be hidden. Am I wright or do I miss something?
Thanks

mat files created by OpenModelica and Dymola have the same structure. They are matlab files, but require some processing to distinguish variables.

I did this in my  own plotting and post-processing program, which is Modelica-aware. In case of interest you can find it here:

https://drive.google.com/open?id=0B7FNP … WtBLVlwMEk

Maybe you are just satisfied from what this program does.
Otherwise, if you really need Matlab, I can share the my cpp routine which reads the mat file. However, you need to do some simple reverse-engineering to understand its details and replicate them in Matlab.

Now I can read the package and ask optimisation using qualified paths.
Basically there was a mistake in the code: inside the model BangBang I used for failing tests I had inadvertently deleted the row

  parameter Real m = 1;

Since I also did not use
getErrorString() I did not realise this.

Thank you both.

Consider this:

package BangBangPkg

model BangBang "Model to verify that optimization gives bang-bang optimal control"

  Real a;

  Real v(start = 0, fixed=true);

  Real pos(start = 0, fixed=true);

  Real pow(min = -30, max = 30) = f * v ;

  input Real f(min = -10, max = 10);

equation

  der(pos) = v;

  der(v) = a;

  f = m * a;

end BangBang;

optimization optBangBang(objective=-pos)

  extends BangBang;

end optBangBang;

end BangBangPkg;

I have this in code in file BangBangPkg.mo, and the two models separately in BangBang.mo and optBangBang.mo.

If, in OMShell, I do

loadFile("BangBang.mo")

loadFile("optBangBang.mo")

optimize(optBangBang, numberOfIntervals=16, stopTime=1, tolerance=1e-8)

everything works well (and  list(BangBang) prints the rightcode).
If, on the contrary I issue

loadFile("BangBangPkg.mo")

I get false and list(BangBangPkg) prints nothing.

I want to make some optimisations according to the example 8.3 of the OpenModelicaUsersGuide-latest.pdf.
The provided BatchReactor example makes usage of two different files BathReactor.mo and nmpcBatchReactor.mo.
Since I want to investigate several cases, instead to have many files I would like to put all models into a package, load it, and make optimisations by using models from that package.
Unfortunately I couldn’t do this: loadFile() command does not load a package. There exist the loadModel() command, but I could not understand how to use it to load a package.
Finally, I wonder whether the OMC command optimize will accept as a first parameter a name that contains dots, e.g. “myPackage.MyOptModel”.

Thanks.

So easy! thanks.

OM is distributed with many libraries. Only some of them are accessible directly from the file menu of OMEdit system libraries. For the loaded Buildings library version is  3.0.0, while other versions of buildings are available. In particular in'm interested in loading Buildings latest.

I tried using file|Load Library and keying cmd-shift-.dot to see /opt folder.

This way I'm able to see Buildings latest folder, but I cannot load it because package.mo is greyed.
How can I load that library?

Maybe you can find it useful to start from a working example:


acFiltQS.mo

a possibility is to create a circuit using quasi-stationary components.
You can use a source (e.g. variableVoltageSource) in which you set as amplitude a const=1 and as frequency the output of a Block.Sources.Clock.
Then you look at voltages and currents over time and the interpretation is time=frequency.

In a simulation I get the following message:

stdout | warning | <p>Error in initialization. Storing results and exiting.<br>
Use -lv=LOG_INIT -w for more information.</p>

I want indeed have more information about the error.
I tried to add "-lv=LOG_INIT" in OMedit in the field Tools|Option!Simulation|OMC Flags, but I got the error message:

[6] 10:15:27 Scripting Error

Unknown option -lv.

What should I do?

thanks

Hi.
If possible, I would become able to distribute (MS windows) executable files created through OM from Modelica models to other people, so that they can execute them repeatedly, with different value of parameters.
If this is possible I could myself create a piece of software with the GUI to do this.

I have two issues:
1) the .exe file has dependencies. Either I should have a clear list of the files to distribute along with exe or, much better, some option to create executables with everything already linked inside, i.e. that have no dependencies.
2) I don't know there the executable reads parameters from.  I suppose there is some text file. And I suppose there is somewhere the formal description of this file so that I can write code to read and write it safely.

Is it possible? Can anyone give hints?

Thanks

The solenoid of your solenoid pump has no inductance, which is unreal. I've added an inductor L=tau*R_Resistor with tau being the time constant. I suppose a realistic tau is 1s, which means L=R_Resistor.
Moreover the output step should be changed from 10ms to 1ms.
With this addition simulation is faster and, I believe, more realistic.

I would like to plot the efficiency map of a motor having the efficiency being in a matrix as a function of two variables (e.g. torque and speed for a motor).
In matlab and scilab this is easily done using the function contour().
In Modelica I could not find anything. I can program it myself, but, since it is not a very easy task, I prefer first to see whether something is already there.
Does anyone know about Modelica code allowing to plot efficiency maps (I.e. contour maps from a matrix)?
Thank you.

you can duplicate transfer function and do the necessary modifications from it.
Basically you have to remove some "parameter" words. Naturally you've first to analyze the code to understand how it works.

The real beauty if Modelica is its acausal approach.
If you want to teach modelica, IMO you cannot give up this feature.

Yes modelica simulates as well causal control systems, algorithms, but these are additions to its very core that is acausual, equation-based simulation.
All tools accept tricks to obtain special results.
But when too many tricks are needed with a tool or language to obtain a purpose, maybe it is better to explore a different tool or language.

Modelica is equation-based, and equations must be solved simultaneously. Therefore I suppose it is impossible to make an interpreted version of it.

However I use it for teaching, and the majority of time one discusses and prepares models. Compilations are not that many, Moreover, that if you have to iteratively  find the right value of a non-structural parameter, you can re-run the simulation very fast without rebuilding the model.
So Modelica and OM are good for teaching.

IMO OM has a single issue that partly jeopardises teaching: it is slow in opening models and in moving parts of a diagram around with arrow keys.
However this issue is not so severe and, according to what I read from the programmers, it will be solved in the coming months, when release 2.0 becomes available.

If you don't mind, could you explain to me, what is the purpose of multiplying the difference between velocities and limiting it? How did you chose these two parameters (k and ymax)?
I noticed that the output of your driver submodel is in Nm so I suppose it is a couple but what does it stand for?

Driver+vehicle constitute a speed-regulated electric drive, whose closed-loop regulator is the driver. The vehicle is torque-controlled through driver's command (accelerator and brake pedals). The driver here is a simple proportional feedback controller, whose gain is "gain", and the torque it requests is limited to be a bit more realistic (maximum and minimum torque the power train is able to deliver or absorb).
This is a very preliminary model, that is just to show the first concept of vehicle simulation to my students.

And finally when simulating your whole model I noticed that the output of the combiTimeTable (here nedc) isn't complete when plotted it goes until 50 km/h as you can see

You have to simulate longer to see the rest :-)

Try with the enclosed file "SimpleEV.mo". Load and open model "EVBasic". Double-click on "Driver". There you can select a text file containing the cycle (e.g. the NEDC I supplied). For the model to run the file must be in your default dymola directory.

SimpleEV.zip

You can take it here:
https://dl.dropboxusercontent.com/u/55064681/NEDC.txt

Since cycles are just text files, you can use this example to create your own cycles.

Thank you,
I did not know of that forum. I will certainly switch to that one.

It seems to me that the Power Systems Library is very powerful, but not well documented.

I would therefore like to create documentation and documented examples of some of its models, to create a subset of it to be used for teaching.

It is just a first idea, the success of which depends on many factors.
Naturally I would gladly share the outcome with anyone interested.

To do this, however, I need to share issues with other users.

My first attempts on analysing and discussing some Spot examples were successful.
The first attempts to analyse Generic examples were not. For instance trying the very basic PowerFlow.GenericComponentsTest.ImpedanceTest, I expected that switching the system refType from Synchronous to Inertial would have changed load.terminal_p.v[1] and  load.terminal_p.v[2] from constant to varying as sine waves, but this did not occur; they remain constantly equal to 10 kV.
I tried this on 0.5 dev version of the library.
Can anyone explain why, or what changes must me made to see the expected behaviour?

A lot of PowerSystems library examples have an horizontal shape. At least nearly all spot examples.
All of them are laid in sheets having a square size: {-100,100},{-100,100}

I've switched in my own version of the  library into rectangular shapes, typically having a vertical span {-80,80} or {-60,60}.
this solution has advantages both in OM and Dymola.

1) in OM it fits much more naturally in the space available to display the model, since as default the bottom part in the modeling perspective is occupied by the Messages Browser.
2) in Dymola this is useful especially when adding the diagram in the simulation perspective. In that perspective  when models are resized, Dymola tries to let the whole sheet fit in the window; in case the sheet has blank parts, its the useful part (i.e. the one containing graphical elements) are shrunk.

So having chosen specific sizes for the examples' sheets results in better usage of the Library.

I propose to do the same in the standard version of the library, i.e. the one that is distributed to users (and enclosed in OM) , so that every user would have this advantage. It's is a simple task, that pays off.

That's wonderful, Francesco.
Sometimes I forget that I'm playing with a very powerful programming language!
This helps a lot solving my problem.

In my original idea I had to invert a matrix inside a function, so inside an algorithm section; this in principle forbids the use of equations, and the technique you proposed.

But my function has to be called only at the beginning of the simulation, so I will try to mix the equation required for the inversion technique you suggested with equations using function calls, in an "when initial()" section.

I have a problem that requires inversion of complex matrix: it is needed for the computation of complex impedances of a bundle of electric lines.
I see that MSL only supplies real matrix inversion "inv.mo" via lapack routines dgetrf() and dgetri().
I know that usage of inv() is discouraged, but in my problem is ok, since inversion is required only at system initialization.

I also know that lapack has twin functions cgetrf() and cgetri() for complex numbers, but I'n not sure whether that complex functions are included in the MSL's lapack dll (I suspect they are not).

Can anyone help me increating a "cinv.mo" function that does the same "inv.mo" does, but is for complex numbers?
Maibe this is not a trivial task since the MSL External Function Interface does not consider complex numbers.

Thanks.

Maybe you mean Simulink.
Simulink is deigned for control (cyber) systems, even though often used for  physical systems as well, but this usage is tricky.

Physical systems are governed by physical equations, not laplace transforms. That's why in the physical part of Modelica models time-based differential equations are used (not Laplaces')
Modelica is for Cyber-physical systems. In Modelica you can manage simulink-like cyber systems. Consider for instance Modelica.Blocks.Continuous.TransferFunction.

Try using "elseif" instead of "else if".
And upgrade to a more recent OM (e.g. OM 1.9.6)

When running a model I get the following error message:

stdout | warning | <p>Solving linear system 233 fails at time 8.66021e-010. For more information use -lv LOG_LS.</p>
LOG_LS | warning | <p>Failed to solve linear system of equations (no. 233) at time 0.000000, system is singular for U[2, 2].</p>
LOG_LS | warning | <p>The default linear solver fails, the fallback solver with total pivoting is started at time 0.000000. That might raise performance issues, for more information use -lv LOG_LS.</p>
LOG_LS | warning | <p>Matrix singular!</p>
LOG_LS | warning | <p>under-determined linear system not solvable!</p>
stdout | warning | <p>Error solving linear system of equations (no. 233) at time 0.000000.</p>
stdout | warning | <p>Solving linear system 233 fails at time 8.66021e-010. For more information use -lv LOG_LS.</p>


When debugging I see that equation # 233 is the following one:

Index     Type       Equation
233      regular     linear, size=46

The other equations are model equations, that can be understood, but this one, I suppose, has a special meaning that I don't know.

Any suggestions?

If you want a  three-phase inverter Modelica model working with OM, plus many other power electronics models you can download
      MSL 3.2.2.dev
from the Modelica Association site.
I did this last summer but I don't remember how to do. So you must find the way yourself.

Moreover, I don't know if I'm allowed to redistribute that code, and therefore I do not attach it here.

I can say that the model
       Modelica.Electrical.PowerConverters.Examples.DCAC.MultiPhaseTewoLevel_R
runs smoothly with today's OM nightly build (Windows)

However today's OMEdit has some issues and crashes frequently. Fixing this is well under way.
.

You are right, some of the three-phase models do not work with OM (yet).

After the renaming issue that you solved, they are ok with Dymola.

I did not check those models with OM for months. I tried yesterday, but a totally different issue was evidenced that caused OMEdit to crash with a model similar to IdPwmTrif2. (ticket #3580).
When this ticket is solved I will see whether also the issue with IdPwmTrif2 you mentioned is gone.

I have created many Modelica models, but only roughly 80% are correctly flattened and simulated by OM.

Yeah.
Before sending you the package, I just changed a few names and did not save the changes correctly.
Top became up, and Bot became down.

I'm glad you are using my models.

IdPwmTrif is a three phase pwm inverter.

It transfers power from a DC source (V1) to an AC load (Rd1, Rd2, Rd3).
Contains a filter (Rf1, Lf1, Cf1 for phase 1) that makes the load voltage much better than that produced by the legs.

It is self explanatory, but is intended for people that know how pwm inverters work.
Any book regarding power electronics is a good guide to my models.

maybe this package helps:
https://dl.dropboxusercontent.com/u/550 … Pkg2015.mo

Is there a way to have plots with multiple axes (like Volts left, current right)?

Not inside OMEdit. You can save output as CSV and do post-pocessing using other SW.
But I strongly recommend you to get accustomed to OMEdit. Maybe it has not all the features you currently use, but it has a lot of wondeful characteristics.

Even if I don't recommend it at this stage, I can mention that a program of mine reads smootly OM's CSVs, and allows several things OMEdit does not allow, e.g.:
- twin vertical axis
- Fourier analysis on plots
- seeing the numerical values (OMEdit just does a dull pixel mapping)
- combining plots with algebraic operators (sums, multiplication, subtraction, division)
- integrating.

It is called PlotXY, there is a 2015 version, and you gan get it from the following URL:
http://www.dsea.unipi.it/Members/ceraol … re/plotxy/

Your model was a bit tangled.
I untangled it and got reasonable result.
Try this:

model parLCmod

  Modelica.Electrical.Analog.Basic.Inductor inductor2(L = 500e-6, i(start = 1.4e-3, fixed = true)) annotation(Placement(visible = true, transformation(origin = {42, 52}, extent = {{-10, -10}, {10, 10}}, rotation = -90)));

  Modelica.Electrical.Analog.Basic.Resistor resistor1(R = 150) annotation(Placement(visible = true, transformation(origin = {20, 18}, extent = {{10, -10}, {-10, 10}}, rotation = 0)));

  Modelica.Electrical.Analog.Basic.Capacitor capacitor1(C = 10e-6, v(start = 11.8255, fixed = true)) annotation(Placement(visible = true, transformation(origin = {-4, -10}, extent = {{-10, -10}, {10, 10}}, rotation = -90)));

  Modelica.Electrical.Analog.Basic.Capacitor capacitor2(C = 10e-6, v(start = 10.0002, fixed = true)) annotation(Placement(visible = true, transformation(origin = {42, -10}, extent = {{-10, -10}, {10, 10}}, rotation = -90)));

  Modelica.Electrical.Analog.Basic.Ground ground1 annotation(Placement(visible = true, transformation(origin = {-4, -48}, extent = {{-10, -10}, {10, 10}}, rotation = 0)));

  Modelica.Electrical.Analog.Sources.TrapezoidVoltage trapezoidVoltage1(V = 10, rising = 1e-6, width = 1, falling = 1e-6, period = 2, nperiod = -1) annotation(Placement(visible = true, transformation(origin = {-52, 20}, extent = {{-10, -10}, {10, 10}}, rotation = -90)));

  Modelica.Electrical.Analog.Basic.Inductor inductor1(L = 50e-6, i(start = 6.1e-3, fixed = true)) annotation(Placement(visible = true, transformation(origin = {-4, 40}, extent = {{-10, -10}, {10, 10}}, rotation = -90)));

equation

  connect(inductor1.n, capacitor1.p) annotation(Line(points = {{-4, 30}, {-3, 30}, {-3, 0}, {-4, 0}}, color = {0, 0, 255}));

  connect(trapezoidVoltage1.n, capacitor1.n) annotation(Line(points = {{-52, 10}, {-52, 10}, {-52, -20}, {-4, -20}}, color = {0, 0, 255}));

  connect(trapezoidVoltage1.p, inductor2.p) annotation(Line(points = {{-52, 30}, {-52, 62}, {42, 62}}, color = {0, 0, 255}));

  connect(ground1.p, capacitor1.n) annotation(Line(points = {{-4, -38}, {-4, -20}}, color = {0, 0, 255}));

  connect(capacitor2.p, inductor2.n) annotation(Line(points = {{42, 0}, {42, 42}}, color = {0, 0, 255}));

  connect(capacitor1.n, capacitor2.n) annotation(Line(points = {{-4, -20}, {-4, -20}, {42, -20}}, color = {0, 0, 255}));

  connect(resistor1.p, inductor2.n) annotation(Line(points = {{30, 18}, {42, 18}, {42, 42}}, color = {0, 0, 255}));

  connect(inductor1.p, inductor2.p) annotation(Line(points = {{-4, 50}, {-4, 62}, {42, 62}}, color = {0, 0, 255}));

  connect(resistor1.n, capacitor1.p) annotation(Line(points = {{10, 18}, {-4, 18}, {-4, 0}}, color = {0, 0, 255}));

  annotation(Icon(coordinateSystem(extent = {{-100, -100}, {100, 100}}, preserveAspectRatio = true, initialScale = 0.1, grid = {2, 2})), Diagram(coordinateSystem(extent = {{-100, -100}, {100, 100}}, preserveAspectRatio = false, initialScale = 0.1, grid = {2, 2})), uses(Modelica(version = "3.2.1")), experiment(StopTime = 0.0009));

end parLCmod;

These circuits normally work wonderfully in OM.
From your message it is not clear which initial conditions you want to impose.
You added spice plots, I suppose. What initial conditions did you set in Spice?

I recommend to continue to play with OM, if you simulate circuits. You will get a lot of satisfaction!

I came across into a model that, when simplified, becomes the one reported below.
I really don't know where the keyword "protected" that is in that model came from.
However this gives rise to unpredictablke results.
In fact, if we run from OMEdit the model "testFactor", we see that uGen.Wel correctly saturates to 140.
If we change factor to 1.0  and rebuild and rerun the model, uGen.Wel correctly saturates to 100.

But let us now do this:
1) put factor= 1.4,
2) build and run the model testFactor  => uGen.Wel correctly saturates to 140
3) in the variables browser of OMedit change factor from 1.4 to 1.0
4) re-run the model using the Re-simulate button
5) => uGen.Wel saturates to 140 (in dymola it saturates to 100, instead).

Now the questions are:
1) are these models correct or they should give rise to a warning or an error?
2) what is the correct behaviour? OM's or Dymola's or some other?

MC

package testText 

  block AsmaUgen 

    parameter Modelica.SIunits.AngularVelocity WeMax(start=314.15);

    Modelica.Blocks.Interfaces.RealOutput Wel;

    Modelica.Blocks.Interfaces.RealInput Wm;

  protected 

    Modelica.Blocks.Nonlinear.Limiter limiter(uMin=0, uMax=WeMax);

  equation 

    connect(limiter.u, Wm);

    connect(Wel, limiter.y);

  end AsmaUgen;

  

  model testFactor 

    parameter Real factor=1.4;

    AsmaUgen uGen(WeMax=factor*100);

    Modelica.Blocks.Sources.Ramp ramp1(height=200, duration=1);

  equation 

    connect(ramp1.y, uGen.Wm);

  end testFactor;

end testText;

the command readSimulationResult is VERY useful.
The example from adrpo shows how to use it effectively.
The explanation in: https://build.openmodelica.org/Document … pting.html
is instead cryptic. Maybe a description of the parameters to be passed and an example can be added?
I mean, something like the explanation given in plotParametric().

Where can I find info about how to use this?

I mean, how to create the file from a previous run?
How the values from the initialisation file mix with the model's variables start  values?
Is there an example somewhere?

Thanks

I would like to start the simulation of a model from a point reached at the end of another simulation.
To do so I should be able to save the simulation state (i.e. all the values of the state variables) at the end of the first simulation, and recall it at the beginning of the second simulation.

Obviously I can do this manually for very simple models having a few states.
I wonder whether there is some way to do this in an automated way, i.e. without having to manually copy all the state variables and setting them again for the second simulation.

Thanks.

Just in case you like, you can also use a program of mine that should be able to read your large CSV file.

It allows more than OMEdit allows for visualization, and allows also to perform some post processing (summing or subtracting variables, integrating variables, finding Fourier polynomial coefficients, etc.) Included there is a pdf that explains everything you can do and how.

Loading large CSV files is slow (377MB file created by OM I measured 50 s). Once the file is loaded, plotting is nearly instantaneous.

This program is named PlotXY and you can get it from the following URL.

http://www.dsea.unipi.it/Members/ceraol … re/plotxy/

If you use omedit, you will find the csv file in the working directory.The working directory is indicated in Options|General|Working directory

You are right.
This answers my question. Thank you.

Is it possible to compare output from different runs of the same model in OMEdit?
Or it is mandatory to create and run different models (i.e. models with different names) so that the output file names are different from each other?

Yeah, I've never used personally garbage collecting and misunderstood its usage.
Sorry for that.

Today, maybe (see ticket 3318) OM's GC creates more problems than it solves.
As a temporary workaround, is it possible to disable somehow (e.g. with a flag) the garbage collector?

Thank you

ok thank you.
It was just a strange thing I wanted to do.
Two windows are ok.

adeas wrote:

Ofcourse you can. Switch to Plotting Perspective and in the toolbar click on "New Parametric Plot Window". See also section 2.6.1.2 of users guide.

It is what I did.
But I wanted two curves.
If for instance a simulation has three variables x, y1, y2, I would like to make two plots (x, y1) and (x, y2) in the same window.
The problem is that once I've made (x,y1) plot, I don't know ho so select again x for the second plot.

In OMedit it is possible to draw a parametric plot in which two different y-variables are plotted against the same x-variable?
I could not find a way to do so.

Thanks

Replying to adrpo.

1. OpenModelica should support DFT via an API so you can plot these kind of things as many people are asking for it.

Good knowing this!

2. OMEdit should support some sort of scripting for ploting so you can plot using OMC API.

You mean that adeas' suggestion is imperfect because allows plotting only outside OMEdit?
Yes, plotting in a OMEdit window from script commands would be nice for all kinds of post-processing. One example is DFT; but also in case DFT is implemented via API, other useful postprocessing stuff could be usefully done.

I think we should open 2 Trac tickets about this. ceraolo, can you do that?

Yes I can do, and I will probably today in the evening.

I intend the second one as something that asks for a way to make, using CLI commands or scripts,  plots to be shown in the Plotting perspective of OMEdit.
In fact adeas has shown a way to see plots, but in a separate window.
Am I correctly interpreting the meaning of your 2nd suggestion?

Thank you,
this suggestion makes me a big step forward.
Even though, as adrpo mentions it would be even better to have the opportunity to make plots displayed directly within OMEdit.

I would like to create a way to make the Discrete Fourier Transform (DFT) of selected simulated signals, and then plot them to see the harmonic spectrum.
This is would be very useful in electric circuits and system analysis, but useful also for vibration analysis in mechanical systems.

This DFT is immediately available in Dymola, and called FFT (as common although partially wrong).
In OMEdit I thought to deal with the issue creating a script.

I have several hurdles to overcome.
One is to plot an array against another instead of time. This can be solved, I think, using the code suggested in permalink #2475 from this forum.

Another issue is to find a way to create a new plot in OMEdit from CLI.
Obviously I launch OMEdit with the command line option  "--OMCLogger=true", so I'm able to read a mat file, and read names and values of stored variables.

But it seems that I cannot use plot() and plotParametric() command from there. Is it true?

if I could execute a plotParametric() in OMEdit from CLI, and I overcome some additional hurdles, I could create a mos script to perform DFT that I could share with anyone interested.

Thanks

oh, yes!
I did not notice this nice copy feature.
I agree that copy as almost the same as Save As. If it works well it can make my original post obsolete.

I tried copying a single model within a package and the feature worked as expected.

I tried to copy a whole package, leaving blank the path field, and a copy of the original package appeared in the libraries browser root. Strangely, however, it did not carry the "+" sign that allows to navigate through submodels. This even though looking at the code everything seemed to be there and in the right place.

I decided that maybe saving-unloading-reloading the newly created package (using copy and empty path) can solve this issue.
I did this, but the reloaded package was empty!
Can you have a look? I can supply a test example if you need.


But i dont'see

regards
MC

OMedit has had since a long time ago in its file menu a "save as" feature. But it is greyed.
I understand that it is greyed because this feature is under development.
I understand that this development is complex because management of multi-file packages requires management of several files and folders in a complex way.

But in many cases people work on single-file packages.
Am I right that it should be possible to add it, in case of single file packages, with a small programming effort?
I mean, both saving a model with a different name or in a different position of one open single-file package, or saving a whole package in a different file under a different package name.
It would significantly enhance the OMEdit usability for those that are using single-file packages.

Thanks

The output of the ramp is the frequency of the signal. Choose the right output depending on the frequency range you want to explore.
The variable source is a component of which you change from the outside frequency and amplitude, in real and imaginary parts (the two components of k constant)

I think that to make interesting bode diagrams we can do as in my example: keep amplitude constant with zero phase (only real component) and vary the frequency.
Maybe you can envisage also other usages of the variable source component.

The basic idea is that quasi stationary models use complex numbers to describe the network. therefore, for me, they are not that important for time domain analysis, but can be very useful for frequency domain evaluations.

Basically Modelica is devoted to time-domain analysis.
However, if you use circuits built with Quasi-Stationary components, it is easy to create Bode diagrams.

You can have a look at the following model.
It works nicely in Dymola but unfortunately it does not work in OpenModelica.
For instance you can verify that there is a resonance peak at 1600 Hz looking at the Rload voltage (Rload.v.re, Rload.v.im, Urms)

model bode
  parameter Real omega=100*Modelica.Constants.pi;
  Real Urms=(Rload.v.re^2+Rload.v.im^2)^2;
  Modelica.Electrical.QuasiStationary.SinglePhase.Basic.Resistor R(R_ref=1)
    annotation (Placement(transformation(extent={{-12,34},{8,54}})));
  Modelica.Electrical.QuasiStationary.SinglePhase.Basic.Inductor L(L=1e-3)
    annotation (Placement(transformation(extent={{16,34},{36,54}})));
  Modelica.Electrical.QuasiStationary.SinglePhase.Basic.Ground ground
    annotation (Placement(transformation(extent={{-36,-64},{-16,-44}})));

  Modelica.Electrical.QuasiStationary.SinglePhase.Basic.Resistor Rload(R_ref=100)
    annotation (Placement(transformation(
        extent={{-10,-10},{10,10}},
        rotation=-90,
        origin={90,12})));
  Modelica.Electrical.QuasiStationary.SinglePhase.Basic.Capacitor C(C=1e-5)
    annotation (Placement(transformation(
        extent={{-10,-10},{10,10}},
        rotation=-90,
        origin={54,12})));
  Modelica.Electrical.QuasiStationary.SinglePhase.Sources.VariableVoltageSource
    variableVoltageSource annotation (Placement(transformation(
        extent={{-10,10},{10,-10}},
        rotation=-90,
        origin={-40,4})));
  Modelica.Blocks.Sources.Ramp ramp(offset=1, height=10000)
    annotation (Placement(transformation(extent={{-90,-38},{-70,-18}})));
  Modelica.ComplexBlocks.Sources.ComplexConstant const(k=Complex(1, 0))
    annotation (Placement(transformation(extent={{-92,18},{-72,38}})));
equation
  connect(R.pin_n, L.pin_p) annotation (Line(
      points={{8,44},{16,44}},
      color={85,170,255},
      smooth=Smooth.None));
  connect(L.pin_n, Rload.pin_p) annotation (Line(
      points={{36,44},{90,44},{90,22}},
      color={85,170,255},
      smooth=Smooth.None));
  connect(C.pin_p, Rload.pin_p) annotation (Line(
      points={{54,22},{54,44},{90,44},{90,22}},
      color={85,170,255},
      smooth=Smooth.None));
  connect(variableVoltageSource.pin_p, R.pin_p) annotation (Line(
      points={{-40,14},{-40,44},{-12,44}},
      color={85,170,255},
      smooth=Smooth.None));
  connect(variableVoltageSource.pin_n, Rload.pin_n) annotation (Line(
      points={{-40,-6},{-40,-20},{90,-20},{90,2}},
      color={85,170,255},
      smooth=Smooth.None));
  connect(C.pin_n, Rload.pin_n) annotation (Line(
      points={{54,2},{54,-20},{90,-20},{90,2}},
      color={85,170,255},
      smooth=Smooth.None));
  connect(ground.pin, Rload.pin_n) annotation (Line(
      points={{-26,-44},{-26,-20},{90,-20},{90,2}},
      color={85,170,255},
      smooth=Smooth.None));
  connect(variableVoltageSource.f, ramp.y) annotation (Line(
      points={{-50,1.77636e-015},{-60,1.77636e-015},{-60,-28},{-69,-28}},
      color={0,0,127},
      smooth=Smooth.None));
  connect(const.y, variableVoltageSource.V) annotation (Line(
      points={{-71,28},{-60,28},{-60,8},{-50,8}},
      color={85,170,255},
      smooth=Smooth.None));
  annotation (uses(Modelica(version="3.2.1")), Diagram(coordinateSystem(
          preserveAspectRatio=false, extent={{-100,-100},{100,100}}), graphics));
end bode;

Maybe delay() is the right function for you?

Maybe delay() is the right function for you?

Just in case anyone had read my previous message and is curious about the solution.
I found the explanation of the type "VariableNames" in section 2.3 of OpenModelicaSystem.pdf. I read as follows:

VariableName – variable name, e.g. v1, v2, vars1[2].x, etc.

I tried... it  works!

Thank you.
that usage is useful for me and straightforward.

I will use this to make a Fourier analysis of some of the output waveforms.
All I have to do is to translate into OM mos the mos I wrote some years ago for Dymola.
The language is modelica, but the functions to call are different.

My first obstacle is how to use  readSimulationResult().
I got some info about it in:
https://build.openmodelica.org/Document … esult.html

I have to pass to it as one of the inputs "variables" that is of VariableNames type.
Where can I find the description of this type? I suppose it is something like a string list, butI cannot envisage how exactly it is to be used.
Maybe there is an example of readSimulationResult() usage somewhere to look at.

MC

Is there a way to run a modelica script (mos file) from OMEdit?
I mean a script in which I use scripting functions from the following link?
https://build.openmodelica.org/Document … pting.html


Thanks.

Modelica is a simulation language and therefore is designed to solve over time.
However, maybe it is good enough to solve load flow equations in the initial equation section.

For instance the following simple two equation set finds "gammaBase" and "wElBase" that are the optimal gamma angle and the electrical base speed of a permanent-magnet synchronous electric drive, for nominal current Inom (maybe as an electric engineering student you know what I mean).
Vnom, Inom, Ld, Lq, IpmRMS are known in advance. They play the role of resistances and inductances in load flow, while gammaBase and wElBase are the unknowns (they can be for instance theta and V in a P-Q node in a load flow problem)

  

parameter Real Vnom, Ld, Psi, Lq;

parameter Real nBase(fixed=false), gammaBase(fixed=false);

initial equation 

 Unom^2 = wElBase^2*((Ld*(IpmRMS - Inom)*sin(gammaBase))^2 + (Lq*Inom*cos(

    gammaBase))^2);

  0 = (-Ld*IpmRMS*sin(gammaBase)) + (Lq - Ld)*Inom*cos(2*gammaBase);

it works!
I had tried with initial equation but did not envisage that the errors I got could be eliminated with fixed=false.
You were very fast and effective, as usual!

I have a model for which the determination of two parameters requires the solution of two non-linear equations.
I solved this problem declaring these as real variables (thus not parameters) and writing the equations that allow their determination in the equation section of my model.
This workaround works but implies that my model is called to evaluate these two equations all the time, giving always the same result. Obviously this is a bit of waste of resources.
Does someone know another way to make such "pre-processing" of parameters?

I checked today (with r24422) and saw
    Modelica.Utilities.Streams.print("message");
working as expected also in OMEdit.

Thanks again!

I could replicate the suggestion from adrpo involving OMShell, and worked as expected.

As sioelund mentions, things seem not to be as good in OMEdit.

I tried both
...
    print("message");
...
and
    Modelica.Utilities.Streams.print("message");

but I could not see "message" in the simulation output window of OMEdit.

I just want to output some text when something occurs.
I suppose it should go to the "Message Browser" in OMEdit.

I tried with the following code:

model msg

  Real x, y;

equation

  x = time;

  when time > 0.5 then

    print("message");

    y = time;

  end when;

end msg;

It should print at t=0.5, but I don't see any message (unless I watch the wrong place"!)

Thank anyone that wants to help.

Using My OM (r24023)
I've received a warning in which 5 variables are quoted.
Unfortunately the text is a lump into which I cannot distinguish these five names.  Can anyone help me to parse the five variables?

My warning is as follows:

*******
[3] 16:44:32 Translation Warning
Assuming fixed start value for the following 5 variables: myTrain.dirToDx:DISCRETE(fixed = false ) .AutoCreateOM.TracksAndTrains.OneTrainPaper, .AutoCreateOM.NewTrain$myTrain, .Modelica.Blocks.Interfaces.BooleanOutput type: Boolean myTrain.powLimiter.delay.y:VARIABLE(start = myTrain.powLimiter.delay.y_start ) "Connector of Real output signal".AutoCreateOM.TracksAndTrains.OneTrainPaper, .AutoCreateOM.NewTrain$myTrain, .AutoCreateOM.SupportModels.PowLimiter$myTrain$powLimiter, .Modelica.Blocks.Continuous.FirstOrder$myTrain$powLimiter$delay, .Modelica.Blocks.Interfaces.RealOutput$myTrain$powLimiter$delay$y type: Real myTrain.mass.v:VARIABLE(start = 0.001 unit = "m/s" ) "Absolute velocity of component".AutoCreateOM.TracksAndTrains.OneTrainPaper, .AutoCreateOM.NewTrain$myTrain, .Modelica.Mechanics.Translational.Components.Mass$myTrain$mass, .Modelica.SIunits.Velocity$myTrain$mass$v type: Real myTrain.driver_AB.Vf:DISCRETE(fixed = false ) "Campionamento della velocita' nell'istante di frenatura (m/s)".AutoCreateOM.TracksAndTrains.OneTrainPaper, .AutoCreateOM.NewTrain$myTrain, .AutoCreateOM.SupportModels.Driver_AB0$myTrain$driver_AB, .Real type: Real myTrain.driver_AB.Sf:DISCRETE(fixed = false ) "Campionamento della posizione nell'istante di frenatura".AutoCreateOM.TracksAndTrains.OneTrainPaper, .AutoCreateOM.NewTrain$myTrain, .AutoCreateOM.SupportModels.Driver_AB0$myTrain$driver_AB, .Real type: Real

there is also ticket #1636 on trac.modelica.org.
So you think that the width issue dominates over the height issue #1635 in  in trac.modelica.org?.
Let see how Modelica.org will handle these two tickets.

Consider the following sequence:
1) launch a Modelica tool and open an empty model
2) drag in a Modelica.Blocks.Interfaces.RealInput
3) drag in a Modelica.Blocks.Continuous.Integrator.
4) Do not resize anything.
The result is very different in Dymola and OpenModelica.
In OpenModelica the interface will have the same size of the integrator and text on the interface is very tiny.
Opposite to this in Dymola the interface will have a larger size than the integrator and text on the interface is roughly the same size of the integrator's.
Is there a mistake in one of the tools or there is a flaw in the MSL code of these two simple models?

It seems to me that the latter is true, since the text height on RealInput is 25 while the one on Integrator is 40.
But management of size elements in Modelica is so complex that I cannot judge well (cfr Otter's explanation on #1635 of Modelica issue tracking).

SystemDynamics|PopulationDynamics|LarchBudMoth contains:
Starvation
Defoliation
Grecr
Logarithm
LBM

Double click on LBM. You will see the full model schmatic. Then you Can  simulate.

Yes, I'm Italian, but in general don't have much free time available.

I'm answering in this forum these days just because of the holiday period.
I hope my answers regarding your issues with Energy_storages were useful.

BTW, Adeel,
did you see that I reopened ticket #2956?
maybe re-fixing it for you is a trivial activity; for me, instead, that is a blocking issue.

I thank you in advance.

Massimo

use a boolean expression instead.

I did the connection giving as index 1, and got the following code that checks well. I did this using OMEdit and OM r23777.

model a

  Modelica.Electrical.Digital.Sources.Step step1 annotation(Placement(visible = true, transformation(origin = {-74, 0}, extent = {{-10, -10}, {10, 10}}, rotation = 0)));

  Modelica.Electrical.Digital.Converters.LogicToBoolean logictoboolean1 annotation(Placement(visible = true, transformation(origin = {-32, 0}, extent = {{-10, -10}, {10, 10}}, rotation = 0)));

equation

  connect(step1.y, logictoboolean1.x[1]) annotation(Line(points = {{-64, 0}, {-38, 0}, {-38, 0}, {-38, 0}}, color = {127, 0, 127}));

  annotation(Icon(coordinateSystem(extent = {{-100, -100}, {100, 100}}, preserveAspectRatio = true, initialScale = 0.1, grid = {2, 2})), Diagram(coordinateSystem(extent = {{-100, -100}, {100, 100}}, preserveAspectRatio = true, initialScale = 0.1, grid = {2, 2})));

end a;

If you use OMEdit you have just to double-click on the LBM icon. Very easy!

I recommend usage of OMEdit to nearly all users, except the most advanced ones.
Since I use OM for teaching, I use OMEdit for my simulations. Only very rarely tried OMC.

Select "LBM" inside "LarchBudMoth" then simulate.

There were a few mistakes in your code.
I've changed it, and changed you current table.
You can change it again at you wish.
Good luck!

Here a working code:

model batt2

  Modelica_EnergyStorages.Batteries.Cells.Basic.StaticResistance statRes(SOCini
      =1, cellParameters=
        Modelica_EnergyStorages.CellRecords.StaticResistance.Test1Parameters())
    annotation (Placement(visible=true, transformation(
        origin={-60,0},
        extent={{-10,-10},{10,10}},
        rotation=0)));
  Modelica.Electrical.Analog.Basic.Ground ground1 annotation (Placement(visible
        =true, transformation(
        origin={-60,-40},
        extent={{-10,-10},{10,10}},
        rotation=0)));
  Modelica.Electrical.Analog.Sensors.CurrentSensor currentsensor1 annotation (
      Placement(visible=true, transformation(
        origin={-40,40},
        extent={{-10,-10},{10,10}},
        rotation=360)));
  Modelica.Electrical.Analog.Sources.TableCurrent tablecurrent1(startTime=100,
      table=[0, 10; 100, 10; 100.1, 20; 200, 20; 200.1, 30; 300, 30])
    annotation (Placement(visible=true, transformation(
        origin={-20,2},
        extent={{-10,-10},{10,10}},
        rotation=-90)));
equation
  connect(tablecurrent1.n, ground1.p) annotation (Line(points={{-20,-8},{-20,-30.1003},
          {-60,-30.1003},{-60,-30}}, color={0,0,255}));
  connect(statRes.pin_n, ground1.p) annotation (Line(points={{-60,-10},{-59.8662,
          -10},{-59.8662,-30},{-60,-30}}, color={0,0,255}));
  connect(statRes.pin_p, currentsensor1.p) annotation (Line(points={{-60,10},{-60.2007,
          10},{-60.2007,39.4649},{-50,39.4649},{-50,40}}, color={0,0,255}));
  connect(tablecurrent1.p, currentsensor1.n) annotation (Line(
      points={{-20,12},{-20,40},{-30,40}},
      color={0,0,255},
      smooth=Smooth.None));
  annotation (
    Diagram(coordinateSystem(
        extent={{-100,-60},{100,60}},
        preserveAspectRatio=false,
        initialScale=0.1,
        grid={2,2}), graphics),
    Icon(coordinateSystem(
        extent={{-100,-60},{100,60}},
        preserveAspectRatio=true,
        initialScale=0.1,
        grid={2,2})),
    uses(Modelica(version="3.2.1")),
    experiment(StopTime=1500, __Dymola_NumberOfIntervals=2000),
    __Dymola_experimentSetupOutput);
end batt2;

I think it is better to use MSL components outside the battery.
Try this:

model batt1

  Modelica_EnergyStorages.Batteries.Cells.Basic.StaticResistance statRes(SOCini
      =1, cellParameters=
        Modelica_EnergyStorages.CellRecords.StaticResistance.Test1Parameters())
    annotation (Placement(visible=true, transformation(
        origin={-60,0},
        extent={{-10,-10},{10,10}},
        rotation=0)));
  Modelica.Electrical.Analog.Basic.Ground ground1 annotation (Placement(visible
        =true, transformation(
        origin={-60,-40},
        extent={{-10,-10},{10,10}},
        rotation=0)));
  Modelica.Electrical.Analog.Sensors.CurrentSensor currentsensor1 annotation (
      Placement(visible=true, transformation(
        origin={-40,40},
        extent={{-10,-10},{10,10}},
        rotation=360)));
  Modelica.Electrical.Analog.Sources.StepCurrent stepCurrent(
    I=20,
    offset=20,
    startTime=500) annotation (Placement(transformation(
        extent={{-10,-10},{10,10}},
        rotation=-90,
        origin={-14,-4})));
equation
  connect(statRes.pin_n, ground1.p) annotation (Line(points={{-60,-10},{-59.8662,
          -10},{-59.8662,-30},{-60,-30}}, color={0,0,255}));
  connect(statRes.pin_p, currentsensor1.p) annotation (Line(points={{-60,10},{-60.2007,
          10},{-60.2007,39.4649},{-50,39.4649},{-50,40}}, color={0,0,255}));
  connect(stepCurrent.p, currentsensor1.n) annotation (Line(
      points={{-14,6},{-14,40},{-30,40}},
      color={0,0,255},
      smooth=Smooth.None));
  connect(stepCurrent.n, ground1.p) annotation (Line(
      points={{-14,-14},{-14,-22},{-60,-22},{-59.8662,-30},{-60,-30}},
      color={0,0,255},
      smooth=Smooth.None));
  annotation (
    Diagram(coordinateSystem(
        extent={{-100,-60},{100,60}},
        preserveAspectRatio=false,
        initialScale=0.1,
        grid={2,2}), graphics),
    Icon(coordinateSystem(
        extent={{-100,-60},{100,60}},
        preserveAspectRatio=true,
        initialScale=0.1,
        grid={2,2})),
    uses(Modelica(version="3.2.1")),
    experiment(StopTime=1500, __Dymola_NumberOfIntervals=2000),
    __Dymola_experimentSetupOutput);
end batt1;

Thank you

When we simulate with OMEdit and we choose Stop Time and Number of Intervals, OMEdit determines the corresponding timestep and converts our Number of Intervals request in an Interval Modelica annotation.

When we re-simulate, currently, we can modify the Stop Time but not the Number of Intervals.
I have two questions:
1) when we change the stop time in the re-simulation setup does OMEdit keep constant the "interval" or the "number of intervals"?
2) is it possible to have in the future also the number of intervals changeable when re-simulating or there is some big obstacle in implementing this?

Sure.
I just wanted first to be sure that it was a real issue and not a fault of mine.
I will post the ticket today.

MC

I want to use arrays of blocks in a model. Consider for instance the following code:

model a

  Modelica.Blocks.Sources.Constant const[3];

  Modelica.Blocks.Math.Gain gain[3];

equation 

  connect(gain.u, const.y) ;

end a;

It looks like it is impossible to create such code graphically in OMEdit.

I tried dragging & dropping  "const" and "gain" from Modelica library, and then making the blocks become arrays changing their names, i.e. "const" into "const[3]" and "gain" into "gain[3]" .  But this did not work.

Indeed, changing "const" into "const[3]" directly in the diagram view perspective causes a strange behaviour:  the name visualised in the diagram view is "const[3]", while the code still reads "const". This is not good.

Maybe some modifications to OMEdit to allow better management of arrays of model is needed?

I suppose you don't really mean "parameter " (i.e. quantity that does not vary during a simulation) but, instead "variable".
If this is the case the answer is obviously yes.
Standard component Modelica.Mechanics.Translational.Components relates force with displacement.

The link you provided isn't working.. at least for me. Even if it's working, as you said, it's short one. So do you think it would be appropriate if I write an detailed tutorial?

I had no problems in connecting to tour.xogeny.com
I liked the xogeny tutorial, that is much more than a pdf, contains chapters and  lessons in a structure way, examples and exercises.

However, answering to the Modelica.org ticket that I mentioned in my previous message would have the additional benefit of working on a tn "official" tutorial, i.e.  one that has been discussed and validated by the association.

Consider, for instance, that Dymola still includes in its distribution that old tutorial.

Do you know that there exist an official modelica tutorial by the modelica association?
It is in theory very well done, but VERY old: it refers to Modelica 1.4 and was written in December 2000
There is a ticket open on the Modelica association site about volunteers wanting to update that tutorial:
    https://trac.modelica.org/Modelica/ticket/106
Maybe you are the right volunteer?

MC

When you post in a ticket as anonymous you will have to do a sum (to avoid spam.
You might read something like (the numbers change every time):;

Anonymous users are allowed to post by adding 6 and 4

In this example you should write, obviously, 10 in the small box aside the message asking to add the two numbers.

Looking at the doc it seems like the functionality required can well be reproduced by Modelica.
A XMILE - to - Modelica translator is sure a possibility,and maybe it is the only thing today can be do to gain access to XMILE-coded models.
However translators have their limits: time required to create them, possibility of errors, need to updates when the source standard is updated, etc.

I hope that in the future, as far as Modelica becomes more known, these kinds or scope-limited simulators will reduce in  number. Having used SystemDynamics By Cellier in OM, I understand that SystemDynamics is a discipline that requires simpler maths than others, and therefore is well simulated using Modelica, or even a subset of Modelica.

If just a "rule for common usage of Modelica in SystemDynamics" or a subset of Modelica were defined, the effort to create such SystemDynamics standards would have been much smaller.
Naturally, I don't want to dismiss other people's valuable work. I just wanted to share a thought that is based on my personal experience.

It is  pity that XMILE people have decided to create another standard, when Modelica is already there and has already shown to be able to describe and simulate SystemDynamics models perfectly. Modelica is also textual, an XML new standard to describe models has not significant advantages over Modelica itself.

For instance  a SystemDynamics library comes with OM and smoothly reproduces the Limits-to-growth models.

It XMILE designers were modelica-aware, maybe they would have, at most, just created a small document depicting a subset of Modelica and some Modelica specification for System Dynamics.
Instead of creating another standard to add-up to the existing ones.

Using OM r22043 I created an FMU from the enclosed rld.mo. When I import back that FMU, StopTime, that was 0.1s, has become 1.0 s.
Maybe this is simple to fix.

RLD.mo

Note that our programs get reformatted when saved.
Upon reformatting some change might happen to be meaningful (not just cosmetic).
In the past I discovered that OM did make a change that caused my program not working anymore. I found exactly what happened, posted a ticket a and in a day or two the issue was fixed.

If I run (using OM r20199)  "gridTest21" of the enclosed package "AutoCreateBug" I get the following message:

"C:\Programmi\OpenModelica1.9.1Nightly\\MinGW\bin\mingw32-make.exe" -f AutoCreateBug.gridTest21.makefile

gcc   -falign-functions -msse2 -mfpmath=sse     -I"C:/Programmi/OpenModelica1.9.1Nightly//include/omc/c" -I. -DOPENMODELICA_XML_FROM_FILE_AT_RUNTIME  -c -o AutoCreateBug.gridTest21.o AutoCreateBug.gridTest21.c

AutoCreateBug.gridTest21.c: In function 'AutoCreateBug_gridTest21_eqFunction_27':

AutoCreateBug.gridTest21.c:458: error: expected expression before 'modelica_integer'

AutoCreateBug.gridTest21.c:458: error: expected ')' before '$Pi$rB$Pv'

AutoCreateBug.gridTest21.c:460: error: expected expression before 'modelica_integer'

AutoCreateBug.gridTest21.c:460: error: expected ')' before '$Pi$rB$Pv'

mingw32-make: *** [AutoCreateBug.gridTest21.o] Error 1

Compilation process exited with code 2

It seems that OM created for my model a C file that is invalid.
What can I do to solve this?

Any help is appreciated.
Thanks a lot in advance.

*** UPDATE *** I could not upload the file. Therefore I will give up discussing this topic here.
I will add a bug report instead (I hope this won't be a false alarm!)

I see.
But what seems strange to me is that Modelica, that is so carefully designed in its syntax, and that is built from the ground up in the distinction between assignments (n algorithms, implementing imperative programming) and equations (in equation sections, implementing  the declarative programming paradigm) is so vague about bindings.
I really don't understand why they allow bindings written in equation form.
It seems to me that they really indicate assignments. But maybe I'm missing something.

In Modelica modifications are made by means of equations (for instance in the following examples taken from sect. 7.2 of ModelicaSpec32):
Real altitude (start=59404)
parameter Real x=2;

To my understanding these should be assignments instead:
Real altitude (start:=59404)
parameter Real x:=2;

I say this because these modification copy the value at the right of sign "=" or ":=" into the variable at its left.
Indeed the Modelica grammar allows for these cases both "=" and ":=", but in the examples typically "=" is used and common tools' GUIs (such as OMEdit) use "="  when the user chooses parameter values.

I'm pretty sure that this has been chosen on purpose by Modelica designers and tool programmers.
But I cannot envisage the reasoning. They wanted there to be equations (at least either equations or assignments). To me they are definitely assignments, not equations.
Any opinions or comments about this?

ah,
I really don't know how I could create this, given the programs (all very new) I use.
Now I've also checked Dymola in pedantic mode and it correctly complains about 'extent'.
Thanks.

MC

I often switch between Dymola and OM, and thus I often incur in compatibility issues.
I've the following code: a model "RL" that uses "myResistor" (both created using Dymola)
the circuit RL is not displayed well (with R20071).
Is there some error in the Modelica code?

Thanks.

model MyResistor "Ideal linear electrical resistor"

  parameter Modelica.SIunits.Resistance R(start=1) ;

  extends Modelica.Electrical.Analog.Interfaces.OnePort;

equation 

  v = R*i;

  annotation (uses(Modelica(version="3.2.1")), Icon(graphics={

        Rectangle(

          extent={{-70,32},{70,-28}},

          lineColor={0,0,255},

          fillColor={255,255,255},

          fillPattern=FillPattern.Solid),

        Line(points={{-90,0},{-70,0}}),

        Line(points={{70,0},{90,0}}),

        Text(

          extent={{-142,-48},{146,-88}},

          lineColor={0,0,0},

          textString="R=%R"),

        Text(

          extent={{-142,56},{142,100}},

          textString="%name",

          lineColor={0,0,255})}));

end MyResistor;



model RL

  Modelica.Electrical.Analog.Basic.Ground ground annotation (extent=[-10, -34; 10,

        -14], Placement(transformation(extent={{-10,-52},{10,-32}})));

  Modelica.Electrical.Analog.Basic.Inductor inductor(L=0.01)

    annotation (extent=[30, -10; 50, 10], rotation=-90);

  Modelica.Electrical.Analog.Sources.ConstantVoltage Vsource(V=10)

    annotation (extent=[-50, -10; -30, 10], rotation=-90);

  MyResistor Resistor(R=1) annotation (extent=[-10, 14; 10, 34], Placement(

        transformation(extent={{-10,10},{10,30}})));

equation 

  connect(inductor.n, Vsource.n) annotation (Line(

      points={{40,-10},{40,-20},{-40,-20},{-40,-10}},

      color={0,0,255},

      smooth=Smooth.None));

  connect(ground.p, Vsource.n) annotation (Line(

      points={{0,-32},{0,-20},{-40,-20},{-40,-10}},

      color={0,0,255},

      smooth=Smooth.None));

  connect(Resistor.n, inductor.p) annotation (Line(

      points={{10,20},{40,20},{40,10}},

      color={0,0,255},

      smooth=Smooth.None));

  connect(Resistor.p, Vsource.p) annotation (Line(

      points={{-10,20},{-40,20},{-40,10}},

      color={0,0,255},

      smooth=Smooth.None));

  annotation (

    uses(Modelica(version="3.2.1")),

    Diagram(coordinateSystem(preserveAspectRatio=false, extent={{-100,-100},{100,

            100}}), graphics),

    experiment(StopTime=0.1),

    __Dymola_experimentSetupOutput);

end RL;

Maybe it is not a bad idea to put two or three examples of good filters in the OpenModelicUsersGuide.pdf.
Also some info about the output formats would save Adeas or other programmers time to answer some questions.
I remember to have asked in this forum about which release (V4, V5, V6 or V7) of the mat format and which structure the format has In case one wants to make a reading routine of his own.

It was just a thought and a kind suggestion.
I know very well how busy OM programmers are, and therefore, that they cannot consider all ideas and suggestions from we users!

Well,
maybe it was a stupid post.
I think I can find myself the answers.
About the "conflicting" equations. The two latter equations are added only when the permanent magnet is isolated. When it is connected to other parts they are substituted with connection equations that in normal situations will solve the conflict.

About the possibility to have components containing a unique connector containing a flow variable.
Now I understand that flow variables are considered such by Modelica tools when connections between components are involved.
Modelica interpreters to not care about what occurs inside models. That enables permanent magnets containing a single connectors.
Obviously, ordinary electric components carry two pins (they are one port components) because the physics of current requires this.
But space phasor currents are mathematical entities that are not subject to the ordinary physics laws for currents.

MC

The model
Modelica.Electrical.Machines.Examples.SMPM_CurrentSource gives reasonable results both in OM and Dymola.

It uses the model
Modelica.Electrical.Machines.BasicMachines.Components.PermanentMagnet.
If we instantiate this latter model in OM we get:

class Modelica.Electrical.Machines.BasicMachines.Components.PermanentMagnet "Permanent magnet excitation"

  parameter Real Ie(quantity = "ElectricCurrent", unit = "A") "Equivalent excitation current";

  Real spacePhasor_r.v_[1](quantity = "ElectricPotential", unit = "V") "1=real, 2=imaginary part";

  Real spacePhasor_r.v_[2](quantity = "ElectricPotential", unit = "V") "1=real, 2=imaginary part";

  Real spacePhasor_r.i_[1](quantity = "ElectricCurrent", unit = "A") "1=real, 2=imaginary part";

  Real spacePhasor_r.i_[2](quantity = "ElectricCurrent", unit = "A") "1=real, 2=imaginary part";

equation

  spacePhasor_r.i_[1] = -Ie;

  spacePhasor_r.i_[2] = 0.0;

  spacePhasor_r.i_[1] = 0.0;

  spacePhasor_r.i_[2] = 0.0;

end Modelica.Electrical.Machines.BasicMachines.Components.PermanentMagnet;

This seems indeed invalid for several reasons. Eq. 1 conflicts with Eq. 3 and eq. 2 is the same as eq. 4.
How come that this can work?
More in general, How it is possible that the "spacePhasor" connectors, that contain a flow variable can be used in a component like this
that has a single connector, not a pair?

Good!
that is what I needed.
thank you.

Good!
that is what I needed.
thank you.

Ehm,
if I understand well, the link tells how to interpret the mat file from Matlab or Octave, or when using python.
What I would like, instead, is to create my own program that reads these files. I program in C++ using Qt.
How OM writes and reads mat files? using C coding or some dll from Mathworks?

Since the files outputted by OM contain character variables the used matlab format must be later than (the very old but still used) 4.0. But which one? Where to find details of the format?

Many thanks.
I should have googled the query myself.

I already have created a plotting program that is able to read many input formats.
I'm now considering to make it capable to read also OM mat output files (and consequently also Dymola output files).
Can anyone tell me where I can find a description of this Format?
I'm quite at ease with Matlab 4 format. But this is not enough to be able to list variables and read contents of OM matlab output flles.

Thanks a lot in advance.

I've checked the URL and it is was not that easy to me to understand how to pull requests.

Is going there the only way?

The modification I discussed is just a way to make Power Systems Library  more Modelica compliant.
Maybe if someone having access to that library maintenance has a look at this forum he can realize that in a few minutes he can significantly enlarge the number of Power Systems examples OM can run.
The suggesion came from the original author of the Power Systems Library.

I've received this very useful hint from Wiesmann, one of the authors of the Power Systems Library:

- in 'Generic.FixedVoltageSource': change 'isRoot' to 'Connections.isRoot'
  (Dymola accepts the short version, OpenModelica rejects)

I've checked that this actually makes this library much more compliant with OM.
Maybe it is a good idea to make this tiny change to the library version distributed with OM, Isn't it?

MC

It you want to input parameters (=quantities not varying during simulations) you don't need real Input.
If you mean actual vectorial input , for instance to feed a three-phase signal voltage or signal current you can use  a vectorised real input e.g. u[3]

MC

Adeel,
your workaround is perfect!
I will also add a ticket on this issue.

I've created a model icon in another tool (dymola 2014). This does not show in OMEdit (r18954).
I wonder whether it is correct Modelica code or not. It it is, maybe some fix must be made in the OMEdit code.
Can someone tell?
Here is  the icon-only model:

model justIcon

equation 

  annotation(Diagram(coordinateSystem(preserveAspectRatio = false, extent = {{-100,-100},{100,100}}), graphics), Icon(coordinateSystem(preserveAspectRatio = false, extent = {{-100,-100},{100,100}}), graphics={  Text(extent = {{-154,-47},{146,-87}}, textString = "%name", lineColor = {0,0,255}),Polygon(points = {{26,0},{-34,40},{-34,-40},{26,0}}, lineColor = {0,0,0}, fillColor = {255,255,255},

            fillPattern =  FillPattern.Solid),Line(points = {{-94,0},{96,0}}, color = {0,0,255}),Line(points = {{26,40},{26,-40}}, color = {0,0,255}),Line(points = {{26,20},{54,50},{54,76}}, color = {0,0,255}),Line(points = {{36,50},{56,30}}, color = {0,0,255}),Line(visible = useHeatPort, points = {{-4,-100},{-4,-20}}, color = {127,0,0}, smooth = Smooth.None, pattern = LinePattern.Dot),Rectangle(extent = {{-66,84},{68,62}}, lineColor = {0,0,255}, fillColor = {255,255,255},

            fillPattern =  FillPattern.Solid),Line(points = {{0,84},{0,106}}, color = {0,0,255}, smooth = Smooth.None)}),

    uses(Modelica(version="3.2")));

end justIcon;

Thanks a lot.
Massimo

I would like to set intitType=3 in a PI block.
I've written the following simple minimal model:

model PI

  Modelica.Blocks.Continuous.PI PI(initType = 3, x_start = 1);

  Modelica.Blocks.Sources.Constant const;

equation

  connect(PI.u,const.y);

end PI;

When I run this in OM r17838 I get the following error:

Translation    08:23:37    C:\OpenModelica1.9.1Nightly\lib\omlibrary\Modelica 3.2.1\Blocks\Continuous.mo    568:5-571:40    Type mismatch in binding initType = 3, expected subtype of enumeration(NoInit, SteadyState, InitialState, InitialOutput), got type Integer.

Can someone tell me how to solve this?

Thank you.

thanks a lot.
I see that Power Systems is not OM-friendly, at least today.
But now we can also clearly wee what already works.

Massimo.

From the www.modelica.org. the library PowerSystems 0.2 is available.

Although in its version 0.x, this library  is already very interesting to power systems engineers.

However, from site:  https://test.openmodelica.org/~marsj/trend.html
I see that its compliance with OM is not monitored.

Indeed OM does not like Power Systems 0.2, but I cannot say wheter the library is fully compliant to Modelica Specifications 3.2 rev2 or not (I guess not)

Does somebody know whether there are plans to at least monitor the OM compliance with Power Systems library?

Sorry for the late reply.
I did not succeed to upload the file. I will send it  to you soon in a separate e-mail.
Massimo

To test FMI Dymola-to-OM communication I've tried with the classic bouncing ball model (that, as a mo file, runs well in both Dymola and OM):

model Bouncing

  parameter Real yStart = 1;

  parameter Real vStart = 0;

  parameter Real dampCoeff = 0.8;

  Real y(start = yStart);

  Real v(start = vStart);

  Real g(start = -9.81);

equation 

  der(y) = v;

  der(v) = g;

  when y < 0 then

      reinit(v, -dampCoeff * v);

  end when;

  when abs(v) < 0.001 and y < 0.0001 then

      g = 0;

    reinit(v, 0);

  end when;

  annotation(uses(Modelica(version = "3.2")),

    experiment(StopTime=4),

    __Dymola_experimentSetupOutput);

end Bouncing;

I've created the FMU using the following Dymola 2014 options:
Type-> model exchange
Version -> 1.0

This generated the FMU shown below(as read by OMEdit), that crashes in OM  r16523.

Any suggestions?

THIS IS THE FMU CODE:

model Bouncing_me_FMU

  constant String fmuFile = "Y:/Documents/Dymola/Bouncing.fmu";

  constant String fmuWorkingDir = "C:/Users/ADMINI~1/AppData/Local/Temp/OpenModelica/OMEdit";

  constant Integer fmiLogLevel = 3;

  constant Boolean debugLogging = false;

  fmi1ImportInstance fmi = fmi1ImportInstance(context, fmuWorkingDir);

  fmi1ImportContext context = fmi1ImportContext(fmiLogLevel);

  fmi1EventInfo eventInfo;

  parameter Real yStart(start = 1.0, fixed = true);

  parameter Real vStart(start = 0.0, fixed = true);

  parameter Real dampCoeff(start = 0.8, fixed = true);

  Real y;

  Real der_y_;

  Real v;

  Real der_v_;

  Real g(start = -9.81, fixed = true);

  constant Integer numberOfContinuousStates = 2;

  Real fmi_x[numberOfContinuousStates] "States";

  Real fmi_x_new[numberOfContinuousStates] "New States";

  constant Integer numberOfEventIndicators = 6;

  Real fmi_z[numberOfEventIndicators] "Events Indicators";

  Boolean fmi_z_positive[numberOfEventIndicators];

  parameter Real flowInstantiate(fixed = false);

  Real flowTime;

  parameter Real flowParamsStart(fixed = false);

  Real flowStatesInputs;

  Boolean callEventUpdate;

  constant Boolean intermediateResults = false;

  Boolean newStatesAvailable;

  Integer fmi_status;

  Real triggerDSSEvent;

  Real nextEventTime;

initial algorithm

  flowInstantiate:=fmiFunctions.fmi1InstantiateModel(fmi, "Bouncing", debugLogging);

  flowParamsStart:=0;

  eventInfo:=fmiFunctions.fmi1Initialize(fmi, eventInfo);

  fmi_x:=fmiFunctions.fmi1GetContinuousStates(fmi, numberOfContinuousStates, flowParamsStart);

equation

  flowTime = fmiFunctions.fmi1SetTime(fmi, time);

  flowStatesInputs = fmiFunctions.fmi1SetContinuousStates(fmi, fmi_x, flowParamsStart + flowTime);

  der(fmi_x) = fmiFunctions.fmi1GetDerivatives(fmi, numberOfContinuousStates, flowStatesInputs);

  fmi_z = fmiFunctions.fmi1GetEventIndicators(fmi, numberOfEventIndicators, flowStatesInputs);

  for i in 1:size(fmi_z, 1) loop

  fmi_z_positive[i] = if not terminal() then fmi_z[i] > 0 else pre(fmi_z_positive[i]);



  end for;

  callEventUpdate = fmiFunctions.fmi1CompletedIntegratorStep(fmi, flowStatesInputs);

  triggerDSSEvent = noEvent(if callEventUpdate then flowStatesInputs + 1.0 else flowStatesInputs - 1.0);

  nextEventTime = fmiFunctions.fmi1nextEventTime(fmi, eventInfo, flowStatesInputs);

  {y,der_y_,v,der_v_,g} = fmiFunctions.fmi1GetReal(fmi, {33554432.0,587202560.0,33554433.0,587202561.0,637534208.0}, flowStatesInputs);

algorithm

  when {(change(fmi_z_positive[6]) or change(fmi_z_positive[5]) or change(fmi_z_positive[4]) or change(fmi_z_positive[3]) or change(fmi_z_positive[2]) or change(fmi_z_positive[1])) and not initial(),triggerDSSEvent > flowStatesInputs,nextEventTime < time} then

      newStatesAvailable:=fmiFunctions.fmi1EventUpdate(fmi, intermediateResults, eventInfo, flowStatesInputs);

    if newStatesAvailable then 

      fmi_x_new:=fmiFunctions.fmi1GetContinuousStates(fmi, numberOfContinuousStates, flowStatesInputs);

      reinit(fmi_x[2], fmi_x_new[2]);

      reinit(fmi_x[1], fmi_x_new[1]);

    else



    end if;  

  end when;

  when terminal() then

      fmi_status:=fmiFunctions.fmi1Terminate(fmi);  

  end when;

protected

  class fmi1ImportContext

    extends ExternalObject;

    function constructor

      input Integer fmiLogLevel;

      output fmi1ImportContext context;



      external "C" context = fmi1ImportContext_OMC(fmiLogLevel)       annotation(Library = {"OpenModelicaFMIRuntimeC","fmilib","shlwapi"});

    end constructor;

    function destructor

      input fmi1ImportContext context;



      external "C" fmi1ImportFreeContext_OMC(context)       annotation(Library = {"OpenModelicaFMIRuntimeC","fmilib","shlwapi"}); 

    end destructor;

  end fmi1ImportContext;

  class fmi1ImportInstance

    extends ExternalObject;

    function constructor

      input fmi1ImportContext context;

      input String tempPath;

      output fmi1ImportInstance fmi;



      external "C" fmi = fmi1ImportInstance_OMC(context,tempPath)       annotation(Library = {"OpenModelicaFMIRuntimeC","fmilib","shlwapi"});

    end constructor;

    function destructor

      input fmi1ImportInstance fmi;



      external "C" fmi1ImportFreeInstance_OMC(fmi)       annotation(Library = {"OpenModelicaFMIRuntimeC","fmilib","shlwapi"}); 

    end destructor;

  end fmi1ImportInstance;

  class fmi1EventInfo

    extends ExternalObject;

    function constructor

    end constructor;

    function destructor

      input fmi1EventInfo eventInfo;



      external "C" fmi1FreeEventInfo_OMC(eventInfo)       annotation(Library = {"OpenModelicaFMIRuntimeC","fmilib","shlwapi"}); 

    end destructor;

  end fmi1EventInfo;

  package fmiFunctions

    function fmi1InstantiateModel

      input fmi1ImportInstance fmi;

      input String instanceName;

      input Boolean debugLogging;

      output Real outFlowInstantiate;



      external "C" outFlowInstantiate = fmi1InstantiateModel_OMC(fmi,instanceName,debugLogging)       annotation(Library = {"OpenModelicaFMIRuntimeC","fmilib","shlwapi"});

    end fmi1InstantiateModel;

    function fmi1Initialize

      input fmi1ImportInstance fmi;

      input fmi1EventInfo inEventInfo;

      output fmi1EventInfo outEventInfo;



      external "C" outEventInfo = fmi1Initialize_OMC(fmi,inEventInfo)       annotation(Library = {"OpenModelicaFMIRuntimeC","fmilib","shlwapi"});

    end fmi1Initialize;

    function fmi1SetTime

      input fmi1ImportInstance fmi;

      input Real inTime;

      output Real status;



      external "C" status = fmi1SetTime_OMC(fmi,inTime)       annotation(Library = {"OpenModelicaFMIRuntimeC","fmilib","shlwapi"});

    end fmi1SetTime;

    function fmi1GetContinuousStates

      input fmi1ImportInstance fmi;

      input Integer numberOfContinuousStates;

      input Real inFlowParams;

      output Real fmi_x[numberOfContinuousStates];



      external "C" fmi1GetContinuousStates_OMC(fmi,numberOfContinuousStates,inFlowParams,fmi_x)       annotation(Library = {"OpenModelicaFMIRuntimeC","fmilib","shlwapi"}); 

    end fmi1GetContinuousStates;

    function fmi1SetContinuousStates

      input fmi1ImportInstance fmi;

      input Real fmi_x[:];

      input Real inFlowParams;

      output Real outFlowStates;



      external "C" outFlowStates = fmi1SetContinuousStates_OMC(fmi,size(fmi_x, 1),inFlowParams,fmi_x)       annotation(Library = {"OpenModelicaFMIRuntimeC","fmilib","shlwapi"});

    end fmi1SetContinuousStates;

    function fmi1GetDerivatives

      input fmi1ImportInstance fmi;

      input Integer numberOfContinuousStates;

      input Real inFlowStates;

      output Real fmi_x[numberOfContinuousStates];



      external "C" fmi1GetDerivatives_OMC(fmi,numberOfContinuousStates,inFlowStates,fmi_x)       annotation(Library = {"OpenModelicaFMIRuntimeC","fmilib","shlwapi"}); 

    end fmi1GetDerivatives;

    function fmi1GetEventIndicators

      input fmi1ImportInstance fmi;

      input Integer numberOfEventIndicators;

      input Real inFlowStates;

      output Real fmi_z[numberOfEventIndicators];



      external "C" fmi1GetEventIndicators_OMC(fmi,numberOfEventIndicators,inFlowStates,fmi_z)       annotation(Library = {"OpenModelicaFMIRuntimeC","fmilib","shlwapi"}); 

    end fmi1GetEventIndicators;

    function fmi1GetReal

      input fmi1ImportInstance fmi;

      input Real realValuesReferences[:];

      input Real inFlowStatesInput;

      output Real realValues[size(realValuesReferences, 1)];



      external "C" fmi1GetReal_OMC(fmi,size(realValuesReferences, 1),realValuesReferences,inFlowStatesInput,realValues)       annotation(Library = {"OpenModelicaFMIRuntimeC","fmilib","shlwapi"}); 

    end fmi1GetReal;

    function fmi1SetReal

      input fmi1ImportInstance fmi;

      input Real realValuesReferences[:];

      input Real realValues[size(realValuesReferences, 1)];

      output Real outFlowParams;



      external "C" outFlowParams = fmi1SetReal_OMC(fmi,size(realValuesReferences, 1),realValuesReferences,realValues)       annotation(Library = {"OpenModelicaFMIRuntimeC","fmilib","shlwapi"});

    end fmi1SetReal;

    function fmi1GetInteger

      input fmi1ImportInstance fmi;

      input Real integerValuesReferences[:];

      input Real inFlowStatesInput;

      output Integer integerValues[size(integerValuesReferences, 1)];



      external "C" fmi1GetInteger_OMC(fmi,size(integerValuesReferences, 1),integerValuesReferences,inFlowStatesInput,integerValues)       annotation(Library = {"OpenModelicaFMIRuntimeC","fmilib","shlwapi"}); 

    end fmi1GetInteger;

    function fmi1SetInteger

      input fmi1ImportInstance fmi;

      input Real integerValuesReferences[:];

      input Integer integerValues[size(integerValuesReferences, 1)];

      output Real outFlowParams;



      external "C" outFlowParams = fmi1SetInteger_OMC(fmi,size(integerValuesReferences, 1),integerValuesReferences,integerValues)       annotation(Library = {"OpenModelicaFMIRuntimeC","fmilib","shlwapi"});

    end fmi1SetInteger;

    function fmi1GetBoolean

      input fmi1ImportInstance fmi;

      input Real booleanValuesReferences[:];

      input Real inFlowStatesInput;

      output Boolean booleanValues[size(booleanValuesReferences, 1)];



      external "C" fmi1GetBoolean_OMC(fmi,size(booleanValuesReferences, 1),booleanValuesReferences,inFlowStatesInput,booleanValues)       annotation(Library = {"OpenModelicaFMIRuntimeC","fmilib","shlwapi"}); 

    end fmi1GetBoolean;

    function fmi1SetBoolean

      input fmi1ImportInstance fmi;

      input Real booleanValuesReferences[:];

      input Boolean booleanValues[size(booleanValuesReferences, 1)];

      output Real outFlowParams;



      external "C" outFlowParams = fmi1SetBoolean_OMC(fmi,size(booleanValuesReferences, 1),booleanValuesReferences,booleanValues)       annotation(Library = {"OpenModelicaFMIRuntimeC","fmilib","shlwapi"});

    end fmi1SetBoolean;

    function fmi1GetString

      input fmi1ImportInstance fmi;

      input Real stringValuesReferences[:];

      input Real inFlowStatesInput;

      output String stringValues[size(stringValuesReferences, 1)];



      external "C" fmi1GetString_OMC(fmi,size(stringValuesReferences, 1),stringValuesReferences,inFlowStatesInput,stringValues)       annotation(Library = {"OpenModelicaFMIRuntimeC","fmilib","shlwapi"}); 

    end fmi1GetString;

    function fmi1SetString

      input fmi1ImportInstance fmi;

      input Real stringValuesReferences[:];

      input String stringValues[size(stringValuesReferences, 1)];

      output Real outFlowParams;



      external "C" outFlowParams = fmi1SetString_OMC(fmi,size(stringValuesReferences, 1),stringValuesReferences,stringValues)       annotation(Library = {"OpenModelicaFMIRuntimeC","fmilib","shlwapi"});

    end fmi1SetString;

    function fmi1EventUpdate

      input fmi1ImportInstance fmi;

      input Boolean intermediateResults;

      input fmi1EventInfo inEventInfo;

      input Real inFlowStates;

      output Boolean outNewStatesAvailable;



      external "C" outNewStatesAvailable = fmi1EventUpdate_OMC(fmi,intermediateResults,inEventInfo,inFlowStates)       annotation(Library = {"OpenModelicaFMIRuntimeC","fmilib","shlwapi"});

    end fmi1EventUpdate;

    function fmi1nextEventTime

      input fmi1ImportInstance fmi;

      input fmi1EventInfo inEventInfo;

      input Real inFlowStates;

      output Real outNewnextTime;



      external "C" outNewnextTime = fmi1nextEventTime_OMC(fmi,inEventInfo,inFlowStates)       annotation(Library = {"OpenModelicaFMIRuntimeC","fmilib","shlwapi"});

    end fmi1nextEventTime;

    function fmi1CompletedIntegratorStep

      input fmi1ImportInstance fmi;

      input Real inFlowStates;

      output Boolean outCallEventUpdate;



      external "C" outCallEventUpdate = fmi1CompletedIntegratorStep_OMC(fmi,inFlowStates)       annotation(Library = {"OpenModelicaFMIRuntimeC","fmilib","shlwapi"});

    end fmi1CompletedIntegratorStep;

    function fmi1Terminate

      input fmi1ImportInstance fmi;

      output Integer status;



      external "C" status = fmi1Terminate_OMC(fmi)       annotation(Library = {"OpenModelicaFMIRuntimeC","fmilib","shlwapi"});

    end fmi1Terminate;

  end fmiFunctions;

  package fmiStatus

    constant Integer fmiOK = 0;

    constant Integer fmiWarning = 1;

    constant Integer fmiDiscard = 2;

    constant Integer fmiError = 3;

    constant Integer fmiFatal = 4;

    constant Integer fmiPending = 5;

  end fmiStatus;

  annotation(experiment(StartTime = 0.0, StopTime = 4.0, Tolerance = 0.0001));

  annotation(Icon(graphics = {Rectangle(extent = {{-100,100},{100,-100}}, lineColor = {0,0,0}, fillColor = {240,240,240}, fillPattern = FillPattern.Solid, lineThickness = 0.5),Text(extent = {{-100,40},{100,0}}, lineColor = {0,0,0}, textString = "%name"),Text(extent = {{-100,-50},{100,-90}}, lineColor = {0,0,0}, textString = "V1.0")}));

end Bouncing_me_FMU;

I've a model that has to take the derivative of the input.
However, when run, OM says:
Translation    16:07:34        0:0-0:0    Error building simulator. Buildlog: gcc  [...]
Translation    16:07:34        0:0-0:0    The model requires derivatives of some inputs as listed below:
der(SOC)
der(SOC)

Maybe it is just a question of supplying the derivatives at t=0: later the program should be able to calculate them.
But I cannot envisage how to tell the program these t=0 derivatives.
Any suggestions?

model MinorLoop

  Modelica.Blocks.Interfaces.RealOutput Uoc annotation(Placement(transformation(extent = {{100,-10},{120,10}})));

  Modelica.Blocks.Interfaces.RealInput SOC annotation(Placement(transformation(extent = {{-140,-20},{-100,20}})));

  parameter Real k = 10;

  Real derUocSoc,Corr;

  Modelica.Blocks.Tables.CombiTable1D UocT(smoothness = Modelica.Blocks.Types.Smoothness.ContinuousDerivative, table = [0,2.85,2.85;0.2,3.2,3.22;0.5,3.29,3.31;0.9,3.32,3.34;1,3.39,3.39], columns = {2,3}) annotation(Placement(transformation(extent = {{-50,-10},{-30,10}})));

  Modelica.Blocks.Routing.Replicator replicator(nout = 2) annotation(Placement(transformation(extent = {{-82,-10},{-62,10}})));

initial equation

  Uoc = (UocT.y[1] + UocT.y[2]) / 2;

equation

  if der(SOC) >= 0 then

    derUocSoc = der(UocT.y[2]) / der(SOC);

    Corr = k * (UocT.y[2] - Uoc);

  else

    derUocSoc = der(UocT.y[1]) / der(SOC);

    Corr = -k * (UocT.y[1] - Uoc);

  end if;

  der(Uoc) / der(SOC) = derUocSoc + Corr;

  connect(replicator.u,SOC) annotation(Line(points = {{-84,0},{-120,0}}, color = {0,0,127}, smooth = Smooth.None));

  connect(UocT.u,replicator.y) annotation(Line(points = {{-52,0},{-61,0}}, color = {0,0,127}, smooth = Smooth.None));

  annotation(Diagram(coordinateSystem(preserveAspectRatio = false, extent = {{-100,-100},{100,100}}), graphics), Icon(coordinateSystem(preserveAspectRatio = false, extent = {{-100,-100},{100,100}}), graphics = {Rectangle(extent = {{-100,100},{100,-100}}, lineColor = {0,0,255}, fillColor = {255,255,255}, fillPattern = FillPattern.Solid)}));

end MinorLoop;

I used "check model" in OMEdit.
This "equation number" issue is blocking, since when I use the proposed model as a submodel of something "runnable", I receive the following message

Symbolic    19:02:42        0:0-0:0    Too many equations, overdetermined system. The model has 546 equation(s) and 539 variable(s)

and simulation does not start.

Below I enclose the model "QSAsma" in a file of its own (model.mo) and in a package (package.mo).
OM reports 221 variables.
OM reports for the model in model.mo 222 equations, for the model in package.mo 228 variables.
Dymola always reports 221 variables and equations.
When this model is simulated in OM (called by other models) OM complains about it having too many equations.

I see two issues:
1) is it possible that for THE SAME model a different number of equations is counted when inside or outside packages?
2) maybe something is wrong also in the model.mo equations counting (222 instead of 221)?

***  FILE MODEL.MO ***

within ;

model QSAsma

  import PI = Modelica.Constants.pi;

  Modelica.Electrical.QuasiStationary.SinglePhase.Basic.Inductor L1_(L = L1) annotation(Placement(transformation(extent = {{-8,8},{12,28}})));

  Modelica.Electrical.QuasiStationary.SinglePhase.Basic.Resistor R1_(R_ref = R1) annotation(Placement(transformation(extent = {{-32,8},{-12,28}})));

  Modelica.Electrical.QuasiStationary.SinglePhase.Basic.Inductor L2_(L = L2) annotation(Placement(transformation(extent = {{26,8},{46,28}})));

  Modelica.Electrical.QuasiStationary.SinglePhase.Basic.Inductor Lm_(L = Lm) annotation(Placement(transformation(extent = {{-10,-10},{10,10}}, rotation = 270, origin = {18,-2})));

  Modelica.Electrical.QuasiStationary.SinglePhase.Basic.VariableResistor Rmecc annotation(Placement(transformation(extent = {{-10,-10},{10,10}}, rotation = 270, origin = {90,-2})));

  Modelica.Electrical.QuasiStationary.SinglePhase.Sources.VariableVoltageSource

                                                                                uTerminals annotation(Placement(transformation(extent = {{-10,10},{10,-10}}, rotation = 270, origin = {-72,-2})));

  Modelica.ComplexBlocks.ComplexMath.PolarToComplex ToComplexUin annotation(Placement(transformation(origin = {-70,84}, extent = {{-10,-10},{10,10}}, rotation = 0)));

  Modelica.Blocks.Interfaces.RealInput U annotation(Placement(transformation(extent = {{-160,40},{-120,80}}), iconTransformation(extent = {{-140,40},{-100,80}})));

  Modelica.Blocks.Sources.Constant const(k = 0) annotation(Placement(transformation(extent = {{-10,-10},{10,10}}, rotation = 180, origin = {-70,58})));

  Modelica.Blocks.Interfaces.RealInput f annotation(Placement(transformation(extent = {{-160,-80},{-120,-40}}), iconTransformation(extent = {{-140,-80},{-100,-40}})));

  Modelica.Mechanics.Rotational.Interfaces.Flange_a flange_a annotation(Placement(transformation(extent = {{108,68},{128,88}}), iconTransformation(extent = {{88,-10},{108,10}})));

  Modelica.Mechanics.Rotational.Sources.Torque torque annotation(Placement(transformation(extent = {{14,68},{34,88}})));

  Modelica.Mechanics.Rotational.Sensors.SpeedSensor Wm annotation(Placement(transformation(extent = {{-10,-10},{10,10}}, rotation = 270, origin = {72,60})));

  Modelica.Blocks.Nonlinear.Limiter limF(uMin = 0.000001, uMax = 1000000.0) annotation(Placement(transformation(extent = {{-112,-70},{-92,-50}})));

  Modelica.Electrical.QuasiStationary.SinglePhase.Sensors.PowerSensor Pag annotation(Placement(transformation(extent = {{54,8},{74,28}})));

  Modelica.Blocks.Sources.RealExpression WmS1(y = (3 * toPag.re) / W0) annotation(Placement(transformation(extent = {{-36,68},{-4,88}})));

  parameter Integer pp = 2 "pole pairs";

  parameter Real R1 = 0.435 "stator's phase resistance";

  parameter Real L1 = 0.004 "stator's leakage indctance";

  parameter Real Lm = 0.0693 "stator's leakage indctance";

  parameter Real R2 = 0.4 "rotor's phase resistance";

  parameter Real L2 = 0.002 "rotor's leakage indctance";

  parameter Real J = 2.0 "rotor's moment of inertia";

  Real W0;

  //velocità meccanica di sincronismo

  Real s;

  //scorrimento

  Modelica.Mechanics.Rotational.Components.Inertia inertia(J = J) annotation(Placement(transformation(extent = {{82,68},{102,88}})));

  Modelica.ComplexBlocks.ComplexMath.ComplexToReal toPag annotation(Placement(transformation(extent = {{-6,-6},{6,6}}, rotation = 270, origin = {46,-8})));

  Modelica.Electrical.QuasiStationary.SinglePhase.Basic.Ground ground annotation(Placement(transformation(extent = {{8,-38},{28,-18}})));

  Modelica.ComplexBlocks.ComplexMath.ComplexToReal toPin annotation(Placement(transformation(extent = {{-6,-6},{6,6}}, rotation = 270, origin = {-54,-10})));

  Modelica.Electrical.QuasiStationary.SinglePhase.Sensors.PowerSensor Pin annotation(Placement(transformation(extent = {{-56,8},{-36,28}})));

  Modelica.Blocks.Interfaces.RealOutput Pdc annotation(Placement(transformation(extent = {{-10,-10},{10,10}}, rotation = 270, origin = {-60,-110}), iconTransformation(extent = {{-10,-10},{10,10}}, rotation = 270, origin = {-70,-110})));

  Modelica.Electrical.QuasiStationary.SinglePhase.Sensors.CurrentSensor currentSensor annotation(Placement(transformation(extent = {{-10,10},{10,-10}}, rotation = 180, origin = {-6,-22})));

  Modelica.ComplexBlocks.ComplexMath.ComplexToPolar ToIPolar annotation(Placement(transformation(extent = {{-6,-6},{6,6}}, rotation = 270, origin = {56,-76})));

  Modelica.Blocks.Interfaces.RealOutput Iac annotation(Placement(transformation(extent = {{-10,-10},{10,10}}, rotation = 270, origin = {60,-110})));

  Modelica.Mechanics.Rotational.Sensors.PowerSensor PmGen annotation(Placement(transformation(extent = {{46,68},{66,88}})));

  Modelica.Blocks.Math.Gain toW1(k = 3) annotation(Placement(transformation(extent = {{-8,-8},{8,8}}, rotation = -90, origin = {-50,-80})));

equation

  W0 = (limF.y * 2 * PI) / pp;

  s = (W0 - Wm.w) / W0;

  Rmecc.R_ref = R2 / s;

  connect(R1_.pin_n,L1_.pin_p) annotation(Line(points = {{-12,18},{-8,18}}, color = {85,170,255}, smooth = Smooth.None));

  connect(L1_.pin_n,L2_.pin_p) annotation(Line(points = {{12,18},{26,18}}, color = {85,170,255}, smooth = Smooth.None));

  connect(Lm_.pin_p,L1_.pin_n) annotation(Line(points={{18,8},{18,18},{12,18}},   color = {85,170,255}, smooth = Smooth.None));

  connect(Rmecc.pin_n,Lm_.pin_n) annotation(Line(points={{90,-12},{90,-22},{18,

          -22},{18,-12}},                                                                        color = {85,170,255}, smooth = Smooth.None));

  connect(ToComplexUin.y,uTerminals.V) annotation(Line(points={{-59,84},{-40,84},

          {-40,40},{-100,40},{-100,2},{-82,2}},                                                                          color = {85,170,255}, smooth = Smooth.None));

  connect(ToComplexUin.len,U) annotation(Line(points = {{-82,90},{-100,90},{-100,60},{-140,60}}, color = {0,0,127}, smooth = Smooth.None));

  connect(const.y,ToComplexUin.phi) annotation(Line(points = {{-81,58},{-92,58},{-92,78},{-82,78}}, color = {0,0,127}, smooth = Smooth.None));

  connect(limF.u,f) annotation(Line(points = {{-114,-60},{-140,-60}}, color = {0,0,127}, smooth = Smooth.None));

  connect(uTerminals.f,limF.y) annotation(Line(points={{-82,-6},{-88,-6},{-88,

          -60},{-91,-60}},                                                                       color = {0,0,127}, smooth = Smooth.None));

  connect(Pag.currentP,L2_.pin_n) annotation(Line(points = {{54,18},{46,18}}, color = {85,170,255}, smooth = Smooth.None));

  connect(Pag.voltageP,Pag.currentP) annotation(Line(points = {{64,28},{54,28},{54,18}}, color = {85,170,255}, smooth = Smooth.None));

  connect(Pag.voltageN,Rmecc.pin_n) annotation(Line(points = {{64,8},{64,-22},{90,-22},{90,-12}}, color = {85,170,255}, smooth = Smooth.None));

  connect(WmS1.y,torque.tau) annotation(Line(points={{-2.4,78},{12,78}},   color = {0,0,127}, smooth = Smooth.None));

  connect(inertia.flange_b,flange_a) annotation(Line(points = {{102,78},{118,78}}, color = {0,0,0}, smooth = Smooth.None));

  connect(Pag.y,toPag.u) annotation(Line(points={{56,7},{46,7},{46,-0.8}},   color = {85,170,255}, smooth = Smooth.None));

  connect(Pag.currentN,Rmecc.pin_p) annotation(Line(points = {{74,18},{90,18},{90,8}}, color = {85,170,255}, smooth = Smooth.None));

  connect(ground.pin,Lm_.pin_n) annotation(Line(points={{18,-18},{18,-15},{18,

          -12},{18,-12}},                                                                       color = {85,170,255}, smooth = Smooth.None));

  connect(Pin.currentN,R1_.pin_p) annotation(Line(points = {{-36,18},{-32,18}}, color = {85,170,255}, smooth = Smooth.None));

  connect(Pin.currentP,uTerminals.pin_p) annotation(Line(points = {{-56,18},{-72,18},{-72,8}}, color = {85,170,255}, smooth = Smooth.None));

  connect(Pin.voltageP,Pin.currentP) annotation(Line(points = {{-46,28},{-56,28},{-56,18}}, color = {85,170,255}, smooth = Smooth.None));

  connect(Pin.y,toPin.u) annotation(Line(points={{-54,7},{-54,-2.8}},   color = {85,170,255}, smooth = Smooth.None));

  connect(Pin.voltageN,uTerminals.pin_n) annotation(Line(points = {{-46,8},{-46,0},{-26,0},{-26,-22},{-72,-22},{-72,-12}}, color = {85,170,255}, smooth = Smooth.None));

  connect(uTerminals.pin_n,currentSensor.pin_n) annotation(Line(points = {{-72,-12},{-72,-22},{-16,-22}}, color = {85,170,255}, smooth = Smooth.None));

  connect(currentSensor.pin_p,Rmecc.pin_n) annotation(Line(points = {{4,-22},{90,-22},{90,-12}}, color = {85,170,255}, smooth = Smooth.None));

  connect(ToIPolar.u,currentSensor.y) annotation(Line(points={{56,-68.8},{56,

          -50},{-6,-50},{-6,-33}},                                                                      color = {85,170,255}, smooth = Smooth.None));

  connect(ToIPolar.len,Iac) annotation(Line(points = {{59.6,-83.2},{60,-83.2},{60,-110}}, color = {0,0,127}, smooth = Smooth.None));

  connect(PmGen.flange_a,torque.flange) annotation(Line(points = {{46,78},{34,78}}, color = {0,0,0}, smooth = Smooth.None));

  connect(PmGen.flange_b,inertia.flange_a) annotation(Line(points = {{66,78},{82,78}}, color = {0,0,0}, smooth = Smooth.None));

  connect(Wm.flange,PmGen.flange_b) annotation(Line(points = {{72,70},{72,78},{66,78}}, color = {0,0,0}, smooth = Smooth.None));

  connect(toW1.u,toPin.re) annotation(Line(points = {{-50,-70.4},{-50,-17.2},{-50.4,-17.2}}, color = {0,0,127}, smooth = Smooth.None));

  connect(Pdc,toW1.y) annotation(Line(points = {{-60,-110},{-60,-88.8},{-50,-88.8}}, color = {0,0,127}, smooth = Smooth.None));

  annotation(Diagram(coordinateSystem(preserveAspectRatio = true, extent = {{-120,-100},{120,100}}), graphics={  Rectangle(extent = {{-80,34},{100,-36}}, lineColor = {255,0,0}, pattern = LinePattern.Dash)}), Icon(coordinateSystem(preserveAspectRatio = true, extent = {{-120,-100},{120,100}}), graphics={  Line(points = {{-100,60},{-48,32}}, color = {0,0,127}, smooth = Smooth.None),Line(points = {{-100,-60},{-48,-30}}, color = {0,0,127}, smooth = Smooth.None),Text(extent = {{-106,138},{106,112}}, lineColor = {0,0,127}, fillColor = {95,95,95},

            fillPattern =                                                                                                    FillPattern.Solid, textString = "%name"),Rectangle(extent = {{-42,66},{78,-54}}, lineColor = {0,0,0},

            fillPattern =                                                                                                    FillPattern.HorizontalCylinder, fillColor = {175,175,175}),Rectangle(extent = {{78,10},{98,-10}}, lineColor = {0,0,0},

            fillPattern =                                                                                                    FillPattern.HorizontalCylinder, fillColor = {95,95,95}),Rectangle(extent = {{-42,66},{-62,-54}}, lineColor = {0,0,0},

            fillPattern =                                                                                                    FillPattern.HorizontalCylinder, fillColor = {128,128,128}),Polygon(points = {{-54,-84},{-44,-84},{-14,-14},{36,-14},{66,-84},{76,-84},{76,-94},{-54,-94},{-54,-84}}, lineColor = {0,0,0}, fillColor = {0,0,0},

            fillPattern =                                                                                                    FillPattern.Solid)}), Documentation(info = "<html>

<p>This model models ans asynchronous machine based on a quasi-stationary approximation: the equivalent single-phase circuit.</p>

<p>This model is very fast and compact, and gives result with sufficient precision in most vehicular propulsion needs.</p>

</html>"),

    uses(Modelica(version="3.2")));

end QSAsma;

*** FILE PACKAGE.MO ***

within ;

encapsulated package EVQSPkg10 "Package per EV con modello QuasiStationary"

  import Modelica;

  import EVQSPkg = EVQSPkg10;

  model QSAsma

    import PI = Modelica.Constants.pi;

    Modelica.Electrical.QuasiStationary.SinglePhase.Basic.Inductor L1_(L = L1) annotation(Placement(transformation(extent = {{-8,8},{12,28}})));

    Modelica.Electrical.QuasiStationary.SinglePhase.Basic.Resistor R1_(R_ref = R1) annotation(Placement(transformation(extent = {{-32,8},{-12,28}})));

    Modelica.Electrical.QuasiStationary.SinglePhase.Basic.Inductor L2_(L = L2) annotation(Placement(transformation(extent = {{26,8},{46,28}})));

    Modelica.Electrical.QuasiStationary.SinglePhase.Basic.Inductor Lm_(L = Lm) annotation(Placement(transformation(extent = {{-10,-10},{10,10}}, rotation = 270, origin = {18,-2})));

    Modelica.Electrical.QuasiStationary.SinglePhase.Basic.VariableResistor Rmecc annotation(Placement(transformation(extent = {{-10,-10},{10,10}}, rotation = 270, origin = {90,-2})));

    Modelica.Electrical.QuasiStationary.SinglePhase.Sources.VariableVoltageSource

                                                                                  uTerminals annotation(Placement(transformation(extent = {{-10,10},{10,-10}}, rotation = 270, origin = {-72,-2})));

    Modelica.ComplexBlocks.ComplexMath.PolarToComplex ToComplexUin annotation(Placement(transformation(origin = {-70,84}, extent = {{-10,-10},{10,10}}, rotation = 0)));

    Modelica.Blocks.Interfaces.RealInput U annotation(Placement(transformation(extent = {{-160,40},{-120,80}}), iconTransformation(extent = {{-140,40},{-100,80}})));

    Modelica.Blocks.Sources.Constant const(k = 0) annotation(Placement(transformation(extent = {{-10,-10},{10,10}}, rotation = 180, origin = {-70,58})));

    Modelica.Blocks.Interfaces.RealInput f annotation(Placement(transformation(extent = {{-160,-80},{-120,-40}}), iconTransformation(extent = {{-140,-80},{-100,-40}})));

    Modelica.Mechanics.Rotational.Interfaces.Flange_a flange_a annotation(Placement(transformation(extent = {{108,68},{128,88}}), iconTransformation(extent = {{88,-10},{108,10}})));

    Modelica.Mechanics.Rotational.Sources.Torque torque annotation(Placement(transformation(extent = {{14,68},{34,88}})));

    Modelica.Mechanics.Rotational.Sensors.SpeedSensor Wm annotation(Placement(transformation(extent = {{-10,-10},{10,10}}, rotation = 270, origin = {72,60})));

    Modelica.Blocks.Nonlinear.Limiter limF(uMin = 0.000001, uMax = 1000000.0) annotation(Placement(transformation(extent = {{-112,-70},{-92,-50}})));

    Modelica.Electrical.QuasiStationary.SinglePhase.Sensors.PowerSensor Pag annotation(Placement(transformation(extent = {{54,8},{74,28}})));

    Modelica.Blocks.Sources.RealExpression WmS1(y = (3 * toPag.re) / W0) annotation(Placement(transformation(extent = {{-36,68},{-4,88}})));

    parameter Integer pp = 2 "pole pairs";

    parameter Real R1 = 0.435 "stator's phase resistance";

    parameter Real L1 = 0.004 "stator's leakage indctance";

    parameter Real Lm = 0.0693 "stator's leakage indctance";

    parameter Real R2 = 0.4 "rotor's phase resistance";

    parameter Real L2 = 0.002 "rotor's leakage indctance";

    parameter Real J = 2.0 "rotor's moment of inertia";

    Real W0;

    //velocità meccanica di sincronismo

    Real s;

    //scorrimento

    Modelica.Mechanics.Rotational.Components.Inertia inertia(J = J) annotation(Placement(transformation(extent = {{82,68},{102,88}})));

    Modelica.ComplexBlocks.ComplexMath.ComplexToReal toPag annotation(Placement(transformation(extent = {{-6,-6},{6,6}}, rotation = 270, origin = {46,-8})));

    Modelica.Electrical.QuasiStationary.SinglePhase.Basic.Ground ground annotation(Placement(transformation(extent = {{8,-38},{28,-18}})));

    Modelica.ComplexBlocks.ComplexMath.ComplexToReal toPin annotation(Placement(transformation(extent = {{-6,-6},{6,6}}, rotation = 270, origin = {-54,-10})));

    Modelica.Electrical.QuasiStationary.SinglePhase.Sensors.PowerSensor Pin annotation(Placement(transformation(extent = {{-56,8},{-36,28}})));

    Modelica.Blocks.Interfaces.RealOutput Pdc annotation(Placement(transformation(extent = {{-10,-10},{10,10}}, rotation = 270, origin = {-60,-110}), iconTransformation(extent = {{-10,-10},{10,10}}, rotation = 270, origin = {-70,-110})));

    Modelica.Electrical.QuasiStationary.SinglePhase.Sensors.CurrentSensor currentSensor annotation(Placement(transformation(extent = {{-10,10},{10,-10}}, rotation = 180, origin = {-6,-22})));

    Modelica.ComplexBlocks.ComplexMath.ComplexToPolar ToIPolar annotation(Placement(transformation(extent = {{-6,-6},{6,6}}, rotation = 270, origin = {56,-76})));

    Modelica.Blocks.Interfaces.RealOutput Iac annotation(Placement(transformation(extent = {{-10,-10},{10,10}}, rotation = 270, origin = {60,-110})));

    Modelica.Mechanics.Rotational.Sensors.PowerSensor PmGen annotation(Placement(transformation(extent = {{46,68},{66,88}})));

    Modelica.Blocks.Math.Gain toW1(k = 3) annotation(Placement(transformation(extent = {{-8,-8},{8,8}}, rotation = -90, origin = {-50,-80})));

  equation

    W0 = (limF.y * 2 * PI) / pp;

    s = (W0 - Wm.w) / W0;

    Rmecc.R_ref = R2 / s;

    connect(R1_.pin_n,L1_.pin_p) annotation(Line(points = {{-12,18},{-8,18}}, color = {85,170,255}, smooth = Smooth.None));

    connect(L1_.pin_n,L2_.pin_p) annotation(Line(points = {{12,18},{26,18}}, color = {85,170,255}, smooth = Smooth.None));

    connect(Lm_.pin_p,L1_.pin_n) annotation(Line(points = {{18,8},{18,18},{12,18}}, color = {85,170,255}, smooth = Smooth.None));

    connect(Rmecc.pin_n,Lm_.pin_n) annotation(Line(points = {{90,-12},{90,-22},{18,-22},{18,-12}}, color = {85,170,255}, smooth = Smooth.None));

    connect(ToComplexUin.y,uTerminals.V) annotation(Line(points = {{-59,84},{-40,84},{-40,40},{-100,40},{-100,2},{-82,2}}, color = {85,170,255}, smooth = Smooth.None));

    connect(ToComplexUin.len,U) annotation(Line(points = {{-82,90},{-100,90},{-100,60},{-140,60}}, color = {0,0,127}, smooth = Smooth.None));

    connect(const.y,ToComplexUin.phi) annotation(Line(points = {{-81,58},{-92,58},{-92,78},{-82,78}}, color = {0,0,127}, smooth = Smooth.None));

    connect(limF.u,f) annotation(Line(points = {{-114,-60},{-140,-60}}, color = {0,0,127}, smooth = Smooth.None));

    connect(uTerminals.f,limF.y) annotation(Line(points = {{-82,-6},{-88,-6},{-88,-60},{-91,-60}}, color = {0,0,127}, smooth = Smooth.None));

    connect(Pag.currentP,L2_.pin_n) annotation(Line(points = {{54,18},{46,18}}, color = {85,170,255}, smooth = Smooth.None));

    connect(Pag.voltageP,Pag.currentP) annotation(Line(points = {{64,28},{54,28},{54,18}}, color = {85,170,255}, smooth = Smooth.None));

    connect(Pag.voltageN,Rmecc.pin_n) annotation(Line(points = {{64,8},{64,-22},{90,-22},{90,-12}}, color = {85,170,255}, smooth = Smooth.None));

    connect(WmS1.y,torque.tau) annotation(Line(points = {{-2.4,78},{12,78}}, color = {0,0,127}, smooth = Smooth.None));

    connect(inertia.flange_b,flange_a) annotation(Line(points = {{102,78},{118,78}}, color = {0,0,0}, smooth = Smooth.None));

    connect(Pag.y,toPag.u) annotation(Line(points = {{56,7},{46,7},{46,-0.8}}, color = {85,170,255}, smooth = Smooth.None));

    connect(Pag.currentN,Rmecc.pin_p) annotation(Line(points = {{74,18},{90,18},{90,8}}, color = {85,170,255}, smooth = Smooth.None));

    connect(ground.pin,Lm_.pin_n) annotation(Line(points = {{18,-18},{18,-15},{18,-12},{18,-12}}, color = {85,170,255}, smooth = Smooth.None));

    connect(Pin.currentN,R1_.pin_p) annotation(Line(points = {{-36,18},{-32,18}}, color = {85,170,255}, smooth = Smooth.None));

    connect(Pin.currentP,uTerminals.pin_p) annotation(Line(points = {{-56,18},{-72,18},{-72,8}}, color = {85,170,255}, smooth = Smooth.None));

    connect(Pin.voltageP,Pin.currentP) annotation(Line(points = {{-46,28},{-56,28},{-56,18}}, color = {85,170,255}, smooth = Smooth.None));

    connect(Pin.y,toPin.u) annotation(Line(points = {{-54,7},{-54,-2.8}}, color = {85,170,255}, smooth = Smooth.None));

    connect(Pin.voltageN,uTerminals.pin_n) annotation(Line(points = {{-46,8},{-46,0},{-26,0},{-26,-22},{-72,-22},{-72,-12}}, color = {85,170,255}, smooth = Smooth.None));

    connect(uTerminals.pin_n,currentSensor.pin_n) annotation(Line(points = {{-72,-12},{-72,-22},{-16,-22}}, color = {85,170,255}, smooth = Smooth.None));

    connect(currentSensor.pin_p,Rmecc.pin_n) annotation(Line(points = {{4,-22},{90,-22},{90,-12}}, color = {85,170,255}, smooth = Smooth.None));

    connect(ToIPolar.u,currentSensor.y) annotation(Line(points = {{56,-68.8},{56,-50},{-6,-50},{-6,-33}}, color = {85,170,255}, smooth = Smooth.None));

    connect(ToIPolar.len,Iac) annotation(Line(points = {{59.6,-83.2},{60,-83.2},{60,-110}}, color = {0,0,127}, smooth = Smooth.None));

    connect(PmGen.flange_a,torque.flange) annotation(Line(points = {{46,78},{34,78}}, color = {0,0,0}, smooth = Smooth.None));

    connect(PmGen.flange_b,inertia.flange_a) annotation(Line(points = {{66,78},{82,78}}, color = {0,0,0}, smooth = Smooth.None));

    connect(Wm.flange,PmGen.flange_b) annotation(Line(points = {{72,70},{72,78},{66,78}}, color = {0,0,0}, smooth = Smooth.None));

    connect(toW1.u,toPin.re) annotation(Line(points = {{-50,-70.4},{-50,-17.2},{-50.4,-17.2}}, color = {0,0,127}, smooth = Smooth.None));

    connect(Pdc,toW1.y) annotation(Line(points = {{-60,-110},{-60,-88.8},{-50,-88.8}}, color = {0,0,127}, smooth = Smooth.None));

    annotation(Diagram(coordinateSystem(preserveAspectRatio = true, extent = {{-120,-100},{120,100}}), graphics = {Rectangle(extent=  {{-80,34},{100,-36}}, lineColor=  {255,0,0}, pattern=  LinePattern.Dash)}), Icon(coordinateSystem(preserveAspectRatio = true, extent = {{-120,-100},{120,100}}), graphics={  Line(points = {{-100,60},{-48,32}}, color = {0,0,127}, smooth = Smooth.None),Line(points = {{-100,-60},{-48,-30}}, color = {0,0,127}, smooth = Smooth.None),Text(extent = {{-106,138},{106,112}}, lineColor = {0,0,127}, fillColor = {95,95,95},

              fillPattern =                                                                                                    FillPattern.Solid, textString = "%name"),Rectangle(extent = {{-42,66},{78,-54}}, lineColor = {0,0,0},

              fillPattern =                                                                                                    FillPattern.HorizontalCylinder, fillColor = {175,175,175}),Rectangle(extent = {{78,10},{98,-10}}, lineColor = {0,0,0},

              fillPattern =                                                                                                    FillPattern.HorizontalCylinder, fillColor = {95,95,95}),Rectangle(extent = {{-42,66},{-62,-54}}, lineColor = {0,0,0},

              fillPattern =                                                                                                    FillPattern.HorizontalCylinder, fillColor = {128,128,128}),Polygon(points = {{-54,-84},{-44,-84},{-14,-14},{36,-14},{66,-84},{76,-84},{76,-94},{-54,-94},{-54,-84}}, lineColor = {0,0,0}, fillColor = {0,0,0},

              fillPattern =                                                                                                    FillPattern.Solid)}), Documentation(info = "<html>

<p>This model models ans asynchronous machine based on a quasi-stationary approximation: the equivalent single-phase circuit.</p>

<p>This model is very fast and compact, and gives result with sufficient precision in most vehicular propulsion needs.</p>

</html>"));

  end QSAsma;

  annotation(uses(Modelica(version = "3.2")));

end EVQSPkg10;

Thanks.
It  is easy and effective.
The when clause indeed opens to me a new world of  options and possibilities.
MC

I have a problem that should be easy but I could not solve.
I want to write a block  that receives x as input and creates y.

It should be:
     y =0                  up to when x > xMax for the first time
and:
     y=1                  after that.
It should be  y=1 even if later x is back below xMax.

Someone can help?

I checked and found that in compile.bat the 8th line was:
    set MINGW=%OPENMODELICAHOME%\MinGW

But my OPENMODELICAHOME environment variable is:
C:\Programmi\OpenModelica\

So I'd just to eliminate the final character (character "\") in the OPENMODELICAHOME environment variable.
After this simple modification everything is ok.
What is actually strange is that I never knew about this environment variable, that shoud therefore have been set by OM itself during installation!

Massimo

I've installed OM 1.8.0 (r 10584) for Windows in the folder:
c:\programmi\OpenModelica

I've tried to run a model that used to work correctly. The model name is:
   FrazAbbass.mo
It is located in the folder:
   C:\Documents and Settings\ceraolo\My Documents\OM\Working\4_Frazionat

When I run it  within OMEdit, I get the following error message:

Translation    10:43:56        0:0-0:0    Error building simulator. Buildlog: The system cannot find the path specified.
gcc  -O3 -falign-functions -msse2 -mfpmath=sse   -I"C:/Programmi/OpenModelica//include/omc" -I. -L"C:/Documents and Settings/ceraolo/My Documents/OM/Working/4_Frazionat"   -c -o FrazAbbass.o FrazAbbass.c
'gcc' is not recognized as an internal or external command,
operable program or batch file.
\MinGW\bin\mingw32-make: *** [FrazAbbass.o] Error 1

I looks like OM cannot find the gcc compiler, but I don't know how to fix this.

Any ideas?
Massimo

Sorry I wanted to cancel a previous post of mine by I was not able.
Therefore I just cancelled the contents of the message!

Apologies

Massimo

I've done as you suggested, but nothing changed.
Please, let me know it it is better for you that I make additional tests or just wait for the next builds.
(note that there is also a mispell in the error message: "transalation" instead of "translation")

Massimo

That is very good news.
This morning I've downloaded build 10304, eager to try the new additions.

I tried to run a file named "frazabbass.mo" that used to work very well on OM versions up to around 10200.

I got troubles related to difficulties of OM to find the compiler.

The message in Omedit is too long to display, and to see it fully needs to be copied and pasted in Notepad.
(this is a first issue I suggest you to evaluate)

The pasted message in Notepad is as follows

Transalation    09:27:53        0:0-0:0    Error building simulator. Buildlog: gcc  -O3 -falign-functions -msse2 -mfpmath=sse   -I"C:/OpenModelica1.8.0//include/omc" -I. -L"C:/Documents and Settings/Max/Documenti/OM/Working/4_Frazionat"   -c -o FrazAbbass.o FrazAbbass.c
"gcc" non Š riconosciuto come comando interno o esterno,
un programma eseguibile o un file batch.
\MinGW\bin\mingw32-make: *** [FrazAbbass.o] Error 1

The part in Italian language can be translated as follows:
"gcc" is not recognised as an internal or external command, an executable program of a batch file"

I've checked in the directory
C:\OpenModelica1.8.0\MinGW\bin

and found that the file gcc.exe is present there.

Massimo

Thanks a lot for this.
I downloaded yesterday a new version on the OM site, that I thought was final. Now I realize that , instead, it was named "test".
Massimo

Now that the "official" OM release 1.8.0 is available for Windows, is it possible to have also a binary release for Mac?
Thanks in advance.

Massimo

I see that in the bug tracker reports bugs date back up to 2006.
Are those old bugs still active?
In case they are not, what is the reason for not deleting them?

Thanks

Massimo

Is there, somewhere, any list of Modelica Standard Library examples that are not working in OM and users would gladly see functioning?
If so I have one such example:
the model     Modelica.Electrical.Analog.Examples.rectifier
does not run with OM 1.8 beta. After some thinking OMEdit says:

******************************************************
---- Error 1 : 09:48:04 ----
Unable to simulate the Model 'Modelica.Electrical.Analog.Examples.Rectifier'
Following Error has occurred.

Simulation execution failed for model: Modelica.Electrical.Analog.Examples.Rectifier
info    | Initialization of the current initial set of equations and initial guesses fails!
        | Try with better Initial guesses for the states.
Error in initialization. Storing results and exiting.
******************************************************

I don't feel like tampering with initial guesses, since that same model works immediately
in Dymola, and therefore the real issue probably is not actually there.

In case this model is made working, probably many more circuits wilth power electronics will work as well, and this would enlarge a lot the fields of effective usage of OM.
Massimo

In this OM beats Dymola! Indeed, if I submit your code to OM, it works; if I submit it to Dymola 2012 I get:

Error: Current version of Dymola cannot deduce indices for for-loops.

Your code modified in only the for statement as follows:
       for i in 1:nout loop

works in both environments

Massimo

The following very simple model does compile and run under Dymola, but OM (build 9599) says it is incorrect.
Which one is right?
Massimo


block Variable3Delay "Delay block with variable DelayTime"
  extends Modelica.Blocks.Interfaces.MIMO;
  parameter Real delayMax(min=0, start=1) "maximum delay time";
  Modelica.Blocks.Interfaces.RealInput delayTime       
equation
  y[:] = delay(u[:], delayTime, delayMax);
end Variable3Delay;

Ah, thanks.

Maybe in cases in which no initialization is set, it is a good idea to give parameters fixed values instead of starting ones, which might tbe confusing.
However, when things are clear (and now for me they are) this is just a minor glitch of some MSL components.

Massimo

I understand that a parameter in Modelica is a variable whose value does not vary during simulation.
However it is frequent done in Modelica Standart Library to see start expressions in parameter definition, such as:

Lmd(start=0.3/(2*pi*fsNominal))

in SM_PermanentMagnet.

If parameters must not change during simulation, why it is possible to set for them a start value instead of a fixed value?
I could not find an answer in the Modelica standard specifications.

MC

The following model runs perfectly with the OM nightly build I downlodaded August, 28th, but does not work with the version downloaded the 19th of September.

The error message I get in OMedit is:

---- Error 3 : 06:38:12 ----
Unable to simulate the Model 'RLD0'
Following Error has occurred.

Simulation failed for model: RLD0


The model is:

model RLD0
  Modelica.Electrical.Analog.Basic.Ground ground;
  Modelica.Electrical.Analog.Ideal.IdealDiode Diode(Ron = 1e-005, Goff = 0.001);
  Modelica.Electrical.Analog.Sources.SineVoltage sineVoltage(freqHz = 50, V = 10);
  Modelica.Electrical.Analog.Basic.Inductor inductor(L = 0.001);
  Modelica.Electrical.Analog.Basic.Resistor resistor1(R = 1);
equation
  connect(Diode.p,sineVoltage.p);
  connect(Diode.n,inductor.p);
  connect(resistor1.n,sineVoltage.n);
  connect(resistor1.p,inductor.n);
  connect(ground.p,sineVoltage.n);
end RLD0;

BTW, how can I retrive the build number from OM files?

When one runs a simulation from Omedit he does not know how it is going until when it has finished., since no information is available on the current simulated time.
This is an issue in case of lenghty simulations:
1) it is very difficult (or impossible) to estimate when the simulation ends
2) in case of an hanging simulation, the issue is not known and therefore the user will wait a very long time before resorting to kill the process

I'm posting this because I've not seen it in the "Omedit wish list" available in the OpenModelica site.

If someone asked me to tell a single improvement in OMEdit I would like to be made, I would certainly have mentioned this one.
I appreciarte a lot OMEdit author's efforts and the result of their work is wonderful already.
But I really miss the possibility of splitting rather large systems into several files, that is impeded that the absence of this feature.

I've studied the issue.
First comment: the Modelica Ideal diode code is very brillant. But it is difficult to understand for a human, let alone for parsing algorithms! OpenModelica parser get confused by this code, while Dymola's does not.
Second: the problem with diodes was indeed already known since it was reported as a bug (N. 1214). However we should not expect it to get solved soon, as it has already been on the site since a year ago and has not been assigned to anyone.
Third My example not only had an ideal diode, but also an ideal thyristor, that caused itself troubles.

Workarounds for my circuit:
1) use the diode model from the Modelica "Semiconductor" library.
2) use an IdealClosingSwitch in series with a diode in stead of the Ideal Thyristor

Using similar workarounds I deem that neaqrly any power electronics cicuit can be simulated with OpenModelica.

The simple circuit I've tried works well on Dymola and is faulty in OpenModelica.
The problem is that the current in inductor Lf drops suddenly to zero (at 0.6, 0,16, 0,26, etc. ms) and this is incorrect, and not even physically possible!
Exactly the same code works well within Dymola.
Since the circuit is very simple it may indicate a very basic issue of OpenModelica when used with power electronics.
If my outcomes are not wrong, they may indicate that OpenModelica 1.7 cannot be used for Power Electronics circuits.

Massimo

model Chopper



Modelica.Electrical.Analog.Sources.ConstantVoltage V1(V=100)

   annotation (

      Placement(transformation(

        extent={{-10,-10},{10,10}},

        rotation=270,

        origin={-72,12})));

Modelica.Electrical.Analog.Ideal.IdealGTOThyristor idealGTOThyristor

    annotation (Placement(transformation(

        extent={{-10,-10},{10,10}},

        rotation=270,

        origin={-32,50})));

Modelica.Electrical.Analog.Ideal.IdealDiode idealDiode

   annotation (Placement(

        transformation(

        extent={{-10,-10},{10,10}},

        rotation=90,

        origin={-32,-14})));

Modelica.Electrical.Analog.Basic.Resistor Rf(R=0.1)

   annotation (Placement(transformation(extent={{-18,6},{2,26}})));

Modelica.Electrical.Analog.Basic.Inductor Lf(L=10e-3, i(start=1))

   annotation (Placement(transformation(extent={{14,6},{34,26}})));

Modelica.Electrical.Analog.Basic.Capacitor Cf(C=100e-6, v(start=70))

   annotation (Placement(

        transformation(

        extent={{-10,-10},{10,10}},

        rotation=270,

        origin={44,-12})));

Modelica.Electrical.Analog.Basic.Resistor Load(R=30)

   annotation (Placement(

        transformation(

        extent={{-10,-10},{10,10}},

        rotation=270,

        origin={72,-8})));

Modelica.Blocks.Sources.SawTooth sawTooth(period=0.001,offset=0,startTime=0)

   annotation (Placement(

        transformation(

        extent={{-9,-9},{9,9}},

        rotation=180,

        origin={31,47})));

Modelica.Blocks.Logical.LessThreshold lessThreshold(threshold=0.8)

    annotation (Placement(transformation(

        extent={{-8,-8},{8,8}},

        rotation=180,

        origin={-2,46})));

Modelica.Electrical.Analog.Basic.Ground ground

    annotation (Placement(transformation(extent={{-82,-66},{-62,-46}})));

equation

  connect(idealDiode.n, idealGTOThyristor.n) annotation (Line(

      points={{-32,-4},{-32,40}},

      color={0,0,255},

      smooth=Smooth.None));

  connect(idealGTOThyristor.p, V1.p) annotation (Line(

      points={{-32,60},{-32,68},{-72,68},{-72,22}},

      color={0,0,255},

      smooth=Smooth.None));

  connect(V1.n, idealDiode.p) annotation (Line(

      points={{-72,2},{-72,-34},{-32,-34},{-32,-24}},

      color={0,0,255},

      smooth=Smooth.None));

  connect(Rf.p, idealDiode.n) annotation (Line(

      points={{-18,16},{-32,16},{-32,-4}},

      color={0,0,255},

      smooth=Smooth.None));

  connect(Lf.p, Rf.n) annotation (Line(

      points={{14,16},{2,16}},

      color={0,0,255},

      smooth=Smooth.None));

  connect(Cf.p, Lf.n) annotation (Line(

      points={{44,-2},{44,16},{34,16}},

      color={0,0,255},

      smooth=Smooth.None));

  connect(Cf.n, idealDiode.p) annotation (Line(

      points={{44,-22},{44,-34},{-32,-34},{-32,-24}},

      color={0,0,255},

      smooth=Smooth.None));

  connect(Load.p, Lf.n) annotation (Line(

      points={{72,2},{72,16},{34,16}},

      color={0,0,255},

      smooth=Smooth.None));

  connect(Load.n, Cf.n) annotation (Line(

      points={{72,-18},{72,-34},{44,-34},{44,-22}},

      color={0,0,255},

      smooth=Smooth.None));

  connect(lessThreshold.y, idealGTOThyristor.fire) annotation (Line(

      points={{-10.8,46},{-12,46},{-12,43},{-21,43}},

      color={255,0,255},

      smooth=Smooth.None));

  connect(sawTooth.y, lessThreshold.u) annotation (Line(

      points={{21.1,47},{16,47},{16,46},{7.6,46}},

      color={0,0,127},

      smooth=Smooth.None));

  connect(ground.p, V1.n) annotation (Line(

      points={{-72,-46},{-72,2}},

      color={0,0,255},

      smooth=Smooth.None));

  annotation (uses(Modelica(version="3.2")), Diagram(graphics),

    experiment(StopTime=0.005, NumberOfIntervals=2000),

    experimentSetupOutput);

end Chopper;