Comments (7)
I pushed the new code. I set all lines and transformers extendable and the capital cost to 1 million. The results of s_nom_opt for the lines and the transformers are saved in two csv fils, which can replace the old s_nom in a new calculation. If we calculate without loadshedding and with the data from the csv files the computation time is essentially faster.
from etrago.
@kimvk could please state your current progress briefly here? Thanks!
from etrago.
When I allow all lines to be extendable, load shedding disappears.
If I extend only the lines connected to the nodes with load shedding, load shedding is lowered, but most load shedding spots will remain.
Next step will be to extend the lines which are connected to the lines extended before until load shedding disappears. This will slower the computation time, because after each extension of the lines, the LOPF will be calculated again to see if load shedding still exist.
from etrago.
maybe we do not have to be that complicated. How does the solution look when you allowed all lines to be extended? Can we may be use this solution as the desired 'debugged' data solution?
Is there a huge grid expansion or only a slight one concerning only the effect of load shedding? Does the dispatch change dramatically or only slightly?
Maybe we can fix the generator dispatch of the load shedding lopf with the help of p_min_pu to limit a substantial change of dispatch and only tackle the load shedding.
Or even better you just set the capital cost of the lines to a very, very expensive value - that it wont change the dispatch substantially and only fix the problems caused by load shedding (load shedding turned off of course) because it has to supply the load. I think that is a very good idea. @kimvk Can you try this out? It should be a fast, easy and nice solution.
Sorry for doing a simultaneous thinking-writing and letting you read my thoughts... I think you can read right away the last paragraph.
from etrago.
Cool, I will use your code perform a lopf for the entire year and calculate s_nom_opt which we can use in the following for the base grid without load shedding :)
from etrago.
I've pushed a new version of code. Two csv-Files (one for transformers, one for lines) including all components with changed s_noms are produced and can then be used to overwrite s_noms in the next run. In a new environment on the server with most recent versions of etrago and egoio, it looks like there are no unbounded timesteps anymore (at least some timesteps which were unbounded before are now feasible). This means we can probably run this as soon as the dp run is finished.
from etrago.
The most recent versions of egoio and etrago didn't solve the issue with unbounded problems entirely, but I identified generator_noise as another solution. Using noise values generated on the server make some timesteps unbounded, whereas noise values generated on my local computer and then copied to the server make them feasible. I calculated over a 100 timesteps now and all are feasible with local noise values. The reason is unclear to me, but it at least seems to be a workaround.
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.