Opened 8 years ago

Last modified 5 years ago

#142 new feature

More complex utility rate modeling - fuel escalation

Reported by: ewilson Owned by: ewilson
Priority: low Component: Economics/Costs
Version: Future Keywords: utility rates, tariff, CPUC
Cc: cchriste, shorowit

Description

As part of the CPUC project, the capability to use more complex utility rate structures (tiered rates, demand charges, TOU, etc.) will be added to BEopt. The ability to use flat rates will be maintained.

NREL's OpenEI.org has a wiki-like utility rate database (URDB) with 350+ rates. SAM uses this database and it seems like the best source for up to date rates (LBNL's Tariff Analysis Project--used by HES?--is not up to date).

The options for modeling are:

1) using built in DOE2 and E+ components for utility rates
2) post-processing hourly data in BEopt

At this point, (1) seems like the better option.

Progress so far:
utility_rates.py has been created with a function that downloads utility rate files (.json) from OpenEI.org and a function that creates a UtilityRate object from a given file.

Utility rate modeling information will be contained in the bldg desc XML file and will specify a flat rate / monthly charge OR a json filename to use.

Attachments (1)

Screen shot 2012-06-05 at 10.39.29 AM.png (13.6 KB) - added by ewilson 7 years ago.
Column graph with negative utility bills

Download all attachments as: .zip

Change History (22)

comment:1 Changed 8 years ago by shorowit

  • Cc shorowit added

comment:2 Changed 8 years ago by shorowit

From BA Team ARBI: California electric utilities use a tiered rate structure that isn’t adequately represented by an average price per kWh. It would be very useful to include the ability to enter in price values for a tiered rate into BEopt and not have to export hourly data and calculate utility costs externally.

comment:3 Changed 7 years ago by shorowit

Eric, I made some changes that impact this (with regard to making this data available to the BEopt interface once it is parsed from the simulation output file), it should be more straight-forward now. If/when you work on this, please talk to me first.

comment:4 Changed 7 years ago by shorowit

Had some discussion with Craig about this ticket, he gave us the thumbs up to try to wrap this up. Eric, lets talk next week regarding next steps.

Remaining todos:

  • Ensure all python code is complete, from taking info from the xml to writing the appropriate output data for BEopt to read
  • Update BEopt to use these results rather than calculate utility bills itself.
  • Add elements to UI. Can start with a radio button ("Utility Rate") and a dropdown for each utility (or residential utility rate?) and a button that allows viewing the data
    • Electricity only?
    • Do we (or can we) filter for only residential rates?
    • Do we distribute the openei json files or retrieve them on the fly? Related, do we send the user to directly to the openei website for visualization of data or do we populate a little form viewer? 

comment:5 Changed 7 years ago by shorowit

Do we still need to allow the user to enter a net-metered excess sellback rate when they use an openei utility rate?

comment:6 Changed 7 years ago by shorowit

Note: We are going to proceed with shipping files (rather than retrieving the latest utility rate info on the fly) because:

  1. This will ensure we never run into problems related to post-processing a project file with output (or re-running a project file) and getting different values
  2. We can do testing on the utility rates we ship
  3. A user does not have to be online to use the utility rates.

comment:7 follow-up: Changed 7 years ago by shorowit

r1845. Everything on the UI side is done, as far as I'm aware. Report any issues.

comment:8 in reply to: ↑ 7 Changed 7 years ago by ewilson

r1864 implemented changes for DOE2 net metering and utility rate output processing.

A couple issues:

1) DOE2 rounds to the nearest dollar for its output reports, which can lead to a discrepancy in annual values. E.g. $7.50 for monthly fixed charge gets rounded to $8, which gives BEopt $96 for an annual value, whereas the actual annual value is $90. So I think we should also read annual values from the utility bill reports and store them in the output xml as well.

2) How do we deal with negative values on column graph? (see attached) It should show $96 (gas fixed) + $149 (gas energy) + $54 (elec fixed) + -$276 (elec energy) = $23 net

3) Also, it looks like "Demand Charge (E)" and "Fixed Charge (E) use the same color on the column graph. Not a big deal, but if we have more colors, let's use them.

FYI, I still need to implement user specified sellback rate.

Changed 7 years ago by ewilson

Column graph with negative utility bills

comment:9 Changed 7 years ago by ewilson

r1875 DOE2 now accounts for user-specified sellback rate.

Dollar value of PV kWh generation is passed as "utility_bill.annual_production_credit" in output.xml. This is the value that will be used for the "PV production" line on the column graph.

comment:10 follow-up: Changed 6 years ago by ewilson

r1941 Much of the discrepancy between DOE2 and E+, which was due to rate processing errors, has been fixed. There still exists some discrepancies, which should be looked into.

Known discrepancies:

  1. When there are no energy charges (e.g. "Alabama Power Co - (PHOTOVOLTAICS)"), it appears that DOE2 automatically adds a $0.07/kWh charge.
  2. Some Seasonal Tiered rates have a problem in E+ (e.g. "Adams Electric Cooperative Inc - Residential Regular"). It looks like one of the tiers is getting double-charged.

The script UtilityRateTest.py downloads utility rates from openEI, generates xml files, and runs them in E+ and DOE2, to facilitate debugging of rates and rate processing.

Remaining to do:

  1. Deal with duplicate rate names (e.g. Xcel of Colorado - R) by comparing start/end dates.
  2. Look into above discrepancies and check for remaining discrepancies.

comment:11 follow-up: Changed 6 years ago by shorowit

I'm getting an error in DOE2 related to utility rates if I run a building without a space heating system. (No cooling system in DOE2 runs fine and E+ runs fine for both situations.)

comment:12 in reply to: ↑ 11 Changed 6 years ago by ewilson

Fixed in r1983. Tested for building with no space heating and no water heater.

comment:13 in reply to: ↑ 10 Changed 6 years ago by ewilson

r1989 fixes the above two known discrepancies and r1990 deals with duplicate rate names. The discrepancies when running 250 rates are now minimal (RMSE = $0.0063/kWh). Next I will run for all rates on the workstation.

comment:14 Changed 6 years ago by shorowit

  • Priority changed from normal to high

I was running a couple optimizations and noticed that the E+ PV points looked weird compared to DOE2. It turns out that E+ simulations aren't returning a PV utility bill credit (I was simply using the site screen defaults, i.e. a flat rate).

comment:15 Changed 6 years ago by shorowit

  • Priority changed from high to low
  • Version changed from 2.0 Beta to 2.0 Final

comment:16 Changed 6 years ago by shorowit

  • Priority changed from low to normal

With the latest commit, some files had filenames too long for windows and were breaking the build. I'm re-running the script to skip long filenames for now, since this is a Beta release.

For the final 2.0 release, we ought to save the tarrifs with filenames using their ratecode, and add the display name for BEopt into the openei.csv file.

comment:17 Changed 6 years ago by shorowit

  • Priority changed from normal to low

r2101. Fixes long filenames and the need to handle, e.g., ampersands.

comment:18 Changed 6 years ago by ewilson

How does fuel rate escalation interact with complex utility rates? Do we need to allow for escalation of some types of charges (energy) and not others (fixed)?

An extreme example (LBNL/Darghouth 2010):

More recently, [California] legislation passed in 2009 (Senate Bill 695), allows Tier 1 and 2 rates to be increased by up to 5% per year, which will presumably lead to less steeply tiered rates and thus reduce the variability across customers in the value of the bill savings provided by net-metered PV.

comment:19 Changed 6 years ago by shorowit

  • Summary changed from More complex utility rate modeling to More complex utility rate modeling - fuel escalation
  • Version changed from 2.0 Final to Future

comment:20 follow-up: Changed 6 years ago by ewilson

We will need to update our scripts when v2 of the OpenEI URDB API is released.

comment:21 in reply to: ↑ 20 Changed 5 years ago by ewilson

Our scripts have been updated for v2 of the API. We made need/want to make a few changes for v3.

We are now calculating utility bills outside of the simulation engine.

Outstanding questions: How does fuel rate escalation interact with complex utility rates? Do we need to allow for escalation of some types of charges (energy) and not others (fixed)?

Note: See TracTickets for help on using tickets.