[BUG] Thermal storage loses no energy over the first interval (soc_initial has no standing-loss decay)
I maintainer di solito rispondono entro 1 giorno
Nessuno ha ancora preso questa issue.
Valutazione
- Difficoltà
- 3/5
- Tempo stimato
- 1-2 giorni
- Idoneità per principianti
- 69/100
Direzione di ricerca
Read edisgo/opf/eDisGo_OPF.jl/src/core/constraint.jl, starting with constraint_store_state_initial and comparing it with the inter-step constraint; check _build_heat_storage in edisgo/io/powermodels_io.py to confirm how p_loss is assigned. Update the initial heat-storage balance to include the matching interval decay, then verify the first-interval energy balance across the time steps listed in the issue.
Scritto dal modello di indicizzazione a partire dal testo della issue.
Descrizione
Type: bug
Affects: edisgo/opf/eDisGo_OPF.jl/src/core/constraint.jl::constraint_store_state_initial
Found while: reviewing #717
Problem
The thermal storage loses no energy over its first interval, at any time resolution.
constraint_store_state_initial couples soc_initial to the state at t = 1:
function constraint_store_state_initial(pm::AbstractBFModelEdisgo, n::Int, i::Int,
energy, charge_eff, discharge_eff,
time_elapsed, kind, p_loss)
...
elseif kind == "heat_storage"
...
JuMP.@constraint(pm.model, hse - soc_initial == - time_elapsed * phs_1) # Eq. (3.23)
There is no decay factor on soc_initial. p_loss is handed to the function and never
read — it appears in the signature and nowhere else in the body, for any of the three
kind branches.
The general inter-step constraint in the same file does apply it:
JuMP.@constraint(pm.model, hse_2 - hse_1 * (1 - p_loss)^(1/24) == - time_elapsed*phs_2)
(with time_elapsed/24 in the exponent once #717 is merged).
Effect
p_loss is 4 % of the state of charge per day for sector == "individual_heating"
(edisgo/io/powermodels_io.py, _build_heat_storage). The first interval of every OPF
therefore keeps the storage's initial energy intact where every later interval decays
it.
The size of the error scales with the step length, because the missing decay is the one
belonging to that step:
| time step | missing decay on soc_initial |
|---|---|
| 15 min | 0.04 % |
| 1 h | 0.17 % |
| 4 h | 0.68 % |
| 24 h | 4.0 % |
Small at fine resolutions, the full daily loss at a daily step. It also makes the first
interval inconsistent with all the others, which matters for anyone reconciling the
energy balance from opf_results.heat_storage_t — the identity
e[t+1] == e[t] * (1 - p_loss)^(time_elapsed/24) - time_elapsed * p[t+1] holds between
every pair of steps except the first.
Suggested fix
Apply the same decay to soc_initial that the inter-step constraint applies to
hse_1, i.e.
hse - soc_initial * (1 - p_loss)^(time_elapsed/24) == - time_elapsed * phs_1
and decide whether the battery (kind == "storage") needs the same treatment — it has
no loss term at all today, in either constraint, so p_loss is 0 for it by
construction (_build_heat_storage sets p_loss = 0 for anything that is not
individual heating) and this is consistent rather than missing. Worth confirming before
changing it.
Note
Out of scope for #717, which fixes the exponent of the inter-step decay and does not
touch the initial step.
- Lingua principale
- Python
- Stelle
- 48
- Fork
- 22
- Merge medio
- 1g 8h
- PR unite (30g)
- 37
Preparare l'ambiente
- Nessun Dockerfile né file Docker Compose
- Ha un modello di pull request
- Nessuna guida per i contributori
Come iniziare
- Leggi tutta la issue e poi la guida ai contributi del progetto.
- Commenta sulla issue per dire che te ne occupi tu — evita che due persone facciano lo stesso lavoro.
- Fai un fork del repository e lavora su un branch.
- Apri una pull request che faccia riferimento al numero della issue.
Altre issue di openego/eDisGo
-
area: database bug priority: low
Difficoltà 2/5 1-3 ore Idoneità per principianti 78/100
I maintainer di solito rispondono entro 1 giorno
-
bug correctness priority: medium
Difficoltà 2/5 1-3 ore Idoneità per principianti 80/100
I maintainer di solito rispondono entro 1 giorno
-
[BUG] Spatial complexity reduction merges MV and LV buses when an LV grid has the ID of the MV gridApertabug correctness priority: high
Difficoltà 2/5 1-3 ore Idoneità per principianti 72/100
I maintainer di solito rispondono entro 1 giorno
-
bug correctness priority: medium
Difficoltà 2/5 1-3 ore Idoneità per principianti 82/100
I maintainer di solito rispondono entro 1 giorno
-
OPF docs: explain where the curtailment request comes from and how versions 3 and 4 handle itApertaarea: opf documentation priority: low
Difficoltà 2/5 1-3 ore Idoneità per principianti 78/100
I maintainer di solito rispondono entro 1 giorno
Tutte le issue di openego/eDisGo
Issue simili
-
Difficoltà 2/5 1-3 ore Idoneità per principianti 77/100
-
needs-triage tooling
Difficoltà 1/5 Meno di un'ora Idoneità per principianti 90/100
neilsh/stunt-reel#317 ·
I maintainer di solito rispondono entro 1 giorno
-
Difficoltà 2/5 1-3 ore Idoneità per principianti 85/100
TandoorRecipes/recipes#4926 ·
I maintainer di solito rispondono entro 1 giorno
-
Difficoltà 2/5 1-3 ore Idoneità per principianti 75/100
PyTomography/PyTomography#431 ·
I maintainer di solito rispondono entro 1 giorno
-
bug
Difficoltà 2/5 1-3 ore Idoneità per principianti 74/100
igormcsouza/tether#278 ·
I maintainer di solito rispondono entro 1 giorno