Closed mwetter closed 2 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.
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.
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 .
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!
@michael-okeefe : Thanks, I will work on it today.
@kim1077 I have pushed the new branch issue622_wet_coil_refactor_2_fuzzy which:
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:
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).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.
@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
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 .
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"
Items to do before merging to master
Hidden.PrintFailureToDifferentiate = true;
for debugging)BaseClasses.effCalc
and useBaseClasses.epsilon_ntuZ
instead. Note that the newly introduced heat exchanger configurationsCrossFlowStream1MixedStream2Unmixed
andCrossFlowStream1UnmixedStream2Mixed
are the same as the existing onesCrossFlowCMinUnmixedCMaxMixed
andCrossFlowCMinMixedCMaxUnmixed
.DUMMY
is used.WetCalcs
is not differentiableWetCoilEffNtuMassFlow
(withAdvanced.GenerateTimers=true
) shows that a large part of the computation is spent in the new functionTSat_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.VAVReheat
model to compare computing time.WetCalcs
andDryCalcs
.Buildings.Fluid.HeatExchangers.Examples.WetCoilCounterFlowMassFlow
has a large sensible heat ratio whileWetCoilEffNtuMassFlow
has a small one.