In Modelica, how to call a variable in a different block without wiring the 2 blocks? - modelica

We are modeling various industrial component blocks, with each having CAPEX, labour cost, maintenance cost, total OPEX, etc. We would like to have 1 block, in the best case not wired to the other blocks, to account for the total OPEX, total CAPEX, total labour costs, etc. induced by the blocks present in a model : the number of blocks is not fixed. Is there a way of not connecting the blocks with a wire ?
In case there is no way, we found the solution of using the RealOutput y vector, as defined in Modelica.Blocks.Interfaces.MO : nout is defined as the number of actual variables we would like to add up (e.g. if CAPEX, OPEX and maintenance are of interest, then nout = n = 3). However, we struggle for 2 points :
How can we pass a matrix through this RealOutput ? This would be useful for instance when the CAPEX has 3 values : estimated, optimistic and pessimistic.
How can we take up this y in only 1 block ? For now we managed to use n Modelica.Blocks.Math.MultiSum blocks to take up each variable separately, but is there a way of adding them up respectively, but in the same block ?
Thank you already for your much appreciated help and answers !

I think you should be able to do this with the inner/outer construct and a custom connector with a flow variable for, e.g., your capex, as demonstrated in section 5.8 of Fritzson's book "Principles of Object-Oriented Modeling and Simulation with Modelica 3.3".
I could have sworn there is already an example around that sums masses of components to a total, but I could not find it anywhere...
package SO_69945088
model System
FinancialAggregator fin_totals() "Collects financial info";
inner CapexConn common_connection "autoshared connection";
Component comp1(capex_info.amount={0, 3, 5});
Component comp2(capex_info.amount={1, 10, 12});
Component comp3(capex_info.amount={5, 6, 7});
equation
//Conveniently collect financial info in fin_totals
connect(common_connection, fin_totals.agg_conn);
end System;
connector CapexConn
// the amount being a "flow" variables means all contributions
// sum at a connection point.
flow Real[3] amount;
// every "flow" variable should have a non-flow variable,
// at least for "physical" connections. Let's add a dummy:
Real [3] period;
end CapexConn;
model CapexEmitter
CapexConn conn;
Real[3] amount = fill(0, 3);
Real[3] period;
equation
// Here you could also have more logic, like computing emitted capex
// depending on the period
conn.amount = -amount; //negative because of sign of flow direction in connectors
conn.period = period;
end CapexEmitter;
model Component "Industrial component block with capex tracking"
// (you would extend your other components from this to use it)
outer CapexConn common_connection; // make outside connection visible
CapexEmitter capex_info;
equation
// all Component instances automatically connect, without manual wiring
connect(capex_info.conn, common_connection);
end Component;
model FinancialAggregator
CapexConn agg_conn;
Real[3] capexsum;
Real period[3] = {1,1,1};
equation
capexsum = agg_conn.amount;
period = agg_conn.period;
end FinancialAggregator;
end SO_69945088;
Simulating System gives a fin_totals.capexsum of {6, 19, 24} (optimistic, estimated, pessimistic).
This should give you a starting point showing the principles.

Related

how to connect multi-dimensional components with multi-dimensional connectors in Modelica?

I tried to connect a 2-dimensional component array to a 1-dimensional component array including 1-dimensional connectors, but when checking the model, there is an error showing unmatched dimensions.
But I could connect a 1-dimensional component array to a component including 1-dimensional connectors,
So Why can't this work for multi-dimensional situations?
Did I do it wrong?
I checked the code, it seems I can't use
connect(tubeWall.port_b,surface.q_port);
but if I use the following code, it works fine.
for i in 1:x loop
for j in 1:y loop
connect(tubeWall[i].port_b[j], surface[i,j].q_port);
end for;
end for;
I did more test, here is the test code which worked fine:
model Unnamed
gain_1[3] gain_1_1
Modelica.Blocks.Sources.Sine[3,3] sine
Modelica.Blocks.Math.Cos[3,3] cos
equation
connect(sine.y, gain_1_1.u);
connect(gain_1_1.y, cos.u);
end Unnamed;
model gain_1
Modelica.Blocks.Math.Gain[3] gain
Modelica.Blocks.Interfaces.RealOutput[3] y
Modelica.Blocks.Interfaces.RealInput[3] u
equation
connect(gain.y, y)
connect(u, gain.u)
end gain_1;
Here is the screenshot of the connections:
So it seems the idea is right, but I am not sure why it doesn't work in my model. Hope someone could give a hint or direction of the unmatched error in my model.
Quoting Fritzon's Principles of object-oriented modeling and simulation with Modelica 3.3:
The connect contruct can be used to directly connect arrays of
connectors. For such array connections the following holds:
The array dimensions of the connected arrays of connectors must match
Each corresponding pair of elements is connected as a pair of scalar connectors
That is, referring to connect(tubeWall.port_b,surface.q_port);
it does not know which dimension of surface[:,:] goes to tubeWall[:] and which to port_b[:]
the for loop works, because you are taking over the task of connecting the pair of elements as scalar connectors
My suggestion for your modeling task is that you create an interface block to put between surface and tubeWall, in which you implement the element-wise connections the way they should be. The connection between surface and interface might then look like:
connect(surface, interface.surfacePort);
I played around to see if I can figure it out. Here three points that might bring you closer to a canonical answer on why there's a different behavior between physical connections (thermal, in your case) and signal connections (Real input/output, in your case):
Real input/output are causal, and declared differently than physical connectors
connector RealInput = input Real "'input Real' as connector" annotation (...);
connector PhysConnector
Real pt;
flow Real flw;
annotation (...);
end PhysConnector;
Real input/output look more like functions than connectors. I suppose the rule The array dimensions of the connected arrays of connectors must match does not apply/is not enforced for them. I can think of different reasons for this; two of them could be:
There's a general accepted framework to deal with tables, the same way the majority of us agree that looking at a geographical map the top-left corner is north-west. So the connections are sorted automatically according to the sequence: 1st dim, 2nd dim, 3rd dim,... Multidimensional physical connections on the other hand might represent all sorts of scenarios. Better leave the model designer the responsibility to build it up correctly
Real input/output generate one assignment instead of a set of equations, therefore they don't mess up too much with the sorting algorithms when figuring out the causality of the system
I tried eventually to test a standard connector with only a potential variable, to see if the problem was due to the two equations generated when also a flow variable is present. The flat Modelica shows there's only one equation generated (as expected), but still the connection matrix[:,:],array[:].array[:] is not allowed.
package MultidimConnections
connector RealConnector
Real r;
annotation(Icon(coordinateSystem(preserveAspectRatio=false)),Diagram(coordinateSystem(preserveAspectRatio=false)));
end RealConnector;
partial model RealInterface
RealConnector realConnector annotation(Placement(transformation(extent={{90,-10},{110,10}})));
annotation(Icon(coordinateSystem(preserveAspectRatio=false),graphics={Rectangle(extent={{-100,100},{100,-100}},lineColor={28,108,200},fillColor={170,213,255},fillPattern=FillPattern.None)}),Diagram(coordinateSystem(preserveAspectRatio=false)));
end RealInterface;
model Source
extends RealInterface;
parameter Real k = 0;
equation
k = realConnector.r;
annotation(Icon(coordinateSystem(preserveAspectRatio=false),graphics={Rectangle(extent={{-80,80},{80,-60}},lineColor={28,108,200},fillColor={151,226,75},fillPattern=FillPattern.Solid), Text(extent={{-100,-60},{100,-100}},lineColor={28,108,200},fillColor={151,226,75},fillPattern=FillPattern.Solid,textString="%name")}),Diagram(coordinateSystem(preserveAspectRatio=false)));
end Source;
model User
extends RealInterface;
Real double;
equation
double = 2*realConnector.r;
annotation(Icon(coordinateSystem(preserveAspectRatio=false), graphics={Rectangle(extent={{-80,80},{80,-60}},lineColor={28,108,200},fillColor={85,170,255},fillPattern=FillPattern.Solid), Text(extent={{-100,-60},{100,-100}},lineColor={28,108,200},fillColor={85,170,255},fillPattern=FillPattern.Solid,textString="%name")}),Diagram(coordinateSystem(preserveAspectRatio=false)));
end User;
model User_multi
MultidimConnections.User user annotation(Placement(transformation(extent={{-10,40},{10,60}})));
MultidimConnections.User user1 annotation(Placement(transformation(extent={{-10,-10},{10,10}})));
MultidimConnections.User user2 annotation(Placement(transformation(extent={{-10,-60},{10,-40}})));
RealConnector realConnector[3] annotation(Placement(transformation(extent={{110,-10},{90,10}})));
equation
connect(user.realConnector, realConnector[1]) annotation(Line(points={{10,50},{98,50},{98,-6.66667},{100,-6.66667}}, color={0,0,0}));
connect(user1.realConnector, realConnector[2]) annotation(Line(points={{10,0},{98,0},{98,4.44089e-16},{100,4.44089e-16}}, color={0,0,0}));
connect(user2.realConnector, realConnector[3]) annotation(Line(points={{10,-50},{98,-50},{98,6.66667},{100,6.66667}}, color={0,0,0}));
annotation(Icon(coordinateSystem(preserveAspectRatio=false), graphics={Rectangle(extent={{-80,80},{80,40}},lineColor={28,108,200},fillColor={85,170,255},fillPattern=FillPattern.Solid),Text(extent={{-100,-60},{100,-100}},lineColor={28,108,200},fillColor={85,170,255},fillPattern=FillPattern.Solid,textString="%name"),Rectangle(extent={{-80,28},{80,-12}},lineColor={28,108,200},fillColor={85,170,255},fillPattern=FillPattern.Solid),Rectangle(extent={{-80,-20},{80,-60}},lineColor={28,108,200},fillColor={85,170,255},fillPattern=FillPattern.Solid),Rectangle(extent={{-100,100},{100,-102}}, lineColor={28,108,200})}),Diagram(coordinateSystem(preserveAspectRatio=false)));
end User_multi;
model TestCustomReal
extends Modelica.Icons.Example;
Source source(k=1) annotation(Placement(transformation(extent={{-60,40},{-40,60}})));
User user annotation(Placement(transformation(extent={{60,40},{40,60}})));
User_multi user_multi annotation(Placement(transformation(extent={{60,-10},{40,10}})));
Source source_arr[3](k=1) annotation(Placement(transformation(extent={{-60,-10},{-40,10}})));
User_multi user_multi_array[3] annotation(Placement(transformation(extent={{60,-60},{40,-40}})));
Source source_mat[3,3](k=1) annotation(Placement(transformation(extent={{-60,-60},{-40,-40}})));
equation
connect(source.realConnector, user.realConnector) annotation(Line(points={{-40,50},{40,50}}, color={0,0,0}));
connect(source_arr.realConnector, user_multi.realConnector) annotation(Line(points={{-40,0},{40,0}}, color={0,0,0}));
connect(source_mat.realConnector, user_multi_array.realConnector) annotation(Line(points={{-40,-50},{40,-50}}, color={0,0,0}));
end TestCustomReal;
annotation(uses(Modelica(version="3.2.3")));
end MultidimConnections;
The connect construct works only if the array dimensions match.
You could provide indices on the create connection window, to make the connection right between tubeWall and surface. which is exactly what the code is doing.
The model Unnammed works because gain_1_1.u is a connector with sizes [3,3]. If you change the size of the instance gain_1, you will see the difference.
Therefore you can either connect same size arrays or explicitly mention the indices during the connection.
Hope this helps.

Inversing the modelica simulation model: steady state model

I want to know if a model can be inversed in modelica. (here inverse means: if in causal statement y= x +a; x and a are input and y is output; but if I want to find 'x' as output and 'y' and 'a' as input, the model is called reversed/inversed model) For example, if I have compressor with input air port and output air port, and port has variables associated with it are pressure(P), temperature(T) and mass flow rate(mdot). I have simple steady state model containing three equations as follow:
OutPort.mdot = InPort.mdot
OutPort.P = rc * InPort.P
OutPort.T = InPort.T * (1 + rc[ (gamma-1)/gamma) - 1][/sup] / eta);
Here, rc, gamma and eta are compression ratio, ratio of specific heat capacitites and efficiency of compressor respectively.
I want to know, if I know values of : gamma, eta, OutPort.mdot, OutPort.P and OutPort.T and InPort.P and InPort.T, can I find the value of rc.
Can I find values of rc and how should be the model of compressor with above equation in Modelica. As far as I know, there are some variables designated as parameters which can not be changed during simulation. How the modelica model should be with above equations
Thanks
Yes, this should not be a problem as long as you make sure that rc is not a parameter, but a normal variable, and you supply the appropriate number of known quantities to achieve a balanced system (roughly, number of unknowns matches number of equations).
E.g. in your case if you know/supply OutPort.P and InPort.P, rc is already determined from eq 2. Then, in the third equation, there are no unknowns left, so either the temperature values are consistent with the equation or you (preferably) leave one temperature value undetermined.
In addition if you only want to compute the parameter rc during steady-state initialization i.e. that nothing changes with time that is also possible:
...
parameter Real rc(fixed=false);
initial equation
Inport.mdot=12; // Or something else indirectly determining rc.
The fixed=false means that rc is indirectly determined from the initialization. However, if the model is not completely stationary it will only find the correct rc during the initialization and then use that afterwards.

Simulink - Building custom components

I have one "Thermal Mass" block in Simulink, which represents a thermal mass, which is the ability of a material or combination of materials to store internal energy. In this standard block of Simulink, the initial temperature must be entered. Only one signal can be connected to the block. The source code of the block looks like following:
component mass
% Thermal Mass
% The block represents a thermal mass, which is the ability of a material
% or combination of materials to store internal energy. The property is
% characterized by mass of the material and its specific heat.
%
% The block has one thermal conserving port.
% The block positive direction is from its port towards the block. This
% means that the heat flow is positive if it flows into the block.
% Copyright 2005-2013 The MathWorks, Inc.
nodes
M = foundation.thermal.thermal; % :top
end
parameters
mass = { 1, 'kg' }; % Mass
sp_heat = { 447, 'J/(kg*K)' }; % Specific heat
end
variables
Q = { 0, 'J/s' }; % Heat flow
end
variables(Conversion=absolute)
T = { 300, 'K' }; % Temperature
end
function setup
% Parameter range checking
if mass <= 0
pm_error('simscape:GreaterThanZero','Mass')
end
if sp_heat <= 0
pm_error('simscape:GreaterThanZero','Specific heat')
end
end
branches
Q : M.Q -> *;
end
equations
T == M.T;
Q == mass * sp_heat * T.der;
assert(T>0, 'Temperature must be greater than absolute zero')
end
end
I would like to build another component, whose initial temperature can come from another block, so that it can be also calculated somewhere else. So, one input parameter and everything else should be the same. I am new to Simulink and don't know much about the domains. Any idea, how this can be done?
Thank you!
Parameters entered on a Simulink block are usually utilized for initial values and tuning of block behavior. While newer versions of Simulink will allow you to tune some parameters during simulation, others will be locked down and un-modifiable. This may mean that you need to first execute a model to calculate the initial value for your Thermal Mass, and then start up a second simulation using that temperature as an initial value.
I believe the Simulink help on how to control block parameters will be useful. Depending on the specific design of your model, different techniques found here may be more or less applicable, but generally speaking I know of 2 easy and simple ways to accomplish modifying a mask value.
Set the value to a variable in your Matlab base workspace.
Place the block inside a Masked subsystem. The mask can be used to define a variable that accessible to all the blocks inside it.
This is not possible, while you can execute some pre-processing to determine initial temperature you can not have this as an input from other blocks.
The workaround described by Jared is probably what you're looking for.
It's actually pretty rare to need to do this, if you tell us why you'r looking to set this up, we may be able to help.

Modelica - Modeling a slider element in OpenModelica

Rheological models are usually build using three (or four) basics elements, which are :
The spring (existing in Modelica.Mechanics.Translational.Components for example). Its equation is f = c * (s_rel - s_rel0);
The damper (dashpot) (also existing in Modelica.Mechanics.Translational.Components). Its equation is f = d * v_rel; for a linear damper, an could be easily modified to model a non-linear damper : f = d * v_rel^(1/n);
The slider, not existing (as far as I know) in this library... It's equation is abs(f)<= flim. Unfortunately, I don't really understand how I could write the corresponding Modelica model...
I think this model should extend Modelica.Mechanics.Translational.Interfaces.PartialCompliant, but the problem is that f (the force measured between flange_b and flange_a) should be modified only when it's greater than flim...
If the slider extends PartialCompliant, it means that it already follows the equations flange_b.f = f; and flange_a.f = -f;
Adding the equation f = if abs(f)>flim then sign(f)*flim else f; gives me an error "An independent subset of the model has imbalanced number of equations and variables", which I couldn't really explain, even if I understand that if abs(f)<=flim, the equation f = f is useless...
Actually, the slider element doesn't generate a new force (just like the spring does, depending on its strain, or just like the damper does, depending on its strain rate). The force is an input for the slider element, which is sometime modified (when this force becomes greater than the limit allowed by the element). That's why I don't really understand if I should define this force as an input or an output....
If you have any suggestion, I would greatly appreciate it ! Thanks
After the first two comments, I decided to add a picture that, I hope, will help you to understand the behaviour I'm trying to model.
On the left, you can see the four elements used to develop rheological models :
a : the spring
b : the linear damper (dashpot)
c : the non-linear damper
d : the slider
On the right, you can see the behaviour I'm trying to reproduce : a and b are two associations with springs and c and d are respectively the expected stress / strain curves. I'm trying to model the same behaviour, except that I'm thinking in terms of force and not stress. As i said in the comment to Marco's answer, the curve a reminds me the behaviour of a diode :
if the force applied to the component is less than the sliding limit, there is no relative displacement between the two flanges
if the force becomes greater than the sliding limit, the force transmitted by the system equals the limit and there is relative displacement between flanges
I can't be sure, but I suspect what you are really trying to model here is Coulomb friction (i.e. a constant force that always opposes the direction of motion). If so, there is already a component in the Modelica Standard Library, called MassWithStopAndFriction, that models that (and several other flavors of friction). The wrinkle is that it is bundled with inertia.
If you don't want the inertia effect it might be possible to set the inertia to zero. I suspect that could cause a singularity. One way you might be able to avoid the singularity is to "evaluate" the parameter (at least that is what it is called in Dymola when you set the Evaluate flat to be true in the command line). No promises whether that will work since it is model and tool dependent whether such a simplification can be properly handled.
If Coulomb friction is what you want and you really don't want inertia and the approach above doesn't work, let me know and I think I can create a simple model that will work (so long as you don't have inertia).
A few considerations:
- The force is not an input and neither an output, but it is just a relation that you add into the component in order to define how the force will be propagated between the two translational flanges of the component. When you deal with acausal connectors I think it is better to think about the degrees of freedom of your component instead of inputs and outputs. In this case you have two connectors and independently at which one of the two frames you will recieve informations about the force, the equation you implement will define how that information will be propagated to the other frame.
- I tested this:
model slider
extends
Modelica.Mechanics.Translational.Interfaces.PartialCompliantWithRelativeStates;
parameter Real flim = 1;
equation
f = if abs(f)>flim then sign(f)*flim else f;
end slider;
on Dymola and it works. It is correct modelica code so it should be work also in OpenModelica, I can't think of a reason why it should be seen as an unbalance mathematical model.
I hope this helps,
Marco

Modeling closed hydraulic cycle in OpenModelica

I'd like to model a closed hydraulic cycle as one can find in the Modelica Standard Library/Fluid/Examples/HeatingSystem. With the heating system as well as with my (minimalistic) example I've got the same problem: The system is overdetermined.
You can find the HeatingSystem as a "bad example" in the following lecture, so I guess this is a well known problem, but I don't really get the point.
http://www.modprod.liu.se/MODPROD2011/1.252944/modprod2011-day2-talk3-Keynote-Francesco-Casella-Control-and-Modelica.pdf (page 20)
My example is:
a pump
model producer
pipe_flange w,k;
parameter Real a,b,c;
equation
w.p = k.p + a * k.Vp ^ 2 + b * k.Vp + c;
end producer;
a resistence
model consumer
pipe_flange w,k;
parameter Real rho;
parameter Real d_i;
parameter Real zeta;
equation
k.p = w.p - rho / 2 * ((w.Vp * 4) / 3.14 * d_i ^ 2) ^ 2 * zeta;
end consumer;
they are connected with a
connector pipe_flange
Real p;
flow Real Vp;
end pipe_flange;
The whole system is:
model System
consumer consumer1(rho = 1000, d_i = 0.06, zeta = 0.5);
producer producer1(a = -740741, b = -19630, c = 1070);
equation
connect(consumer1.w,producer1.w);
connect(consumer1.k,producer1.k);
end System;
Can anybody give me a hint what the problem is all about?
Are you sure your system is overdetermined? I'm; not sure how this can be since both your producer and consumer models are underdetermined.
As a general rule, the number of equations you need in a component will be equal to the number of flow variables across all its connectors + the number of internal variables (parameters do not count) + the number of outputs.
By this method, your producer model should have 2 equations (because it has 2 flow variable across all its connectors). Similarly, your consumer model should have 2 equations (Because it has two flow variables across all its connectors). So I don't see how you can generate too many equations.
Your model is also tricky because you are modeling the flow of momentum through your system (indicated by the presence of velocity on your connector as a flow variable). But your potential variable is pressure. There is no tracking of mass in your problem (as there usually is).
So, in summary, your component models definitely have an issue because they are "unbalanced" (according to the Modelica Specification) since they do not have the right number of equations. But even on a "physical" level, your formulation (pressure and velocity) is unusual in my experience and it seems to me that it could lead to problems as well once the equation balance issue is overcome.
Maybe it helps to introduce a so called loop-breaker component.
For a closed hydraulic cycle this could be an expansion vessel or storage tank with a variable level
(such a component will also exist in reality).