I want to get into modeling with modelica especially the thermial and fluid branches. So now I am reversing and altering examples from stackoverflow and the modelica library to get to know the language better.
At the moment I try to understand Modelica.Fluid.Examples.DrumBoiler.DrumBoiler. I have no problems to comprehend what the model does physically. But when I rebuilt it, I get the error message:
Function Cv.from_bar not found in scope DrumBoiler.
I rebuild the model from scratch and I copied the example from the library. Both the same problem.
The problem lies here:
Modelica.Fluid.Sources.FixedBoundary sink(
nPorts = 1,
p = Cv.from_bar(0.5), <-- problem
redeclare package Medium = Modelica.Media.Water.StandardWaterOnePhase,
T = 500)
In order to define the starting (?) pressure of the sink, a function is called. But the function was not defined anywhere. And yet the model works when I simulate it from the library, but it does not when I copy it from there.
What am I missing?
I am using OMedit.
The function is here: Modelica.SIunits.Conversions.from_bar. You can use import to import it, or import Cv = Modelica.SIunits.Conversions to import it under the shorter alias name Cv.
You can also read more about importing here:
https://mbe.modelica.university/components/packages/nimport
https://mbe.modelica.university/components/packages/importing
Related
I am interested to replace my own PID-regulator models with MSL/Blocks/Continuous/LimPID. The problem is that this model restricts limitations of output signals to be parameters and thus do not allow time-varying limits, which I need to have.
Studying the code I understand that the output limitation is created by a block MSL/Blocks/Nonlinear/Limiter and I just want to change this to the block VariableLimiter.
I can imagine that you need to ensure that changes of output-limitations vary in a time-scale slower than the regulator in order to not excite unwanted behaviour of the controller. Still here is a class of problems where it would be very useful to allow this limits to vary slowly.
Thanks for the good input to my question and below a very simple example to refine my question. (The LimPID is more complicated and I come back to that).
Let us instead just modify the block Add to a local block in MyModel.
I copy the code from Modelica.Blocks.Math.Add and call it Addb in MyModel. Since here is a dependence of Interfaces.SI2SO I need to make an import before the extends-clause. This import I take from the ordinary general MSL package, instead of copying also that in to MyModel. Then I introduce a new parameter "bias" and modify the equation. The annotation may need some update as well but we do not bother with that now.
MyModel
...
block Addb "Output the sum of the two inputs"
import Modelica.Blocks.Interfaces;
extends Interfaces.SI2SO;
parameter Real k1=+1 "Gain of input signal 1";
parameter Real k2=+1 "Gain of input signal 2";
parameter Real bias=0 "Bias term";
equation
y = k1*u1 + k2*u2 + bias;
annotation (...);
end Addb;
MyModel;
This code seems to work.
My added new question is whether it is enough to look up "extends-clauses" and other references to MSL and make the proper imports since the code is now local, or here are more aspects to think of? The LimPID code is rather complex with procedures for initialization etc so I just wonder if here is more to do than just bring in a number of import-clauses?
The models in Modelica Standard Library (MSL) should only be seen as exemplary models, not covering all possible applications. MSL is write protected and it is not possible to replace the limiter block in LimPID (and add max/min input connectors). Also, it wouldn't work out if you shared your simulation model with others, expecting their MSL to work like your modified MSL.
Personally, I have my own libraries of components where MSL models are inadequate. For example, I have PID controllers with variable limits, manual/automatic functions and many more functions which are needed in my applications.
Often, I create a copy of an MSL model, place it in the same package in my own library and make the necessary modifications and additions, e.g. MyLibrary.Blocks.Continuous.PID.
How can I fix this error for drumboiler example?
It's kind of hard to answer questions without the model code, but based on the error with Cv.from_bar my guess is that you copied some code containing that from MSL (Modelica Standard Library - shown to the left in your package browser) for the boiler.
The likely corrections are:
Replace Cv.from_bar by Modelica.Units.Conversions.from_bar in the parameter-dialog of some component (sink?).
In Modelica text for this model add import Cv=Modelica.Units.Conversions;
If the models aren't directly from MSL they may contain errors.
I'm making the interface package which can input the parameters of the models in the simulation loop.
To connect between the interface package and the simulation model, I used the Controlbus from the Standard Modelica Library Ver. 3.2.2.
Checking model was Okay, but if i simulate the model, the error like the picture below popped up.
And here's the equation related to this model
Omega_e = Omega_d * N_t[N];
Alpha_d = der(Omega_d);
To solve the differential equation, i think the solver need a specific parameter of N_t.
So i put the parameters from the interface model and sent the parameters using the Controlbus component in the Standard Modelica Library.
As in the picture above, i definitely put the parameters.
(Specific values of the parameters are deleted because it's a confidential)
I can't find what is the problem of this error.
Please help me guys.
Thank you very much.
Based on the incomplete model it's a bit tricky to say what happened, but:
Sending parameters through the control-bus (or a connector in general) is a bit complicated and not that encouraged.
It should be possible by declaring the "computed parameter" as parameter Integer N(fixed=false); initial equation N=myBus.N;, and don't have it as parameter in the connector.
If you don't declare it as parameter Dymola will try (and fail) to differentiate it.
If you declare it as parameter in the connector it will not be propagated (as connecting two parameters lead to an assertion).
I could declare a package or import a package in Modelica models, but I am not sure if there is any difference between them, I tried the following code, both of them work fine.
My question is :
Is there anything I should pay attention to when using these two methods?
partial model A
package SI1=Modelica.SIunits;
import SI2=Modelica.SIunits;
SI1.Voltage u1;
SI2.Voltage u2;
end A;
You are doing two fundamentally different things here, which both work for this case:
package SI1=Modelica.SIunits; is called a short class definition.
You create a new package named SI1, which inherits everything from Modelica.SIunits.
Short class definitions are basically the same as writing
package SI1
extends Modelica.SIunits;
end SI1;
See chapter 4.5.1 Short Class Definitions in the Modelica spec for details.
import SI2=Modelica.SIunits on the other hand simply influences where the Modelica tool looks for class definitions - so no new class is defined here. The chapter 13.2.1.1 Lookup of Imported Names explains that in the Modelica spec.
If you just want to use the package, import it. That's what import was designed for. Declaring a new package only makes sense if you want to add functionality or change anything (which is very limited though, if you are using the short class definition).
Only the import clause seems to trigger the lookup on a package that is not already loaded. Using for example the Modelica_LinearSystems2 library:
import: it checks, and Modelica_LinearSystems2 is loaded
partial model A
import ls2=Modelica_LinearSystems2;
end A;
package: it checks, but Modelica_LinearSystems2 is not loaded
partial model B
package ls=Modelica_LinearSystems2;
end B;
I guess that can break your models if not all of their dependencies are loaded when trying to simulate.
It is nevertheless interesting to see how Dymola (or even Modelica, since pedantic check doesn't throw any error) does not seem to care much about the use of package instead of import, when it comes to packages already loaded. I wasn't expecting the following model to work:
model C
package SI1=Modelica.SIunits;
SI1.Voltage u1;
parameter SI1.Current R=1;
equation
u1=2*R;
end C;
It turns out that even auto-completion (Ctrl+Space) works:
I am using some components from the Modelica Standard Library (MSL) in my simulations. These components each have some parameters. For example, Modelica.Fluid.Sources.MassFlowSource_T has a parameter m_flow. Usually, parameters can be changed between simulation runs without re-compilation. This is not the case for m_flow, because it has an annotation(Evaluate=true), so it is used for symbolic processing.
Is it possible to change the annotations of parameters at instantiation? I tried the following, but it didn't work.
Modelica.Fluid.Sources.MassFlowSource_T source2(
redeclare package Medium = Medium2,
nPorts=1,
m_flow=22.17 annotation(Evaluate=false));
Of course there are workarounds, like making a copy first and changing the annotation there or using use_m_flow_in=true and a constant source block.
As far as I know this is not possible with current Modelica Specification.
Some tools might support it if you extend MassFlowSource_T:
model MassFlowSource_T_2
extends Modelica.Fluid.Sources.MassFlowSource_T;
// declare m_flow here again with annotation(Evaluate=false);
end MassFlowSource_T_2;
use MassFlowSource_T_2 when you declare source2.
There is some work in progress to extend the way annotations are specified/handled
but it will be a while until it makes it into the Modelica Specification:
https://trac.modelica.org/Modelica/ticket/1293 (not open to the public yet).