MASTR: open-mastr bulk export silently drops the entire combustion table (0 conventional plants)

[MaykThewessen]

Summary

When the MASTR source is built from a fresh open-mastr bulk export (instead of the frozen Zenodo CSV dump), the entire combustion table (EinheitenVerbrennung → gas / coal / oil / conventional CHP) can be silently dropped, yielding 0 German conventional thermal plants in the combined dataset.

Symptom

open_mastr.Mastr().download() logs:

[ERROR] Error processing file 'EinheitenVerbrennung.xml': 'could not convert string to float: '2442, 2442''

This is logged as an ERROR only - download() still exits 0 and every other technology (solar, wind, hydro, storage, ...) parses normally. So it is easy to ship a German fleet missing ~93.6k conventional units (~101 GW) without noticing.

Root cause (upstream open-mastr)

open_mastr/xml_download/utils_cleansing_bulk.py::replace_mastr_katalogeintraege casts catalog-code columns with .astype("float"). The WeitereBrennstoffe (additional fuels) column can hold multiple comma-separated catalog codes (e.g. "2442, 2442"), which crashes the float cast and aborts the whole table.

Workaround

Re-drive the catalog casts through pd.to_numeric(errors="coerce") (the unparseable multi-code value is unused downstream by ppm). This restores ~93.6k combustion rows, cleansed.

Asks

1. This should be fixed upstream at [OpenEnergyPlatform/open-MaStR]; happy to file there too.
2. Independently, powerplantmatching could guard against it: after a MASTR build, validate non-empty per-technology row counts (or at least per fueltype) and emit a loud warning if a whole technology is empty, so a silently-truncated registry does not flow into a model.

Context

Surfaced while refreshing MASTR from the live bulk export (Zenodo's published dump is frozen at 2025-02-09). See companion proposal on bulk-export compatibility.