Open casella opened 5 months ago
I'm not sure; I think one possibility was nominal(mj.c.m_flow)
; I don't see why excluding the nominal for the flow itself would be good.
What I can see is that these formulas aren't very clear (some variables have subscripts - some depend on them and don't have subscripts), and they should be cleaned up.
What I can see are some major considerations:
Adding this to me meeting just to see if anyone knows who can investigate. I don't expect anyone to know the answer.
Phone meeting: @casella can you try to give some more input on what the desired solution is?
Phone meeting: @casella can you try to give some more input on what the desired solution is?
Pinging @casella again.
Let me recap. The stream connector concept automatically formulates balance equations for advectively carried quantities. These equations become undetermined when all flow rates go to zero, so in order to avoid that, we tweak the calculations when all flow rates become very small, thus obtaining a formulation that is continuous and always well defined.
The question is, what is a very small flow rate? The answer of course depends on the specific application: a small flow rate in a Gen IV molten-lead-cooled power plant (order of magnitude about 100,000 kg/s) is much different from a small flow rate in a pharmaceutical production plant (order of magnitude about 0.001 kg/s). So, we need to somehow take into account the magnitude of the flow rates, using their nominal
attributes. Note that using their actual values is not really possible, since the approximation must be introduced exactly when the variables approach zero, so some a-priori information such as the nominal attribute should necessarily be used.
If all the flows in the connection set have the same order of magnitude, that's no big deal. What if there is one small leak flow? Well, consider the case in which all the big flows are exactly zero and only the small leak flow is present: in this case, the mixing quantity (e.g. the specific enthalpy) is entirely determined by the actual flow rate of the small leak flow. This should be approximated (thus give actually wrong results) only when it is very small compared to its typical order of magnitude, i.e. its nominal attribute. So, I would consider the min value of all the relevant flow variables.
Hence, considering the kind of pseudo-code already employed in that part of the specification, a reasonable and easily implemented solution would be:
eps := relativeTolerance*min(nominal(mj.c.m_flow) for j in 1:N); `
Strictly speaking, the set over which the min attribute should be computed is not the whole connection set (all the connectors mj
with j
going from 1 to N), but only those which are relevant to determine the mixing value, so we should remove from that set the connector on which we are calling inStream(), as well as all the connectors in the connection set that have min >= 0. But I'd say this is probably overkill, so I would stick to the full 1:N set.
Language phone meeting: casella: should be possible to use the simplest variant (all variables). min(nominal(mj.c.m_flow for j in 1:N)) should be min(mj.c.m_flow.nominal for j in 1:N)
Language phone meeting: casella: should be possible to use the simplest variant (all variables). min(nominal(mj.c.m_flow for j in 1:N)) should be min(mj.c.m_flow.nominal for j in 1:N)
However, need to verify - reports that it failed in some rare cases for small flows. (Possibly for Modelon Hydraulics.) Try to make example.
The sophisticated implementation of
positiveMax()
in Section 15.2 contains the following definition:It's not clear what is the meaning of
min(nominal(mj.c.m_flow))
. From what I remember, the idea was to consider the minimum nominal attribute of all flows involved in the connection set, so I guess this should bemin(nominal(mj.c.m_flow) for j in 1:N)
, or possiblymin(nominal(mj.c.m_flow) for j in cat(1, 1:i-1, i+1:N))
if we want to exclude the nominal attribute of the flow of the i-th connector, which is irrelevant when computinginStream()
.@HansOlsson can you please confirm?
Keeping @perost in the loop.