build_openapi_system aborts when two TwoWindingTransformer records share a bus pair and circuit id

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

Los mantenedores suelen responder en 6 días

Nadie ha tomado este issue todavía.

Evaluación

Dificultad
4/5
Tiempo estimado
3-5 días
Aptitud para principiantes
45/100
Tipo de issue
Error
Claridad
Bastante claro
Estado de actividad
Activo
Stack tecnológico
julia
Área
backend

Línea de trabajo

Start in src/openapi/branch.jl, especially read_branches! and the proposed _unique_branch_name helper. First determine from PSS/E behavior or the Data Formats manual whether duplicate bus-pair and CKT records are accepted, rejected, or overwritten. Done means choosing and documenting the permanent parser behavior based on that finding, rather than relying only on the current local renaming solution.

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

Descripción

Two-winding transformer records that connect the same pair of buses with the same circuit id cannot be built into an OpenAPI document. The stage-2 PowerModels dict holds both rows without complaint, but build_openapi_system throws on the second one:

The whole build fails, so one duplicated pair blocks the entire case.

read_branches! names each two-winding transformer through get_pm_branch_name as --i, where the circuit id is the record's PSS/E CKT field carried in source_id. register! in the id registry treats (type, name) as a key and throws on a repeat. Bus names themselves are already made unique by read_bus!, which appends the bus number to repeated names, so the collision only happens when two rows genuinely share the same bus pair and circuit id.

Current local solution:

A helper _unique_branch_name(reg, type_name, name, d) in src/openapi/branch.jl asks the registry whether the default name is taken. If not, the name is used unchanged. If it is, the circuit-id suffix is extended to _2, then _3 and so on until a free name is found, and a warning is logged naming the PSS/E record through its source_id:

TwoWindingTransformer TAP_201-LOW_202-i_1 already exists; PSS/E record Any["transformer", 201, 202, 0, "1 ", 0] shares its endpoint buses and circuit id. Naming it TAP_201-LOW_202-i_1_2.

read_branches! calls it on the transformer path only. Records are visited in pm dict index order, so the record that appears first in the file keeps the plain name. Every record still materializes with its own TransformerCircuit and arc, so no data is dropped.

Open question: how does PSS/E treat this?

Before this becomes the permanent behavior we need to know what PSS/E itself does with these inputs, because the answer decides whether renaming is the right fix or whether the parser should reject or merge instead.

  • Does PSS/E accept two TRANSFORMER records with identical bus pair and CKT in a RAW file, or does the reader reject or overwrite the second? If it rejects, case 1 above is corrupt data and an error with a clear message may be better than a renamed component.
  • The Data Formats manual states that bus pair plus CKT identifies a branch within its section, but the copy on hand does not say how RAW import resolves a repeat. Checking behaviour in PSS/E, or in the manual's activity documentation for READ or RDCH, would settle it.

@mcllerena do you know how PSSE handles these issues?

Lenguaje dominante
Julia
Estrellas
1
Forks
3
Merge medio
7 d 8 h
PR fusionados (30 d)
9

Preparar el entorno

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 Sienna-Platform/PowerFlowFileParser.jl

Todos los issues de Sienna-Platform/PowerFlowFileParser.jl

Issues similares

Más issues de Julia

Recibe los nuevos issues en tu correo

Un resumen breve de issues de GitHub para principiantes.