More precise limits on nodal reserve activation from aggregated reserve activation

[junglegobs]

Indeed on some nodes the imbalance appears to have a maximum of 0. This is mean values, need to look into the bounds.

[junglegobs]

So there could definitely be useful bounds for some of the nodes.

More things to consider:

• Timestep dependent bounds
• Bounds which are a linear function of the total imbalance (this sounds trickier however...)
• Bounds which are linear functions of each other (easier to implement than the above since less issues with quantile -> scenario conversion)

[junglegobs]

See these packages for convex hull definitions:

• https://juliareach.github.io/LazySets.jl/dev/man/polyhedral_approximations/, actually no this: https://juliareach.github.io/LazySets.jl/dev/man/convex_hulls/
• https://juliapackages.com/p/concavehull

[junglegobs]

opts = options_diff_days(sn)[1]
opts["initial_state_of_charge"] = 0.0
opts["reserve_shedding_limit"] => 0.05
opts["unit_commitment_type"] = "none"
opts["upward_reserve_levels_included_in_redispatch"] = 1:10
opts["downward_reserve_levels_included_in_redispatch"] = 1:10
opts["absolute_limit_on_nodal_imbalance"] = true
opts["time_out"] = 120
gep_abs_lim = run_GEPPR(opts)

opts["absolute_limit_on_nodal_imbalance"] = false
opts["save_path"] *= "_n"
gep_no_lim = run_GEPPR(opts)

gep_vec = [gep_no_lim, gep_abs_lim]
df = DataFrame(
    "Limits" => ["Absolute", "None"],
    "Reserve Shedding" => sum.([gep[:rsL⁺] for gep in gep_vec]),
    "Load shedding" => sum.([gep[:loadShedding] for gep in gep_vec]),
)

2×3 DataFrame
 Row │ Limits    Reserve Shedding  Load shedding 
     │ String    Float64           Float64       
─────┼───────────────────────────────────────────
   1 │ Absolute             0.0     -7.3257e-12
   2 │ None                39.958   -4.26326e-14

EDIT: this is the case whether or not I have constraints on reserve shedding.

[junglegobs]

Ok, so trying to implement convex hull constraints leads to infeasibilities... lets see what Kenneth says on Monday.

[junglegobs]

Idea: reduce number of nodes for which I define a convex hull.

[junglegobs]

Debugging ideas:

• Don't include reserve activation network constraints but just the convex hull, see if that's possible.
• Add some slack and penalise this in the objective to see what's happening.
• Try only upwards/downwards reserve levels.
• Check out "FeasOpt" option in Gurobi.

[junglegobs]

To answer first question, I ran this:

opts = options_diff_days(sn)[4]
rm(opts["save_path"]; force=true, recursive=true)
opts["initial_state_of_charge"] = 0.0
opts["convex_hull_limit_on_nodal_imbalance"] = true
opts["n_scenarios_for_convex_hull_calc"] => 1_000
opts["upward_reserve_levels_included_in_redispatch"] = 1:10
opts["downward_reserve_levels_included_in_redispatch"] = 1:10

gep = run_GEPPR(opts)

... having also commented out the call to make_probabilistic_redispatch_net_zero_node_injection_constraint!(gep), and... the problem is feasible! So the convex hull constraints aren't completely wrong then.

[junglegobs]

Same as above but neglecting downward constraints still leads to an infeasible model. I'm going to call it a day.

[junglegobs]

Noticed that I was not enforcing the absolute limit or convex hull constraints due to a bug (see this commit: 6e8377f3a97cd190c2889f60cafec943608162e1).

For no UC constraints, I get the following results (see log file attached for more details):

2022_05_30_ASoSEPOC_log_file_1.txt

3×4 DataFrame
 Row │ Limits    Reserve Shedding  Load shedding  Objective 
     │ String    Float64           Float64        Float64   
─────┼──────────────────────────────────────────────────────
   1 │ None               39079.1        1587.97  1.02486e6
   2 │ Absolute           47532.5        1633.81  1.46575e6
   3 │ Convex             47532.5        1633.81  1.46575e6

I guess perhaps previous infeasibilities were occurring from the UC constraints? Am also surprised that the convex hull constraints do nothing...

[junglegobs]

I wasn't enforcing the convex hull constraints due to a spelling error. The infeasibilities are coming back now, even for no UC, simultaneous charge/discharge allowed.

Highly unlikely this is due to numerical issues, given that setting Method to dual simplex (1), PreSolve off and NumericFocus to the max (3) did not help.

Now checking whether it continues even if I remove the energy balance (I doubt it, I'm pretty sure I already checked this and the issue is not with the definition of the convex hull).

[junglegobs]

Huh... removing the energy balance still makes it infeasible... Not sure how to interpret that...

I'm going to try the slack constraint approach.

[junglegobs]

Adding slack variables to the nodal imbalance balance (ha) doesn't help, so maybe it really is the convex hull limits which are incorrect? I imagine there might be numerical issues after all?