ExaModelsPower.jl: A GPU-Compatible Modeling Library for Nonlinear Power System Optimization

As GPU-accelerated mathematical programming techniques mature, there is growing interest in utilizing them to address the computational challenges of power system optimization. This paper introduces ExaModelsPower.jl, an open-source modeling library for creating GPU-compatible nonlinear AC optimal power flow models. Built on ExaModels.jl, ExaModelsPower.jl provides a high-level interface that automatically generates all necessary callback functions for GPU solvers. The library is designed for large-scale problem instances, which may include multiple time periods and security constraints. Using ExaModelsPower.jl, we benchmark GPU and CPU solvers on open-source test cases. Our results show that GPU solvers can deliver up to two orders of magnitude speedups compared to alternative tools on CPU for problems with more than 20,000 variables and a solution precision of up to $10^{-4}$, while performance for smaller instances or tighter tolerances may vary.

💡 Research Summary

The paper introduces ExaModelsPower.jl, an open‑source Julia library that enables the creation of fully GPU‑resident nonlinear AC optimal power flow (AC‑OPF) models. Built on top of the general‑purpose modeling framework ExaModels.jl, the library abstracts power‑system optimization problems into a SIMD‑friendly representation, automatically generating GPU kernels for the objective, constraints, Jacobian, and Hessian. This eliminates the need for users to hand‑code GPU callbacks, a task that is traditionally error‑prone and labor‑intensive.

Motivation and Context
AC‑OPF is a nonlinear programming (NLP) problem that must satisfy power‑flow equations together with operational limits. While DC‑OPF offers a linear approximation, it can produce sub‑optimal or infeasible solutions, and the industry estimates that switching to AC‑OPF could save billions of dollars annually. Real‑world applications often require multi‑period (MP) formulations to capture storage dynamics and security‑constrained (SC) formulations to ensure resilience against contingencies. These extensions quickly inflate the problem size to tens of thousands of variables and constraints, making CPU‑only solution methods a bottleneck.

Technical Foundations
ExaModels.jl provides a SIMD abstraction: model equations are expressed as collections of identical computational patterns applied over data arrays. Users write models using generator expressions (e.g., objective(core, expr for i in 1:N)) that pair a Julia function with a host or device array. The framework then applies reverse‑mode automatic differentiation (AD) independently to each term, aggregates the results, and automatically detects sparsity. The resulting callbacks conform to the NLPModels.jl interface (obj, grad!, cons!, jac!, hess!), making the model compatible with any solver in the NLPModels ecosystem.

ExaModelsPower.jl specializes this abstraction for power‑system data structures (buses, branches, generators, etc.). Variables such as voltage magnitude (vm), voltage angle (va), active/reactive power injections (pg, qg), and branch flows (p, q) are declared with bounds directly from the network data. Constraints for reference angles, active/reactive power flow, thermal limits, and generator limits are added via constraint(core, ...). The objective typically aggregates generator cost functions. All of this can be executed on a CPU or a GPU simply by passing backend = :gpu (or similar) when constructing the ExaCore.

Implementation Highlights

• Automatic GPU kernel generation: No explicit CUDA code is required; the library emits kernels from the high‑level algebraic expressions.
• Backend‑agnostic model object: The returned ExaModel is a subtype of AbstractNLPModel, allowing seamless use of solvers such as MadNLP.jl (GPU‑native), Ipopt, and KNITRO.
• Support for advanced formulations: Static AC‑OPF, MP‑OPF with storage, and SC‑OPF (including the GOC3 benchmark with up to 48 periods and thousands of contingencies) are provided out‑of‑the‑box.
• Extensibility: Users can inject custom components via user‑defined callbacks, preserving the SIMD structure.

Benchmark Results
The authors benchmarked several open‑source test cases ranging from IEEE 118‑bus to large GOC3 instances. Key findings:

• For problems with >20,000 variables and a solution tolerance of 1e‑4, GPU‑accelerated solvers (e.g., MadNLP on CUDA) achieved up to 100× speed‑up compared with CPU‑based Ipopt/KNITRO.
• Speed‑up diminishes for smaller instances (≤5,000 variables) due to kernel launch overhead and data transfer costs.
• Tightening the tolerance to 1e‑6 reduces the advantage, as more iterations and higher‑precision linear solves become dominant.
• Memory consumption on a single GPU becomes a limiting factor for very large MP‑SCOPF models; the authors suggest data partitioning or multi‑GPU strategies for future work.

Comparison with Existing Tools

• PowerModels.jl / MATPOWER: High‑level modeling but rely on CPU solvers; no automatic GPU support.
• ExaGo: Similar goal of GPU‑compatible OPF, but its current version (v1.6.0) cannot run a fully GPU‑resident solve because the interfaced solvers lack full GPU support and only handle mixed sparse‑dense formulations.
• ExaModelsPower.jl distinguishes itself by delivering a complete GPU‑resident workflow from model definition to solution, leveraging the mature GPU‑native linear solver in MadNLP.

Broader Implications
The library also opens pathways for machine‑learning‑based OPF proxies. Training such proxies on the entire pglib‑opf dataset requires rapid evaluation of many OPF instances; the GPU‑native evaluation provided by ExaModelsPower.jl can dramatically reduce the offline training time.

Conclusions and Future Directions
ExaModelsPower.jl demonstrates that a well‑designed high‑level modeling abstraction can bridge the gap between power‑system optimization and modern GPU hardware. It delivers (1) user‑friendly syntax, (2) automatic generation of GPU kernels for all necessary NLP callbacks, and (3) compatibility with a wide range of existing solvers. The reported benchmarks confirm substantial performance gains for large‑scale, moderately tolerant problems. Remaining challenges include:

• Development of more robust GPU sparse linear solvers to handle tighter tolerances and larger sparsity patterns.
• Scaling to multi‑GPU or distributed GPU environments for the biggest MP‑SCOPF cases.
• Enhancing numerical stability for high‑precision solutions (≤1e‑6).

Overall, ExaModelsPower.jl positions itself as a pivotal tool for researchers and practitioners aiming to exploit GPU acceleration in modern power‑system optimization.