Skip to content

Fix/ego 213 pv rooftop building id duplicate bus - #748

Open
joda9 wants to merge 3 commits into
devfrom
fix/ego-213-pv-rooftop-building-id-duplicate-bus
Open

Fix/ego 213 pv rooftop building id duplicate bus#748
joda9 wants to merge 3 commits into
devfrom
fix/ego-213-pv-rooftop-building-id-duplicate-bus

Conversation

@joda9

@joda9 joda9 commented Sep 2, 2026

Copy link
Copy Markdown
Collaborator

Description

Please include a summary of the change and which issue is fixed.

Fixes # (issue)

Type of change

Please delete options that are not relevant.

  • Bug fix (non-breaking change which fixes an issue)
  • New feature (non-breaking change which adds functionality)
  • Breaking change (fix or feature that would cause existing functionality to not work as expected)

Checklist:

  • New and adjusted code is formatted using the pre-commit hooks
  • New and adjusted code includes type hinting now
  • I have commented my code, particularly in hard-to-understand areas
  • I have made corresponding changes to the documentation
  • I have added tests that prove my fix is effective or that my feature works
  • New and existing unit tests pass locally with my changes
  • The Read the Docs documentation is compiling correctly
  • If new packages are needed, I added them the setup.py, and if needed the rtd_requirements.txt, the eDisGo_env.yml and the eDisGo_env_dev.yml.
  • I have added new features to the corresponding whatsnew file

joda9 and others added 3 commits September 2, 2026 07:43
0.3.0 was published on 2026-08-03 (daf14ab set the date, the tag and the
PyPI upload followed), so its changelog section describes a released
artifact and must not keep growing. Every change landing on dev now belongs
to the next release.

Adds `doc/whatsnew/v0-3-1.rst` and includes it above 0.3.0 in
`doc/whatsnew.rst`, so the newest section stays at the top of the rendered
page.

Moves the one entry that had already been appended to 0.3.0 after the
release: the `config_opf_julia.cfg` Julia version correction from 1d2b5de,
committed at 14:44 on the day the release date was set at 09:08. It
documents a change that is not in the 0.3.0 artifact, so readers comparing
the changelog against the released package would not find it.

`Release date: not yet released` is a placeholder; it gets stamped the way
daf14ab did for 0.3.0 when 0.3.1 is published.
Importing generators failed for some grids with

    ValueError: cannot reindex on an axis with duplicate labels

raised from `gens_df.update()` in `_integrate_pv_rooftop`
(openego/eGo#213, reported for MV grids 33084 and 33695).

The function derived a bus -> building ID map from the conventional loads.
That map was deduplicated on "building_id" but indexed by "bus", so a bus
carrying the loads of two different buildings kept both rows and produced a
duplicated bus label. `gens_df.loc[:, ["bus"]].join(..., on="bus")` then
emitted two rows per generator, and `DataFrame.update` reindexes its argument
onto `self.index`, which rejects a non-unique index.

The map is not repaired here, it is removed, because it has had no effect on
the result for two and a half years. It was introduced in ae00203 to supply
the key for matching existing PV rooftop plants against the scenario data,
which merged `on="building_id"` at the time; the generators in a ding0
topology carry no building ID, so one was guessed from the conventional load
sitting at the same bus. A ToDo above the block already asked for the match
to use the unique MaStR source ID instead. d33e851 did exactly that and
removed the ToDo, but left the map behind.

Since then the guessed value has been discarded: `gens_existing` is merged
with `pv_rooftop_df` on "source_id" with `suffixes=("_old", "")`, so the
building ID written back to `generators_df` comes from the scenario data and
the guessed one survives only as the unread column `building_id_old`. Every
PV rooftop generator is either decommissioned and removed, or matched and
updated from the scenario, so there is no path on which the guess is read.
Setting the building ID of all 2472 conventional loads in the test grid to a
sentinel value changes nothing about the generators the function produces,
and `generators_df` is byte-identical with and without the block. Fixing the
deduplication would therefore have preserved a computation whose only
remaining observable behaviour was this crash.

`loads_df` was read for the map alone, so the function no longer touches the
loads at all.

The regression test is kept as a guard against reintroducing a per-bus load
lookup. The shipped test grid cannot produce the situation on its own: it has
70 buses with more than one conventional load, but all of them share a single
building ID, so the second building is added explicitly. The test fails on dev
with the exact error above.
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

1 participant