lbl-srg / modelica-buildings

Modelica Buildings library
250 stars 155 forks source link

add wet coil model based on epsilon-NTU approach #622

Closed mwetter closed 2 years ago

mwetter commented 7 years ago

Items to do before merging to master

michael-okeefe commented 7 years ago

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 commented 7 years ago

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 commented 7 years ago

Thanks, I deleted the branch issue622_wet_coil_base_class_refactor

On Mon, Apr 17, 2017 at 3:32 PM, michael-okeefe notifications@github.com wrote:

Note: I've pulled/merged in the branch issue622_wet_coil_baseclass 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 https://github.com/lbl-srg/modelica-buildings/issues/622#issuecomment-294614840, or mute the thread https://github.com/notifications/unsubscribe-auth/ABRHuJLe5NKNToee49ERiN0ZzROuqvnpks5rw-iBgaJpZM4Lftj8 .

michael-okeefe commented 7 years ago

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 commented 7 years ago

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

AntoineGautier commented 4 years ago

@kim1077 I have pushed the new branch issue622_wet_coil_refactor_2_fuzzy which:

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

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

AntoineGautier commented 4 years ago

@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

kim1077 commented 4 years ago

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 notifications@github.com 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 https://github.com/lbl-srg/modelica-buildings/issues/622#issuecomment-635914639, 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 commented 3 years ago

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"