Find open study data for a cross-tool comparison gallery example (e.g. ReEDS vs Sienna)

[micahpw]

Cross-tool comparison on the same system is GAT's core selling point, and the gallery has zero coverage of it — every example is single-scenario Sienna (plus the shared-API transmission example). We need openly licensed study data that can serve as a fixture for a MultiScenario / ReEDS-vs-Sienna example.

The format gap: published results on OEDI and similar open-data platforms are typically post-processed deliverables, not native solve outputs. E.g. the National Transmission Planning Study ReEDS results on OEDI are not in the standard ReEDS run-folder format that ReEDsScenario parses — so 'data exists' and 'data GAT can load' are different things today.

Paths to evaluate:

1. Survey OEDI and similar open platforms for studies published in (or convertible to) native tool formats — ideally a study with both CEM (ReEDS) and PCM (Sienna/PLEXOS-class) results for the same system.
2. Converter: a small adapter from a published-results format (e.g. the NTP Study OEDI layout) into what the ReEDS handler expects — potentially generally useful beyond the gallery, since users will hit the same gap.
3. Synthesize: a minimal ReEDS-format fixture for the same footprint as the existing Sienna RTS-GMLC fixture, so the comparison example is apples-to-apples even if stylized.

Deliverable: a gallery example demonstrating a cross-tool comparison (capacity and/or dispatch, ReEDS vs Sienna) on one system, with the fixture either downloadable or regenerable.

Constraints: data must be openly licensed and small enough for CI (or fetched on demand); any comparison example is also a natural first consumer of the units contract (#8) — cross-tool unit normalization is exactly where it earns its keep. Related: #13 (fixture horizon) if the comparison wants monthly/annual views.

[micahpw]

Option 4 (likely the strongest): synthesize the pair from one small ReEDS model.

• Build a small ReEDS case (~3 zones). Its native run-folder output is directly what ReEDsScenario parses — no converter needed.
• Translate the build-out to a Sienna system via R2X, and solve the PCM side in PowerSimulations as copper plate per zone with inter-regional transfer limits (area interchange with limits). That matches ReEDS's own transport representation, so the CEM-vs-PCM comparison is apples-to-apples by construction rather than by approximation.
• Division of labor between fixtures: this 3-zone pair covers the cross-tool story (capacity build-out vs dispatch, zonal interchange, MultiScenario plots), while RTS-GMLC keeps the nitty-gritty Sienna coverage (nodal line flows, unserved energy via Surface unserved energy (balance slack) as a first-class dataset #10, reserves).

Wrinkles:

• ReEDS is open source but GAMS-backed, so CI can't re-solve it. Fine for a fixture: solve the 3-zone case once locally, and commit/publish the (small, synthetic, openly-licensed) run folder as a static fixture — it's the Sienna side that benefits from regeneration, and that fits the existing Docker fixture pattern.
• The zonal Sienna solve is tiny (3 areas, transport-constrained) — negligible CI cost next to the RTS fixture.
• This pair is also the ideal first consumer of the units contract (Design: unit-aware datasets across parsers, query API, and plots #8): two tools, same system, different native units and conventions, normalized at the parser boundary.

[micahpw]

Option 5: resource adequacy via PRAS. Translate the fixture system with Sienna2PRAS and run PRAS in the fixture build, then compare RA metrics against the PCM results. Two properties make this attractive:

• Fully open stack — PRAS is open-source Julia with no commercial solver dependency, so unlike the ReEDS path (GAMS) the whole pair can regenerate in CI inside the existing Docker fixture pattern.
• Completes the integrated-planning picture — CEM (build-out) + PCM (dispatch) + RA (adequacy) under one API is the full 'unified integrated system planning analysis' story, not just tool-vs-tool.

Prerequisite: a PRAS scenario handler in GAT (new parser + scenario type for PRAS output — shortfall/surplus samples, EUE/LOLE metrics). That's a real feature of its own; split into a dedicated issue when this option is pursued. It's also a forcing function for the plugin units contract (#8): RA metrics (EUE in MWh, LOLE in events/yr) are dimensionally unlike dispatch quantities, so the handler would exercise the 'declare units to register' rule immediately.