eHV subnetworks

[eosram]

Working with the networkclustering PyPSA always determines eight subnetworks for a clustered ehv - network. (Based on 'Status Quo' data used for the article.) Seven of those subnetworks consist of 6 or less buses. Those subnetworks render the problem infeasible. How should I handle this?

e.g.

select * 
from model_draft.ego_grid_pf_hv_bus 
where bus_id in (1127,1128,1132,23838,24743,24899)

[ulfmueller]

that are very interesting findings! I assume all transformers 380-220 are included. Get you check which voltage level those subnetworks are in? 220 or 380 or both? Including the transformer the whole system should be one. So these cases seem to be significant routing bugs probably due to faulty/difficult osm information. I suppose we should try to understand these cases and connect them to the main grid (since they probably have some sort of important transmission role). @lukasol I would be interested in what the topology experts say to this. By the way are these 'isolations' also happening in SciGRID?

[ulfmueller]

but in the meantime I would kick out these small subnetworks in order to test your methodology (just as an interim solution). @ilkacu has some scripts for that procedure... How many buses does the subgrid contain, which has more than 7 buses?

[IlkaCu]

Here you find the SQL code I'm usually using to delete subgrids. Obviously the substation-IDs and the scenario names need to be adjusted.

[lukasol]

The example above is a quite well-known structure in Berlin. In osmTGmod we connected it to the 110 kV grid. Note: None of the buses in the example is a "proper" eHV substation. They are either joints or are of voltage 110 kV. I'm wondering why they pop up here?!

@s3pp can you also put the other cases here? I would then compare those to the ones deleted in SciGRID.

[ulfmueller]

Note: None of the buses in the example is a "proper" eHV substation. They are either joints or are of voltage 110 kV. I'm wondering why they pop up here?!

Do I understand you right? In osmTGmod those buses (bus_id in (1127,1128,1132,23838,24743,24899)) are of 110kV? Because after the dp they are definitely 380kV.

[eosram]

Other subnetworks row wise 1127, 1128, 1132, 23838, 24743, 24899 23561, 23574, 26088, 27149, 27330 23795, 26595, 7677 24504, 26179 25533, 25536, 28431 25562, 25564 26299

[lukasol]

Do I understand you right? In osmTGmod those buses (bus_id in (1127,1128,1132,23838,24743,24899)) are of 110kV? Because after the dp they are definitely 380kV.

Yes, they are also in osmTGmod 380 kV, but not in OSM. So they must have been assigned to 380 at some point in the abstraction. I'll go hunting, you can guess my mood.

[lukasol]

The buses are not only 380 kV, they are just "on top" of 110 kV buses (because substations are divided by voltage in otg). However, the subnetwork problem still persists. I checked the ones mentioned by @s3pp

1127, 1128, 1132, 23838, 24743, 24899

Berlin subgrid, see above.

23561, 23574, 26088, 27149, 27330

Kraftwerk Weiher (Saarland), there is a proper OSM line missing somehow, don't see the reason why.

23795, 26595, 7677

That's one of the subgrids also deleted in SciGRID --> OSM mapping issue

24504, 26179

also in Saarland, another line connecting the subgrid is missing in otg, why?

25533, 25536, 28431

Sweden connection.

25562, 25564

I don't see why this is a subnetwork. Can you also provide the lines that are not connected?

26299

Kraftwerk Weisweiler.

There was a bugfix concerning power plant connections by wupperinst. Since some of the subnetworks are power-plant specific, I'll check for that. Otherwise, I was told that some of the subnetworks are quite close to the national border and that there might by an issue with cross-border lines. I will also follow that approach.

[lukasol]

Generally, I would propose to go ahead with deleting the subnetworks until we resolve this issue (either by bugfixing or by a connection approach)

[ulfmueller]

But we have to check what generation/demand is connected to these buses and if there is underlying 110kV infrastructure with again demand and generation. If we delete that stuff we get troubles when disaggregating results from the ehv level to the hv level and might lose hv-mv substations which are a interfaces to the MV world. Also for example just deleting the entire connection to Sweden does not seem very handy.

[lukasol]

That's true. I implemented a query to connect eHV subgrids in osmTGmod, seems to work fine. It can, however, only be checked with the full data set / for the LOPF when the dp runs again with this new dataset.

[ulfmueller]

@lukasol can you check what happened to the connection Lübeck-Siems (Sweden connection) after applying the algorithm? Since there is a 380kV at Siems but only coming 220 from Lübeck I wonder if the algorithm connects it with the help of a transformer to the next 220kV(Lübeck) or goes to very far away 380kV...

[lukasol]

I checked. It's not connected :(

I'll check on that...it seems the algorithm does not work as expected.

[lukasol]

I could change the algorithm so that the 380kV line is connected to the 220 kV grid. Since there is a connection via the 110 kV grid, I am not certain if we should really implement a separate connection algorithm for eHV at all. Let's discuss this at the next opportunity.

[lukasol]

Since this is osmTGmod related, refer to https://github.com/openego/osmTGmod/issues/10 for future discussions.