add wet coil model based on epsilon-NTU approach

[mwetter]

No description provided.

[mwetter]

Items to do before merging to master

• Update reference results so that we don't introduce a new error when revising the model.
• Add revision notes
• Add info and revision notes to examples
• Remove numerical Jacobians (use Hidden.PrintFailureToDifferentiate = true; for debugging)
• Delete BaseClasses.effCalc and use BaseClasses.epsilon_ntuZ instead. Note that the newly introduced heat exchanger configurations CrossFlowStream1MixedStream2Unmixed and CrossFlowStream1UnmixedStream2Mixed are the same as the existing ones CrossFlowCMinUnmixedCMaxMixed and CrossFlowCMinMixedCMaxUnmixed.
• mwetter Check why DUMMY is used.
• WetCalcs is not differentiable
• Profiling of WetCoilEffNtuMassFlow (with Advanced.GenerateTimers=true) shows that a large part of the computation is spent in the new function TSat_ph which includes its own solver. Maybe this can be refactored to use not a function but rather equations, and let the tool solve the nonlinear equation.
• mwetter to insert in VAVReheat model to compare computing time.
• mwetter: remove non-differentiability in WetCalcs and DryCalcs.
• add flow reversal treatment and a test that verifies that the results are the same if the flow reverses the direction
• verify why Buildings.Fluid.HeatExchangers.Examples.WetCoilCounterFlowMassFlow has a large sensible heat ratio while WetCoilEffNtuMassFlow has a small one.
• Make most instances in the coil protected.
• Add the following variables to WetEffectivenessNTU model: QSen, QLat, mWat_flow, SHR?, QTot?

[michael-okeefe]

Updated the items listed above. Performance of the model is similar to the WetCoilCounterFlow model. I've added quite a bit of documentation to the models and cleaned up the commits to remove models/functions I'm no longer using.

[michael-okeefe]

Note: I've pulled/merged in the branch issue622_wet_coil_base_class_refactor directly and also merged the pull request of the same name so we can probably delete the issue622_wet_coil_base_class_refactor branch at some point.

[mwetter]

Thanks, I deleted the branch issue622_wet_coil_base_class_refactor

…

On Mon, Apr 17, 2017 at 3:32 PM, michael-okeefe ***@***.***> wrote: Note: I've pulled/merged in the branch issue622_wet_coil_base_class_ refactor directly and also merged the pull request of the same name so we can probably delete the issue622_wet_coil_base_class_refactor branch at some point. — You are receiving this because you were assigned. Reply to this email directly, view it on GitHub <#622 (comment)>, or mute the thread <https://github.com/notifications/unsubscribe-auth/ABRHuJLe5NKNToee49ERiN0ZzROuqvnpks5rw-iBgaJpZM4Lftj8> .

[michael-okeefe]

I should have committed and pushed up from the remaining TODO items assigned to me. I just repushed a few minutes ago to correct an issue where a new Example I added (to test reverse flow) was not in alphabetical order. I need to switch to another project right now but don't hesitate to reach out to me if you have any questions or comments or would like to discuss further. Thank you!

[mwetter]

@michael-okeefe : Thanks, I will work on it today.

[AntoineGautier]

@kim1077 I have pushed the new branch issue622_wet_coil_refactor_2_fuzzy which:

• was created from your development branch https://github.com/kim1077/modelica-buildings/tree/issue622_wet_coil_refactor_2_fuzzy,
• was updated to merge the master of Buildings,
• was updated with two unit tests for WetEffectivenessNTU_Fuzzy, see: Buildings.Fluid.HeatExchangers.Validation.UnitTestWetCoilCooling and Buildings.Fluid.HeatExchangers.Validation.UnitTestWetCoilHeating.

Based on our last discussion I start here a list of things to do:

• Update the fuzzy logic implementation to support simulation in heating mode.
• The model uses smoothMax to guard against zero flow rate when computing Z=CMin/CMax and NTU=UA/CMin. This is likely the cause of the simulation error (too high heat flow rate for the actual mass flow rate).
• The exposed parameter is currently UA_nominal. This must be changed in favor of temperature and humidity nominal values as in Buildings.Fluid.HeatExchangers.DryCoilEffectivenessNTU.

Please tell me which parts you will handle and I will work on the remaining ones.

[AntoineGautier]

@kim1077

The Newton solver convergence issues in Buildings.Fluid.HeatExchangers.Examples.WetCoilEffNtuMassFlowFuzzy_V2_2 are likely due to the transition to NTU(Sta) = 0 and eps(Sta) = 1 at low flow rates as implemented in DryCalcsFuzzy_V2_2 and WetcalcsFuzzy_V2_2, which seems to yield a discontinuity in eps(Sta). With Dymola 2020x, the transition to fixed point iterating solves the issue. With Dymola 2021 the simulation fails with the error

Fixed point iterating to handle problem.
Previous problem occured when evaluating crossing function, reducing step-size
cvode: CVODE cvRcheck3 At t = 2102.95, the rootfinding routine failed in an unrecoverable manner.
Unexpected value: -12 at time 2102.4

Could you consider a similar approach as in epsilon_C function with an additional smooth gain to regularize NTU? I implemented this here for DryCalcsFuzzy_V2_2 and WetcalcsFuzzy_V2_2 and it solved the issue.

I think we should consider converting DryCalcsFuzzy_V2_2, WetcalcsFuzzy_V2_2 and ParcalcsFuzzy_V2_2 into functions that we could call to compute UA_nominal based on temperature and humidity nominal values. We indeed need to compute the nominal sensible heat flow rate for that, which we cannot do with the current model implementation.

I cannot remember which validation model led to initialization issues. I did not notice any issue anymore but you may have solved it already?

EDIT: I ran some additional testing in https://github.com/AntoineGautier/modelica-buildings/tree/issue622_wet_coil_refactor_3_ang. I used the NTU regularization described before as simulations fail otherwise. I still get a lot of non convergence errors when simulating the models Buildings.Applications.DHC.Loads.Examples.CouplingSpawnZ6Wet and Buildings.Applications.DHC.Loads.Examples.CouplingTimeSeriesWet. For the latter, here is the comparison of the simulation statistics for a one year simulation when using

• Buildings.Fluid.HeatExchangers.DryCoilEffectivenessNTU

Integration terminated successfully at T = 3.1536e+07
   CPU-time for integration                  : 5.487 seconds
   CPU-time for initialization               : 0.00416493 seconds
   Number of result points                   : 8772
   Number of grid points                     : 8761
   Number of accepted steps                  : 191690
   Number of rejected steps                  : 20723
   Number of f-evaluations (dynamics)        : 309373
   Number of non-linear iteration            : 309345
   Number of non-linear convergence failures : 802
   Number of Jacobian-evaluations            : 6982
   Number of crossing function evaluations   : 200523
   Number of model time events               : 2
   Number of state events                    : 4
   Number of step events                     : 0

• Buildings.Fluid.HeatExchangers.WetEffectivenessNTU_Fuzzy_V2_2

Fixed point iterating to handle problem.
Integration terminated successfully at T = 3.1536e+07
   CPU-time for integration                  : 11.3251 seconds
   CPU-time for initialization               : 0.00607491 seconds
   Number of result points                   : 8772
   Number of grid points                     : 8761
   Number of accepted steps                  : 196000
   Number of rejected steps                  : 20963
   Number of f-evaluations (dynamics)        : 315440
   Number of non-linear iteration            : 315409
   Number of non-linear convergence failures : 878
   Number of Jacobian-evaluations            : 7272
   Number of crossing function evaluations   : 204824
   Number of model time events               : 2
   Number of state events                    : 4
   Number of step events                     : 0

[kim1077]

Sounds exciting! Let me pull the changes and play it a bit hopefully before our meeting next Monday. By the way, how is it going in Paris? Flexible enough to move around and enjoy your life? Donghun

…

On Fri, May 29, 2020 at 4:08 AM Antoine Gautier ***@***.***> wrote: @kim1077 <https://github.com/kim1077> The Newton solver convergence issues in Buildings.Fluid.HeatExchangers.Examples.WetCoilEffNtuMassFlowFuzzy_V2_2 are likely due to the transition to NTU(Sta) = 0 and eps(Sta) = 1 at low flow rates as implemented in DryCalcsFuzzy_V2_2 and WetcalcsFuzzy_V2_2, which seems to yield a discontinuity in eps(Sta). With Dymola 2020x, the transition to fixed point iterating solves the issue. With Dymola 2021 the simulation fails with the error Fixed point iterating to handle problem. Previous problem occured when evaluating crossing function, reducing step-size cvode: CVODE cvRcheck3 At t = 2102.95, the rootfinding routine failed in an unrecoverable manner. Unexpected value: -12 at time 2102.4 Could you consider a similar approach as in epsilon_C function with an additional smooth gain to regularize NTU? I implemented this here for DryCalcsFuzzy_V2_2 <https://github.com/AntoineGautier/modelica-buildings/blob/4a4af7c146640458ed03c4caf9b9ac03b739399a/Buildings/Fluid/HeatExchangers/BaseClasses/DryCalcsFuzzy_V2_2.mo#L123> and WetcalcsFuzzy_V2_2 <https://github.com/AntoineGautier/modelica-buildings/blob/4a4af7c146640458ed03c4caf9b9ac03b739399a/Buildings/Fluid/HeatExchangers/BaseClasses/WetcalcsFuzzy_V2_2.mo#L172> and it solved the issue. I think we should consider converting DryCalcsFuzzy_V2_2, WetcalcsFuzzy_V2_2 and ParcalcsFuzzy_V2_2 into functions that we could call to compute UA_nominal based on temperature and humidity nominal values. We indeed need to compute the nominal sensible heat flow rate for that, which we cannot do with the current model implementation. I cannot remember which validation model led to initialization issues. I did not notice any issue anymore but you may have solved it already? — You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub <#622 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AMNNA25L32EM5VOE2IUPJILRT6JTTANCNFSM4C363D6A> .

-- ================================================== Donghun Kim, PhD http://www.linkedin.com/pub/donghun-kim/37/b34/263 Research Scientist, Energy Technology Area, Lawrence Berkeley National Laboratory ==================================================

[AntoineGautier]

For reference, the computation of the specific heat capacity for air and water does not take into account the flow direction. This is a workaround for a bug in Dymola, see attached bug report.
bug_cp.pdf
The variable always corresponds to the entering fluid according to the design flow direction.
Note that the computation of the effective capacity to represent the wet regime is based on the enthalpy and is not impacted by this simplification.
Once Dymola bug is fixed the equations can be rewritten as follows.

  Modelica.Blocks.Sources.RealExpression cp_a1Exp(
    final y = if allowFlowReversal1
    then
      fra_a1 * Medium1.specificHeatCapacityCp(state_a1_inflow)
      + fra_b1 * Medium1.specificHeatCapacityCp(state_b1_inflow)
    else
      Medium1.specificHeatCapacityCp(state_a1_inflow))
    "Expression for cp of air"

  Modelica.Blocks.Sources.RealExpression cp_a2Exp(
    final y = if allowFlowReversal2
    then
      fra_a2 * Medium2.specificHeatCapacityCp(state_a2_inflow)
      + fra_b2 * Medium2.specificHeatCapacityCp(state_b2_inflow)
    else
      Medium2.specificHeatCapacityCp(state_a2_inflow))
    "Specific heat capacity at port a2"