I have running a model with a block composed of several interfaces (thermal ports).
The dimension of the port is variable and sometime can be up to 20x20...
When I run the simulation, the calculation are performed (slowly) but the worst part is when the simulation is done and has to prepare all the data (results)..
In the list of the result there are 20x20 of each interface ! this take several minutes to appears.
I don't need to know the ports values and I want to hide it.
I tried this :
Modelica.Thermal.HeatTransfer.Interfaces.HeatPort_a F6[Nw, Nh] annotation(HideResult = true,
Placement(visible = true, transformation(origin = {120, -94}, extent = {{-10, -10}, {10, 10}}, rotation = 0), iconTransformation(origin = {150, 120}, extent = {{-10, -10}, {10, 10}}, rotation = 0)));
but it is still showing the result...
Also, I can't use "protected" as I need to access the port in a global model, but also to some variables of the block which are calculated.
Do you have any solution ?
Thanks for your help :)
HideResult annotation is exactly for this purpose.
I tried a minimal example in OpenModelica v1.19.2 and that works as expected.
model HideResult
Real public_var = 1;
Real hidden_var = 2 annotation(HideResult=true );
equation
end HideResult;
I guess your issue is related to the array definition of heat ports. You could instead apply the HideResult annotation to single variables inside the connector defintion.
That means, define you own connector class and apply the annotation there.
If you keep everything else unchanged (type and name of variables), your customized connector is 100% compatible.
Related
In the model that I am working on i have a Boolean of that controls the turn ON and OFF of a system, that means during simulation my system turns ON and OFF many times, so I want to calculate the frequency of the ON/OFF, does anyone have an idea, please
thank you
model Boolean_Test
Modelica.Blocks.Sources.BooleanPulse BooleanPulse(period = 20e-3, width = 20) annotation(
Placement(visible = true, transformation(origin = {-66, 6}, extent = {{-10, -10}, {10, 10}}, rotation = 0)));
Real counter(start=0); // Counter to count the number of sets and resets
Real frequency(start=0);
equation
when Modelica.Math.BooleanVectors.oneTrue([BooleanPulse.y,pre(BooleanPulse.y)]) then
counter =pre(counter)+1;
frequency=0.5*counter/time;
end when;
annotation(
uses(Modelica(version = "3.2.3")));
end Boolean_Test;
You can use the above example to achieve your objective. Here I use xor principle to sense the toggle in the boolen output (BooleanPulse.y). A similar idea can be implemented in your source code. The above code is a simple example where I used to validate the computed frequency. For me the computed is equal to frequency value defined in Modelica.Blocks.Sources.BooleanPulse
Just trying to simplify Akhil Nandan's answer a bit, could result in:
model Boolean_Test2
Modelica.Blocks.Sources.BooleanPulse BooleanPulse(period = 20e-3, width = 20) annotation (
Placement(visible = true, transformation(origin = {-66, 6}, extent = {{-10, -10}, {10, 10}}, rotation = 0)));
Real counter(start=0); // Counter to count the number of sets and resets
Real frequency(start=0);
equation
when BooleanPulse.y then
counter =pre(counter)+1;
frequency=counter/(max(time,1e-6));
end when;
annotation(uses(Modelica(version="4.0.0")));
end Boolean_Test2;
To calculate the boolean frequency (F) where ON is the boolean in my model, I used the following model:
when ON and ON <> pre(ON) then
F=pre(ON)+1;
end when;
In Open Modelica Fluid Environment, I´m seeing the Error
"Medium is partial, name lookup is not allowed in partial classes." Which is commonly solved properly defining the media in each element.
I followed the related instruction of the post (How to specify medium in Openmodelica?) Namely I have redeclared the medium in each component of my system but still get this error when I try to simulate, although the check went through just fine.
Now this error is referenced to the Interfaces file, specificaly the line:
"stream Medium.ExtraProperty C_outflow[Medium.nC] "Properties c_i/m close to the connection point if m_flow < 0"; "
Do you understand why this still happens? I guess this C_outflow refers to concentration or other specific property of fluid. However I haven´t set any particular property. I tried turning false the allowFlowReversal option in order to not have m_flow < 0 but it didn´t help.
Do you have any ideas of how to solve this issue? I´d appreciate any help from this dear community.
Here my model code with the first element as an example. Many thanks in advance.
model ####
replaceable package Medium = Modelica.Media.Water.StandardWaterOnePhase constrainedby Modelica.Media.Interfaces.PartialMedium; parameter Real D_p = 0.0254; //Normal Diameter of pipe
Modelica.Fluid.Vessels.ClosedVolume Tank1(redeclare package Medium = Medium, V = 0.05, nPorts = 2 ) annotation( Placement(visible = true, transformation(origin = {-2, 46}, extent = {{-10, -10}, {10, 10}}, rotation = 0))); ...
In Dymola, after plotting the result, how could I smooth the curve?
I don't know a way of doing it in the plot window, but smoothing a curve could be done in multiple ways. You have to be aware that you are manipulating the actual simulation result with that.
I would recommend using a filter yourself and just create a smoothed signal without influencing the actual simulation. I made a small sample model with an original and filtered signal using a Butterworth filter from the MSL.
I just copied and modified an example slightly, please disregard most of the inline comments. You have to fiddle a bit with the f_cut such that it cuts the correct high frequencies for your case.
model FilterTest "Demonstrates the Continuous.Filter block with various options"
extends Modelica.Icons.Example;
Real original = add.y;
Real filtered = Butterworth.y;
protected
parameter Integer order=3;
parameter Modelica.SIunits.Frequency f_cut=2;
parameter Modelica.Blocks.Types.FilterType filterType=Modelica.Blocks.Types.FilterType.LowPass
"Type of filter (LowPass/HighPass)";
parameter Modelica.Blocks.Types.Init init=Modelica.Blocks.Types.Init.SteadyState
"Type of initialization (no init/steady state/initial state/initial output)";
parameter Boolean normalized=true;
Modelica.Blocks.Continuous.Filter Butterworth(
analogFilter = Modelica.Blocks.Types.AnalogFilter.Butterworth,
f_cut= 100,
f_min=1,
filterType=Modelica.Blocks.Types.FilterType.LowPass, gain = 1,
init=init,normalized=normalized,
order=order)
annotation (Placement(visible = true, transformation(extent = {{38, 18}, {58, 38}}, rotation = 0)));
Modelica.Blocks.Sources.Sine sineHigh(freqHz = 200) annotation(
Placement(visible = true, transformation(origin = {-62, 54}, extent = {{-10, -10}, {10, 10}}, rotation = 0)));
Modelica.Blocks.Sources.Sine sineLow(amplitude = 10, freqHz = 3) annotation(
Placement(visible = true, transformation(origin = {-56, 2}, extent = {{-10, -10}, {10, 10}}, rotation = 0)));
Modelica.Blocks.Math.Add add annotation(
Placement(visible = true, transformation(origin = {-8, 28}, extent = {{-10, -10}, {10, 10}}, rotation = 0)));
equation
connect(add.u1, sineHigh.y) annotation(
Line(points = {{-20, 34}, {-20, 55}, {-51, 55}, {-51, 54}}, color = {0, 0, 127}));
connect(add.u2, sineLow.y) annotation(
Line(points = {{-20, 22}, {-33.5, 22}, {-33.5, 2}, {-45, 2}}, color = {0, 0, 127}));
connect(Butterworth.u, add.y) annotation(
Line(points = {{36, 28}, {3, 28}}, color = {0, 0, 127}));
annotation(
experiment(StopTime = 0.9),
Documentation(info = "<html>
<p>
This example demonstrates various options of the
Filter block.
A step input starts at 0.1 s with an offset of 0.1, in order to demonstrate
the initialization options. This step input drives 4 filter blocks that
have identical parameters, with the only exception of the used analog filter type
(CriticalDamping, Bessel, Butterworth, Chebyshev of type I). All the main options
can be set via parameters and are then applied to all the 4 filters.
The default setting uses low pass filters of order 3 with a cut-off frequency of
2 Hz resulting in the following outputs:
</p>
<img src=\"modelica://Modelica/Resources/Images/Blocks/Filter1.png\"
alt=\"Filter1.png\">
</html>"),
uses(Modelica(version = "3.2.2")));
end FilterTest;
The plot windows in Dymola feature some signal operators, which you can use for post processing. But they do not feature a smoothing function.
If you want to do it in Dymola, the easiest option is to continuously compute the averaged values during the simulation, like kabdelhak suggested.
An alternative would be to apply signal processing filters in Matlab or in Python on the .mat result file created by Dymola.
I personally find it easier to express the 'amount' of filtering in terms of a time constant than a cutoff frequency.
If you don't want to mind writing a couple of lines of code you could write the equation of a first-order filter to achieve something similar to the answer of kabdelhak, i.e.
model Preheater_Model_Validation
Modelica.SIunits.MassFlowRate m_flow_filtered;
parameter Modelica.SIunits.Time tau=120 "filter time constant" annotation(Evaluate=false);
... (other declarations)
initial equation
der(m_flow_filtered) = 0 "steady-state initialization";
equation
tau*der(m_flow_filtered) = hex.summary.m_flow_in - m_flow_filtered;
end Preheater_Model_Validation;
The Evaluate=false annotation in the code means that you can tweak the time constant in the 'Variable browser' in Dymola without re-translating the code.
Best regards
Rene Just Nielsen
How do I define relations between multiple parameters in such a way that I can choose which parameters from the set to define, some equations defining the rest?
For example, I have a model with 3 parameters for the radius, height and volume of a cylinder, and they are related via the equation for volume V=r^2*h.
I want to be able to choose on model instantiation if I define r and h (and V is computed), r, V (and h is computed), or h, V (and r is computed).
In the following minimal example, I have tried the approaches 1-3, but none does what I need. I got the feeling that this has to be a common/solved problem, and I am just missing a certain modelling technique. Can you help?
model test_params "Model for a cylinder"
model Cylinder
parameter Real r;
parameter Real h;
parameter Real V;
//Approach 3: binding equation. Works, but what to do if I have V, h and want to know r??
//parameter Real V=r^2*Modelica.Constants.pi*h;
Real t;
initial equation
//Approach 2, apparently chooses V as 0 before getting to the initialisation equation
//V=r^2*Modelica.Constants.pi*h;
//Parameter cylinder.V has no value, and is fixed during initialization (fixed=true), using available start value (start=0.0) as default value.
// The initial conditions are over specified. The following 1 initial equations are redundant, so they are removed from the initialization sytem:
// cylinder.V = 3.141592653589793 * cylinder.r ^ 2.0 * cylinder.h.
equation
t = V;
// Approach 1
//V=r^2*Modelica.Constants.pi*h; //Leads to: Too many equations, over-determined system.
end Cylinder;
test_params.Cylinder cylinder(h = 1, r = 2) annotation(
Placement(visible = true, transformation(origin = {-44, 30}, extent = {{-10, -10}, {10, 10}}, rotation = 0)));
equation
end test_params;
This is on OpenModelica 1.14, if that should be relevant.
This can be done using your mentioned approach 2 if you set the dependent parameter as fixed=false parameter.
model TestParams "Model for a cylinder"
encapsulated model Cylinder
import Modelica.Constants.pi;
parameter Real r;
parameter Real h;
parameter Real V;
initial equation
V = r^2*pi*h "Cylinder volume";
end Cylinder;
TestParams.Cylinder cylinder_1(h=1, r=2, V(fixed=false)) "Compute cylinder V(h, r)"
annotation (Placement(transformation(origin={-70,50}, extent={{-10,-10},{10,10}})));
TestParams.Cylinder cylinder_2(h(start=0, fixed=false), r=2, V=13) "Compute cylinder h(r, V)"
annotation (Placement(transformation(origin={-30,50}, extent={{-10,-10},{10,10}})));
TestParams.Cylinder cylinder_3(h=1, r(start=0, fixed=false), V=13) "Compute cylinder r(h, V)"
annotation (Placement(transformation(origin={10,50}, extent={{-10,-10},{10,10}})));
end TestParams;
I would propose, in order to have a graphical selection, something similar to:
package test_params2 "Model for a cylinder"
type InputChoice = enumeration(rh,rv,hv);
model Cylinder
parameter InputChoice choice;
parameter Real r;
parameter Real h;
parameter Real v;
Real R,H,V;
equation
if choice==InputChoice.rh then
R=r;
H=h;
elseif choice==InputChoice.rv then
R=r;
V=v;
else
H=h;
V=v;
end if;
V=R^2*Modelica.Constants.pi*H;
end Cylinder;
model test_params
Cylinder cylinder(choice = test_params2.InputChoice.rh,h=1,r=2, v = 30) annotation(
Placement(visible = true, transformation(origin = {-44, 30}, extent = {{-10, -10}, {10, 10}}, rotation = 0)));
end test_params;
end test_params2;
I am creating a library for System Dynamics modeling which unlike the existing free library by Cellier is making use of acausal connectors. For "Flow" - Elements I have a GenericFlow class that defines the interfaces:
partial model GenericFlow "Flow Template with replaceable ports"
replaceable FlowPort portA "Flow from/to Stock A";
replaceable FlowPort portB "Flow to/from Stock B";
end GenericFlow;
The magenta colored FlowPort connectors are declared to be replaceable - the icon in System Modeler looks like this:
For some special cases I will use different ports, a connector called SpecialFlowPort that is visualized as a red square. To give an example, below is a class called Outflow which will redeclare the connector class used for one of its ports (i.e. portA):
model Outflow "Outflow from a stock"
extends Interfaces.GenericFlow(redeclare Interfaces.SpecialFlowPort portA);
[...]
end Outflow;
Its icon will automatically show the red colored SpecialFlowPort that has been exchanged for portA (on the left side):
But, when I use this component (drag & drop) in a new model, it will be shown with two magenta ports and on hovering over the ports System Modeler will give the class name as FlowPort - not SpecialFlowPort:
The behavior of the component is done correctly though and a connection of a magenta FlowPort port with the left port shown for Outflow is prohibited.
Am I doing something wrong? Why is the graphical annotation shown correctly for the class with the redeclared connector not shown upon its use in a model?
UPDATE:
Otto Tronarp from Wolfram MathCore correctly noted that the above example is not complete since I failed to include the graphical annotations (which often make code unreadable but are rather essential in this case).
So to give a SSCCE I will include his example here:
package ConnectorsTest
partial model GenericFlow "Flow Template with replaceable ports"
replaceable FlowPort portA "Flow from/to Stock A" annotation(Placement(visible = true, transformation(origin = {-66.537, 24.02}, extent = {{-10, -10}, {10, 10}}, rotation = 0), iconTransformation(origin = {-100, 0}, extent = {{-10, -10}, {10, 10}}, rotation = 0)));
replaceable FlowPort portB "Flow to/from Stock B" annotation(Placement(visible = true, transformation(origin = {110, 0}, extent = {{-10, -10}, {10, 10}}, rotation = 0), iconTransformation(origin = {100, -0}, extent = {{-10, -10}, {10, 10}}, rotation = 0)));
end GenericFlow;
model Outflow "Outflow from a stock"
extends GenericFlow(redeclare SpecialFlowPort portA);
end Outflow;
connector FlowPort
annotation(Icon(coordinateSystem(extent = {{-100, -100}, {100, 100}}, preserveAspectRatio = true, initialScale = 0.1, grid = {10, 10}), graphics = {Rectangle(visible = true, origin = {0, 5}, fillColor = {107, 255, 252}, fillPattern = FillPattern.Solid, extent = {{-50, -55}, {50, 55}})}));
end FlowPort;
connector SpecialFlowPort
annotation(Icon(coordinateSystem(extent = {{-100, -100}, {100, 100}}, preserveAspectRatio = true, initialScale = 0.1, grid = {10, 10}), graphics = {Rectangle(visible = true, origin = {0, 5}, fillColor = {246, 114, 123}, fillPattern = FillPattern.Solid, extent = {{-50, -55}, {50, 55}})}));
end SpecialFlowPort;
end ConnectorsTest;
Using the class Outflow as defined in this package in a model diagram in WSM 4.3 will show false graphical annotations (e.g. two green instead of one red and one green connector).
People from Wolfram MatheCore on Wolfram Community posted that this is an issue pertaining to Wolfram System Modeler up to Version 5.1:
Thank you very much for this report. It does indeed seem like Model Center does not properly render redeclared connectors inside components. It is something we will look into.
As a work-around you could create multiple versions of your component
class with different set of connectors, and make the instances of the
component class replaceable. Not sure if this would be an acceptable
work-around for you, but it should work.