Repository navigation
Change Storage constraints to be relative #236
Description
Activity
Yes, we urgently need
relative_initial_charge_state, relative_minimal_final_charge_state, relative_maximal_final_charge_statebut I would not cancel the absolute parameters, as they could be very necessary in some cases!
Furthermore we someday need
relative_minimal_charge_state relative_maximal_charge_stateas a time series. Unfortunately they double a little bit with start/end-parameters:
relative_initial_charge_state, relative_minimal_final_charge_state, relative_maximal_final_charge_stateFurthermore we someday need
relative_minimal_charge_state relative_maximal_charge_stateas a time series. Unfortunately they double a little bit with start/end-parameters:
relative_initial_charge_state, relative_minimal_final_charge_state, relative_maximal_final_charge_stateWe already have those ;)
But they are currently quite confusing, as they are one step longer then the others.
We maybe should merge them into one timeseries for the bounds.I would suggest revising the parameters for the storage considering the following:
- Initializing a model with parameters that are longer than all other parameters is quite unintuitive
- doubling parameters for the final charge state that try to express the same should be avoided
- relative bounds are they way to constraint the flowrate in the class FLOW
Considering this, I would suggest:
- shorten the bounds for the storage to the common length
- use dedicated parameters to constraint the final charge state
- preferably use ONLY relative bounds. This prevents issues with investments and is more in line with existing model parameters
Remaining:
Addrelative_initial_charge_state
Currently the constraints for the storage are partly absolute (initial_charge_state, minimal_final_charge_state, maximal_final_charge_state) and relative (relative_minimum, relative_maximum).
Both initial and final charge state could be constrained in a relative way, that would prevent conflicts with Investments.