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?
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.
@mcllerena do you know how PSSE handles these issues?