condensing cooling coil model

[Mathadon]

We are working on a cooling coil model that supports condensation, without using discretisations.

[thorade]

Would that be a moving boundary model, with 3 segments, or a different approach?

[Mathadon]

No, rather a simple model with average specific enthalpy between inlet and outlet and the e-NTU method. PR soon!

[Mathadon]

1113 contains a first version of the model

Many things still need to happen, but the main issue right now is to choose a parameterization for the computation of UA_nominal. At the Aachen meeting I showed that there was an issue when cross-validating the cooling coil model. This is caused by the fact that the current parameterization of the heating coil model implicitly assumes that the nominal conditions (Q_flow_nominal, m_flow_nominal, etc) are at fully dry conditions. Based on these conditions the UA value of the heat exchanger is computed inconsistently, which causes the observed errors. The question is now how to include the degree of condensation at nominal conditions into the model parameters. Options include parameters for:

• fraction of latent or sensible heat flow rate at nominal conditions
• absolute value of latent or sensible heat flow rate at nominal conditions
• wet bulb inlet temperature at nominal conditions
• absolute humidity or relative humidity of inlet temperature at nominal conditions

Depending on the choice, we may have to do (many) inverse computations of the normal equations to compute UA. If wrong parameters values are supplied, the resulting inverse computations may give infeasible results. From that point of view option 3) or 4) look most dummy-proof, however 1) and 2) are easier to use. @mwetter @icupeiro Any suggestions here?

edit: I tried using Q_sen_nominal as a parameter and to rescale cp_nominal accordingly, but that does not lead to Q_flow_nominal at the nominal conditions. Commit a186432 implements code where the nominal absolute inlet humidity is a parameter of the model. This parameter allows to consistently compute the inverse of the model equations such that UA is computed correctly. The question is. though whether users will have access to this parameter. An alternative would be to allow users to provide the wet bulb temperature instead. One more issue: based on the model, UA is significantly larger in the wet regime than in the dry regime (270 W/K instead of 200 W/K). This will lead to an overestimation of the heat transfer in the dry regime based on the wet regime nominal conditions. Is there an alternative to IBPSA.Fluid.HeatExchangers.BaseClasses.HADryCoil that we can use to overcome this?

[icupeiro]

@Mathadon the manufacturer information we are using provides absolute values of latent and sensible heat flow rate, so I'd stick to this

[Mathadon]

@icupeiro indeed that makes sense. The question is also how to specify the 'nominal conditions'. For a dry coil this is just the nominal flow rate and temperature difference but for a wet coil the model also requires some indication of the model humidity. This can be provided either using:

• inlet absolute humidity
• inlet relative humidity
• inlet wet bulb temperature

Right now I'm using absolute humidity. The disadvantage is that this value is not that easy to know and it's hard to provide a good default value. Therefore it's perhaps better to use relative humidity, or allow both?

[icupeiro]

@Mathadon standard EN 1397:2015 establishes test conditions of 19 degC air wet bulb temperature and 27degC of dry bulb temperature (therefore the 46.3% on humidity I think it was), so I would stick to the wet bulb temperature as the default parameter. Perhaps is also convenient to check if there are other test procedures (ASHRAE maybe?) and what is the humidity parameter they fix.

[Mathadon]

@mwetter can you provide feedback on this before further implementing the model?

[mwetter]

I think using the absolute humidity is fine for the parameterization. I have not done yet a more thorough review. Donghun from our team will work this summer on cooling coil modeling.

[Mathadon]

@mwetter I have fixed some issues. The unit tests now pass but the model is not yet ready.

Open issues:

• [ ] The model currently supports condensation at both sides. Usually water is used on one side. The model requires the parameter X_w1_nominal and X_w2_nominal, which does not make sense when using water. We could avoid this by extending the base class into a model that only has condensation at one side?
  • [ ] The model HADryCoil leads to a non-symmetric model since it assumes by default that side 1 of the heat exchanger uses water and the other side uses air. Moreover, the implementation of DryCoilEffectivenessNTU and now also WetCoilEffectivenessNTU does not verify whether indeed Medium1 = Water and Medium2=Air, as HADryCoil assumes. I would therefore opt for a more simplified and symmetric implementation such that switching the sides of the heat exchanger produces exactly the same results. The assert in WetCoilEffectivenessNTU that verifies whether the model is symmetric can then be enabled.
• [ ] The current implementation allows condensation on both sides but does not support bidirectional flow yet. Implementing this would require the regularization of many equations. These regularizations may cause errors or wrong solutions in the regularization range. Therefore I propose to only support allowFlowReversal=false for now.
• [ ] Do we need more examples and/or validations?
• [ ] We may want to refactor the code since there is now code duplication between WetCoilEffectivenessNTU and DryCoilEffectivenessNTU.
• [ ] The implementation changes cause small reference result changes. E.g. due to the use of sta_nominal instead of sta_default for the computation of cp_nominal.

[mwetter]

Since it is a "coil", and uses the heat transfer coefficients of a coil, we should not allow specifying condensation on the water side. More examples would be good.

[Mathadon]

I see, I did not realize the specific meaning. In that case it would make sense to add more generic heat exchanger models though?

[mwetter]

Yes, we could start with moving Buildings.Fluid.HeatExchangers.PlateHeatExchangerEffectivenessNTU to IBPSA, and in a 2nd step, it would be good to refactor those effectiveness models to make them graphically (as we did for the Mover) which I think would make them much clearer.

[Mathadon]

Open questions from my side for today's discussion:

• [x] How to approach multiple air/water based heat exchangers and conventions?
• [x] How to deal with UA values that are humidity-dependent?

[Mathadon]

Todo:

• [ ] No backwards flow but ensure somewhat reasonable results, e.g. set Cp=Medium.cp_default
• [ ] Ask Donghun to check this model.
• [ ] Create separate issue for refactoring the models into blocks and one for adding more heat exchangers.
• [ ] Add more parameters for computing UA scaling factor in wet regime, look for physical approximation.

[Mathadon]

@mwetter can you check the parameterization of EP? Then we can try to be consistent.