Standardize use of controller output `commodity_set_point` across storage models

[elenya-grant]

Standardize use of controller output commodity_set_point across storage models

This came up as I was working on PR #493.

The relevant control strategies are:

• DemandOpenLoopStorageController: in h2integrate/control/control_strategies/storage/demand_openloop_controller.py
• PassThroughOpenLoopController: in h2integrate/control/control_strategies/passthrough_openloop_controller.py

The relevant storage performance models are:

• StorageAutoSizingModel in h2integrate/storage/simple_storage_auto_sizing.py
• SimpleGenericStorage in h2integrate/storage/simple_generic_storage.py

Examples 01, 02 and 12 use the StorageAutoSizingModel with the PassThroughOpenLoopController. Examples 03 (co2_hydrogenation_doc), 14, 16, 19, and 24 use the SimpleGenericStorage with the DemandOpenLoopStorageController. There are no examples/tests where StorageAutoSizingModel is used with DemandOpenLoopStorageController or where SimpleGenericStorage is used with PassThroughOpenLoopController. This is good because the storage performance models will only operate as expected if they're tied to the controller.

The PassThroughOpenLoopController outputs commodity_set_point (which is equal to commodity_in). The commodity_set_point input to the StorageAutoSizingModel is used as the commodity available to input to the storage model. The commodity_out output of the of the StorageAutoSizingModel is calculated as commodity_set_point - storage_charged + storage_discharged.

The DemandOpenLoopStorageController outputs commodity_set_point as commodity_in - storage_charged + storage_discharged, aka the output timeseries of the available input commodity and storage used to meet the demand. The SimpleGenericStorage acts as a pass-through storage component, where the output commodity_out is equal to the input commodity_set_point.

If the commodity_set_point from the DemandOpenLoopStorageController was input to the StorageAutoSizingModel, the StorageAutoSizingModel would not behave appropriately because the commodity_set_point from the DemandOpenLoopStorageController is the "target" commodity_out rather than equivalent to commodity_in from the PassThroughOpenLoopController.

One way of thinking about this is that DemandOpenLoopStorageController outputs commodity_set_point as the "target" commodity out, whereas the StorageAutoSizingModel uses commodity_set_point as the commodity available.

The reason these controllers and storage performance models are so commonly paired is that each includes a "pass-through" component and a "charge/discharge" component.

• StorageAutoSizingModel (charge/discharge component) with the PassThroughOpenLoopController (pass through component)
• SimpleGenericStorage (pass through component) with the DemandOpenLoopStorageController (charge/discharge component)

First question: how should commodity_set_point be calculated/defined/used across controllers and performance models in a way that would allow for any controller to be compatible with any storage performance model. Given that storage components have two "control decisions" to make (1. when to charge and 2. when to discharge) - should commodity_set_point be the desired output of the charge/discharge component or be used as the available input commodity?