openego / eDisGo / 33632913940

84%

dev: 84%

Build Type

push

github

Committed by joda9

Commit Message

fix(run): let load_from_base satisfy the overlying-grid requirement

`aggregate_district_heating` declares `requires={"overlying_grid"}`, which
`import_overlying_grid_data` provides. But that is not the only task that can
put overlying-grid data on an EDisGo object: `load_from_base` restores a saved
grid and takes `import_overlying_grid`, which reaches
`OverlyingGrid.from_csv`. It declared only `provides={"grid"}`, so a pipeline
picking up a saved grid and continuing with the aggregation was rejected by
the validator although the data was right there.

`load_from_base` now declares the overlying grid as well. Like the guarantee
`import_overlying_grid_data` gives, it is static: a pipeline using
`import_overlying_grid: false` validates and then finds nothing to subtract.
The validator is name-based and never sees runtime flags, so this is the same
trade-off already accepted for the import task, not a new one.

The same path also skipped the district-heating label normalisation — a saved
grid carries whatever labels were written into it, and every consumer looks
the ID up as the string of an integer. The normalisation is therefore lifted
out of `import_overlying_grid_data` into
`normalise_district_heating_labels`, and both paths call it. Behaviour of the
import task is unchanged; only the two warning messages lost their task-name
prefix, since the helper does not know which task called it.

Coverage Stats

23 of 26 new or added lines in 2 files covered. (88.46%)

12 existing lines in 1 file now uncovered.

9506 of 11343 relevant lines covered (83.8%)

0.84 hits per line