`l2rpn_idf_2023` bundled `grid.json` ships transformers with a sign-invalid `i0_percent`, causing solver-dependent reactive-power divergence

[risjain]

Summary

The pandapower network bundled at grid2op/data/l2rpn_idf_2023/grid.json has 4 of its 13 transformers with a negative i0_percent (magnetizing/no-load current). This is invalid by pandapower's own stated rules for that field (docstring: a magnitude; pandapower.diagnostic: valid range >=0), and traces to a specific, since-fixed defect in pandapower's own MATPOWER/PYPOWER converter (see companion report filed against pandapower: e2nIEE/pandapower#3110). It was not introduced by Grid2Op; it was inherited when this environment's grid was originally built from pandapower.networks.case118()-lineage data, at a time before pandapower's fix existed, and the file has not been regenerated since.

Reproduction

import grid2op, os, json
import pandapower as pp

path = os.path.join(os.path.dirname(grid2op.__file__), "data", "l2rpn_idf_2023", "grid.json")
meta = json.load(open(path))
print(meta["_object"]["version"])  # pandapower save version embedded in the file: "2.8.0"

net = pp.from_json(path)
bad = net.trafo[net.trafo.i0_percent < 0]
print(bad[["name", "hv_bus", "lv_bus", "i0_percent"]])
# 4 of 13 transformers come back negative

Tested against grid2op 1.12.1 and 1.12.5, pandapower 3.5.4 (installed alongside, used only to load/inspect the file — grid2op itself doesn't need to regenerate it to reproduce this).

Why this matters

A transformer's magnetizing branch is physically inductive. Backends/converters that read i0_percent's sign literally when building a solver model from this network (in particular, lightsim2grid's pandapower-v2-style conversion path — the default LightSimBackend uses implicitly for this environment) end up with a capacitive branch on these 4 rows instead of an inductive one — the physically wrong sign. Converters that ignore the sign (a pandapower-v3-style conversion of the same file, or an independent AC solver) do not inherit the error.

Concretely: replaying recorded episodes from this environment against an independent power-flow solver and comparing reactive branch flows shows close agreement (~1 MVAr) on all 173 plain AC lines, but a persistent, roughly 150–210 MVAr disagreement confined to exactly these 4 transformers. Re-solving with LightSim2Grid itself, changing only the sign of i0_percent on these 4 rows and nothing else, reproduces that same disagreement — i.e. the sign of this one field, on these four rows, is sufficient to explain the entire discrepancy.

This was found while independently validating Grid2Op RL-agent episodes against a separately licensed PSS/E model (an unrelated third-party validation project); happy to share the full worked trace, including the raw MATPOWER data comparison that pins down where the sign discrepancy originates, if useful.

Possible remedies (maintainer's call — not proposing a specific fix here)

• Regenerate this grid.json (and check other IEEE-118-derived bundled environments for the same lineage/pattern) using a current, sign-hardened pandapower converter.
• If preserving the exact current numbers is important for reproducibility of existing published results on this environment, documenting the known sign issue explicitly (so downstream users relying on physically-correct transformer behavior are not silently affected) would also address the immediate concern.

Scope

Checked only l2rpn_idf_2023. Given the shared lineage (this file embeds pandapower version 2.8.0 metadata and matches pandapower.networks.case118()'s own affected rows), other bundled IEEE-118-derived environments may carry the same pattern — not checked here.