[lukelowry]

Description

AC optimal power flow module (OptimalPowerFlow) solved with Ipopt using exact sparse derivatives from Enzyme. It follows the PhasorDynamics structure (OptimizationEvaluator -> Component -> SystemModel) and uses the same JSON case format. Scope is ACOPF only, coupling with PhasorDynamics will be a separate PR.

• Components: Bus, Branch, Generator, Load (Cartesian voltages)
• Solver: SteadyState::IpoptInterface
• Example: EconomicDispatch, tested against PYPOWER costs for IEEE39, Hawaii, and ACTIVSg2000

Checklist

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

Further comments

I can remove the large new OPF formatted cases if needed.

[pelesh]

A few comments:

• If you have JSON input parser already available, I suggest you use that instead of MATPOWER format. I was thinking you could use some of the existing power flow implementation, but since you took a different route, I suggest you ditch MATPOWER and go straight to JSON.
• I would have optimal power flow app in EconomicDispatch subdirectory in examples directory, at the same level as PhasorDynamics.
• I would rename Optimization/OptimizationProblem.*pp files (and the class within) into Optimization/SteadyState.*pp. We will likely have Multiperiod and MixedInteger as new optimization modules in the future.

[lukelowry]

@pelesh I changed it so it uses the PowerFlow parser with very few changes. I do believe its valuable to have that as the input format only because it makes validation easier and there is practically unlimited data in .m, and OPF data does not always come with dynamic case files.

I believed I addressed your other issues too. I am able to use the example app to change the objective/model, solve for new operating point, and start simulation in steady state at that new point!

[pelesh]

This is very nice work. I suggest limiting the scope of this PR to providing ACOPF module only. Imho, the integration with dynamic simulations modules should be done after ACOPF is tested and input file format specified.

[superwhiskers]

tests pass on my end. i think it works quite well, but there are a few implementation questions we should sort out before this moves forward.

additionally, if we are to continue with matpower, are we intending to handle capability curves for generators or the convention of a dispatchable load as a generator with negative real-power injection? if they are outside the intended scope, could we reject them and document that limitation?

i think these conventions, particularly the latter, strengthen the argument for going with our own format, as using an existing format such as matpower requires us to adhere to its conventions, which may not be desirable.

[nkoukpaizan]

Overall nice work! The component implementations are clear and I like the consolidated ComponentModelImpl.hpp.

A few comments:

• For Enzyme, can we re-use some of the existing boilerplate for LowerSparseStorage and use buffers instead of CooEntries wrapping std::vector)? Feel free to amend the wrappers.
• Can we bind GridKit::LinearAlgebra::Vector at the component level instead of std::vector? This could be a follow-up PR.
• Several methods, e.g., in OptimizationEvaluator* and SteadyState* don't have a Doxygen documentation.

[pelesh]

This looks very good and has clean component model structure. Main issues that I would raise are:

• Separating equality and inequality constraint evaluation methods.
• Selection of coordinates polar vs. Cartesian.
• Inheritance patterns should mirror PhasorDynamics module. If we want to change it, then the change should made be across the GridKit modules.

[lukelowry]

Thank you all for detailed review, I believe I have addressed all except a distinct few. I will go response by response soon, but the overall design is overall more consistent with PhasorDynamics except for the inheritance structure. I am considering removing the larger ACTIVSg2000 case until after this is merged, please let me know what you think.

[superwhiskers]

some further changes since i looked a little closer at the ipopt interface code

[read-the-docs-community]

Documentation build overview

📚 GridKit | 🛠️ Build #35486724 | 📁 Comparing dafe4e8 against latest (4315301)

  🔍 Preview build  

190 files changed · + 102 added · ± 77 modified · - 11 deleted

+ Added

• api/reference/classAnalysisManager_1_1SteadyState_1_1IpoptInterface.html
• api/reference/classGridKit_1_1Model_1_1ConfigurationChecks.html
• api/reference/classGridKit_1_1Model_1_1OptimizationEvaluator.html
• api/reference/classGridKit_1_1Model_1_1ParameterReader.html
• api/reference/classGridKit_1_1OptimalPowerFlow_1_1Branch.html
• api/reference/classGridKit_1_1OptimalPowerFlow_1_1Bus.html
• api/reference/classGridKit_1_1OptimalPowerFlow_1_1Component.html
• api/reference/classGridKit_1_1OptimalPowerFlow_1_1Generator.html
• api/reference/classGridKit_1_1OptimalPowerFlow_1_1Load.html
• api/reference/classGridKit_1_1OptimalPowerFlow_1_1SystemModel.html
• and 92 more...

± Modified

• genindex.html
• cases/README.html
• development/CHANGELOG.html
• development/CONTRIBUTING.html
• examples/README.html
• api/reference/classGridKit_1_1PhasorDynamics_1_1Branch.html
• api/reference/classGridKit_1_1PhasorDynamics_1_1BusBase.html
• api/reference/classGridKit_1_1PhasorDynamics_1_1BusSignalVoltageIn.html
• api/reference/classGridKit_1_1PhasorDynamics_1_1BusSignalVoltageOut.html
• api/reference/classGridKit_1_1PhasorDynamics_1_1Component.html
• and 67 more...

- Deleted

• api/reference/classGridKit_1_1PhasorDynamics_1_1BusFault.html
• api/reference/dir_GridKit_Model_PhasorDynamics_BusFault.html
• api/reference/enum_namespaceGridKit_1_1PhasorDynamics_1a688a138fbd3d7f6a08b3e474496f2771.html
• api/reference/enum_namespaceGridKit_1_1PhasorDynamics_1ac462ff3ce4dd5e49f8ea341c58c383c2.html
• api/reference/enum_namespaceGridKit_1_1PhasorDynamics_1ad07447f57a589d38b98504a9ada9ccac.html
• api/reference/enum_namespaceGridKit_1_1PhasorDynamics_1adbd99bf52e0ba1864a89a33c66065fc8.html
• api/reference/enum_namespaceGridKit_1_1PhasorDynamics_1af5e4141351261054f3d5aa62eb231e7d.html
• api/reference/file_GridKit_Model_PhasorDynamics_BusFault_BusFault.hpp.html
• api/reference/file_GridKit_Model_PhasorDynamics_BusFault_BusFaultData.hpp.html
• api/reference/typedef_namespaceGridKit_1_1PhasorDynamics_1ae2aa91267342226bbb0b840ff8be1f65.html
• and 1 more...

[lukelowry]

I have adjusted so that OPF now follows same inheritance of PhasorDynamics. Once again, thank you for the invaluable feedback. I have taken great care to touch existing files very little! Nearly ready.

[lukelowry]

Addressed!

[nkoukpaizan]

Looks good! I'll wait for a rebase before merging to make sure there's no interference from #632.

[lukelowry]

Rebased! thanks so much

[lukelowry]

Is it in play to get this merged today?