Calculate detailed utility bills

[joseph-robertson]

Pull Request Description

Closes #988.

Add optional detailed_filepath yml argument for pointing to user-specified TSV file of electricity tariff file paths. The TSV file can contain electricity tariff file paths mapped by State, or any other parameter.

Test the new optional detailed_filepath yml argument in the testing projects, under Bills3 (resources/data/detailed_rates/County.csv). The existing Bills3 scenario was changed from pointing to resources/data/simple_rates/County.csv.

Checklist

Not all may apply:

• Tests (and test files) have been updated
• Documentation has been updated
  • If related to resstock-estimation, checklist includes data dictionary, source report, options_lookup
• Changelog has been updated
• openstudio tasks.rb update_measures has been run
• No unexpected regression test changes on CI (checked comparison artifacts)

[yingli-NREL]

I run a simulation with three utility bill scenarios (Bills, Bills2, Bills3) as described in the Pull Request Description. In the simulation results file "results-Baseline.csv", there are two values for the fixed charges and marginal rates. It looks like the first value is the for Bill, not sure the second value is for Bills2 or Bills3?

How about creating individual columns of fixed charges and marginal rates for each secenarios? like build_existing_model.utility_bills_natural_gas_fixed_charges, build_existing_model.utility_bills2_natural_gas_fixed_charges, build_existing_model.utility_bills3_natural_gas_fixed_charges

[joseph-robertson]

I run a simulation with three utility bill scenarios (Bills, Bills2, Bills3) as described in the Pull Request Description. In the simulation results file "results-Baseline.csv", there are two values for the fixed charges and marginal rates. It looks like the first value is the for Bill, not sure the second value is for Bills2 or Bills3? How about creating individual columns of fixed charges and marginal rates for each secenarios? like build_existing_model.utility_bills_natural_gas_fixed_charges, build_existing_model.utility_bills2_natural_gas_fixed_charges, build_existing_model.utility_bills3_natural_gas_fixed_charges

It gets a bit complicated based on all the intricacies of our workflow, but let me try to break it down.

The build_existing_model.utility_bill_natural_gas_fixed_charges column you reference above is an example for one of many utility bill related arguments. They serve to pass information from the yml file into our OS-HPXML measure arguments. All of these arguments hold comma-separated strings, where each individual element corresponds to one of the bill scenarios. So for example if you look at build_existing_model.utility_bill_scenario_names you will see "Bills,Bills2,Bills3".

For build_existing_model.utility_bill_natural_gas_fixed_charges, this means that Bills=1.0, Bills2=8.7, and Bills3=''. Bills3 is empty because the particular sample you are showing represents a county not populated in data/detailed_rates/County.tsv. That lookup file intentionally does not contain all counties because we want to demonstrate the process of falling back to default rates when information is not present. If you were to simulate a datapoint representing a county found in that lookup, you would see a value populated for the element corresponding to Bills3.

In terms of presenting fixed charges and marginal rates in a more user-friendly way, we probably could do that but it'd be a departure from our normal workflow. It could also greatly increase the size of the results.csv file depending on how many utility bill scenarios are defined. The inputs themselves are already contained in the user-defined lookups, as well as OS-HPXML resource files for default values.

[yingli-NREL]

the size of the results.csv file depending on how many utility bill scenarios are defined.

Thanks for the explanation. Yes, the size of the results.csv file will be increased if we add extra columns for different utility bill scenarios. In that way, it may not worth to add extra columns since it is not the simulation results.

[yingli-NREL]

The workflow is clear. Did a test run. It works well and the results looks reasonable.