junglegobs / asosepoc Goto Github PK

Ideas to try:

• Selectively remove scenarios
• Reduce reserve coverage
• Only consider upwards or downwards reserves

For day 208, the minimum this limit can take appears to be ~0.925. Perhaps due to network constraints.

This is the results for the day selection (not that the load was multiplied by 1.5):

days_for_analysis.csv

Clearly there is load shedding for day 285, 1,247 MWh to be precise. However, in my analysis of day 285 I don't observe this load shedding! See here for:

no_OR.csv

This could of course be due to the cyclic storage constraints, but still... suspicious.

The forecast error scenarios I generated using @asutera's code appear to be biased, both when aggregated and also at the nodal level. This is particularly clear for Wind (day 41, top is for node GOUY, bottom is aggregated over Belgium):

This may be fine, if Antonio didn't correct for this (and we could / should), however it may also be an indication of something being very wrong. It is also so "bad" that there are certain hours (9 - 11) in which there are essentially no scenarios in which a negative imbalance occurs, which is unusual to say the least...

For the main_model_runs and the run base_UC=true_DANet=true_RSV=0.0_L⁺=1:10_L⁻=1:10_AbsIm=true) (opts_vec[39]) I get infeasibilities. I have since added slacks to the absimb constraints to see what that does and it's feasible, but even after 800 seconds there's no solution. I will try a quadratic penalty now to see if that helps.

Again I'm getting feasibility issues, I just hadn't noticed them since the reserve shedding limit constraint isn't binding even for very low levels, i.e. it only becomes binding for values < 0.1.

Some thoughts:

• This may be related to the network constraints, so I'm going to try removing my network re-dispatch constraints.
• Similarly can try removing the network entirely to see if that helps.

This isn't really a bug but an observation:

• For day 285, I have load shedding between hours 8 and 11 (see Figure 4 here). This is almost definitely because of storage, and the cyclic constraint on the state of charge. To be confirmed by running the same model without this constraint.
• The "edge effects" that Efthymios noticed were likely due to storage being fully discharged at the end of the day, at which point it could not be used by him to contribute to operational security (see #10, to be confirmed by Efthymios).
• If I start with a state of charge of 0, load shedding occurs entirely in the morning. Can't find proof for this right now, other than I wrote this in an email to Efthymios (on the 27th of May, copied below), but intuitively if the first point is true then this point is too (probably).
• I'm quite convinced that if I removed storage then this would be an absolutely terrible system i.e. lots of load shedding and curtailment. This is because Andreas Belderbos conceived it using a planning model in which the line capacities were fixed, so essentially the only balancing option his planning model had was storage (either batteries or power to gas), hence the impressive (101 GWh!!!) capacity of storage in the system. So this is not really an option.

This is just to highlight the sensitivity of the system to how storage is assumed to operate. I'm going to keep things as they are, i.e. state of charge is 0.5 at the start of the day and there's a cyclic constraint.

Email I sent to Efthymios:

The issues is that the last for the last hour of the day, load shedding is quite great. I originally thought this might be a unit commitment edge effect, but I'm not so sure anymore - at the very least the generation is within bounds:

julia> z_min = [sum(z[(g,n),Y[1],P[1],t]*NPC[g]*MSOP[g] for (g,n) in GN) for t in T]
24-element Vector{Float64}:
 1769.88
 1769.88
 1769.88
 1769.88
 1769.88
 1769.88
    ⋮
 1745.8
 1745.8
 1745.8
  518.0
 1227.8

julia> q_sum
24-element Vector{Float64}:
 6315.010836016901
 6321.0
 6321.0
 6321.0
 6321.0
 6321.0
    ⋮
 1745.8
 1745.8
 1745.8
  518.0
 1227.8

Probably need to ask Efthymios for his results file, because it's currently hard to debug.

Brief description of issue:

We initially decided to select 3-4 days, in which there were varying levels of scarcity. I did this initially by inspecting the residual load (RL) duration curve. However, after fixing many bugs (mostly data input issues), I realised that the RL is not a good indicator of scarcity, since scarcity occurred due to congestion, unit commitment and reserve requirements as well as high RL (see Table 2 here, where inclusion of operating reserves network leads to load shedding).

At that point I was choosing days which led to load shedding for a full year economic dispatch model. While it led to the results shown in the above pdf, I noticed more bugs, and when I solve the full year model now I don't get any load shedding at all (again, because I need UC + operating reserves to trigger load shedding, and including both in a full year model would be computationally expensive). So I went back to selecting based on the RL, but I have the same problem that the "most scarce day" doesn't display any scarcity at all (see #11, where I realised that .

That there is no scarcity is problematic mostly for me, since I want to look at the tradeoff between reserve shedding and load shedding. If there's no load shedding, there's no tradeoff. For interacting with ULiege, it's perhaps less problematic, because in any case my schedule will likely have operational security issues anyway, and their main goal is to train their machine learning algorithm.

Solutions:

• Ignore it, just send Efthymios the new selection of days and don't worry about it.
  • Doesn't resolve anything really.
• Add day 309 to the list of days to analyse, so that I have at least one day where this tradeoff is evident.
  • No justification for doing this, which was the whole point of using the RL in the first place (it's transparent).
• Select a number of days with highest RL, e.g. the first 5, instead of just 1.
  • No real guarantee that this will fix the issue.
  • Adds an unnecessary amount of additional days
• Solve the full year model again, this time with a load multiplier of 1.5 to ensure load shedding, and select days based on that.
  • Seems the most logical option.

So I'm going with the last option. Hopefully it leads to load shedding...

This could be due to excessive renewable curtailment, i.e. renewables are being curtailed just to ensure grid feasibility. To be verified.

It is feasible if storage dispatch is not included. This means that somehow the storage dispatch is leading to infeasibilities obviously, but why...