|
== charge_state.isel(time=slice(None, -1)) * (1 - rel_loss * hours_per_step) |
In the storage model the influence of the length of timesteps is incorrectly modeled.
The way it is currently implemented is a linear scaling of the loss per timestep with the hours per timestep. However it should scale exponentially.
Currently long timesteps and high losses per hour could even lead to negative charge states. However because they are forbidden by the boundaries of the corresponding variables, the solver would refrain from using the storage at all. This leads to unintended and unexpected behaviour for timesteps of a length other than one hour.
I therefore propose the following change:
== charge_state.isel(time=slice(None, -1)) * ((1 - rel_loss) ** hours_per_step)
That way the loss per hour would scale exponentially with the hours per timestep which is the mathematically correct implementation.
flixopt/flixopt/components.py
Line 494 in 97a1aeb
In the storage model the influence of the length of timesteps is incorrectly modeled.
The way it is currently implemented is a linear scaling of the loss per timestep with the hours per timestep. However it should scale exponentially.
Currently long timesteps and high losses per hour could even lead to negative charge states. However because they are forbidden by the boundaries of the corresponding variables, the solver would refrain from using the storage at all. This leads to unintended and unexpected behaviour for timesteps of a length other than one hour.
I therefore propose the following change:
== charge_state.isel(time=slice(None, -1)) * ((1 - rel_loss) ** hours_per_step)That way the loss per hour would scale exponentially with the hours per timestep which is the mathematically correct implementation.