Use extendable lines to replace load shedding

[lukasol]

Depending on the results of load shedding analyses in #19 allow the respective lines (those that connect nodes with increased load shedding) to be extendable. Then test this functionality and its potential to replace load shedding in a new run.

[lukasoldi]

@kimvk could please state your current progress briefly here? Thanks!

[kimvk]

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.

[ulfmueller]

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.

[kimvk]

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.

[ulfmueller]

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 :)

[MarlonSchlemminger]

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.

[MarlonSchlemminger]

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.