Enhancement for Heat Exchanger for Variable-Speed Heat Recovery Ventilation

[yujiex]

Pull request overview

introduction

For lab buildings, the heating-cooling air flow rate could vary substantially depending on the occupancy, the type of experiment, and the operation protocol. Correctly capturing its HVAC energy consumption and heat recovery performance requires accurate information on heat exchangers' sensible and latent effectiveness at various flow conditions. However, in EnergyPlus, the heat exchanger object, HeatExchanger:AirToAir:SensibleAndLatent, describes the sensible and latent effectiveness at only two reference points (100% and 75% airflow) for either heating or cooling. This feature will add four new optional fields at the end of the HeatExchanger:AirToAir:SensibleAndLatent object. These new fields will specify four performance curves to more flexibly express the relationship between sensible and latent effectiveness at different relative airflow (the percentage of the actual airflow relative to the nominal supply airflow). Being able to characterize the efficiency at low-flow-rate conditions can allow more accurate modeling of the heat recovery system and justify the adoption of high-potential energy-saving strategies like using variable speed fans in the exhaust air heat recovery systems in laboratories.

NOTE: ENHANCEMENTS MUST FOLLOW A SUBMISSION PROCESS INCLUDING A FEATURE PROPOSAL AND DESIGN DOCUMENT PRIOR TO SUBMITTING CODE

Transition

The following folder contains the example files I tested for transition. They all run through successfully except for the "SingleFamilyHouse_HP_Slab.idf" and "SingleFamilyHouse_HP_Slab_Dehumidification.idf" which had some error about BuildingSurface:Detailed="FLOOR_UNIT1", invalid Outside Boundary. This seems to also be present in the develop branch?

testTransition.zip

ExpandObject

Two helper functions are implemented to add the heat exchanger effectiveness curves (Table:Lookup): AddSenEffectCurve and AddSenLatEffectCurve. The former corresponds to the case where "Heat Recovery Type" is "Sensible" in the HVACTemplate objects and the latter corresponds to when it is "Enthalpy". The following excel file summarizes where the AddSenEffectCurve and AddSenLatEffectCurve functions are called. I have added some example files to test them. These files are also put on Github, in the commit "add idfs to test ExpandObject". Once we're sure the ExpandObject works, we can revert this commit.

expandObjectTest.xlsx

Regression diffs

number of default fields

The following files have regression diffs in the number of "Fields with Defaults". This is due to the removal of four effectiveness fields for 75% airflow. These fields have defaults. The removal of them will cause the reduction in the number of fields with defaults.

• ASHRAE901_Hospital_STD2019_Denver
• ASHRAE901_HotelLarge_STD2019_Denver
• SingleFamilyHouse_HP_Slab
• SingleFamilyHouse_HP_Slab_Dehumidification
• US+SF+CZ4A+hp+crawlspace+IECC_2006_VRF

For example, ASHRAE901_Hospital_STD2019_Denver has 3 HeatExchanger:AirToAir:SensibleAndLatent object, so it has 12 fewer default fields after the modification.

For the following files, the change in the number of default fields is reflected in table diffs

• 5Zone_Unitary_HXAssistedCoil
• _CrashLights_9680
• ASHRAE901_ApartmentHighRise_STD2019_Denver
• ASHRAE901_ApartmentMidRise_STD2019_Denver

other differences in audit, eio, math, tbl, etc.

The following files have such regression diffs

• 5ZoneFanCoilDOASCool
• 5ZoneFanCoilDOAS_ERVOnAirLoopMainBranch
• 5ZoneFanCoilDOAS_HumidifierOnOASystem
• AirflowNetwork_MultiZone_SmallOffice_HeatRecoveryHXSL
• DOAS_wNeutralSupplyAir_wFanCoilUnits
• DOAToFanCoilInlet
• DOAToFanCoilSupply
• DOAToPTAC
• DOAToPTHP
• DOAToUnitVentilator
• DOAToUnitarySystem
• DOAToVRF
• DOAToWaterToAirHPInlet
• DOAToWaterToAirHPInlet_MultispeedFan
• DOAToWaterToAirHPSupply
• HVACStandAloneERV_Economizer
• HVACTemplate-5ZoneFanCoil-DOAS
• OutdoorAirUnit
• OutdoorAirUnitwithAirloopHVAC
• TermRhGenericOAHeatRecMinExh
• TermRhGenericOAHeatRecPreheat
• VRFMultispeedFan

The magnitude of the sensible/latent effectiveness difference

Most of them have very small differences in the sensible and latent effectiveness

Updated table for the set of idfs with heat exchanger sensible and latent effectiveness output

idf	output variable	sensible max abs diff	sensible max relative diff	latent max abs diff	latent max relative diff
5ZoneFanCoilDOASCool	DOAS HEAT RECOVERY:Heat Exchanger Sensible Effectiveness	1.57E-09	2.27E-09	1.57E-09	2.45E-09
5ZoneFanCoilDOAS_ERVOnAirLoopMainBranch	DOAS HEAT RECOVERY:Heat Exchanger Sensible Effectiveness	1.45E-09	2.09E-09	1.45E-09	2.26E-09
5ZoneFanCoilDOAS_HumidifierOnOASystem	DOAS HEAT RECOVERY:Heat Exchanger Sensible Effectiveness	3.20E-10	4.62E-10	3.20E-10	4.97E-10
AirflowNetwork_MultiZone_SmallOffice_HeatRecoveryHXSL	OA HEAT RECOVERY 1:Heat Exchanger Sensible Effectiveness	1.85E-14	2.30E-14	1.87E-14	2.56E-14
HVACStandAloneERV_Economizer	OA HEAT RECOVERY 1:Heat Exchanger Sensible Effectiveness	3.41E-14	8.11E-14	3.05E-14	8.08E-14
HVACStandAloneERV_Economizer	OA HEAT RECOVERY 2:Heat Exchanger Sensible Effectiveness	1.85E-14	4.40E-14	1.67E-14	4.41E-14
HVACStandAloneERV_Economizer	OA HEAT RECOVERY 3:Heat Exchanger Sensible Effectiveness	1.08E-14	2.57E-14	9.66E-15	2.56E-14
HVACTemplate-5ZoneFanCoil-DOAS	DOAS HEAT RECOVERY:Heat Exchanger Sensible Effectiveness	2.29E-09	3.32E-09	2.47E-09	3.86E-09
TermRhGenericOAHeatRecMinExh	OA HEAT RECOVERY 1:Heat Exchanger Sensible Effectiveness	3.22E-15	3.94E-15	3.11E-15	4.22E-15
TermRhGenericOAHeatRecPreheat	OA HEAT RECOVERY 1:Heat Exchanger Sensible Effectiveness	4.44E-16	5.88E-16	4.44E-16	6.57E-16

Updated table for the set of idfs without HX effectiveness output

idf	output variable	sensible max abs diff	sensible max relative diff	latent max abs diff	latent max relative diff
doas_wneutralsupplyair_wfancoilunits	heatrecoveryhex 1:heat exchanger sensible effectiveness	1.67e-15	2.10e-15	1.78e-15	2.50e-15
doatofancoilinlet	doas heat recovery:heat exchanger sensible effectiveness	7.96e-12	1.15e-11	7.96e-12	1.24e-11
doatofancoilsupply	doas heat recovery:heat exchanger sensible effectiveness	1.39e-11	2.02e-11	1.39e-11	2.18e-11
doatoptac	doas heat recovery:heat exchanger sensible effectiveness	3.33e-16	4.21e-16	1.11e-16	1.74e-16
doatopthp	doas heat recovery:heat exchanger sensible effectiveness	5.55e-16	6.21e-16	4.44e-16	5.27e-16
doatounitventilator	doas heat recovery:heat exchanger sensible effectiveness	4.44e-16	5.19e-16	3.33e-16	4.14e-16
doatounitarysystem	doas heat recovery:heat exchanger sensible effectiveness	2.22e-16	3.22e-16	1.11e-16	1.74e-16
doatovrf	doas heat recovery:heat exchanger sensible effectiveness	6.16e-14	8.94e-14	6.16e-14	9.64e-14
doatowatertoairhpinlet	doas heat recovery:heat exchanger sensible effectiveness	3.33e-16	4.18e-16	2.22e-16	2.90e-16
doatowatertoairhpinlet_multispeedfan	doas heat recovery:heat exchanger sensible effectiveness	6.66e-16	9.53e-16	6.66e-16	1.03e-15
doatowatertoairhpsupply	doas heat recovery:heat exchanger sensible effectiveness	4.44e-16	5.05e-16	1.11e-16	1.73e-16
outdoorairunit	zone3oauhx:heat exchanger sensible effectiveness	2.22e-16	2.96e-16	1.11e-16	1.65e-16
outdoorairunit	zone2oauhx:heat exchanger sensible effectiveness	2.22e-16	2.94e-16	2.22e-16	3.19e-16
outdoorairunit	zone1oauhr:heat exchanger sensible effectiveness	2.22e-16	2.87e-16	2.22e-16	3.28e-16
outdoorairunitwithairloophvac	zone3oauhx:heat exchanger sensible effectiveness	9.61e-14	1.28e-13	9.60e-14	1.43e-13
outdoorairunitwithairloophvac	zone2oauhx:heat exchanger sensible effectiveness	1.19e-12	1.58e-12	1.19e-12	1.76e-12
outdoorairunitwithairloophvac	zone1oauhr:heat exchanger sensible effectiveness	1.16e-12	1.55e-12	1.16e-12	1.73e-12
vrfmultispeedfan	doas heat recovery:heat exchanger sensible effectiveness	3.33e-16	4.12e-16	3.33e-16	4.36e-16

example

Using the 5ZoneFanCoilDOASCool.idf as an example, according to the eplusout.csv.absdiff.csv (after adding Heat Exchanger Sensible Effectiveness and Heat Exchanger Latent Effectiveness output variables), there is a maximum of 4.86E-10 absolute difference (7.00E-10 and 7.55E-10 relative difference) in sensible and latent effectiveness.

The numeric differences in the eso, mtr, table, etc. are caused by switching from the old 2-reference-point method to the curve-multiply-100%-reference-point method when specifying the sensible and latent effectiveness. To justify this, I overwrote the new curve-based method with hard-coded effectiveness calculation using the old 2-reference-point method.

We can see that after this overwritten step, most of the regression diffs are gone.

The remaining table and audit diffs are due to the addition of new table:lookup objects and the change of the number of default fields.

audit diffs

These diffs are also related to the fields. The following example is from the 5ZoneFanCoilDOASCool.idf.

• NumOfRVariable= 7997
• NumOfRVariable(Total)= 7997

• NumOfRVariable= 8001
• NumOfRVariable(Total)= 8001

It's caused by the added two curves for the sensible and latent effectiveness (SenEffectivenessTable and LatEffectivenessTable)

some (e.g. ASHRAE901_ApartmentHighRise_STD2019_Denver) are related to the number of EMS actuators

• numEMSActuatorsAvailable= 28089

• numEMSActuatorsAvailable= 28091

This is related to the added table/curve due to the removal of the effectiveness reference points at 75% airflow

Pull Request Author

Add to this list or remove from it as applicable. This is a simple templated set of guidelines.

• Title of PR should be user-synopsis style (clearly understandable in a standalone changelog context)
• Label the PR with at least one of: Defect, Refactoring, NewFeature, Performance, and/or DoNoPublish
• Pull requests that impact EnergyPlus code must also include unit tests to cover enhancement or defect repair
• Author should provide a "walkthrough" of relevant code changes using a GitHub code review comment process
• If any diffs are expected, author must demonstrate they are justified using plots and descriptions
• If changes fix a defect, the fix should be demonstrated in plots and descriptions
• If any defect files are updated to a more recent version, upload new versions here or on DevSupport
• If IDD requires transition, transition source, rules, ExpandObjects, and IDFs must be updated, and add IDDChange label
• If structural output changes, add to output rules file and add OutputChange label
• If adding/removing any LaTeX docs or figures, update that document's CMakeLists file dependencies

Reviewer

This will not be exhaustively relevant to every PR.

• Perform a Code Review on GitHub
• If branch is behind develop, merge develop and build locally to check for side effects of the merge
• If defect, verify by running develop branch and reproducing defect, then running PR and reproducing fix
• If feature, test running new feature, try creative ways to break it
• CI status: all green or justified
• Check that performance is not impacted (CI Linux results include performance check)
• Run Unit Test(s) locally
• Check any new function arguments for performance impacts
• Verify IDF naming conventions and styles, memos and notes and defaults
• If new idf included, locally check the err file and other outputs

[rraustad]

I have no problem with increasing the accuracy of the HX model. The manufacturers contacted during this model's development said that the HX should not be operated outside the 50% - 130% air flow range, where the effectiveness is roughly linear. If there are curves available for better accuracy then that is a good thing. The curve above is shown for a 10C delta T. Does HX eff vary at other delta Ts or is air flow the driving factor? are there other delta T curves available? or equations of effectiveness that describe performance at other delta T? and/or detla w? where these curves could be created as bi-quadratic/bivariate.

[yujiex]

John McHugh provided some more examples on the heat recovery curves.
The effectiveness curve from [this paper] (https://research.chalmers.se/publication/526453/file/526453_Fulltext.pdf) shows the following curve, where the effectiveness is a function of both air flow rate and liquid capacity flow ratio (the minimum capacity flow rate of all streams in a heat exchanger divided by the maximum). The airflow rate ranges from 0.3 to 1.5 m^3/2, where the lowest air flow rate is 20% of the highest. If the capacity flow ratio is fixed at some value, say 1.0, then the distances between the curves for different air flow rates are not even. This indicates the non-linear relationship between the airflow and the effectiveness. The air-flow-and-effectiveness relationship could be non-monotonic as well for certain values of capacity flow ratio.

This other product does show linear efficiency changes with air flow rate changes.

Let me investigate some more on the ranges of the heat exchanger air flow ratio and form of the curves.

[nealkruis]

I know it will cause some fairly complex transition rules, but this might be an opportunity to clean up this object and get rid of the overly-specific 100% and 75% flow inputs. With the curve inputs, a user could also put in a table with values at 100% and 75%. I understand that 100% and 75% come from AHRI ratings, but that AHRI has replaced the ratings with certified software.

[EnergyArchmage]

Improving this model is a good idea. As @rraustad indicates, could be useful here to allow either single-independent-variable curves or two-independent-variable curves.

As a practical matter when used in an interface, I have had to customize the model a bit to decrease the severity of the flow imbalance error message and to not extrapolate effectiveness beyond the 75% and 100% flows.

                if (HXAirVolFlowRatio < 0.75) {                           // TRANE
                    this->SensEffectiveness = this->HeatEffectSensible75; // TRANE
                    this->LatEffectiveness = this->HeatEffectLatent75;    // TRANE
                } else if (HXAirVolFlowRatio > 1.0) {                     // TRANE
                    this->SensEffectiveness =                             // TRANE
                        this->HeatEffectSensible100;                      // TRANE
                    this->LatEffectiveness = this->HeatEffectLatent100;   // TRANE
                }

[rraustad]

@nealkruis have you used the HX certification software? or have access to it? It might be a good idea to review the inputs required for certification. E+ does cooling coil ratings now and maybe other objects could show standard ratings?

[yujiex]

I know it will cause some fairly complex transition rules, but this might be an opportunity to clean up this object and get rid of the overly-specific 100% and 75% flow inputs. With the curve inputs, a user could also put in a table with values at 100% and 75%. I understand that 100% and 75% come from AHRI ratings, but that AHRI has replaced the ratings with certified software.

I also debated whether to just replace the existing fields with the four table/curve objects. Curves are more flexible to use and it can stop the extrapolation if users don't want it to, like in @EnergyArchmage 's case. I'll bring it up in technicality and see what everybody thinks.

[nealkruis]

@rraustad, each manufacturer develops their own software that is then certified by AHRI to generate ratings at a wider range of conditions. It appears that there is actually a mix of both approaches still used for certified products. Some use the certified software approach, while others use the individual rating point approach (see screenshot below). I believe the intention is to get away from individual rating points eventually.

FWIW, ASHRAE SSPC 205 has an HRV working group that is proposing a schema for performance maps that can be generated from the manufacturers certified software and subsequently fed into simulation programs.

[mjwitte]

I know it will cause some fairly complex transition rules, but this might be an opportunity to clean up this object and get rid of the overly-specific 100% and 75% flow inputs. With the curve inputs, a user could also put in a table with values at 100% and 75%. I understand that 100% and 75% come from AHRI ratings, but that AHRI has replaced the ratings with certified software.

Rather than eliminate the existing inputs, how about making them optional? If curves are input, then the fixed values would be ignored.

[yujiex]

I know it will cause some fairly complex transition rules, but this might be an opportunity to clean up this object and get rid of the overly-specific 100% and 75% flow inputs. With the curve inputs, a user could also put in a table with values at 100% and 75%. I understand that 100% and 75% come from AHRI ratings, but that AHRI has replaced the ratings with certified software.

Rather than eliminate the existing inputs, how about making them optional? If curves are input, then the fixed values would be ignored.

Currently, the curves are optional fields at the end. Would the users rather have both the specific points and curves? Or would they be okay with using just the curves? How serious would the backward compatibility issue be? I guess to transition from older versions, there will need some effort to create curves from the 100% and 75% points.

[mjwitte]

Rather than eliminate the existing inputs, how about making them optional? If curves are input, then the fixed values would be ignored.

Currently, the curves are optional fields at the end. Would the users rather have both the specific points and curves? Or would they be okay with using just the curves? How serious would the backward compatibility issue be? I guess to transition from older versions, there will need some effort to create curves from the 100% and 75% points.

Sorry, my suggestion is exactly what you proposed in the NFP, as long as you add notes to the existing fields that they will be ignored (and may be left blank) if curves are input. It lets existing files produce the same results, and lets someone specify an HX without the need for curves. And it lets those who have curve data model that. And then there's no transition requirement.

[yujiex]

Rather than eliminate the existing inputs, how about making them optional? If curves are input, then the fixed values would be ignored.

Currently, the curves are optional fields at the end. Would the users rather have both the specific points and curves? Or would they be okay with using just the curves? How serious would the backward compatibility issue be? I guess to transition from older versions, there will need some effort to create curves from the 100% and 75% points.

Sorry, my suggestion is exactly what you proposed in the NFP, as long as you add notes to the existing fields that they will be ignored (and may be left blank) if curves are input. It lets existing files produce the same results, and lets someone specify an HX without the need for curves. And it lets those who have curve data model that. And then there's no transition requirement.

Sorry, I might have miscommunicated. I was just wondering which way is better for users (optional curve fields vs using the curve to replace fixed points). If it's much better to use curves to replace the fixed points, then it might be worth a transition. In that case, I can try to learn how to do that.

[JasonGlazer]

@rraustad, each manufacturer develops their own software that is then certified by AHRI to generate ratings at a wider range of conditions. It appears that there is actually a mix of both approaches still used for certified products. Some use the certified software approach, while others use the individual rating point approach (see screenshot below). I believe the intention is to get away from individual rating points eventually.

@nealkruis, thinking about this more, I presume that AHRI has requirements for the inputs and outputs from that software that the manufacturer provides. What those requirements are should probably guide the input or curves. Do you know, are they simply sensible and latent effectiveness at different airflows?

[rraustad]

1. Does there really need to be curves for cooling and heating? isn't it just effectiveness versus air flow? and 2) what happens when these curves are not used?, the effectiveness is constant? I don't recall the conference call discussion on this.

[yujiex]

The notes are updated in the newer commits. The curves are multipliers to the 100% airflow effectiveness value. The multiplier will be a function of airflow. If the curve is not there the value will be 0. There are four curves as sensible and latent effectiveness for both heating and cooling will need to be specified.

[nealkruis]

@JasonGlazer, I'm haven't looked at the AHRI standard yet, but we just had a call with the ASHRAE 205 heat recovery working group today. They are planning a multi-dimensional performance map that includes:

• supply flow rate
• supply temperature
• supply humidity
• relief flow rate
• relief temperature
• relief humidity
• ambient pressure
• wheel speed

This list is still being revised, but my understanding is that this captures the range of inputs that the certified software can use to provide performance (sensible/latent effectiveness).

For this NFP, it won't be possible to handle all these independent variables with the current curve forms.

[yujiex]

Hi, @mjwitte I have updated the regression diff section in the PR description and added some description about the transition and expand object. Could you please take another look? Thanks.

[Myoldmopar]

This PR did not have the IDDChange label attached, and I was ignoring it. I added that label now so it gets reviewed.

[mjwitte]

@yujiex The expandobjects changes all look correct. I ran the full testfiles suite as annual simulations with daily output and only got small diffs in csv and mtr, so that's good.

@Myoldmopar Handing this off to you for final review/merge.

[yujiex]

@yujiex The expandobjects changes all look correct. I ran the full testfiles suite as annual simulations with daily output and only got small diffs in csv and mtr, so that's good.

@Myoldmopar Handing this off to you for final review/merge.

Thanks @mjwitte. @Myoldmopar there are a bunch of new test idfs for examining the diffs due to the ExpandObject changes (this commit: add idfs to test ExpandObject. Please let me know if you want me to revert it.

[mjwitte]

@yujiex The expandobjects changes all look correct. I ran the full testfiles suite as annual simulations with daily output and only got small diffs in csv and mtr, so that's good.
@Myoldmopar Handing this off to you for final review/merge.

Thanks @mjwitte. @Myoldmopar there are a bunch of new test idfs for examining the diffs due to the ExpandObject changes (this commit: add idfs to test ExpandObject. Please let me know if you want me to revert it.

@yujiex We probably don't need to include those in the release package. We can either revert this or add "_" to the names so they stay and run in CI but don't get included in the package.
@Myoldmopar ??

[Myoldmopar]

@yujiex @mjwitte that's way too many new files to add into CI, so we need to revert most/all of the new ones. @yujiex which 1 or 2 of the new test files are most important? If they were really just for testing, I'll pull them all out.

[Myoldmopar]

🚩 If this is expected to make IO freeze (today), then the extraneous IDFs need to be cut out. @yujiex 🚩

[Myoldmopar]

🚨 @yujiex this will either get pushed until 24.2 or I may just go in and delete all the newly added test files. 🚨

[yujiex]

🚨 @yujiex this will either get pushed until 24.2 or I may just go in and delete all the newly added test file
Hi Edwin, I will revert that commit. There is a HVACTemplate in the original test idf already. Other ones are trying to test whether individual calls to the function AddSenLatEffectCurve that expands a template object with curves.

[yujiex]

Hi @Myoldmopar I just reverted the two commits with testing idfs. Sorry for the delay.

[Myoldmopar]

Way better, thank you. I'll let CI wrap up, but if it's happy I'll merge it and kick off a test build of I/O freeze. If there's anything noted after merge, it can be in a follow-up. Thanks @yujiex, and thanks @mjwitte

[yujiex]

Thanks @Myoldmopar =)

[Myoldmopar]

I saw some odd results locally, and CI is showing diffs, so I pulled develop in and will get good results overnight.

[Myoldmopar]

OK, the extraneous diffs from being behind develop appear gone and were back to what is described in the top comment above. I think I will merge this and that will (likely) do it for IO freeze. Anyone have comments speak up soon! 🕒 🕑 🕐

[Myoldmopar]

OK, calling it. Thanks @yujiex. If anything else pops up, we'll do it with a follow-up. Merging.

[yujiex]

Thanks @Myoldmopar