Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Account for baseline house duct size in the energy model #1154

Open
jonwinkler opened this issue Oct 27, 2023 · 10 comments
Open

Account for baseline house duct size in the energy model #1154

jonwinkler opened this issue Oct 27, 2023 · 10 comments
Assignees

Comments

@jonwinkler
Copy link

The current approach for modeling fan power effectively results in upgrades having a higher power use for a given flow despite a targeted fan efficiency of 0.375 W/cfm in the upgraded home compared to 0.5 W/cfm in the baseline home. Comparing pressure rise vs flow curves shows that the fan pressure rise has increased for a given flow for the upgrade. Essentially the duct system has become more restrictive.

The first step is to expose fan W/cfm in OS-HPXML.

@joseph-robertson
Copy link
Contributor

joseph-robertson commented Oct 30, 2023

I'm starting to wonder whether a new "fan W/cfm" argument is the way to go here. Since the needed inputs to make the fan W/cfm adjustment include upgrade design max airflow, the ApplyUpgrade measure would need to either (A) somehow call apply_hvac_sizing from OS-HPXML first, calculate the W/cfm override, and then apply the BuildResidentialHPXML measure, or (B) apply the BuildResidentialHPXML measure twice (once to get upgrade_design_max_airflow and again with the calculated W/cfm value).

What if, instead of exposing a "fan W/cfm" argument, we exposed a "fan intermediate power" argument. This would be baseline_design_max_airflow * upgraded_fan_watts_per_cfm. Then the apply_hvac_sizing method gets updated to use this value
(and upgrade_design_max_airflow) in the calculation of the fan W/cfm override.

Or maybe there's an easy way to get upgrade_design_max_airflow without calling the entire apply_hvac_sizing method?

@shorowit @jonwinkler

@joseph-robertson
Copy link
Contributor

joseph-robertson commented Nov 2, 2023

@jonwinkler and I proposed that we'd introduce two new arguments to BuildResidentialHPXML:

When hvac_distribution_design_max_airflow_for_adjustment is assigned, it (along with the newly calculated design max airflow) would be used to make an adjustment to hvac_distribution_fan_watts_per_cfm.

Edit: perhaps additional_properties could be used instead of introducing hvac_distribution_design_max_airflow_for_adjustment?

Another edit: perhaps we go with hvac_distribution_duct_max_airflow_cfm which receives the baseline value, and then another "multiplier" argument? This could also be useful with another heat pump sizing methodology.

@shorowit
Copy link
Contributor

shorowit commented Nov 2, 2023

Why can't you apply the adjustment upstream (i.e., in ResStockArguments)? I don't follow why the adjustment needs to live in BuildResHPXML.

@joseph-robertson
Copy link
Contributor

The adjustment is a function of the airflow that's calculated in the upgraded building.

@shorowit
Copy link
Contributor

shorowit commented Nov 2, 2023

Maybe it would make more sense to be able to specify the heating/cooling airflows instead?

We already have HPXML extension elements for airflow rates (search hpxml.rb for heating_airflow_cfm and cooling_airflow_cfm) that we use for reporting purposes. We could start using them if they are entered in the HPXML file.

@joseph-robertson
Copy link
Contributor

Would we need to be careful not to suggest that values entered for heating_airflow_cfm or cooling_airflow_cfm become the populated values in the HPXML file? Seems safer to use additional_properties where only the ApplyUpgrade measure assigns heating_airflow_cfm and cooling_airflow_cfm.

@shorowit
Copy link
Contributor

shorowit commented Nov 2, 2023

Why wouldn't you want them in the HPXML file? I may be missing some nuance here, but I was specifically suggesting this approach so that the values do get entered in the HPXML and then used to create the model.

@joseph-robertson
Copy link
Contributor

The adjustment to the fan W/cfm is a function of both the calculated existing and upgraded airflows. I'm suggesting we pass into BuildResHPXML the existing airflow (somehow), use OS-HPXML's sizing method to calculate the upgraded airflow (as usual), and then use those two values to make an adjustment to the fan W/cfm.

Here is some stubbed code for the adjustment.

@joseph-robertson
Copy link
Contributor

@jonwinkler @shorowit @afontani

Sounds like it may be useful to expose, in addition to hvac_distribution_fan_watts_per_cfm, another argument for passing in the calculated maximum airflow rate for existing ducts -- something like hvac_distribution_duct_max_airflow_cfm. Analogous to system capacities, we can use ApplyUpgrade to assign the values corresponding to the existing building. This could make sizing heat pump upgrades (i.e., a new advanced HVAC sizing control input) more realistic where the maximum allowed airflow rate could be based on the baseline.

Another, maybe unrelated question, is when to apply the fan W/cfm adjustment.

@jonwinkler
Copy link
Author

@joseph-robertson, Checking in to see if the hvac_distribution_fan_watts_per_cfm input been fully implemented.

@whiphi92 Mentioned EUSS would be interested in this fix as well.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
3 participants