Zero base power

[luke-kiernan]

Looks like the behavior on this issue has regressed.

We should disallow 0.0 as a base power for components. Otherwise, you can get thoroughly confusing things like PSB issue Sienna-Platform/PowerSystemCaseBuilder.jl#174: get_reactive_power(comp) yields 0.0, but calling set_reactive_power!(comp, 0.0) then changes the reactive power to NaN.

[luke-kiernan]

I tried to reproduce this in PowerFlowFileParser and could not. The evidence points at PSY's tabular (RTS-GMLC CSV) parser rather than anything in this repo.

The component in PSB #174 isn't from PFFP's path

PSB #174 names the component 314_SYNC_COND_1. That's RTS-GMLC tabular naming (the GEN UID column of gen.csv). PFFP's PSS/E path names the same machine generator-314-1. So RTS_GMLC_DA_sys is built through PowerSystems' tabular parser, which PFFP has no part in.

PFFP's RTS files are clean

Parsing the RTS cases in the PowerSystemsTestData artifact (RTS-GMLC.RAW, RTS_30.raw, case73.raw, case24.raw): no generator has mbase == 0, and every SynchronousCondenser is built with base_power = 100.0.

Every generator path is guarded

All five generator makers route through _device_base_power (src/openapi/generation.jl:85), which substitutes the system base and warns:

• make_thermal_generator! and _make_hydro_dispatch_body! (via _gen_base_and_limits)
• make_renewable_dispatch!, make_renewable_nondispatch!, make_synchronous_condenser!

That is the same guard PSY carries at its six make_* sites in src/parsers/power_models_data.jl, so the port did not drop it. Transformer bases are guarded too: SBASE1-2 falls back to baseMVA at src/pm_io/psse.jl:1116, and the three-winding SBASE values at psse.jl:1435.

Corpus sweep

CaliforniaTestSystem.m is the worst case available — 2149 of 3892 generators have mbase == 0.0. After a full build_openapi_system, 0 of 17189 base-power fields are zero (checking base_power, base_power_12, base_power_23, base_power_31 across every component type). Sweeping every .raw and .m in the artifact gives the same result: no component anywhere ends up with a zero base power.

The one unguarded path

make_storage! (src/openapi/generation.jl:475) assigns base_power = thermal_rating with no zero check. Its docstring documents this as deliberately bug-compatible with PSCB, with the fix tracked upstream, so I left it alone. Only one corpus file has storage at all (case5_strg.m, no zeros), so nothing currently exercises it.

Suggestion

Unless there's a specific .raw/.m that shows a zero base power through this parser, this looks like it belongs in PowerSystems.jl against the tabular parser. Happy to add a defensive check here anyway — e.g. rejecting base_power == 0 centrally at the end of build_openapi_system, which is what PSY #1575 asks for — but that needs a decision on the storage carve-out first, since it would fire there.