2W transformer `rating`/`rating_b`/`rating_c`/flows scaled by winding base instead of system base when `SBASE1-2 ≠ SBASE`

クローズ
  • 何か問題がありますか？
#74 コメント 0 件 リアクション 0 件 担当者 1 名 GitHub で見る

メンテナーはふだん 6 日以内に返信

@luke-kiernan がすでに取り組んでいます。

2026年10月14日 から。

  • #75 @luke-kiernan による — マージ済み

評価

この issue はまだ評価されていません。

説明

Summary

For PSS/E 2-winding transformers whose winding base (SBASE1-2) differs from the system base, the OpenAPI reader produces ratings and initial flows scaled by SBASE1-2 / SBASE. Impedances are correct.

Reproducer

A 100 MVA system with three 2W transformers, each with RATA1 = RATB1 = RATC1 = 55 MVA and impedances given on the system base (CZ = 1), differing only in SBASE1-2 (.raw below):

import PowerSystems as PSY
import PowerFlowFileParser as PFP
import PowerSystemCaseBuilder: system_from_openapi
using PowerSystems.Unitful: @u_str
using InfrastructureSystems.PerUnit

sys = system_from_openapi(PFP.PowerModelsData("transformer_rating_base.raw"); runchecks = false)
for t in PSY.get_components(PSY.TwoWindingTransformer, sys)
    c = PSY.get_circuit(t)
    println(PSY.get_name(t), "  rating = ", PSY.get_rating(c, u"MW"), " MW  x = ", PSY.get_x(c, u"SU"))
end
transformer SBASE1-2 rating (MW) expected x (SU)
XFMR_SB50 50 27.5 55 0.2 ✓
XFMR_SB100 100 55.0 55 0.2 ✓
XFMR_SB200 200 110.0 55 0.2 ✓

(Run against the in-development psy6 branches of PowerSystems.jl and PowerFlowFileParser.jl; their Project.toml versions, 5.10.0 and 0.3.0, have not been bumped yet. The bug is in PFP, so it does not depend on the PSY version.)

transformer_rating_base.raw 
0,   100.00, 33, 0, 1, 60.00     / PSS(R)E 33 RAW
TRANSFORMER RATING BASE REPRODUCER
THREE 2W TRANSFORMERS, ALL RATA1 = 55 MVA, SBASE1-2 = 50 / 100 / 200 MVA
     1,'HV138       ', 138.0000,3,   1,   1,   1,1.00000,   0.0000,1.10000,0.90000,1.10000,0.90000
     2,'LV50        ',  13.8000,1,   1,   1,   1,1.00000,   0.0000,1.10000,0.90000,1.10000,0.90000
     3,'LV100       ',  13.8000,1,   1,   1,   1,1.00000,   0.0000,1.10000,0.90000,1.10000,0.90000
     4,'LV200       ',  13.8000,1,   1,   1,   1,1.00000,   0.0000,1.10000,0.90000,1.10000,0.90000
0 / END OF BUS DATA, BEGIN LOAD DATA
     2,'1 ',1,   1,   1,    20.000,     5.000,     0.000,     0.000,     0.000,     0.000,   1,1,0
     3,'1 ',1,   1,   1,    20.000,     5.000,     0.000,     0.000,     0.000,     0.000,   1,1,0
     4,'1 ',1,   1,   1,    20.000,     5.000,     0.000,     0.000,     0.000,     0.000,   1,1,0
0 / END OF LOAD DATA, BEGIN FIXED SHUNT DATA
0 / END OF FIXED SHUNT DATA, BEGIN GENERATOR DATA
     1,'1 ',    60.000,    15.000,   100.000,  -100.000,1.00000,     0,   200.000, 0.00000E+0, 1.00000E+0, 0.00000E+0, 0.00000E+0,1.00000,1,  100.0,   200.000,     0.000,   1,1.0000
0 / END OF GENERATOR DATA, BEGIN BRANCH DATA
0 / END OF BRANCH DATA, BEGIN TRANSFORMER DATA
     1,     2,     0,'1 ',1,1,1, 0.00000E+0, 0.00000E+0,2,'XFMR_SB50   ',1,   1,1.0000,   0,1.0000,   0,1.0000,   0,1.0000,'            '
 1.00000E-2, 2.00000E-1,    50.00
1.00000,   0.000,   0.000,    55.00,    55.00,    55.00, 0,      0, 1.10000, 0.90000, 1.10000, 0.90000,  33, 0, 0.00000, 0.00000,  0.000
1.00000,   0.000
     1,     3,     0,'1 ',1,1,1, 0.00000E+0, 0.00000E+0,2,'XFMR_SB100  ',1,   1,1.0000,   0,1.0000,   0,1.0000,   0,1.0000,'            '
 1.00000E-2, 2.00000E-1,   100.00
1.00000,   0.000,   0.000,    55.00,    55.00,    55.00, 0,      0, 1.10000, 0.90000, 1.10000, 0.90000,  33, 0, 0.00000, 0.00000,  0.000
1.00000,   0.000
     1,     4,     0,'1 ',1,1,1, 0.00000E+0, 0.00000E+0,2,'XFMR_SB200  ',1,   1,1.0000,   0,1.0000,   0,1.0000,   0,1.0000,'            '
 1.00000E-2, 2.00000E-1,   200.00
1.00000,   0.000,   0.000,    55.00,    55.00,    55.00, 0,      0, 1.10000, 0.90000, 1.10000, 0.90000,  33, 0, 0.00000, 0.00000,  0.000
1.00000,   0.000
0 / END OF TRANSFORMER DATA, BEGIN AREA DATA
   1,     1,     0.000,    10.000,'AREA1       '
0 / END OF AREA DATA, BEGIN TWO-TERMINAL DC DATA
0 / END OF TWO-TERMINAL DC DATA, BEGIN VSC DC LINE DATA
0 / END OF VSC DC LINE DATA, BEGIN IMPEDANCE CORRECTION DATA
0 / END OF IMPEDANCE CORRECTION DATA, BEGIN MULTI-TERMINAL DC DATA
0 / END OF MULTI-TERMINAL DC DATA, BEGIN MULTI-SECTION LINE DATA
0 / END OF MULTI-SECTION LINE DATA, BEGIN ZONE DATA
   1,'ZONE1       '
0 / END OF ZONE DATA, BEGIN INTER-AREA TRANSFER DATA
0 / END OF INTER-AREA TRANSFER DATA, BEGIN OWNER DATA
   1,'OWNER1      '
0 / END OF OWNER DATA, BEGIN FACTS DEVICE DATA
0 / END OF FACTS DEVICE DATA, BEGIN SWITCHED SHUNT DATA
0 / END OF SWITCHED SHUNT DATA, BEGIN GNE DATA
0 / END OF GNE DATA, BEGIN INDUCTION MACHINE DATA
0 / END OF INDUCTION MACHINE DATA
Q

Root cause

The header comment in src/openapi/branch.jl (lines 8–18) already describes it:

  1. _make_per_unit! divides rate_a/rate_b/rate_c/pf/qf by baseMVA, which puts them in system-base pu (pm_io/data.jl:403, :415).
  2. psse.jl rebases br_r/br_x/g_fr/b_fr onto the winding base, d["base_power"], which puts them in device-base pu.
  3. The 2W builder converts everything back with the device base: 
    rating = _natural_value(rate_a, base_power),            # branch.jl:435-437, same for rate_b/rate_c
active_power_flow = get(d, "pf", 0.0) * base_power,     # branch.jl:442-443
    Impedances are correct because they really are device-base. Ratings and flows are system-base, so they pick up a stray base_power / sys_mbase factor.

Lines don't show the bug because their base_power == baseMVA. The 3W path doesn't either, because its ratings come straight from the raw MVA fields and skip _make_per_unit!.

Why it wasn't caught

The header comment says the behavior was deliberately ported from the old PSCB converter (the "oracle") for parity: "this reader reproduces exactly that." It also notes that every fixture on hand, and all MATPOWER input, has winding base equal to system base, "so no real fixture can distinguish them." So parity tests pass by construction, and the bug only appears on real PSS/E cases with non-default SBASE1-2.

Proposed fix

  • In the 2W builder, convert rate_a/rate_b/rate_c/pf/qf with sys_mbase, as the line builder does (branch.jl:326-330).
  • Rewrite the header comment so it records the correct convention instead of defending the inherited one.
  • Add the reproducer above as a regression fixture, since no existing fixture has SBASE1-2 ≠ SBASE.
  • Decide whether the PSCB oracle should be fixed too, or whether the parity test should stop treating this field as ground truth.
  • Worth a look: dc_branch.jl:443 notes a similar oracle scaling quirk ("multiplies an already-natural number by sys_mbase") that may be the same kind of copied bug.

The pf/qf part is inferred from the code; the reproducer only checks ratings.

🤖 Generated with Claude Code

主要言語
Julia
スター
1
フォーク
3
平均マージ
7日 8時間
マージ済み PR（30日）
9

環境構築

はじめの一歩

  1. issue を最後まで読み、次にプロジェクトのコントリビューションガイドを読みます。
  2. 着手することを issue にコメントします — 二人が同じ作業をするのを防げます。
  3. リポジトリをフォークし、ブランチを切って変更します。
  4. issue 番号を参照したプルリクエストを送ります。

Sienna-Platform/PowerFlowFileParser.jl のほかの issue

Sienna-Platform/PowerFlowFileParser.jl の issue をすべて見る

似ている issue

Julia の issue をもっと見る

新しい issue をメールで受け取る

初心者向けの GitHub issue を短くまとめたダイジェスト。