Add selection for DCOPF, network flow, or copper plate transmission model

[danielolsen]

No description provided.

[danielolsen]

For a network/transport model, we would still have power flow on each line, it just wouldn't be constrained by KVL. But with a copper-plate model, we no longer have meaningful values for pf. In order to keep these scenarios compatible with PowerSimData, I think we either need to save an empty pf.pkl file in the extraction process and/or modify PowerSimData so that it knows how to properly interpret a missing pf file.

[danielolsen]

Another transmission model we may be interested in: copper-plate, within interconnections only. I think we could enable this by removing all flow limits on AC lines, but not DC lines. This could let us investigate e.g. the difference between the best-case transmission upgrades within interconnections vs. the best case transmission upgrades including bridging the interconnections.

[BainanXia]

Another transmission model we may be interested in: copper-plate, within interconnections only. I think we could enable this by removing all flow limits on AC lines, but not DC lines. This could let us investigate e.g. the difference between the best-case transmission upgrades within interconnections vs. the best case transmission upgrades including bridging the interconnections.

This can be achieved by scaling the capacities of all AC branches to 0 via change table right, although, it is ugly in some sense.

[danielolsen]

@BainanXia scaling the capacities of the AC branches down to zero will remove the min & max constraints on the AC lines, but REISE.jl will still add variables for the flow on each branch, enforce branch-angle constraints on their flows, and create power-balance constraints for each bus. It would work, but still creates a model with unnecessary complexity (although maybe Gurobi would realize this and presolve some/all of the unnecessary complexity away).

I think what we want is:

• DCOPF: branch-angle, flow min/max, power balance
• network flow: flow min/max, power balance
• interconnection copper-plate: flow min/max on DC only, power balance (only really necessary at the seams, but I think we might need more complex code to automatically collapse AC interconnections to single nodes)
• copper-plate: generation = demand

[BainanXia]

@danielolsen Agree. A true copper-plate mode should ignore the topology completely as long as the graph is a connected component.

[danielolsen]

For a network/transport model, we would still have power flow on each line, it just wouldn't be constrained by KVL. But with a copper-plate model, we no longer have meaningful values for pf. In order to keep these scenarios compatible with PowerSimData, I think we either need to save an empty pf.pkl file in the extraction process and/or modify PowerSimData so that it knows how to properly interpret a missing pf file.

@rouille I would like to get your opinion on how to design for this.

[rouille]

If a the PF file is not in data/output on the server the get_data method of the OutputData class will throw an error via the copy_from method of the SSHDataAccess class (even if I don't see an explicit error raised there ...). I think it is not an issue and we could refine the message associated to the error when the user use the get_pf method in the Analyze class.

I think the necessary refactoring will happen in the extract_data script where we should implement a mechanism to not write the PF file for model different than DCOPF.

[danielolsen]

extract_data.py will definitely need refactoring. Do you think the transmission model would be something we want to record in the ScenarioList as part of the create state (defaulting to 'dcopf'), and retrieve from there within call.py when we launch a scenario using a scenario ID? Then Analyze would know not to even look for a PF for scenarios that are run copper-plate.

[danielolsen]

Eventually we may even want to have ACOPF or security constrained OPF

[BainanXia]

Plus unit commitment, SCUC.

[danielolsen]

We may also want to add different formulations of DCOPF. This paper seems to show a pretty significant speed-up in computation time for the 'Kirchoff' formulation, around 2x-4x for large problems. The original formulation seems to come form https://ieeexplore.ieee.org/document/192975. This should be easy to swap in now that #117 is done.