Where
eDisGo_OPF.jl/src/core/constraint.jl, heat-storage inter-timestep balance:
JuMP.@constraint(pm.model, hse_2 - hse_1 * (1 - p_loss)^(1/24) == - time_elapsed*phs_2)
Problem
p_loss is a daily loss rate (edisgo/io/powermodels_io.py: p_loss = 0.04, # 4% of SOC per day). The exponent 1/24 converts it to a fixed one-hour decay, while the charging
term on the right-hand side scales with time_elapsed — the time handling is inconsistent
within one equation. For 15-min steps the storage loses 4× too much per step; for 4-h steps 4×
too little. Non-hourly resolutions are in real use.
Fix
Scale the decay with the actual step length:
(1 - p_loss)^(time_elapsed/24)
(Interacts with the time_elapsed computation bug on the Python side — see #693;
both need fixing for sub-hourly runs to be correct.)
Where
eDisGo_OPF.jl/src/core/constraint.jl, heat-storage inter-timestep balance:Problem
p_lossis a daily loss rate (edisgo/io/powermodels_io.py:p_loss = 0.04, # 4% of SOC per day). The exponent1/24converts it to a fixed one-hour decay, while the chargingterm on the right-hand side scales with
time_elapsed— the time handling is inconsistentwithin one equation. For 15-min steps the storage loses 4× too much per step; for 4-h steps 4×
too little. Non-hourly resolutions are in real use.
Fix
Scale the decay with the actual step length:
(Interacts with the
time_elapsedcomputation bug on the Python side — see #693;both need fixing for sub-hourly runs to be correct.)