Thanks to visit codestin.com
Credit goes to github.com

Skip to content

Update plug load end uses for operational calculations#1775

Merged
shorowit merged 6 commits into
masterfrom
plug_loads_operational_calc
Sep 4, 2024
Merged

Update plug load end uses for operational calculations#1775
shorowit merged 6 commits into
masterfrom
plug_loads_operational_calc

Conversation

@shorowit

@shorowit shorowit commented Jul 11, 2024

Copy link
Copy Markdown
Contributor

Pull Request Description

Closes #1773. For operational calculations (where NumberofResidents is provided), we now directly use equations from RECS 2020 that are a function of number of occupants.

Checklist

Not all may apply:

  • Schematron validator (EPvalidator.xml) has been updated
  • Sample files have been added/updated (openstudio tasks.rb update_hpxmls)
  • Tests have been added/updated (e.g., HPXMLtoOpenStudio/tests/test*.rb and/or workflow/tests/test*.rb)
  • Documentation has been updated
  • Changelog has been updated
  • openstudio tasks.rb update_measures has been run
  • No unexpected changes to simulation results of sample files

@shorowit shorowit added the enhancement New feature or request label Jul 11, 2024
@shorowit shorowit self-assigned this Jul 11, 2024
Comment on lines +301 to +302
elsif unit_type == HPXML::HPXML::ResidentialTypeManufactured
annual_kwh = 1795.1 # No good relationship found in RECS, so just using a constant value

Copy link
Copy Markdown
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Bringing attention to this. If anyone has a better idea, I'm all ears.

Copy link
Copy Markdown
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I guess I am not surprised by the lack of relationship for num_occ and cfa. What about the number of bedrooms? I know it is a little strange to introduce a separate variable just for Manufactured homes. I do like the idea of the value changing based on some variable and not constant, but if we don't have a clear trend then maybe we should keep it constant.

Copy link
Copy Markdown
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

@joseph-robertson's analysis shows that all the different combinations of independent variables (CFA, # bedrooms, # occupants) have very low R2 values for MH. Worse, all the coefficients are negative. So, for example, the equation based on # bedrooms would be:
annual_kwh = 2299.72 - 191.7 * num_br
and would have lower electricity use when there are more bedrooms. Which I don't think makes sense.

Comment on lines +324 to +325
# Note: If we know # of televisions, we could use these better relationships instead:
# - SFD: 67.7 + 243.4 * num_tv

Copy link
Copy Markdown
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Here too.

@afontani afontani Jul 17, 2024

Copy link
Copy Markdown
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

When @joseph-robertson was looking at regression equations using RECS 2020, number of TVs was by far the variable to include in a regression. I would be in favor of using num_tv in the regression.

Copy link
Copy Markdown
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Right. We currently don't have an input for # tvs in OS-HPXML. If we did add one, it would have to be optional, and we would need to have a default (based on # occupants and/or # bedrooms?).

I guess the idea you're proposing is that, if we use the equations based on # tvs, it might give a similar result to the equations I implemented when the number of TVs is not known, but if someone who does know the number of TVs gets a better result.


.. [#] If NumberofResidents not provided, an *asset* calculation is performed assuming standard occupancy, in which occupant-driven end uses (e.g., plug loads, appliances, hot water) are calculated based on NumberofBedrooms.
If NumberofResidents is provided, an *operational* calculation is instead performed, in which hot water end uses are calculated based on NumberofResidents from `Estimating Daily Domestic Hot-Water Use in North American Homes <http://www.fsec.ucf.edu/en/publications/pdf/fsec-pf-464-15.pdf>`_ and all other occupant-driven end uses are adjusted using the following relationship from `RECS 2015 <https://www.eia.gov/consumption/residential/reports/2015/overview/>`_:
If NumberofResidents is provided, an *operational* calculation is instead performed, in which *some* occupant-driven end uses, as described throughout the documentation, are adjusted using the following relationship from `RECS 2015 <https://www.eia.gov/consumption/residential/data/2015/>`_:

Copy link
Copy Markdown
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Is there a plan to transition to RECS 2020 for number of bedrooms?

Copy link
Copy Markdown
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Yes, @prsh5175 was working on that here, but we ran into issues with hot water use. Thus we ended up pursuing an alternative hot water use approach. Assuming testing looks good and it gets merged, we should be able to revisit and wrap up Prateek's PR after that.

@shorowit shorowit marked this pull request as ready for review July 18, 2024 01:10
@shorowit shorowit linked an issue Jul 18, 2024 that may be closed by this pull request
Base automatically changed from hot_water_operational_calc to master August 21, 2024 20:02
@shorowit

shorowit commented Sep 3, 2024

Copy link
Copy Markdown
Contributor Author

Create issues for @afontani's review comments before merging.

shorowit and others added 4 commits September 3, 2024 14:16
…o plug_loads_operational_calc

# Conflicts:
#	HPXMLtoOpenStudio/measure.xml
#	HPXMLtoOpenStudio/resources/hpxml_defaults.rb
#	HPXMLtoOpenStudio/tests/test_miscloads.rb
#	docs/source/workflow_inputs.rst
#	workflow/tests/base_results/results_simulations_bills.csv
#	workflow/tests/base_results/results_simulations_energy.csv
#	workflow/tests/base_results/results_simulations_loads.csv
#	workflow/tests/base_results/results_simulations_misc.csv
@shorowit shorowit merged commit 84564d8 into master Sep 4, 2024
@shorowit shorowit deleted the plug_loads_operational_calc branch September 4, 2024 00:40
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

enhancement New feature or request

Projects

Archived in project

Development

Successfully merging this pull request may close these issues.

Use RECS PlugLoads = f(Nocc) equations

2 participants