10k Bus Case + Three Fully Validated Cases

[lukelowry]

Description

Three validated cases against PowerWorld with amazing accuracy & added ACTIVSg10k bus case.

Requires #525 #460, WECC case validation is failing until those merge.

PhasorDynamics Cases

• ACTIVSg200
• ACTIVSg500
• ACTIVSg2000
• ACTIVSg10k
• Hawaii
• IEEE39
• WECC240

Validation Cases

I chose these as the validation cases because they are fully, 100% modeled in GridKit.

• ACTIVSg200 Validation
• ACTIVSg500 Validation
• WECC240 Validation

Relative Error Against PowerWorld

Field	ACTIVSg200	ACTIVSg500	WECC240
Generator real power, P	0.031% / 0.116%	0.016% / 0.066%	0.005% / 0.022%
Generator reactive power, Q	0.066% / 0.137%	0.133% / 0.179%	0.099% / 0.165%
Bus voltage magnitude, |V|	0.004% / 0.078%	0.002% / 0.037%	0.001% / 0.012%
Generator speed deviation, Δω	0.513% / 0.404%	0.227% / 0.198%	0.646% / 0.342%

Each entry reports relative RMSE and maximum error, respectively

Example validation on WECC240

Proposed changes

• Adjusted DynamicSimulation to print monitored variables pre- and post- fault. This is clearer and makes validation easier, and IMO more correct. It only printed pre-fault values before.
• Top-level cases/ with cleaned files, README.md, one-line diagrams. This allows us to reuse cases for tests, validations, and examples.
• Validation folder under examples/PhasorDynamics/validation/ with one *.solver.json and corresponding README.md explaining what is being validated and subfolders for cleanliness: references/ and figures/

Checklist

• All tests pass.
• Code compiles cleanly with flags -Wall -Wpedantic -Wconversion -Wextra.
• The new code follows GridKit™ style guidelines.
• NA There are unit tests for the new code.
• The new code is documented.
• The feature branch is rebased with respect to the target branch.
• I have updated CHANGELOG.md to reflect the changes in this PR. If this is a minor PR that is part of a larger fix already included in the file, state so.

Further comments

• ACTIVSg10k is still slow, but optimization is out of scope. Experimental branches show there are a lot of low hanging fruit
• Because of how cases and the solver file work, the ctest only runs against omega unless you change the monitors in the case and the output file. I think we need some multi-sink monitors as @PhilipFackler has suggested previously (tracked in Multiple Monitor Sinks + Remove monitor field from case #529)

[lukelowry]

The simulation runs much more slowly after I rebuilt it using the develop branch's Jacobian changes. It ran for a few minutes and did not finish. I am not confident what the hotpath is

(Edit: Without monitored output, it takes 43s to simulat, as opposed to ~8s before #447 )

[nkoukpaizan]

The simulation runs much more slowly after I rebuilt it using the develop branch's Jacobian changes. It ran for a few minutes and did not finish. I am not confident what the hotpath is

(Edit: Without monitored output, it takes 43s to simulat, as opposed to ~8s before #447 )

Good to know! Let's push to merge a clean version of this case. I can then profile and see how to better deal with the bus Jacobians. There wasn't a clean way for each connected component to access the entries owned by the bus and add to them in a thread-safe way, and the tradeoff was worth it on the 2k case.

[nkoukpaizan]

Oh, another difference is that bus faults are currently variable-owning. So, if a bus fault is attached to every bus, the number of bus variables is basically doubled (despite these not contributing anything to the system). I recommend only having one fault in the large cases for now. Once we make the bus class itself faultable, this should no longer be an issue.

[lukelowry]

Oh, another difference is that bus faults are currently variable-owning. So, if a bus fault is attached to every bus, the number of bus variables is basically doubled (despite these not contributing anything to the system). I recommend only having one fault in the large cases for now. Once we make the bus class itself faultable, this should no longer be an issue.

That helped. It runs in 28s now, with only one BusFault in the case. Still slower but much more usable, thank you for that! We probably should change how ContingencyAnalysis works soon, so we don't need a BusFault at each bus. cc @PhilipFackler