Extendable storages in networkclustering about etrago HOT 13 CLOSED

I would suggest to do the clustering before assigning the extendable storage. But that would mean to shift this from the data processing to etrago, which I would prefer anyhow.

Or your disregarding idea sounds good as well and would have the same outcome. I don't know how the clustering would have to be changed. @S3PP: what do you think?

from etrago.

Do you mean that extendable storages would no longer be part of the storages table and their definition takes place in eTraGo? Imo the code would become more explicit by that and separate scenario data and application functionality. I think that would be a good idea. Or did I get your idea wrong? @ulfmueller The far more easier way though is to adapt the networkclustering. This should only be a few lines of extra code.

from etrago.

I agree shifting the storage settings to eTraGo to ensure comparability of the storage parameters for the clustering. I`m not sure whether I got the disregarding idea. It is about fixing the EHV nodes during clustering and therefore the storage settings (parameters remain in data processing) of them won't be averaged?

from etrago.

The idea of "disregarding" was to simply leave out the averaging for storages connected to the EHV and just use the one or two storages directly sited at the EHV node.
That should be quite easy to implement, I guess?! @S3PP

I'm, however, not entirely certain if we'll get any drawbacks from that, e.g. when it comes to dis-aggregating the results back to HV nodes. Do you think that the one EHV storage could be sufficient information to distribute the results in any way of dis-aggregation?

from etrago.

• @S3PP said it would be easy to implement.
• Maybe due to the underground storage potentials it could be a bit more tricky...
• What do you think about the idea of moving the extendable storage functionality to eTraGo?

from etrago.

Maybe due to the underground storage potentials it could be a bit more tricky...

That would be okay, since we thought about reducing the underground storages to EHV nodes anyway...(since they will be too big for HV)

What do you think about the idea of moving the extendable storage functionality to eTraGo?

I think it's too much effort for too much nice-to-have. But could be realized if it turns out to be necessary.

from etrago.

I think it's too much effort for too much nice-to-have. But could be realized if it turns out to be necessary.

probably. ok, then I would say we go into the 'adjustment of ehv network clustering direction'.

disaggregation is anyhow a challenge. Since these storages are an optimization variable and we only will optimize on the ehv level, in general I think it is ok to disregard the storage variables on the hv levels. In particular, I guess we should develop our methodology of disaggregation in order to be sure about this #22 @IlkaCu

Moreover, the k-means clustering might be even more tricky in this context, due to the fact that a new grid is created based on the old one. In the easiest approach you could probably argue the same as in the case of the ehv clustering.

from etrago.

I talked to @S3PP a bit yesterday. In this context I had an idea. In both clustering methods the generators are aggregated with respect to their carriers. Would it be an option to cluster the ext. storages (as well as the already existing ones) with respect to their attributes, in which they differ? In which ways do they differ? max_hours, due to the two types long-term and short-term storage? Then we could cluster with respect to max_hours and have at each node ehv node after clustering several aggregated storages. e.g. 2, one short-term and one long-term.
@lukasol Did I explain myself? What do you think?

That way we might also get a good solution for the existing storages...

from etrago.

Well, yes you explained yourself. Generally, that sounds good. Since we don't have capacity limits for the extendable storages (well, it is 1000000 currently), there is not really much difference between clustering the storages of the same class and just applying one storage per class.
So I think clustering only makes sense for the existing storages and here I would prefer your solution of aggregating by class of storages (max_hours).

from etrago.

@S3PP I humbly ask you if it would be possible be for you to implement a clustering of storages with respect to their 'max_hours' (comparable with the methodology for the generators and their 'carriers')?
If it is not possible for you, maybe you can show me how/where you would implement this...

We decided that this would be the most adequate solutions since this works for the existing as well as for some extendable storages... (by the way I wonder how the pypsa guys handle this for the existing storages)

from etrago.

@ulfmueller Of course I can try to implement it next week or at least start to do so and keep you up to date here!

from etrago.

Ups, thought this would solve the issue. It does not. Will look into it.

from etrago.

I had to come up with a solution so that PyPSA's _flatten_multiindex (networkclustering.py) does not have to handle a Float64Index inside the Pandas Multiindex of the grouped new_df DataFrame. I don't know how to handle this in a better way. It's hard coded for max_hours now : (.

from etrago.