Calculations eGon2035

[ClaraBuettner]

I will start some calculations on the server over the holidays (especially for the eTraGo paper). Please comment here if could would like to add a setting for calculations or sensitivity here.

Current list of settings:

• eGon2035: 300 AC nodes, 80 CH4 nodes, every 5th snapshot, limited imports
• eGon2035_lowflex: 300 AC nodes, 80 CH4 nodes, every 5th snapshot, limited imports (same grid as in eGon2035)
• eGon2035: 300 AC nodes, 80 CH4 nodes, every 3rd snapshot, limited imports
• eGon2035_lowflex: 300 AC nodes, 80 CH4 nodes, every 3rd snapshot, limited imports (same grid as in eGon2035)

[KathiEsterl]

Maybe we could also give it another try with the k-means Clustering? = eGon2035: 300 AC nodes (kmeans), 80 CH4 nodes(kmeans), every 5th snapshot, limited imports

Additionally, I would be interested in an calculation with 500 AC nodes. = eGon2035: 500 AC nodes (kmedoids), 80 CH4 nodes(kmedoids), every 5th snapshot, limited imports

Both variations are not of very high priority, but maybe you could add them to the end of the calculation-queue?

[ClaraBuettner]

Maybe we could also give it another try with the k-means Clustering? = eGon2035: 300 AC nodes (kmeans), 80 CH4 nodes(kmeans), every 5th snapshot, limited imports

Additionally, I would be interested in an calculation with 500 AC nodes. = eGon2035: 500 AC nodes (kmedoids), 80 CH4 nodes(kmedoids), every 5th snapshot, limited imports

Both variations are not of very high priority, but maybe you could add them to the end of the calculation-queue?

Sure, I can add this. Should I try to re-use the same bus weighting or sth for comparison?

[KathiEsterl]

Maybe we could also give it another try with the k-means Clustering? = eGon2035: 300 AC nodes (kmeans), 80 CH4 nodes(kmeans), every 5th snapshot, limited imports Additionally, I would be interested in an calculation with 500 AC nodes. = eGon2035: 500 AC nodes (kmedoids), 80 CH4 nodes(kmedoids), every 5th snapshot, limited imports Both variations are not of very high priority, but maybe you could add them to the end of the calculation-queue?

Sure, I can add this. Should I try to re-use the same bus weighting or sth for comparison?

In the best case, we would use the same busmap from the k-medoids Clustering (before the Dijkstra assignment) as result of the k-means Clustering. Normally, this should be the case when setting the respective random_state. It might be working for the eGon2035 scenario if the differences in the former calculations really come from some less flexibilities in the low flex scenario.

[KathiEsterl]

Maybe we could also give it another try with the k-means Clustering? = eGon2035: 300 AC nodes (kmeans), 80 CH4 nodes(kmeans), every 5th snapshot, limited imports Additionally, I would be interested in an calculation with 500 AC nodes. = eGon2035: 500 AC nodes (kmedoids), 80 CH4 nodes(kmedoids), every 5th snapshot, limited imports Both variations are not of very high priority, but maybe you could add them to the end of the calculation-queue?

Sure, I can add this. Should I try to re-use the same bus weighting or sth for comparison?

In the best case, we would use the same busmap from the k-medoids Clustering (before the Dijkstra assignment) as result of the k-means Clustering. Normally, this should be the case when setting the respective random_state. It might be working for the eGon2035 scenario if the differences in the former calculations really come from some less flexibilities in the low flex scenario.

To be very sure, we can export a k-means busmaps during the k-medoids Dijkstra Clustering and use this one for the k-means clustered network. If that is not too much work for you, that it would be great! I can also send you some lines for that, I did the export here: https://github.com/openego/eTraGo/blob/0a079ef3487440524eb4d06371af2d11f5ead4b0/etrago/cluster/spatial.py#L703 This would be the very safe option, I guess. But, as I said before, I don't know if it is necessary.

[KathiEsterl]

Maybe we could also give it another try with the k-means Clustering? = eGon2035: 300 AC nodes (kmeans), 80 CH4 nodes(kmeans), every 5th snapshot, limited imports Additionally, I would be interested in an calculation with 500 AC nodes. = eGon2035: 500 AC nodes (kmedoids), 80 CH4 nodes(kmedoids), every 5th snapshot, limited imports Both variations are not of very high priority, but maybe you could add them to the end of the calculation-queue?

Sure, I can add this. Should I try to re-use the same bus weighting or sth for comparison?

In the best case, we would use the same busmap from the k-medoids Clustering (before the Dijkstra assignment) as result of the k-means Clustering. Normally, this should be the case when setting the respective random_state. It might be working for the eGon2035 scenario if the differences in the former calculations really come from some less flexibilities in the low flex scenario.

To be very sure, we can export a k-means busmaps during the k-medoids Dijkstra Clustering and use this one for the k-means clustered network. If that is not too much work for you, that it would be great! I can also send you some lines for that, I did the export here:

https://github.com/openego/eTraGo/blob/0a079ef3487440524eb4d06371af2d11f5ead4b0/etrago/cluster/spatial.py#L703

This would be the very safe option, I guess. But, as I said before, I don't know if it is necessary.

Okay, I just use the random_state and I hope it will be the same!

(I tried to check it, but ran into one problem about overwriting, just found out the reason one minute before I have to leave now and can't check it again, sorry. We just hope it is working!)

[KathiEsterl]

Maybe we could also give it another try with the k-means Clustering? = eGon2035: 300 AC nodes (kmeans), 80 CH4 nodes(kmeans), every 5th snapshot, limited imports Additionally, I would be interested in an calculation with 500 AC nodes. = eGon2035: 500 AC nodes (kmedoids), 80 CH4 nodes(kmedoids), every 5th snapshot, limited imports Both variations are not of very high priority, but maybe you could add them to the end of the calculation-queue?

Sure, I can add this. Should I try to re-use the same bus weighting or sth for comparison?

In the best case, we would use the same busmap from the k-medoids Clustering (before the Dijkstra assignment) as result of the k-means Clustering. Normally, this should be the case when setting the respective random_state. It might be working for the eGon2035 scenario if the differences in the former calculations really come from some less flexibilities in the low flex scenario.

To be very sure, we can export a k-means busmaps during the k-medoids Dijkstra Clustering and use this one for the k-means clustered network. If that is not too much work for you, that it would be great! I can also send you some lines for that, I did the export here: https://github.com/openego/eTraGo/blob/0a079ef3487440524eb4d06371af2d11f5ead4b0/etrago/cluster/spatial.py#L703

This would be the very safe option, I guess. But, as I said before, I don't know if it is necessary.

Okay, I just use the random_state and I hope it will be the same!

(I tried to check it, but ran into one problem about overwriting, just found out the reason one minute before I have to leave now and can't check it again, sorry. We just hope it is working!)

I checked it again today, random_state-setting is working as hoped while using only one scenario.