Comments (13)
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.
Related Issues (20)
- Dealing with other flexibility options in redispatch calculation
- Explicitly determine redispatch for electrolyzer
- incompatible python version due to pypsa restriction HOT 1
- Function "select_elec_network" can not be used for market-optimization
- Allow dynamic line rating when using SCLOPF HOT 1
- Split extended lines within sclopf
- Update path to unit commitment file HOT 1
- Dev failing when importing scenario data HOT 2
- Gas clustering is failing
- My model from the eTraGo data has many overloaded lines
- Clean up appl.py
- Gas clustering not working with status2019
- Adaptation to eGon-data's Updated Power Capacity Specification for Gas Power Plants HOT 1
- Implement adjustments based on method validation
- Define method for AP7
- Calculations in plotting functions: calc_ac_loading, calc_dc_loading, plot_grid
- Calculations in plot function: calc_dispatch_per_carrier
- Incorrect Handling of X and R Values for Transformers During LOPF HOT 4
- Misleading naming of cross border flow functions HOT 1
- ramp_up generators not dispatching
Recommend Projects
-
React
A declarative, efficient, and flexible JavaScript library for building user interfaces.
-
Vue.js
🖖 Vue.js is a progressive, incrementally-adoptable JavaScript framework for building UI on the web.
-
Typescript
TypeScript is a superset of JavaScript that compiles to clean JavaScript output.
-
TensorFlow
An Open Source Machine Learning Framework for Everyone
-
Django
The Web framework for perfectionists with deadlines.
-
Laravel
A PHP framework for web artisans
-
D3
Bring data to life with SVG, Canvas and HTML. 📊📈🎉
-
Recommend Topics
-
javascript
JavaScript (JS) is a lightweight interpreted programming language with first-class functions.
-
web
Some thing interesting about web. New door for the world.
-
server
A server is a program made to process requests and deliver data to clients.
-
Machine learning
Machine learning is a way of modeling and interpreting data that allows a piece of software to respond intelligently.
-
Visualization
Some thing interesting about visualization, use data art
-
Game
Some thing interesting about game, make everyone happy.
Recommend Org
-
Facebook
We are working to build community through open source technology. NB: members must have two-factor auth.
-
Microsoft
Open source projects and samples from Microsoft.
-
Google
Google ❤️ Open Source for everyone.
-
Alibaba
Alibaba Open Source for everyone
-
D3
Data-Driven Documents codes.
-
Tencent
China tencent open source team.
from etrago.