Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Fix topological errors within 380 and 220 kV level with respect to ENTSO-E map #10

Open
ulfmueller opened this issue Apr 26, 2017 · 35 comments
Assignees

Comments

@ulfmueller
Copy link
Member

When abstracting the 380 and 220 kV grid some sub grids are occurring which obviously are stating errors mainly due to osm data issues. See this issue for more information on these locations.

Apart from developing and using subgrid connection algorithms we want to use the ENTSO-E grid map in order to fix these errors by changing openstreetmap.org

@ClaraBuettner : I think that could be a fun job for you. What do you think? Do you need any more details? Just contact me when you have time for this.

@ClaraBuettner
Copy link

Just to be sure, I should try to connect them by subgrid connection algorithms and if that doesn't work change openstreetmap.org?
I think I can start next week, probably I ask for more details at that time.

@ulfmueller
Copy link
Member Author

the subrid connection algorithm is already implemented by @lukasol ... Your task would be to change osm by looking at the ENTSO-E map. That way the algorithm would not be needed not that much and we get more realistic data and at the same time give that effort back to osm...
yeah just ask for more detail when you are ready...

@ClaraBuettner
Copy link

Okay, sorry for misunderstanding. Up to now, I have never worked with osm.
I wanted to start looking for the errors in osm. But I couldn't find an osm-layer for electricity which divides in different voltage levels. Can you help me with this?

@ulfmueller
Copy link
Member Author

The key voltage defines the voltage of a cable in osm. If you take for example this power line from Lübeck to Siems at has a voltage of 110 kV. On the same route there is a 220 kV (ENTSO-E grid map) missing which you could add to openstreetmap. Actually it seems that there is not a line missing (see also satallite pictures like at bing or google) but there is 2 lines with each 6 cables (2 systems). It total there are 4 systems of 110kV but I would think that at least one the systems is a 220kV. If it is like that. It would be an relatively easy change. You would not have to add a new line and think about where to but it (including the poles) but only have to change the voltage level of the particular system from 110000 to 220000...

@ulfmueller
Copy link
Member Author

if your about to have some trips to places it like that in Schleswig-Holstein you could also use and check out this app

@ClaraBuettner
Copy link

I just added a 220kV from Lübeck to Siems, hopefully that was right.
Looking for the other busses, it seems that some are transformers (bus_id 25562 and 25564), I couldn't find unconnected busses or lines there. Maybe there is a problem with them?

@ClaraBuettner
Copy link

Fix topological errors within 380 and 220 kV.pptx

I've collected everything I've found in a PPP. In some cases I could not see anything causing the error.

@ulfmueller
Copy link
Member Author

Cool, thx! Could you also upload it as a pdf?

@ClaraBuettner
Copy link

Fix topological errors within 380 and 220 kV.pdf

@ClaraBuettner
Copy link

I would like to fix the errors but, apart from the Lübeck Siems connection, we have not discoussed how I should do this...

@ClaraBuettner
Copy link

I just took a closer look at the transformer station in Uchtelfangen. It seems that some lines got the wrong voltage level. Two 220 kV lines are missing in the DB, one of them is as well 110 kV. But in the substation, both are connected via an 110kV line. Satelite pictures show that the line is connecteted to the 220kV busbar, in osm it is also connected to the 110kV busbar, I can't see that on the pictures.
So I guess there is a mistake in osm.
u1

@ulfmueller
Copy link
Member Author

I am sorry I am not sure about the 'take-home-message'. Can you fix what is wrong in osm? Change 110kV to 220kV(did I understand it more-or-less right?)? At the same time do you think you can fix it in the post-processing being part of the data processing (as we discussed it)?

@ulfmueller
Copy link
Member Author

@lukasol I just mention you here so you are informed. Clara and I went through that presentation (see pdf above) which tried to cover the cases which popped up in the context of the ehv clustering.
We decided to introduce a fixing-script in the dp (powerflow part after reading the osmTGmod data) in that way, that it seems right. Only in the cases where it is very sure we would fix it in osm (unfortunately that is the case very seldomly).

@ClaraBuettner
Copy link

Yes, I would change the voltage level and delete a line I can't see on satelite pictures.
In addition, I add the line to the script I am writing as we discussed it.

@ClaraBuettner
Copy link

I just changed some voltage levels from lines in Uchtelfangen in osm respecting bing and entso-e.

@ClaraBuettner
Copy link

I added the script to the feature branch. Up to now there are still some problems.
For the errors in Weiher and Heinitz, the lines will just be added if they havn't exist before.
I tried to do the same for Lübeck, but the missing line has the same geom as an existing line, just with another voltage level. But the voltage level is not defined in the line-table, so I couln't find a possibility to get that running.
Maybe I find another solution, so the file is only temporary.

@ClaraBuettner
Copy link

I added electrical parameters to the lines, I took the one for transmission lines, as listed on GitHub.
If it was possible, I chose the number of cables from entso-e, otherwise I implemented 2 systems.
Hopefully thats all right.
Unfortunately, I couldn't find a solution for the line in Lübeck.

@ClaraBuettner
Copy link

I was just looking at the problem again. I'm afraid I had to notice that the script I wrote won't work. It deletes buses which are needed for components like generators. In some cases, the power is very small and it can be reconnected to a bus with the same geom, but not always.
I tried to figure out a new method but in some cases it is really difficult to find a good way.
In addition it needs a very long time to test, because I need a new busmap every time I delete or add a bus.

@ClaraBuettner
Copy link

ClaraBuettner commented Jan 8, 2018

Here are some new information about the subnetworks:
The ones in Lübeck, Weiher and Heinitz can be fixed by adding a line, which was already discussed before. For the others I got more information and other solutions.

In Berlin, there are 380kV lines and buses which shouldn't be there in respect to entso-e. Two buses (Umspannwerk Lichtenberg and Umspannwerk Biesdorf Nord) are used to connect a small solar generator and/or loads. In the osm both are tagged as 110kV stations, and there are 110kV buses in our data. That's why I suggest to reconnect the generator and the loads to the 110kV buses and delete the 380kV buses and lines.

The industrial park in Höchst has a subnetwork due to a 220kV line inside. The osm is nor sure, if it's 220kV or 110kV. Looking at the website of the park, it says they only have high voltage and not extra high voltage. In addition there are mostly 110kV buses with the same geom like the 220kV buses. So I would change the voltage of the line to 110kV by reconnecting it to the 110kV buses and delete the 220kV buses.

The subnetwork in Plattling is caused by a line, which looks different in osm. The substation is divided into two parts, one transforming from 380kV to 110kV and one only with 110kV. But in our data, both have an 380kV bus and are connected via a line which doesn't exists in osm and satellite pictures. There is a quite similar line, connecting the substation to the nearest 380kV line, which is missing in our data. I suggest to delete the line between the substation parts and add the missing line.

The subnetwork in Weisweiler is just one 380kV bus. In our data, it's just connected via a transformer, but in the osm, there are connections to the next 380kV line as well. So I would add a line, like in the osm, that connects the 380kV bus to the 380kV line. All buses are already there, I just need to connect them.

When you agree with the suggestions, I would test it local in the next days.

@ulfmueller
Copy link
Member Author

nice @ClaraBuettner . Your suggestions sound reasonable. We just have to be very careful if we change voltage levels of buses. Especially when we change 380/220 kV buses to 110kV buses.
If buses are changed/deleted/added it influences the whole generator/load assignment procedure. So for a clean process these topology adjustments would have to be included in the data processing with care and at early stages. That is probably nothing you could do or wait for in your remaining bachelor thesis time.
So you need a post-processing method - which at least works for your thesis work.
Please check whether the buses you change have loads/generator attached. If they have, the changes are more critical.
changing/deleting/adding lines is zero critical.
How can you proceed? Anyhow you can do as you suggested and test it locally and see if your changes have the desired effect. You can definitely use this for your thesis. It would be nice if you could document your changes in detail also with some screenshots etc. (because it is hard to understand these things without something graphic). And try to check whether the changes you make could have an effect on our assignment procedure and therefore try to estimate the error which is produced by that. Maybe we can meet on this some time e.g on the second half of next week (so this knowledge does not get lost and we check that you do not commit any major error)...

@ClaraBuettner
Copy link

ClaraBuettner commented Jan 8, 2018

For my thesis, I would reconnect the one-ports to existing buses, so it can be used as a post-processing. Most often, there are already 110kV buses when I need them, there is just one 220kV bus I need to change to 110kV.
I think it's just in the industrial park in Höchst where I need to change from 220kV to 110kV. When this is not possible, I could sum the geoms of the connected lines, then I don't have to do so.
I started documenting while writing the script. It's not ready but the problem with Höchst is hopefully
easier to understand..

subnetworks.pdf

@ulfmueller
Copy link
Member Author

Can you check if the 380kV buses which you want to delete have loads and generators connected?

@ClaraBuettner
Copy link

I already did it, they are listed in the table as generators, loads and storages

@ClaraBuettner
Copy link

I finished the documentation and am currently testing most of the suggested options. Just the one in Pleiting is missing up to now. I need to connect the substation to an existing line, but there is no bus at the position I have to do that. So I'm wondering if pypsa needs lines with the same buses to know that they are connected, or if it's enough that they touch. I suggest the first option, but that would mean I have to split up an existing line. That's why I'm not sure what to do.

subnetworks.pdf

@ulfmueller
Copy link
Member Author

Like you suggest it is not enough if they geographically touch. I think you would have to delete the existing line which you want to split up and then built a new bus and three new lines...

The buses with generators/loads/storages attached are crucial. Can you check how much installed power these units have? It would be good to attach them to the most adequate bus around with respect to our assignment methodology. Maybe @IlkaCu can help you with that.

By the way, are you working with the newest data set (v0.3.0)? The amount of storages in Berlin seem a bit weird to me...

@ClaraBuettner
Copy link

It worked! I created a new busmap overnight and could run the eHV-clustring with just one sub-network, which is the one in Plattling I havn't adjusted yet (as you can read above). Looking at the geometries with qGis, everything worked fine. So I just need to find a method for the last one.
I wrote a SQL-script which works like a post processing at the moment, so I can work with it. To use it in the dp, I can easily delete the lines which reconnect one-ports, which won't be needed then.

@ClaraBuettner
Copy link

Ok, then I will adjust this like you said.
I will take a look at the installed power by now, in some cases I already did so. But the problem won't be there when is't early integrated in the dp, is it?
Yes, I work with the new data. The reason for the high number of storages (and generators as well) is, that the different scenarios have different ids for generators and storages, so in one scenario there is mostly just one third. Does that make it better?

@ClaraBuettner
Copy link

For the generators and storages in Berlin, I somehow made a mistake in the documentation. There is only one 63kW solar generator and two storages with p_nom = 0 in each scenario.
I Höchst, the number of generators per scenario is either 6 (Status Quo, NEP 2035) or 3 (ego 100), and there are two p_nom = 0 storages in each scenario.
The maximum power of a genetrator is 96.5MW, which seems to be to high to connect it in 110kV.
The other sub_networks were fixed without changing buses.
I also updated the documentation.

subnetworks.pdf

@IlkaCu
Copy link
Member

IlkaCu commented Jan 9, 2018

@ClaraBuettner: If you like, we can meet this week and discuss how your changes interact with the DP and how we can bring both together.

@ClaraBuettner
Copy link

That would be great! Can you tell me when you have time for that?

@ulfmueller
Copy link
Member Author

good and thx @IlkaCu! the storages are extendable storages and therefore do not have p_nom values. They are optimization variables - so you do not have to care about them in this case.

@IlkaCu
Copy link
Member

IlkaCu commented Jan 9, 2018

Tomorrow 15:30?

@ClaraBuettner
Copy link

Yes, that's fine.

@IlkaCu
Copy link
Member

IlkaCu commented Feb 6, 2018

@ClaraBuettner: Is there anything which needs to be added to the branch feature/fix_eHV_subnetworks before merging it back into the dev branch?
If not, I would ask you to create a pull request for this branch.

@ClaraBuettner
Copy link

ClaraBuettner commented Feb 6, 2018

Some lines won't be needed anymore when it's included earlier.
Up to now, it is included in utilities as a post-processing. We talked about adding it right after the osmTGmod to pypsa script. Is that still right?
And I did a small adjustment, too. I will upload it like that soon.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

No branches or pull requests

3 participants