-
Notifications
You must be signed in to change notification settings - Fork 14
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
Handle missing type and subtype of Generators #35
Comments
I'd like to get a better understanding why this happens in DP. Is it a bug or a feature? |
I will check if problem occurs with unstable dataset. |
The type-subtype list in both versions match.
all types are filled, there's only one empty subtype in type |
Thanks for the investigation on this! I'm wondering that missing type specification only occurs at subtype of solar. @miguelparadacontzen found missing subtype of run_of_river Besides that, I gives sense that both RES datasets in open_eGo have the same missing subtype (solar). Both table found on the same EE Anlagenregister. Further questions/ thoughts
|
@miguelparadacontzen Is the subtype still missing in the current data? (see link above) Concerning your questions: I'd set the subtype in ding0, not in eDisGo.
|
With the current version of the dev branch, running dingo over all MV districts from 4 to 3607, gives the following generation type/subtypes at MV level:
"other" comes whenever subtype==None |
At LV level:
|
Thx! |
Had short chat with @wolfbunke: Missing subtypes of solar PP originates from from missing data in EE Anlagenregister which cannot be resolved that easily in DP. Means, we need to use assumptions in order to this. Hence, we can resolve it entirely in Ding0. |
I can take care of it.. |
@miguelparadacontzen How can I get these statistics
in dingo? I tried your stats branch but got only CSVs with detailed data.. |
I wrote a small script to get those numbers from the saved .csv file with the stats that I have locally in my hard drive:
|
Cheers! |
If a subtype of a RES generator is unknow it is set to 'unknown'. Conventional generators' subtype is set to 'unknown' by default. Tested with MV grid districts in Ding0 and eDisGo. * 391 * 2507 * 1066 * 1117 * 1167 Above MVGDs include both RES generators with unknown subtype and conventional generators. For further discussion details see [here](openego/eDisGo#35).
This should be fixed by openego/ding0@effb54e. If it's still an issue, please reopen. |
Great! But why didn't you work with the assumptions from above? Do you want to be strict not to use further assumptions additionally to the original data provided by OPSD? |
To be honoest, I overlooked it. I'm undecided if we want to mix up data provided by OPSD dataset and own assumptions. They are quite valid (I would guess) but we cannot be sure... I'll give you a call on that soon |
We keep it for now. |
Problem
Some generators imported from Ding0 data do not have specified and type and/or subtype. We need this information for several things
Thus, we somehow need to define type/subtype if this information is missing.
Ideas/ Questions
@birgits votes for solving the issue in the DP. In general, I agree on that, but I will take us a while until we have a versioned version of this data (meanwhile we can work with model_draft but even this takes time).
Thus the idea would be to temporarily implement a workaround in eDisGo that assign data for missing type and subtype.
We could replace each missing type/subtype by 'other' or 'unknown'. This is simply straightfoward but causes other issues. For example if the type is missing, we should anyhow guess its type in order to find the right time series for this generator. For this we can create a translation dict that re-maps subtypes (when type is missing) to the actual type.
The text was updated successfully, but these errors were encountered: