Reconsider storage performance model outputs

[elenya-grant]

Reconsider storage performance model outputs

This came up somewhat during PR #493

This is somewhat related to Issue #498, and was briefly mentioned in this comment on Issue #485 which says:

the battery capacity factor and rated capacity will not result in the same "battery production" as using "battery.electricity_out" because "battery.electricity_out" is equal to: electricity_in - electricity_for_charging + electricity_discharged - excess_electricity whereas the battery capacity factor and rated capacity are based only on electricity_discharged. This would only be a concern where the battery is specified as the commodity stream (for a finance subgroup).

I'll stick to using the battery for this example, but this applies to any storage component. Control strategies for storage components (currently, this is only the DemandOpenLoopStorageController model) have inputs of:

• commodity_in
• commodity_demand

and outputs of:

• commodity_unmet_demand
• commodity_unused_commodity
• commodity_set_point
• total_commodity_unmet_demand

and the storage performance models have an input of commodity_set_point and output the standard outputs of the PerformanceModelBaseClass such as

• commodity_out
• rated_commodity_production
• total_commodity_produced
• annual_commodity_produced
• capacity_factor

In the case of using the DemandOpenLoopStorageController with the PerformanceModelBaseClass (which is done in 6 examples) and perhaps instances of using Pyomo dispatch controllers with the PySAM battery, there will be "issues" when using the storage component as the commodity_stream in a finance subgroup (done in Example 14, 18, 19, and 29) because the battery capacity factor and rated capacity are not as "tied" to the "electricity_out" of the battery as is the case for converter performance models. The battery capacity factor and rated capacity are based on the power discharged from the battery. The electricity_out of the battery is the electricity_in - battery_charged + battery_discharged - excess_electricity.

For most cases where a converter is defined as the commodity_stream, the finance subgroup results should not change if we use capacity_factor and rated_commodity_production instead of sum_comp.total_commodity_produced. This is not the case for storage, because the capacity factor and rated production are calculated on the commodity discharged not the commodity_out.

I think that we need to:

1. standardize what's passed from storage control strategies to storage performance models (Issue Standardize use of controller output commodity_set_point across storage models #498)
2. standardize make all control strategies compatible with all storage performance models (I can't find the issue right now, but be able to use Pyomo control strategies with a storage performance model that isn't the PySAM battery)
3. redefine/recalculate/refactor the outputs of storage performance models

Proposed solution

1. Standardize (and define) what is input/output of storage controller strategies and how that should be interpreted by the performance model its connected to (Issue Standardize use of controller output commodity_set_point across storage models #498)
2. Remove saturating commodity_out of storage performance models to be limited to the demand profile, the demand profile for a storage component should only used to decide when to charge/discharge storage. Aka - commodity_out or commodity_set_point should not be saturated at the demand profile.
3. Change the calculation of commodity_out from the storage performance models to instead be a timeseries of the battery charge and discharge profiles. commodity_out is negative if the storage is being charged, and positive if the storage is being discharged.
4. Use a combiner to combine the electricity stream that was going into the battery with the electricity stream out of the battery. The output of the combiner would be equal to commodity_in - commodity_to_charge_storage + commodity_discharged_from_storage

Alternatives considered

Additional context

[jaredthomas68]

Thank you for the thought you have put into this. I think the standardization effort has highlighted the problems we have with system control being owned by an individual storage technology. If the control deciding what electricity was going to the battery or to another component was owned by a separate component and being fed to the battery, we could circumvent many of the difficulties.

1. I agree about standardizing the controller IO, we can discuss details of that in the tagged issue
2. I don't really agree with non-saturating. If there is no additional demand, we should not dispatch more. This could be handled strictly in the controller though
3. I think we avoided having a positive/negative output specifically to make the storage more similar to other performance models. commodity_out holds only what is flowing out of the storage. However, having the pass-through commodity amounts and the storage discharge both in commodity_out is confusing. I think it would make sense to have commodity_out just hold what is dispatched from the battery, with commodity_excess available for use in other systems. If the control was above the level of the storage (not-owned by the storage), then only the commodity to be used in storage would be sent to the storage and only dispatched amounts would come from the storage. Moving dispatch control to a higher/system level is what I think should be done in the long run, but more discussion is probably needed on how to do that.
4. This is an interesting idea, but I think it is a bit of a hack that highlights the need to have dispatch control live on the system, not the storage technology. If the dispatch control lived at the system instead of the storage tech, we would not need extra components like a combiner or a positive/negative output.

[jaredthomas68]

An important consideration is the unmet demand. If we do move to a system level control approach then it would make sense for the system level control to own the unmet demand, but that would necessitate loops in the model flows.

[johnjasa]

Thanks for writing up this issue in a clear and understandable way! It is very helpful and paints a comprehensive picture of the situation. I also appreciate the clarity in your proposed solution steps.

Overall, I think your solution pathway is a good one. Given more time/effort to think through the system-level control setup that Jared mentions could exist (but doesn't yet) within in H2I, I'd suggest going that route. But we don't necessarily have room for a bigger overhaul of that now! So I digress and will respond to your numbered points.

1. Big fan.
2. This is a bit trickier. I'm not sure if I fully understand your suggestion. Could you please make it more clear, perhaps by describing an example system, what the proposed variables would represent?
3. I might be underthinking this, but I'd like it more if commodity_out from the storage was just the amount coming out, not the net amount. That makes it more clear what the variable means imo. If commodity_in is larger than commodity_out at that timestep, then the storage is charging. Both commodity_in and commodity_out would be strictly positive (or 0) then. Does that work in the system you're imagining?
4. This seems like a good approach and is by far the most explicit (in a good way) for users. I'm worried that a setup like this might make the problem creation seem unwieldy but always needing a combiner or more components to model something correctly. But the way you wrote it out, I like it because it doesn't make it look like the (e.g.) battery is discharging a huge amount of electricity when in reality it might just be passing it through.

The more I think about this and hold Jared's comments in my mind simultaneously, I think a revisit for what a system-level control setup would look like would be helpful. I welcome others' thoughts here and will bring up the notion of a larger-scale discussion focused on what it would mean to examine system-level control in H2I in our next code standup.

[genevievestarke]

I think this is a really important issue, and also related to the value of storage in general and how it's measured (big question)!

I think at the very least, we should separate out the total commodity_out of the system from the commodity_out of the battery, which I think Elena's solution enables. I do think we will have to keep adding more and more components, like the combiner, if we don't address the system-level control.

For the approaches suggested, my thoughts are

1. I agree with this!
2. I think I also agree with this. This point becomes much trickier when, for example, you want the battery to charge from the grid if your system isn't producing electricity. Then you would want the "unmet demand" that you hand to the grid to be higher than the load demand if you are meeting your demand and charging your battery with grid electricity.
3. I agree with this from a system perspective of what the battery is actually doing and not having to back-calculate the battery dispatch. It also makes basing the battery CF on battery dispatch much easier.
4. I think I agree with all three points above: this makes the most sense currently, it's a little cumbersome, and would be addressed by a system-level controller.