Leverage OpenEI's Utility Rate Database to help modelers

[JasonGlazer]

Issue overview

Gathering information on utility tariffs and modeling them in EnergyPlus is time consuming and this time could be reduced for users by creating a script that would leverage OpenEI's database of utility tariff information to populate EnergyPlus utility tariff objects.

https://openei.org/wiki/Utility_Rate_Database

[mitchute]

We're doing this for another tool I'm working on. If someone picks this task up, let me know and we can discuss it.

[JasonGlazer]

@mitchute are you already translating from the OpenEI API into EnergyPlus objects and using EnergyPlus to calculate the energy costs?

[mitchute]

No, we're pulling from the API and processing the output for a different tool - not E+. I could at least discuss that piece. Shouldn't be too difficult to get from there to E+ objects, though.

[bonnema]

@mitchute, assuming you're speaking to EVI-EDGES, I think that uses the SAM-URDB link directly. I think translating into E+ UtilityCost:* objects is a fair bit of work. Maybe some of the PVWatts/SAM stuff @nmerket did could be leveraged.

[bonnema]

There also may be some annoying details to deal with, like I think the SAM/URDB link fixes a start day (Monday) and does not handle holidays. Probably more, but I am not super SAM knowledgeable.

[leijerry888]

@JasonGlazer @mitchute , we have a working script at PNNL that handles OpenEI rates json pulled from their API and calculates electricity costs with EnergyPlus timeseries outputs. It is currently an independent postprocessing tool for EnergyPlus. We'd be interested in collaborating if need be.

[bonnema]

@leijerry888 pulling rates via the API sounds like a promising start. Does your script return a $/kWh and $/kW number for a given hour? I foresee some issues translating an OpenEI rate into E+ UtilityCost:* objects (its more about capturing the entire rate rather than the cost for any given hour). I could also be way off base. :grin:

[eringold]

I made a small effort of translating URDB json into EnergyPlus input and ran into some difficulty parsing complex rate structures into EnergyPlus's time of use schedule variables. Part of what made it difficult is there is no consistency between the order of charge structure periods (i.e. values in the "energyratestructure" array) and the numbers used in the 'schedule' ("energyweekdayschedule").

For example, here the Summer Weekday peak period is value '5', corresponding to the 5th value of Tiered Energy Usage Charge Structure table, and the rates are ordered roughly lowest to highest.

But this tariff uses the first value '1' for the weekday peak period, with the rates ordered roughly highest to lowest.

Not to say these are insurmountable issues, but add difficulty since those values have to be mapped to 'Peak/Shoulder/Offpeak/Midpeak' values in the EnergyPlus TOU schedule. I think this is an example of 'annoying details' @bonnema warned about.

[leijerry888]

@bonnema Yes it does, it's mapping the unit price values to each hour of the 8760 hours year and providing those long vectors as part of the intermediate results. Turning the rates structure into EnergyPlus objects in their current forms sounds like a difficult task.

[shorowit]

We've also used the SAM SDK to do this (inside an OpenStudio measure, at that), but it's not ideal.

Two comments:

1. Rather than a script, it'd be much better to have an E+ object with a field that references an OpenEI JSON file path, with the translation to EnergyPlus rate structures/objects occurring inside EnergyPlus itself. That would make it most convenient for the widest range of users, whereas a script could be hard to integrate into any given workflow.
2. We need to move away from doing output post-processing for anything that is essentially the dot product of two timeseries vectors -- whether that's utility bills, TDV, Cambium carbon calculations, etc. It's inefficient to request timeseries output from EnergyPlus, only to read it back in and perform the calculations. These calculations should be inside EnergyPlus and occur on the timestep level. Speed matters, especially for applications that involve numerous (or thousands of) EnergyPlus simulations.

[JasonGlazer]

@eringold the inconsistency of labeling the periods is annoying but, I agree, could be figured out.

I would like to see the actual UtilityCost: input objects populated and available to the user, whether by script or as @shorowit suggested by reference in a new EnergyPlus object (presuming it generates the UtilityCost: details and saves it to a local file). I think it is important for the modeler to be able to go in and fix the rates if necessary. My experience with other databases of tariffs is that some values occasionally need correcting or updating. It sounds like an interesting challenge that would benefit a lot of groups and help typical modelers also.

As the author of the UtilityCost:* code, I would be glad to help. It also sounds like it would make sense to leverage work that has been done by people on this thread. I know a lot about EnergyPlus but have just started looking in more detail at the OpenEI URDB.