Clarification on positiveMax implementation

[casella]

The sophisticated implementation of positiveMax() in Section 15.2 contains the following definition:

 eps := relativeTolerance*min(nominal(mj.c.m_flow)); 

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 be min(nominal(mj.c.m_flow) for j in 1:N), or possibly min(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 computing inStream().

@HansOlsson can you please confirm?

Keeping @perost in the loop.

[HansOlsson]

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:

• Consistency restrictions. How does various formulations impact the enthalpy-residual - in particular does different epsilon in the sum imply an unneeded enthalpy-residual?
• Scaling. Assuming we have a n connectors connected with the same nominal, and then connect a small "leak" (with a small nominal). Does it make sense that this impacts the regularization of the existing connectors? (If it were a big "leak" with large nominal I could imagine it having an impact).

[HansOlsson]

Adding this to me meeting just to see if anyone knows who can investigate. I don't expect anyone to know the answer.

[HansOlsson]

Phone meeting: @casella can you try to give some more input on what the desired solution is?

[HansOlsson]

Phone meeting: @casella can you try to give some more input on what the desired solution is?

Pinging @casella again.

[casella]

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.