search

openego / powerd-data

GNU Affero General Public License v3.0
1 stars 0 forks source link

Wrong pumped_hydro generators installed capacities #219

Closed CarlosEpia closed 5 months ago

CarlosEpia commented 6 months ago

There are only pumped_hydro generators for Germany and the sum-up is smaller than expected in the scenario2019.

khelfen commented 6 months ago

Hey @CarlosEpia :) We can confirm your findings for status2023. We have pumped hydro capacity of 3.3 GW in our model, but it should be 9.5 GW in Germany.

Besides your existing fix, we found that here pumped hydro outside Germany is dropped. It should be checked if these pumped hydro plants are connected to the German grid. If so they should not be dropped for the "Everything" run.

nailend commented 6 months ago

Besides your existing fix, we found that here pumped hydro outside Germany is dropped. It should be checked if these pumped hydro plants are connected to the German grid. If so they should not be dropped for the "Everything" run.

image

These are the ones, which are dropped (1.7 GW). As they are quite far away from the german border, we assume its fine.

CarlosEpia commented 6 months ago

Hi @khelfen and @nailend, I was just dealing with these storages. I will include them as part of Germany since they are operated by a German network operator as part of their system. You can see some details here

nailend commented 6 months ago

Around 1.8 GW of pumped-hydro capacity is missing (https://www.marktstammdatenregister.de/MaStR/Akteur/Marktakteur/DetailOeffentlich/2679571#zugehoerigeEinheiten). This is due, to missing data in the openMastR dump from 2001, which is used for pumped hydro. The pp were registered only in january 2021 in MastR. Although the mastr dump used for hydro-power is from may 2021, the data was still missing.

To fix this, we propose to use the newest dump from january 2024 (https://zenodo.org/records/8225106) or at least the one from 2022 (this is simply done by switching to the mastr_new_working_dir. Probably this commit is also needed to avoid a conversion error of plz)

CarlosEpia commented 6 months ago

I would be in favour of using a newer dump from 2024 if it does not require too many changes. Maybe we could check if there are new column names or significant changes (like the last time we changed the MastR dump) and probably just replace cleanly the data that we used when we refer to mastr_new_working_dir.

nailend commented 6 months ago

I would be in favour of using a newer dump from 2024 if it does not require too many changes. Maybe we could check if there are new column names or significant changes (like the last time we changed the MastR dump) and probably just replace cleanly the data that we used when we refer to mastr_new_working_dir.

The zenodo record I linked, is already cleaned and formated by @nesnoj. I already implemented it for hydro power storage in status2023. We will give feedback as soon as we have checked the results.

nesnoj commented 6 months ago

The zenodo record I linked, is already cleaned and formated by @nesnoj. I already implemented it for hydro power storage in status2023. We will give feedback as soon as we have checked the results.

No, the one you linked is the general open-mastr release record, the correct ones with special eGon-data are:

nailend commented 6 months ago

No, the one you linked is the general open-mastr release record, the correct ones with special eGon-data are:

ups, thanks for clarifying!

@CarlosEpia I wrote a new pumped_hydro function, only using the MaStR-data and assigning capacities outside germany to the closes foreign buses at their voltage-level. This results in a total of 9.7 GW. There is no differentiation for SH or whole germany though. And no filter for commissioning.

CarlosEpia commented 6 months ago

Hi @nailend I tried to use the mentioned new function and it works quite well also using the mastr from 2022. Are you planning to use your model in eTraGo? If that is the case, assigning the foreign pumped hydro generators to their foreign closest bus can be problematic. During the execution of the clustering process, eTraGo clusters all the buses that belong to the same foreign country (except the UK and Denmark). It is made under the assumption that only one bus has elements as loads, generators, etc.

Could it be an option for you to limit the possible foreign buses to connect the pumped hydro generators to the buses returned by this function?

nailend commented 6 months ago

@CarlosEpia thx for the hint. As we will not apply any spatial clustering this shouldn't be a problem for us but definitely worth mentioning in the docstring. @khelfen fyi

khelfen commented 6 months ago

Hi @nailend I tried to use the mentioned new function and it works quite well also using the mastr from 2022. Are you planning to use your model in eTraGo? If that is the case, assigning the foreign pumped hydro generators to their foreign closest bus can be problematic. During the execution of the clustering process, eTraGo clusters all the buses that belong to the same foreign country (except the UK and Denmark). It is made under the assumption that only one bus has elements as loads, generators, etc.

Could it be an option for you to limit the possible foreign buses to connect the pumped hydro generators to the buses returned by this function?

In this case I would suggest that eTraGo should aggregate all loads and generators within a country and assign them to a bus before running the cluster algorithm. Or am I missing something important why this is not done in eTraGo?

For our project we do not plan to use spatial clustering and it should have no effect.

CarlosEpia commented 6 months ago

Hi @nailend I tried to use the mentioned new function and it works quite well also using the mastr from 2022. Are you planning to use your model in eTraGo? If that is the case, assigning the foreign pumped hydro generators to their foreign closest bus can be problematic. During the execution of the clustering process, eTraGo clusters all the buses that belong to the same foreign country (except the UK and Denmark). It is made under the assumption that only one bus has elements as loads, generators, etc. Could it be an option for you to limit the possible foreign buses to connect the pumped hydro generators to the buses returned by this function?

In this case I would suggest that eTraGo should aggregate all loads and generators within a country and assign them to a bus before running the cluster algorithm. Or am I missing something important why this is not done in eTraGo?

For our project we do not plan to use spatial clustering and it should have no effect.

@khelfen Since you are not going to use spatial clustering in eTrago I think it is fine for you to leave it like it is now. In our case, I will implement that small change, considering that we plan to use that function and eTraGo decides how many and which buses to keep per foreign country based on the condition of loads, generators or storage units attached to them. It is important for the case of the UK and Denmark. Additionally, all the data used from Entsoe allows only that level of spatial complexity.