Economic Dispatch formulation

[klamike]

Adds the EconomicDispatch formulation, to match the E2ELR paper.

Todo:

• [ ] Add tests for soft versions
• [x] Add a way to export the PTDF to H5
• [x] Add reserve data generators
• [x] Integrate reserve sampling into OPFSampler (note, currently only the method described in the E2ELR paper is supported, which does not match how UnitCommitment.jl generates reserve data)

New formulation checklist:

In exp/config.toml:

• [x] Add an entry to the OPF table

In src/opf/opf.jl:

• [x] Add to SUPPORTED_OPF_MODELS
• [x] Add to OPF2TYPE
• [x] Include src/opf/<opf>.jl

In src/opf/<opf>.jl:

• [x] Implement build_opf
• [x] Implement solve!
• [x] Implement update!
• [x] Implement extract_result
• [x] Implement json2h5

In test/opf/opf.jl:

• [x] Add to OPT_SOLVERS
• [x] Include test/opf/<opf>.jl

In test/opf/<opf>.jl:

• [x] Implement test_opf_pm

In test/sampler.jl:

• [x] Add to the test config in test_sampler_script
• [x] Implement _test_update

[klamike]

Also need to decide how to export the PTDF. In my standard form code link1 link2, I re-build the model at H5-merge-time in order to include the constraint matrix in the final H5 but this is not very nice.

An alternative would be to:

1. Have sampler.jl always write an H5 file, each one containing the PTDF
2. Edit the merge script to not stack certain keys (corresponding to the PTDF), instead checking if the matrix is the same from chunk to chunk

[mtanneau]

Also need to decide how to export the PTDF

Since this is a (dense) matrix, the easiest would probably be to save it to a specific file. We can do .h5, we can also do .npx or .npz if that's easier for python.

[klamike]

For generating reserve data, we should hook into the OPFSampler, detecting if one of the OPFs to be solved is an EconomicDispatch with reserves enabled. Not super clear to me how to do that

[mtanneau]

For generating reserve data, we should hook into the OPFSampler, detecting if one of the OPFs to be solved is an EconomicDispatch with reserves enabled. Not super clear to me how to do that

We would also need to generate maximum reserve dispatches for each generator. Note that without a binding maximum reserve dispatch, the reserve constraint will basically reduce to whether total capacity is higher than total load + reserve requirement. In practice, maximum reserve dispatches are based on generators' ramping rates. For instance, if reserves need to be deployed within 5 units of time, then we would set rmax = 5 * ramp_up_rate.

PGLib instances do not include information about ramping, so we would have to make those up.

[klamike]

@mtanneau Any guidance on how to generate reserve data? We need minimum reserve and the min/max per generator.

Also, how do you want to handle testing for this formulation? I guess we can use PM.solve_opf_ptdf_branch_power_cuts?

I believe these are the only two things left for this PR.

[mtanneau]

how to generate reserve data? We need minimum reserve and the min/max per generator.

This is what we did in the E2ELR paper:

In UnitCommitment.jl, they use the following strategy (according to their docs):

• Reserve requirements are a fixed % of total load.
• Per-generator reserve minimum is always zero.
• Per-generator max reserve is normally based on ramping rate, e.g. the MW equivalent of 5min or 10min of ramping. PGLib instances do not include ramping information... in UnitCommitment, they say they fixed the ramping rate to a % of total maximum capacity... which reduces to setting max reserve capacity to a fixed % of the generator's capacity.

I do not know how they chose the % in UC.jl

how do you want to handle testing for this formulation? I guess we can use PM.solve_opf_ptdf_branch_power_cuts?

We do not have a comparison baseline. Short of designing our own small test cases where we can compute the optimum analytically, the best we can do is to run and check the validity (feasibility) of the solution.

[codecov[bot]]

Codecov Report

Attention: Patch coverage is 96.11307% with 11 lines in your changes missing coverage. Please review.

Files	Coverage Δ
src/opf/opf.jl	100.00% <ø> (ø)
src/sampler/sampler.jl	94.87% <100.00%> (+3.20%)	:arrow_up:
src/sampler/reserve.jl	96.66% <96.66%> (ø)
src/opf/ed.jl	95.78% <95.78%> (ø)

... and 1 file with indirect coverage changes