[BUG] SOC→NC warm-start condition is inverted, and NC results are adopted without checking the termination status

Abierto
  • ¿Algo no está bien?
#696 0 comentarios 0 reacciones 0 asignados Ver en GitHub

Los mantenedores suelen responder en 1 día

Nadie ha tomado este issue todavía.

Evaluación

Dificultad
4/5
Tiempo estimado
3-5 días
Aptitud para principiantes
48/100
Tipo de issue
Error
Claridad
Bien especificado
Estado de actividad
Tranquilo
Stack tecnológico
python
Área
backend, databases

Línea de trabajo

Start with eDisGo_OPF.jl/Main.jl and trace the soc_tight, warm_start, and method="nc" paths in pm_optimize. Check how the solver termination and primal status are represented before update_data! adopts a result. Done means non-tight SOC results trigger NC rescue, and unsuccessful NC runs in either path fall back to the SOC solution with a loud warning.

Escrito por el modelo de indexación a partir del texto del issue.

Descripción

area: opf bug correctness priority: high

Intended behaviour (two-stage solve)

Stage 1: SOC relaxation (Gurobi). If the SOC solution is tight, it is already AC-feasible —
done, no NC solve needed. If it is not tight, the relaxed solution is physically infeasible
and stage 2 should rescue feasibility: solve the exact non-convex model (Ipopt) warm-started
from the SOC solution. (This is also what the SOCBFPowerModelEdisgo docstring describes.)

Actual behaviour (eDisGo_OPF.jl/Main.jl)

  1. Condition inverted: if soc_tight & warm_start — the NC polish runs only in the tight
    case (where it is unnecessary), and is skipped exactly when the SOC solution is not tight.
    A non-tight relaxed solution is returned to eDisGo as the result (only a violations JSON is
    written to opf_solutions/).
  2. No termination-status check on the NC result: result_nc_ws is adopted unconditionally
    via update_data!. If Ipopt ends LOCALLY_INFEASIBLE/ITERATION_LIMIT, a worse-than-SOC
    solution is silently returned. The same unconditional adoption exists in the method="nc"
    cold-start path.
  3. Rescue gated behind an opt-in flag: warm_start defaults to False in pm_optimize,
    so out of the box a non-tight solution is never rescued.

Fix

  • Run the NC rescue when !soc_tight (regardless of the warm_start flag); skip the NC solve
    when the SOC solution is tight.
  • Check the NC termination/primal status: on success adopt the NC solution, otherwise fall back
    to the SOC solution and log a loud warning. Apply the same status check to method="nc".
Lenguaje dominante
Python
Estrellas
48
Forks
22
Merge medio
1 d 7 h
PR fusionados (30 d)
38

Preparar el entorno

  • Sin Dockerfile ni archivo de Docker Compose
  • Tiene una plantilla de pull request
  • Sin guía de contribución

Primeros pasos

  1. Lee el issue completo y luego la guía de contribución del proyecto.
  2. Comenta en el issue que vas a ocuparte — evita que dos personas hagan lo mismo.
  3. Haz un fork del repositorio y trabaja en una rama.
  4. Abre un pull request que haga referencia al número del issue.

Más de openego/eDisGo

Todos los issues de openego/eDisGo

Issues similares

Más issues de Python

Recibe los nuevos issues en tu correo

Un resumen breve de issues de GitHub para principiantes.