Nothing has really changed, as long as there are no merge conflicts it's fine. You need to sign the CLA though, see your PR, otherwise it can't be merged.

Youth wrote:

Thanks for your kindly reply, perost.
I see that this issue is under fixing now on GitHub here:  https://github.com/OpenModelica/OpenModelica/pull/8506
Could you please tell me when this fix can be present in the nightly-build 1.19 - dev released?
Thanks again!

Hopefully soon, but I can't really give an accurate estimate. But it's a very high priority issue.

There's currently an issue on Windows, see this issue. Our library testing is done on Linux, so that's why it works there but not for you.

If you encounter an internal error then something has gone wrong in the compiler, since such errors are mostly just sanity checks and should never occur. The best way to report the problem is to open an issue on Github. We'll also need a model that can be used to replicate the issue in order to investigate it, any model that triggers this particular error is fine.

M in Modelica.Electrical.Analog.Basic.Transformer is declared as a parameter, which means it never changes during the simulation. So you can't use that model if you want to have a time-variant coupling inductance, but unfortunately I don't know if there exists any alternatives so you might have to implement your own.

This seems like a bug in the compiler, the model is valid as far as I can see. I opened a ticket for it, see #7767.

(Sorry for the late reply, I've been on vacation. It might be a while until I have time to look at this issue.)

Error 127 seems to mean "file not found". Since it only happens for certain models I guess it might be some external function using some resource that OM can't find? The complete compilation log would be very helpful to see.

In our regression testing the model compiles fine, but that's on Linux. Though I see that it doesn't simulate using the new frontend while it works with the old, so that's something we need to look into.

You're right, it should just be a warning when checking a model. I've changed it in PR 7532.

If you use the "Check All Models" button in OMEdit it'll check all nested models, including simple.A which would give the messages you get. The messages are not really an error as such, they just tell you that simple.A can't be simulated since it contain a top-level outer element and thus can only be used as part of another model (like simple.B in this case).

If you just want to check simple.B you can use the "Check Model" button instead with simple.B selected.

Arinomo23 wrote:

Hi perost,

Ok, i'll try it on the nightly build. But that means, I have to include the path to Library on OPENMODELICALIBRARY env variable? (i'm using window)

In OMEdit you can also add user libraries in Options->Libraries, or just put the libraries in one of the default paths (you should get a message saying which folders where searched if it can't find a library).

Loading model_1 also loads Lib_A for me, assuming the Library-folder is in the MODELICAPATH. But 1.14 is very old so it might be something that has been fixed since, I suggest you try the latest release instead.

For the modifiers you can remove the [:] parts since they're wrong and unnecessary. So instead of e.g. extraPropertiesNames[:]=fill("",0) it should just be extraPropertiesNames=fill("",0).

For the third error the issue is that Modelica does not allow subscripting generic expressions, only arrays. One solution is to store the result of readMatrix in an array, for example:

  parameter matrix[:,:] = readMatrix(fileName, tableName, dim[1], dim[2]);

equation

  u_min = matrix[1, 1];

  u_max = matrix[dim[1], 1];

The first error is because subscripted modifiers are not legal Modelica, i.e. something like

x(y[1] = 0)

is not allowed and needs to be rewritten so that it modifies the whole array instead. The other errors I can't say anything about without seeing the actual source code of the library.

OpenModelica doesn't really differentiate between class and model, since historically they've been pretty much the same thing. This has been changed in the specification recently though, by restricting class to only be allowed to contain class-definitions, annotations, and extends-clauses. class also has the property that anything can extend a class, while model is really only allowed to extend other models.

I don't think there are many situations where you would actually need to use class now, and the recommendation is to always use the most specialized type of class that you can. In other words, prefer to use model when something is an actual model.

JPG84 wrote:

The idea behind is that a connector could propagate all the data I need but failed.

It doesn't work like that, connections just create equations. The dimensions of an array needs to be specified directly or deduced from the arrays binding equation, it can't be deduced from a normal equation.

That looks like a pretty clear bug, please open a ticket on our bug tracker. If you can, please include a model that can be used to replicate the issue too.

You can use the outputFormat argument to simulate:

simulate(System, stopTime=20, outputFormat="csv");

Something like this should work:

model M

  import Medium = Modelica.Media.Air.MoistAir;

  Medium.BaseProperties medium;

end M;

You can't import the name Air.MoistAir though, because import requires a fully qualified name. I.e. you must give the full path to the name, so Modelica.Media.Air.MoistAir instead of Air.MoistAir.

x_sat is a protected member of MoistAir.BaseProperties, so you're not supposed or allowed to modify it. If you want to change the definition of x_sat you'd have to either make your own BaseProperties model or make one that extends from one of the existing BaseProperties, but I don't really know how Media is supposed to be used.

The modifier expression just needs to be a parameter expression, where the parameter in question is declared doesn't matter as long as it's accessible in the scope where the modification occurs.

The attributes in the builtin types are parameters, see the specification. So this works:

model M

  parameter Real s = 1.0;

  Real x(start = s);  // ok, s is a parameter expression

end M;

while this doesn't:

model M

  Real s = 1.0;

  Real x(start = s);  // s is continuous, not parameter

model M;

I'm afraid I'm not much of a modeler, so I can't give you an answer on which parts of the MSL you should use for your application. But for Fluid you usually need to redeclare the medium in the components you use, for example:

Modelica.Fluid.Pipes.StaticPipe pipe(redeclare package Medium = Modelica.Media.Air.MoistAir);



or 



package Medium = Modelica.Media.Air.MoistAir;

Modelica.Fluid.Pipes.StaticPipe pipe(redeclare package Medium = Medium);

The issue seems to be that there are different definitions of what a medium is. The Modelica.Media package in the MSL uses packages extended from Modelica.Media.InterfacesPartialMedium as medium, while Thermal instead uses records extended from Modelica.Thermal.FluidHeatFlow.Media.Medium. Same name, but very different things.

MoistAir is one of the medium packages in Media, so it's not meant to be used with Thermal. There are a couple of predefined mediums defined in Modelica.Thermal.FluidHeatFlow.Media that you can use:

Modelica.Thermal.FluidHeatFlow.Sources.Ambient amb(medium = Modelica.Thermal.FluidHeatFlow.Media.Air_30degC());

If you want to define your own medium you pretty much just extend from Medium and supply your own values:

record MyMedium

  extends Modelica.Thermal.FluidHeatFlow.Media.Medium(

    rho = 234,

    cp = 100,

    cv = 54,

    lambda = 0.54,

    nue = 94);

end MyMedium;



Modelica.Thermal.FluidHeatFlow.Sources.Ambient amb(medium = MyMedium());



or



MyMedium medium;

Modelica.Thermal.FluidHeatFlow.Sources.Ambient amb(medium = medium);



if you want to be able to use the same medium for multiple components

Like the error message says the array dimension must be defined at compile time, not by an equation system that's solved during initialization/simulation. So for example:

  model R1

    parameter Integer N = if iB then 3 else 1;

    parameter Boolean iB = true ;

  end R1;

We also have a Japanese translation of OMEdit which hasn't been updated for quite some time. See https://github.com/OpenModelica/OpenMod … ources/nls if you wish to contribute to it.

Modelica does not allow arrays with unknown size, except in functions. A variable with : dimensions must therefore have a binding equation, either in the declaration itself or from a modifier, that the compiler can use to deduce the size of the variable. For example:

model A

  Real x[:];

end A;



model B

  A a1; // Wrong, size of x can't be determined.

  A a2(x = {1, 2, 3}); // Ok, x has type Real[3].

end B;

The issue seems to be that you've forgotten to redeclare the Medium package in your tank component.

This does indeed look like a bug, but I can't reproduce it based on the code fragment you've given (I tried to extrapolate a complete model, but the model I ended up with worked just fine).

It looks like you're using an old nightly build, so you might want to try it with the latest nightly build in case the issue has already been fixed. Otherwise you can open a new ticket on our bug tracker, or just provide a complete model here that can be used to reproduce the issue.

jobehrendt wrote:

leeds to an error message
Component SS of variability parameter has binding 'DN1.S' of higher variability continuous.

That has nothing to do with partial. The error means that you're trying to give a parameter a continuous binding, like this:

model A

  parameter Real x;

end A;



model B

  Real y;

  extends A(x = y); // Not allowed.

end B;

The value of a parameter doesn't change during the simulation, so trying to give it a binding equation that can change is not allowed.

You can also call terminate() in the model if you want to terminate the simulation when a certain condition is fulfilled, rather than at a fixed time point.

This is a bug in the old frontend and shouldn't work, the old frontend doesn't handle inheritance correctly. The variable must be reachable in the scope where it's used, but y is not declared inside the include model. In other words, the name resolution is done in the scope where a variable is used, not the scope it's inherited into.

Since GTunitBase is a partial model you can't declare components of that type, i.e. you can't instantiate it. What you need to do is extend the model, and redeclare the needed bits:

model MyGTunitBase

  extends ThermoPower.Gas.BaseClasses.GTunitBase(

    redeclare package Air = Some.Air.Medium,

    redeclare package Fuel = Some.Fuel.Medium,

    etc...

  );

end MyGTunitBase;

However, are you sure you want to use GTunitBase? You probably won't be able to use the model like this without additional setup. You might be better of using the GTunit model instead, which already does this. If you want to configure the mediums used in GTunit you can still extend from it like shown above, or you can create a GTunit component since GTunit isn't partial:

model SomeModel

  ThermoPower.Gas.GTunit gtUnit1(redeclare package Air = Some.Air.Medium, etc..);

end SomeModel;

You might also want to look at the models in ThermoPower.Test, which contains examples of how the models can be used.

You must use arrays in that case, you can't construct variable names dynamically like that.

Well, the error says exactly what the issue is. The left hand side of the equation (V) is a Real, while the right hand side (expanded linspace expression) has type Real[n] (since linspace returns an array with n elements). I.e. you need to declare V to be an array if you want to use it in that way.

Note that you can't use n as the dimension of V, since dimensions must be parameter expressions. But you should probably declare n as a parameter anyway, since it shouldn't change during the simulation. Then you'll also have to change any variables that n depends on to be parameters too, which again is probably a good idea anyway.

Also "d_vec = V.*limits_d_max;" won't work with the code in your first post, since d_vec is neither Real nor an array. This is also true for many of your other variables, which are declared as scalars but used as arrays.

bele wrote:

as my value of n=512, I tried with
1) d_vec = linspace(x1, x2, n).*limits_d_max; ..................(with defining input n=512)
2) d_vec = linspace(x1, x2, 512).*limits_d_max;
3) d_vec = linspace(x1, x2, sqrt(22.62)).*limits_d_max;

still the error is same

Do you really get the same error with variant 2? 3 is of course not valid since sqrt returns a Real value, and 1 is still not valid if you haven't changed the declaration of n to be an Integer.

Here's a small example model that works:

model M

  Real x1 = 0;

  Real x2 = 1;

  Integer n = 512;

  Real vec[512];

equation

  vec = linspace(x1, x2, n);

end M;

Your variable n that you use as the last argument to linspace is a Real variable, but the last argument to linspace should be an Integer (since it represents the number of elements in the created array).

bele wrote:

input Real objects_p_0 = transpose({0,20},{0,10});

error: Wrong type or wrong number of arguments to transpose({0, 20}, {0, 10}).
(in component <NO COMPONENT>).

how can I solve this one?

transpose takes a single 2-dimensional array as input, you're trying to use it with two 1-dimensional arrays instead. You probably meant transpose({{0, 20}, {0, 10}}) (note the outer { }). And you need to declare objects_p_0 as an array too of course.

pravin wrote:

Yes. Thank you. But I am using OpenModelica 1.11 due to some compatibility issues for the library I am working on. Is it possible to update OMEdit to newer version and use OpenModelica 1.11?

No, it's not really OMEdit that needs to be updated but the compiler (omc). If you for some reason have to use OM 1.11 then you won't be able to use the new frontend, some OM 1.11 is far too old. I'd recommend trying to fix the issues with your library in that case though, rather than trying to work around old compiler bugs.

I assume you mean something like this:

model A

  outer parameter Integer n;

  Real x[n];

end A;



model M

  inner parameter Integer n = 2;

  A a;

end M;

It seems our current frontend has issues with this, but the new frontend handles it just fine. You can try using the new frontend by either enabling the "Enable experimental new instantiation phase" option in OMEdit->Tools->Simulation, or by setting the compiler flag "-d=newInst" if you use some other tool. If you use OMEdit and you don't have this option you might want to update to a newer version which has it, since the new frontend is constantly improved.

A vdi file is a VirtualBox Disk Image. To use it you just create a new virtual machine in VirtualBox, and select the vdi file when it asks you whether you want to create a new disk or use an existing image.

If you use an older version you can add the flag in the "Additional Translation Flags" field, but 1.13.0 is likely too old for the new frontend to work well. It looks like we have a VM image of OM 1.13.2 that's probably recent enough to work, but I'd recommend installing one of the nightly builds (Download->Nightly Builds at the top of this page) when using the new frontend since it's constantly improved.

This looks like some redeclare issue in the current frontend of OM. The model works using the new frontend though, which can be enabled by using the "-d=newInst" flag (in recent nightly builds you can also enable it with the "Enable experimental new instantiation phase" option under Tools->Options->Simulation in OMEdit).

The annotation is separate from the modifier, so it would look like this:

model Pump

  Modelica.Fluid.Machines.Pump pump1(redeclare package Medium = Modelica.Media.Water.StandardWater)

     annotation(Placement(visible = true, transformation(origin = {0, 0}, extent = {{-10, -10}, {10, 10}}, rotation = 0)));

equation



annotation(

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



end Pump; 

In other words, the syntax for a component is:

model M

  SomeType componentName(modifier1 = value, modifier2 = value, ...) annotation(...);

end M;

Adding

replaceable package Medium = Modelica.Media.Water.StandardWater;

to your model does nothing more than declare a new package called Medium, that's not used anywhere. What you want to do is redeclare the Medium inside the pump1 component via a modifier:

model pump

  Modelica.Fluid.Machines.Pump pump1(redeclare package Medium = Modelica.Media.Water.StandardWater);

end pump;

For Fluid models you also need to declare an inner system component that defines the properties and default values used:

model pump

  Modelica.Fluid.Machines.Pump pump1(redeclare package Medium = Modelica.Media.Water.StandardWater);

  inner Modelica.Fluid.System system;

end pump;

This model will flatten without errors, but won't simulate though. I assume that's because it makes no sense to simulate a pump by itself, it needs to be connected to something such that you get a complete fluid system.

DanField wrote:

So either I'm misunderstanding how to correctly reference the real Color and FillPattern types outside of graphical annotations or they just aren't available outside of the graphic annotation context.

It's the latter I'm afraid, see section 4.8.8.5 in the Modelica specification:

Graphical Annotation Types
A number of “predefined” record types and enumeration types for graphical annotations are described in Chapter 18. These types are not predefined in the usual sense since they cannot be referenced in ordinary Modelica code, only within annotations.

adeas wrote:

Unfortunately OpenModelica compiler is crashing hard on command "getComponents(FCSys.Conditions.Environment)". I have made a minimal example for testing

InstUtil.splitInnerAndOtherTplLstElementMod was some old code written in a non-tail recursive way, so it would cause a stack overflow on large inputs. I've fixed that particular issue by rewriting the function to use a for-loop instead, but unfortunately getComponents still segfault. It seems like the instantiation goes into a loop and runs out of stack, which is probably much harder to fix.

And even if that was fixed it doesn't look very good for FCsys on our coverage tests at the moment.

loadModel is a bit misnamed, a more accurate name would have been loadLibrary. That is to say, loadModel loads a library that can be found in the library path (e.g. loadModel(Modelica) will load the Modelica Standard Library). See the API documentation.

Anyway, most commands won't print any errors that occured, so you need to put getErrorString() after e.g. loadModel to get the actual reason for the failure.

fjld61 wrote:

Ok. Thanks: it appears to be installed ... I'm just wondering if it is the right thing to use since it is not maintained any longer.

Probably not, but it depends on what you want to do. If you just want to make models you should take a look at OMEdit instead.

Actually, Definitions is illegal since a type must always extend from a basic type, and models are not allowed to extend from a type either (but the compiler doesn't catch that). You should make Definitions a package instead, and either use the name directly or import Definitions.Species where needed.

Each flow-variable which is not connected as an inside connector will be set to 0. I.e. a model such as this:

model M

  connector C

    Real e;

    flow Real f;

  end C;



  C c;

end M;

will result in the flattened model:

class M

  Real c.e;

  Real c.f;

equation

  c.f = 0.0; // Automatically generated by the compiler because c.f is not connected to anything.

end M;

So writing the equations manually and using connect is not the same thing, because a connector is not considered to be connected to anything unless you actually use connect. Not using connect will usually introduce extra equations which makes the model unbalanced.

Yes, that's one of the main points of using Modelica, that you can create parts and connect them together. There's already a big standard library available that contains all the parts you list, see the Modelica library in OMEdit.

I'm not entirely sure what you want to accomplish (an example would be good), but maybe it's conditional components you're looking for? When you declare a component you can give it a condition that determines whether it's enabled or not:

model M

  RealInput x if some_condition;

end M;

some_condition should be a scalar Boolean parameter expression (i.e. a Boolean expression that can be evaluated at compile-time by the compiler). A conditional component (x in this case) may only be modified or used in a connection (not in normal equations), and if the condition is false it will be removed from the model along with any connections to it.

This means that you have an array modification that's not an array, like this:

Real x[3](start = 1.0);

The proper way of doing this is to use each, like this:

Real x[3](each start = 1.0);

This issue should be fixed in the latest nightly build now. These models were actually broken before my changes, because they only worked since the compiler were quietly dropping some modifiers. My latest fix should fix the issue the compiler had when it had to consider all modifiers, so hopefully the models should now work better than they did previously. I've also made some more fixes for the Buildings library today, so the next nightly build might work even better with Buildings.

Btw, we run automated test of Buildings each day, see this page for the latest status.

That is by design, the mof-file is only a partial representation of the intermediate model that is actually used by the compiler. It doesn't include types, only variables and functions.

Both of the equations work fine for me. I've fixed several issues with enumeration lately, so I would suggest you install the latest nightly build and see if it works for you.

Strictly speaking I don't think that either of the equations should work though. You should only be allowed to index an array dimension with the enumeration type it's declared with, but it seems we don't check that. But the most correct way should be:

Out[TComponent.Cost] = Out[TComponent.A:TComponent.C] * ComponentPrices;

What version of OM do you use? From what I can see this was fixed in r15501, almost two years ago.

The error is correct, const.k is a scalar, so of course you can't give it a vector as value. You need to make const a vector to make it work:

  Modelica.Blocks.Sources.Constant const[3](k = {-800,400,0});

You also need to change the first connect equation to connect the whole arrays:

  connect(const.y,force.force[1]);

Hi,

k is a scalar Real, {1000.0,0.0,0.0} is an array of type Real[3], so the types don't match. You need to give k a scalar binding, like k = 1000.0.

Pliskin wrote:

It would be really nice if there was a description on how variables and equations are counted and when variables are left out. But i guess there is no such thing right?!

Of course there is, it's part of the Modelica specification. See section 4.7 Balanced Models in the Modelica specification.

You probably want to use the +s flag to generate simulation code.

Sorry for taking so long, but the issue has now been fixed in revision 20241.

Because the issue was caused by the compiler not knowing the type of the component references v1 and v2 at one point, and this caused it to assign the wrong type later on. {2, 1} and {3, 2} are array literals and much easier to type.

Sanjay_Kamath wrote:

Can you tell me what caused this error?

The issue was that outerProduct was incorrectly typed in this case. Because of how the compiler is constructed this led to a situation where the compiler thought the types on both sides of the equation where different even though they were the same. Such cases are always compiler bugs, hence the error message.

Thank you for reporting this. It was quite easy to fix, so I've already fixed it. The fix should be in the next nightly build tomorrow.

Using time in the manner described in the chapter does not only not work in current Modelica (whatever that means, since Modelica is a language), but is actually forbidden. So there doesn't really seem to be any point in this page, since pretty much everything it says is wrong. I've created a ticket in our bug tracker here, hopefully someone will replace the page with something that's actually useful.

Sorry, no. Modelica does not have any constructs for renaming components. Perhaps you could explain what it is you're trying to do? There might be another solution.

Ok, I thought you wanted different blocks somehow. Then the question is when you want to change the parameter value, before building the simulation executable or after? I.e. do you want to be able to compile the model, simulate it, change the parameter, compile it again, etc. Or do you want to compile the model once, and then change the parameter between simulation without recompiling it?

Changing the parameter before simulation is trivial, just change Const itself. In that case you might as well just make Const a package and have A be a constant.

To change the parameter after compilation is a bit trickier, since inheritance probably won't work for large models. For example:

model Const

  parameter Real A = 2;

end Const;



model A

  extends Const;

end A;



model B

  extends Const;

end B;



model C

  A a;

  B b;

end C;

In this case a.A and b.A are different parameters, which both have to be changed in either the variable browser or the init-file. So there's no longer a single parameter that needs to be changed in this case. One solution is to define the parameter at the top level and then propagate it downwards as needed. A possibly more convenient method is to use inner/outer:

model M1

  outer parameter Real A;  // This is a reference to A higher up in the instance hierarchy.

end M1;



model M2

  inner parameter Real A = 3; // This is the actual definition of A.

  M1 m1;

end M2;

Ok, do you mean that you want to drag Const to Calc? That would create a new instance of Const in Calc, i.e.

model Calc

  Const c;

end Calc;

Then you could change the parameters of the instance c, and then use c.A in your Calc model. Inheritance doesn't seem necessary in this case, but you could also have Calc inherit from Const as in your example. Then you would modify the inherited Const like this:

model Calc

  extends Const(A = 4);

end Calc;

I don't think there's any way of doing that via the GUI though.

Exactly how are you changing the values between simulations? I just tried this in OMEdit by first simulating the model, then changing the parameter values in the variable browser and choosing re-simulate, and C changed as expected. This is pretty much the same as manually editing the init xml-file.

Thank you, I've created a bug ticket here. You can add yourself as Cc on the ticket if you wish to be notified when it's fixed. I'll take a look at it when I have some time, it's probably not hard to fix. Not sure if I will have time this week though.

Salman wrote:

the link to bug tracker is not working

Sorry, wrong syntax. The link has been fixed now.

This looks like a bug to me, the first output of singularValues has two dimensions but the compiler thinks it has one. The second error can be ignored, it's caused by the first one. Please open a ticket in our bug tracker about this. I get a similar but different error when I run the function through the latest version of the compiler, so please include information about what version of OM you're using and how you got this error.

JoakimSandin wrote:

Thanks! A ticket was sent and a few minutes later the 1.9.1 Beta2 (r19422) was uploaded and the problem was solved

Beta2 was actually uploaded 4 days ago I fixed the issue a week ago, and Beta2 was just conveniently released a couple of days later. But great, then I'll close the ticket.

Sure, just create a .mos-file with something like this in it (substitute names as appropriate):

loadModel(Library1);  // Load any libraries you need, e.g. Modelica, WW, etc.
loadModel(Library2);
loadFile("file.mo"); // Load the file with your model.
saveTotalSCode("model_total.mo", modelname); // Use saveTotalSCode to dump the model to model_total.mo.

Then run it through the OM compiler (omc.exe on Windows, omc on other platforms). If one of the calls fail they usually just return false, in that case you can put getErrorString(); after the failed call to see the error.

Ok, I can't actually see any issues with that code, so it might be that you've found a bug in the compiler. Could you tell me which libraries you are using? I assume that WW is the WasteWater library, but the version of WW linked from modelica.org seems to be a MSL 1.6 library, while your code looks like MSL 2.x.

If you know how to use mos-scripts you could use the saveTotalSCode("filename.mo", modelname) API call to make a total model dump of your model (i.e. a model with all it's dependencies in one file) and upload that to a new ticket on our bug tracker. Otherwise, just tell me the exact versions of the libraries you're using and I'll see if I can replicate the issue myself.

Hi Pliskin,

Yes, that's a really bad error message. The intended meaning seems to be that you're trying to modify an attribute of a builtin type that doesn't exist, e.g.:

Real x(foo = 4);  // foo doesn't exist in Real.

Would you be able to share a small model that gives this error message? I've already confirmed that I get this error message with a declaration as the one above, but you might have found some other case.

Cheers,
Per

It's because you have dots in your model name, i.e. WasteWater.ASM1.Interfaces.ASM1base, which is not allowed in Modelica. Either rename the model to something without dots, or enclose the name in single quotes. See the definition of IDENT in appendix B of the Modelica specification for more details on valid characters in model names.

I'm unfortunately not a modeler and can't tell you exactly how to fix your model, but I can try to explain how connectors work in Modelica. In Modelica you have the concept of outside and inside connectors. Outside connectors are connectors declared in the same scope as the connection (or in connectors in that scope), while inside connectors are declared in a non-connector component. For example:

connector Flange

  flow Real tau;

  Real theta;

end Flange;



model M1

  Flange f1;

end M1;



model M2

  M1 m1;

  Flange f2;

equation

  connect(m1.f1, f2); // m1.f1 is an inside connector because f1 is declared inside non-connector component m1, 

                      // f2 is an outside connector because it's declared in the same scope as this connect equation.

end M2;

Zero-equations are automatically generated for flow-variables in connector components which have not been connected as inside. In my example above you would get an equation "f2.tau = 0.0", because f2.tau has not been connected as inside, only outside. This is done to make sure that models are balanced, and if your model becomes unbalanced because of these extra equations it means that your model most likely has some issues. You probably need to remove the zero-equations you've added yourself for those flow-variables, and connect your motor to some other components to make it work correctly.

This feature was actually added to OMEdit just two days ago, so if you feel brave you can try the latest nightly build. It's still a work in progress, but it seems like it's already possible to change values of parameters in the plot view and resimulate without recompiling. Otherwise you can edit the init-file or use the override functionality as SKD suggested.

Also, you can use the +showAnnotations flag to have omc print out the annotations in the flat code, the default is to not print them.

Hi Markus,

It seems like we only generate asserts for constant or parameter arrays in connectors, which is wrong. Looks fairly easy to fix. I've opened a ticket here: https://trac.openmodelica.org/OpenModelica/ticket/2154 . You can add yourself as Cc if you wish to be notified when it's fixed.

Regards,
Per Östlund

alberich wrote:

Any idea why that doesn't work?

Yes, array subscripting and slicing for assignments were not implemented in the scripting environment. I have just committed a fix for that in r15725, so it should be available tomorrow in the nightly builds. If you find any further issues, please submit a ticket to our bug tracker.

Hi,

This is a known issue, see https://trac.openmodelica.org/OpenModelica/ticket/2089 .

/Per

Hi Stefan,

Thank you for reporting this, I've fixed it in revision 15242. If you find any more issues, please submit tickets to our bug tracker: https://trac.openmodelica.org/OpenModelica .

Or configure with --without-paradiseo if you don't care about OMOptim.

Hi Michael,

Unfortunately we don't fully support MSL 3.2 yet, which means that the Complex stuff isn't working yet. At the moment I don't know when support for Complex might be implemented.

Regards,
Per

Ok, I see. Unfortunately I don't really know how to solve this problem. Perhaps saying der(TotalInfected) = Incubating / IncubationTime would work? Remember that the model is simulated for a certain number of timesteps, so saying der(TotalInfected) = Incubating should integrate the number of incubating people. I'm a bit unsure about the division with IncubationTime though.

I get about 58 million infected people though, i.e. about half the population, which doesn't seem completely unreasonable. Hopefully someone who knows what they're doing can give you some better advice.

Hi Loni,

I tried to simulate your model, and it simulates just fine. The Incubating variable gives a nice bell curve, which seems about right to me. Could you perhaps be a bit more specific? What do you mean with "will not let me integrate". Do you get an error message from the compiler, or do you simply not get the result you were expecting?

I think the issue is mostly with calls where the first identifier is an instance, the last a function and one or more classes in between. Calling a function in this manner is actually a new feature introduced in the soon to be released Modelica 3.3 specification, even though Dymola has supported this for a long time. Calling a function via an instance without any other classes in between should work fine in OM.

Hi Florian,

The error message is correct, the wrapper instance does not contain a Container class so wrapper.Container.f cannot be found. I assume you meant to call wrapper.P.f() instead? Unfortunately that will also fail, since we currently have some issues with calling functions via instances. We are working of fixing that, but at the moment I cannot give an estimate when this might be fixed.

Hi Hans,

Your usage of reinit is not valid, since the variable being reinitialized must be of type Real. Unfortunately we don't check this yet. But I think the real problem is that reinit is not counted as one equation, since a state variable should already have another equation associated with it. So from PartialCompliant you get 6 unknown and 5 equations, and then you introduce 1 unknown and 1 equation in your model. So you need to also supply an equation for broken to make the model balanced.

Unfortunately I'm not a modeler, so I'm not sure how to solve this problem. Hopefully someone else will be able to help you with that.

Hi,

A new nightly build is now available which should fix your problems, download it here. Unfortunately I know nothing about MapleSim, so I can't help you there. Your model defines x and bPen twice though, which is illegal.

We had some issues with scalar operations on matrices. I've fixed those now, and your function now works as it should for me. I assume your using Windows, so I'll see if I can get a new nightly build up for you.

Hi again,

You say that you're using 1.8.1, but are you perhaps referring to the 1.8.1 beta? We actually released 1.8.1 yesterday, so you could try that version if you're not already using it. I fixed some issues with the sum operator between the 1.8.1 beta and the full 1.8.1 release that I think fixes your particular issues. You will run into other issues related to scalar exponents on arrays, but I'm looking into fixing those right now.

Hi,

I can't see anything obviously wrong with your function, so this is most likely a bug in the compiler. I tried your model myself with the latest development version, but got another error instead. I'll investigate this further tomorrow and get back to you with my findings. Which version of OpenModelica are you using, and how do you call the function?

Hi Lorenzo,

The class HelloWorld is a model, while simulate and plot are scripting commands to the OMC compiler. When you're using OMEdit, create a new model and put in the code for the HelloWorld class in the text view. Then simply press the Simulate button in OMEdit (looks like an arrow) to simulate the model. OMEdit will then switch to the plot mode, and you can choose which variables to plot.

You can also use OMShell by loading the model from a file with loadFile or something similar, and then executing the commands. But OMEdit is much more user friendly, so use that instead unless you have some reason to use OMShell.

Regards,
Per

Thank you for the patch, I have applied it to our trunk in revision 11042.

Hi,

While-loops are only available in algorithm sections in Modelica, since they make no sense in equation sections. What you probably want is a when-equation, i.e.

when h > 0 then

  t_dummy = time;

end when;

I'm not a modeler though, so I don't know if this is the best way of doing this. Perhaps someone else has some better ideas.

I don't know, but the message seems to imply that SimulationX has some limit on how many state variables you can have. Are you perhaps using a trial version of SimulationX? In that case it's probably a restriction built in that stops you from simulating large models without buying a license.

You have done nothing wrong, these warnings are because the Modelica Standard Library is missing the 'each' keyword where it should have been used. OMC will print a warning about this, but continue as if the 'each' keyword had in fact been used so that the MSL works. You can thus safely ignore these warnings, they are caused by the authors of the MSL and not you.

Hi,

I took a look at the FuelCellLib library, and if you look at the top package in FuelCellLib you will see some imports for inter and SI:

import inter = Modelica.Electrical.Analog.Interfaces;

import SI = Modelica.SIunits;

So inter is simply an alias for Modelica.Electrical.Analog.Interfaces while SI is an alias for Modelica.SIunits. You can just add those imports to the model and it should work, or replace inter and SI with their full paths.

RandomUniform does not exist in either the Modelica Standard Library or FuelCellLib though, so you will have to implement it yourself unless you can find an implementation of it. Based on the name I would guess that it's simply a uniform distribution PRNG. Modelica does not have any random generators built in, but you can write an external C function that calls rand or the PRNG of your choice quite easily.

Hi Georg,

I'm afraid that you are unlikely to get answers about the inner workings of Fluid on this forum, since most of us OM developers who read these forums are not ourselves modelers. You are probably better off contacting the Modelica association instead, which is responsible for the Modelica Standard Library.

Also, support for the Fluid library is still work in progress, and while you are welcome to try it out you will probably encounter problems with it. The only reason why we recently enabled it in OMEdit is that it no longer causes the compiler to crash Full support for Fluid is one of our main goals right now though, and at the moment we have about half of the example models working. Unfortunately it is very hard to estimate how much work is left until we can fully support Fluid, so I can't say when that will finally happen.

Ok, this is now fixed in r10589. Thank you for reporting this.

Ok, I only tested instantiation of the model and assumed that it worked. But it seems like there's some problem with checking it. I will look into the problem.

Hi Michael,

This bug was solved some time ago, so if you update to the latest release of OpenModelica it should work as intended.

Hi aido,

Thank you for reporting this, it turned out to be a small mistake in the compiler that caused it to allocate huge amounts of memory in some cases. I have fixed this in revision 10424.

I fixed the issue with that model in revision 10291, so when you update your OMC you should not get any errors or warnings for that model anymore.

Hi Christian,

I think you questions are answered in this thread.

Hi Javier,

I looked at your model, and I think that you can safely ignore that error message. The model still seems to instantiate properly, and you can even compile and simulate it. I have not investigated it much yet, but what is probably happening is that the compiler fails somewhere and instead tries something else that succeeds. In that case it should not print out an error message, but in this case it does so anyway. I will investigate this further and see if I can get rid of this issue.

Hi Javier,

I have fixed the issues with the cat operator in revision 10258, so your model works now with some slight modifications. The usage of divisionType1 in the modifier of bDivisions is illegal, you need to prefix it with the enumeration type name, i.e. MyType.divisionType1. Besides this it should work fine.

There are still some issues left though, since the compiler seems to give the same error if it fails on anything when evaluating the binding of aDivisions or bDivisions (such as not finding divisionType1). This will only give the wrong error message though, and correct code should still work.

Hi Yun,

I implemented a code generator for OMC that generates CUDA code for my masters thesis, but it is very experimental and limited in what it can do. It has also not been updated in over a year, and I doubt that it even compiles now. You can check it out from our SVN with

svn co https://openmodelica.org/svn/OpenModelica/branches/cuda_codegen

if you wish.

For something a bit more recent you should contact Kristian Stavåker, a PHD student here at PELAB that is currently working on a new CUDA backend for OMC. I'm not sure how far he has gotten yet, but you can contact him via e-mail at kristian.stavaker at liu.se.

This bug has now been fixed in revision 5419 of trunk.

edes wrote:

Code:

model C  

  function find

    input  Integer index;

    output Real value;       

    algorithm

    for j in labels loop

      if index == Integer(j) then value := werte[i]; end if;

    end for;

  end find;

  type labels = enumeration (one "1st", two "2nd");

  constant Real[labels] values := {1.1, 2.2};

  Real valueTwo = find(Integer(labels.two));

end C;  

The problem in this case is that enumerations as you have seen are not completely implemented yet. When the enumeration is used as the range in the for loop it is unfortunately converted into an integer range, which causes the Integer call to fail since Integer only works on enumerations. A workaround in this case would therefore be to remove the Integer call in the for loop, and just use the iterator as it is. The best solution would of course be to keep the iterator as an enumeration instead of converting it to an integer, but at the moment I can't say when that will fixed. I'll add it to our bug tracker though, so hopefully it will be fixed sometime in the near future.

Cheers,
Per