MassFlowSource_T with 2 ports does not balance flow among port[1]+port[2]

[modelica-trac-importer]

Reported by mwetter on 25 Mar 2009 22:53 UTC
If MassFlowSource_T is used with nPorts=2, then
ports[1].m_flow is not equal to ports[2].m_flow.

I expect the behavior
ports[1].m_flow = ports[2].m_flow = m_flow/nPorts.

The attached total model shows a configuration in which
m_flow = 0.1 kg/s
ports[1].m_flow = 1.0 kg/s
ports[2].m_flow = -1.1 kg/s

The root cause seems to be that the model only specifies
sum(ports.m_flow) = -m_flow_in_internal;
which does not guarantee equality of the flows in the ports.

---

Migrated-From: https://trac.modelica.org/Modelica/ticket/739

[modelica-trac-importer]

Comment by fcasella on 26 Mar 2009 00:16 UTC
I guess there might have been some misunderstanding here. In the case of a pressure source, having multiple connectors has obvious semantics, as the pressure is an intensive quantity. Consequently, we put a vector of ports to avoid unnecessary mixing equations at the boundary.

Conversely, the semantics of a flow source with multiple connectors is more ambiguous, as Michael's remark shows. I would resemble it to a sort of ideal volumetric pump with an outlet header having many flanges, so for me it is obvious that the prescribed flow is just the sum of all the flows which are going out of the ideal source, and that the pressures of all of those ports have to be equal.

Michael's interpretation is instead a bunch of parallel pumps, each with one N-th of the total flow, and thus each having a different pressure.

In my view, the most obvious semantics is the first one, because there is just one source (even though it might have multiple ports). Maybe the documentation should be improved to make it clear.

Comments?

[modelica-trac-importer]

Comment by mwetter on 26 Mar 2009 04:42 UTC
I see. However, assuming we stick with Francesco's interpretation (ideal flow source with header and many flanges), there is also a bug in the current implementation of the energy, species and trace substance balance.

First, regarding the semantics, what led me to my interpretation (ideal parallel flow sources) of the semantics is the vector FluidPorts_b, which caused me to believe that there is no mixing between the fluid streams. Isn't that what we try to convene when using this graphical annotation? I suggest -- if we go with Francesco's interpretation of the semantics -- to use a FluidPort_b (no vector) because we want the user to think that there is mixing in the port, and to update the documentation.

Second, regarding the bug, check the attached TestSources2PortsTotalVersion2.mo.
The MassFlowSource_T on the left (called source) has
X[1] = 0.01 kg/kg
C[1] = 0
T = 10 degC
m_flow = 1 kg/s
The MassFlowSource_T on the bottom (called preFlo) has
X[1] = 0.05 kg/kg
C[1] = 1
T = 60
m_flow = 0.1 kg/s
However, at port_2 of the junction on the right (called Junction2), the simulation result is
Xi_outflow[1] = 0.05 kg/kg
C_outflow[1] = 1
T = 60
m_flow = -1.1 kg/s
Thus, Xi_outflow, C_outflow, and T are wrong, because MassFlowSource_T sets, for all i,
ports[i].Xi_outflow = medium.Xi;
ports.C_outflow = fill(C_in_internal, nPorts);
and
ports[i].h_outflow = medium.h;

[modelica-trac-importer]

Comment by fcasella on 9 May 2012 14:46 UTC
moved from https://trac.modelica.org/Modelica_Fluid/ticket/89

[modelica-trac-importer]

Modified by fcasella on 9 May 2012 14:55 UTC

[modelica-trac-importer]

Modified by rfranke on 21 Jan 2013 09:02 UTC

[modelica-trac-importer]

Changelog removed by rfranke on 21 Jan 2013 09:02 UTC

[modelica-trac-importer]

Comment by rfranke on 21 Jan 2013 10:42 UTC
It appears that MassFlowSource_T and MassFlowSource_h are intended for one port with fluid flow. Multiple connections resulting in mixing are indeed better treated with a lumped port.

This is why SVN e9d8473 introduces the new base class Modelica.Fluid.Sources.PartialFlowSource, which changes the graphics from FluidPorts_b to FluidPort_b. The implementation remains a vector ports for reasons of backwards compatibility.

Moreover an assertion has been added to ensure that there is at most one connection with fluid flow:

  assert(abs(sum(abs(ports.m_flow)) - max(abs(ports.m_flow)))
         <= Modelica.Constants.small, 
    "FlowSource only supports one connection with flow");

All examples and tests are running without change. If someone has made a model using a MassFlowSource with more than one connection with fluid flow, then this model has wrong energy and substance balances. The new assertion would fail and the model needs revisal.

The attached screen shot of Fluid.Examples.TraceSubstances.RoomCO2 shows a situation with two connections to MassFlowSource_T boundary1. It is clear that we don't want to have an equal distribution of the flows to the volume and to the traceSource sensor.

Once MSL_withConversionScript will be available (hopefully soon), also the implementation could be changed from vector ports to a lumped port. Then also the new assertion can be removed again as ideal mixing would take place at the lumped port.