Capture varying tier limits in multi-period electric rates

[rathod-b]

When using electric tariffs with multiple periods and multiple tiers where tier limits may differ across periods (assuming same # of tiers across all periods) the model only reports one of the tier limits in its outputs instead of capturing the variation in tier limits.

• Does REopt correctly calculate cost of electricity under each period and tiers within each period?
• Does REopt accurately provide the tier limits in model outputs json file?

[brtietz]

Hey @rathod-b can you post an example of a rate where this is a concern? We have some restrictions on this in SAM (the tier limits all have to be the same within a given month) and it'd be good to be consistent or at least confirm we're both interpreting utility docs in the same way. See NREL/ssc#1207 and NREL/SAM#1783 for details on the SAM implementation.

[rathod-b]

Hey @rathod-b can you post an example of a rate where this is a concern? We have some restrictions on this in SAM (the tier limits all have to be the same within a given month) and it'd be good to be consistent or at least confirm we're both interpreting utility docs in the same way. See NREL/ssc#1207 and NREL/SAM#1783 for details on the SAM implementation.

Hey @brtietz, check out this tariff: https://apps.openei.org/IURDB/rate/view/6772cd0e36492aad0d0e53ed. This came up in one of my projects (the team had to make assumptions to convert the daily kWh tier limits into a monthly kWh tier limit so usage units would be kWh). If we change the tier limit of one of the tiers, we find that REopt does not accurately report the variation. Tier limits are only considered as a matrix with rows = months and columns = # of tiers.

[zolanaj]

Just a note that there's a similar issue raised by @adfarth on demand tiers here: #297

Also it seems like there's a different issue in the tariff mentioned above (#540) - specifically that daily limits are not interpreted currently. @brtietz do you know if those are handled in SAM currently? (because these are tiers of the "easier" kind, i.e., cost goes up as you advance in tiers, this is relatively "easy" for the solver and it could be a good test case for a future fix.)

[brtietz]

@rathod-b Great - SAM can handle this one since periods 1, 2, and 3 are summer and 4, 5, and 6 are winter. Generally I would consider changing a single tier limit to be invalid, summer and winter need to be consistent within themselves (so the minimum number of tier limits to change is 3). I think that means its possible to keep your months & tiers structure for this rate?

@zolanaj We just multiply the daily limit by the number of days in the month: https://github.com/NREL/ssc/blob/ce1a12f6f9f57e95a9f311799228896e35cb592d/shared/lib_utility_rate_equations.cpp#L668

In reality, this should be the number of days in the billing period, but SAM doesn't acknowledge a difference between billing periods and months right now.

[zolanaj]

Upon further review of this specific rate, the single table for months and tiers wouldn't be sufficient for this site in REopt's case because the tier limit is shared across 1, 2, and 3 in each month rather than a separate limit for schedule 1, schedule 2, and schedule 3. The underlying issue is that REopt only accepts monthly rate structures, and the consumption in schedules 1, 2, and 3 should be tracked separately, each with their own limit. (we have "ratchets" that more or less work as sub-monthly tiers, but these only apply to demand charges.)

We can probably borrow some of the setup for the ratchets and apply it to the energy rates, but a lot of it would be introducing new sets and constraints in REopt (since "months" is used elsewhere).