Closed junglegobs closed 2 years ago
Indeed, removing the network constraints means that there is no more reserve shedding for day 208, and also it is solvable for a limit of 0.9 (makes sense since no reserve shedding anymore). I should add that I removed the constraint on the initial commitment.
In the case of day 5 (which should have scarcity in redispatch), a limit of 0.5 is possible (again without enforcing the initial unit commitment, which come to think of it, probably not the best idea to begin with given that it probably under estimates the required commitment).
It also does appear to work - if I reduce the reserve shedding limit from 0.5 to 0.4 I reduced sum(rsL+)
by ~ 1,000 MWh (I forgot to save the terminal output).
Suggestions from Kenneth:
It seems that the network constraints lead to more reserve shedding, but still feasibility for day 5 (first case is linear model, no network, second case is with network. Not network constraints included in the operating reserves.)
I have entered a new world of pain. Suddenly even the easiest day (214) is infeasible, and this even if I ignore network constraints. Currently figuring out how many scenarios I have to exclude until its feasible again.
I think that the infeasibility came from the downwards reserves, though not sure. I had negative demand levels for some nodes (due to to storage) which may have led to weird effects.
Scratch that, the feasibility came from the fact that I had reduced the reserve coverage...
I've realised that my storage charges and discharges at the same time, I assume so that some generators can stay online and not shut down:
Fixed:
Something extremely strange is going on, I am able to run units below the minimum stable operating point despite having them committed. Seriously need to investigate this.
EDIT: no minimum stable operating point is given, jezus...
Ok, so fixed that, also fixed a bug regarding simultaneous storage charging and discharging which was breaking things, see b0104328d3badb97d8690d9997af8ecafb1a1628 and 12e1c7dffcb0b465214e89ffda10c64f5c771f6f.
Now everything "works", even with a strict reserve shedding limit, except if I try to include my network redispatch constraints.
Hmmm, ok, so relaxing the reserve shedding limit by 10% means the model is feasible, though even after 500 seconds no solution is found. Perhaps I can fix this by not imposing a solution method for Gurobi?
Indeed it does seem to fix things, woo!
Ok, I'm closing this, with the caveat that I can't have a 0% reserve shedding limit and also including several reserve levels greatly increases computation time (and I'm not bothered right now).
For day 208, the minimum this limit can take appears to be ~0.925. Perhaps due to network constraints.