Hello simulators :-)

Im working with Modelica/Dymola5 for approximately one month now. Topically I'm facing the following problem as I'm modeling a network of pipes for water containing a fraction of salt:

Several (let's say N) mass flow rates consisting of multible components (in my case two: water and salt) meet each other in a nodal-point of pipes (crotch, pipe branching) where they may split or merge or just pass if there are only two pipes meeting (a simple pipe).
Considering fluid properties like salinity (m_salt per m_water) or specific enthalpie or what you like, incoming mass flow rates with externaly determined properties transmit there properties to outgoing mass flow rates. In other words, properties of inlets are the "cause" whereas properties of outlets are results/effects. Mathematically, outgoing properties are calculated as a kind of average from the incoming ones which doesn't matter in detail here.
Now we model this pipe-node as an element with N acausal "mass-flow-connectors" for all the inlets and outlet transporting their properties. Inlet properties might be determined by such blocks from Modelica.Blocks.Sources.*
What's important for me now: Imagines that due to external pressure variations the directions of some mass flow rates may invert. Suddenly, inlets become outlets and as a consequence of that their properties may not be determined by signal sources any more. Even if we found some if-construction to handle the alternating flow directions within our nodal-point of pipes (as e.g. proposed by http://www.modelica.org/events/Conference2...vist_fluid.pdf), I cannot imagine how to handle the outer world connections to signal sources determining the porperties of (the changing) inlets. It's a kind of "flying splice" (online swap) of cause and effect.

Does anyone of you know a solution for my problem? I thank you for every useful hint.

Cheers,
Hannes

Maybe I can formulate my problem a little bit more concrete way :

You have N hydraulic devices (e.g. pipes) pocessing several ports (connector) each. Such a connector transmits mass flow rate dotM as the FLOW variable, a pressure p and a certain property variable, e.g. a specific enthalpie h. One out of the ports of all these devises shall be connected to the according ports of the other devices, so that at the end these particular ports of all these devices are connected in a starlike way (with the connect(bla,bla)-command).
In consequence, all pressures must be equal. Furthermore the sum of all mass flow rates must equal to zero. But now it comes. What about the property variable h?
Let's start like this: Every device shall have an internal specific enthalpy called h_i with i=1,...,N. As every device possesses an instance of a connector (called port from here on), there's also a specific enthalpy h^port_i delivered from or delivered to the starlike connections and thus to all the other devices. In an analogous manner, there's the mass flow rate (positive if incoming into the device) dotM^port_i.
As the starlike connections between there port don't have any capability to store, delay or what ever (connector don't allow equations as far as I know), all the h^port_i must be equal as well:

h^port_i =: h_0 for all i=1,...,N

So how is the relation between h_i, i=1,...,N and h_0 ? The paper I proposed in my last writing tries a construction like this (I adapted it a little,little bit):

h_0 = if ("all dotM_i == 0") then B else A

with

A := sum_i^N [ if dotM^port_i<0 then (-dotM^port_i * h_i) else 0 ] / sum_i^N [ if dotM^port_i>0 then dotM^port_i else 0 ]
B := 0

So this formula work fine as already found out and shown by the authors of that paper. But where in hell shall I write it in? It must be written somewhere, where all these dotM^port_i and h_i are well known... But I cannot write it into the starlike connections between the ports. Those connections are just created by the commands connect(bla, bla). The are not a "real object" in which this equation could be placed in.

My next idea, was to define separate central point model in which all connections meet. Then there is an object in which one can write down that equation for the internal specific enthalpy. But nonetheless the problem isn't solved, as now all those h_i are unknown so that there input pariables for the h_0-formula are missing . Only those h^port_i are known which equal h_0

So help me, what is the thought I didn't have so far to understand my problem and find a solution.

Hannes

Hello Hannes,

I cannot solve your problem, but reading the comments to the new released Modelica 3.0 specification on http://www.modelica.org/release_of_modelica_3_0/view you should think about your connector design.

In Modelica 3.0 there is the following constraint for a connector: "For each non-partial connector class the number of flow variables shall be equal to the number of variables that are neither parameter, constant, input, output, nor flow".

Your connector does not hold this constraint, and thus will not work in this way in the future anymore.

Maybe by adding another flow variable, e.g. the Energy flow you can solve the origin problem.

Regards

Florian

Currently, I'm trying this one here:

connector Port_SeaWater "Interface for a streaming salty seawater (binary fluid with water and salt)
OUT OF or INTO a hydraulic device"
[...]
Water.StaticPressure p "Static non-gauge pressure";
flow Water.MassFlowRate dotM_flow "Total mass flow rate";
Water.SpecificEnthalpy h "Mass-specific enthalpy";
flow Water.EnthalpyFlowRate dotH_flow "Enthalpy flow rate";
Water.MassFraction X_s "Ratio: Mass of salt per total mass";
flow Water.MassFlowRate dotM_flow_s "Mass flow rate of salt";
end Port_SeaWater;

Here, I have such pairs you are talking of, right? When using this port in a component (e.g. a pump or pipe), one may only define the flow variables like this:

Port_SeaWater flow_port;
// ...
flow_port.dotH_flow = flow_port.dotM_flow * ( if flow_port.dotM_flow <= 0 then flow_port.h else h)
"Send/Receive-Switch";

where h is the inner specific enthalpy of the very component. Remembering

flow_port.dotH_flow (Komponent A) + flow_port.dotH_flow (Komponent B) = 0 (for flow-variables)
flow_port.dotM_flow (Komponent A) + flow_port.dotM_flow (Komponent B) = 0 (for flow-variables)

this means that flow_port.h is only fully defined (except for dotM_flow==0) when both components are finally connected to each other. Nevertheless, flow_port.dotH_flow is really fully defined due to the obvious Modelica-rule (sure?)

0 * undefined = 0

Do you agree with me?

As to my bizarre N-port from above, the thoughts I just wrote hold for each of N-port's N ports.

I would add something like this into the N-port

if sum(abs(port[:].dotM))<1e-9 then
h = 0;
X_s = 0;
else
h = sum((if port[i].dotM>0 then port[i].dotM*port[i].h else 0) for i in 1:N) /
sum((if port[i].dotM>0 then port[i].dotM else 0) for i in 1:N);
X_s = sum((if port[i].dotM>0 then port[i].dotM*port[i].X_s else 0) for i in 1:N) /
sum((if port[i].dotM>0 then port[i].dotM else 0) for i in 1:N);
end if;
for i in 1:N loop
port[i].dotH = if port[i].dotM>0 then
port[i].dotM*port[i].h else
port[i].dotM*h;
port[i].dotM_s = if port[i].dotM>0 then
port[i].dotM*port[i].X_s else
port[i].dotM*X_s;
end for;