PaperlayerView exact revision on arXiv

Source-linked AI summary

Integrating Agentic Artificial Intelligence with High-Performance Computing for Grid Planning

Samim Konjicija, Slaven Peles

arXiv:2609.04544v1eess.SYcs.SY

TL;DR

Power-system planning tasks can be difficult to formulate as mathematical optimization problems, and iterative expert analysis is time-consuming. AgentiGrid couples LLM-guided search with ExaGO simulations, including parallel scenario analysis. Preliminary results report that the four tested LLM agents performed the three tasks well, with a trade-off between iterations and solution accuracy for GPT-5.4 and Claude Sonnet 4.6.

  • Problem

    Power-system tasks that are hard to formulate as mathematical optimization problems often require time-consuming expert iteration, while existing LLM agents predominantly use sequential single-simulation steps.

    Source: §I · p. 1

  • Method

    AgentiGrid wraps ExaGO applications in an LLM-driven search loop, with parallel analysis of multiple scenarios or contingencies.

    Source: §I · pp. 1–2

  • Results

    Preliminary results report that all four LLM agents performed the three tasks well; GPT-5.4 took the most steps but gave the most accurate solutions, while Claude Sonnet 4.6 took the fewest iterations but missed a critical contingency.

    Source: C. Results Summary · pp. 5–6

  • Takeaways & Limitations

    The authors conclude that using an LLM as an optimizer is practically viable for power-system analysis tasks that are difficult to express as formal optimization problems.

    Source: §V · p. 6

Abstract

from arXiv · show

We present AgentiGrid, an agentic artificial intelligence (AI) framework that integrates large language models (LLMs) intelligence and high-performance computing (HPC) to streamline and accelerate the multi-scenario power flow studies. AgentiGrid is an autonomous decision-making agent that proposes parameter modifications, invokes analyses through HPC analysis toolkit ExaGO, interprets results, and determines subsequent actions. ExaGO provides multiple power flow applications that can perform deterministic, stochastic and security constrained optimal power flow analyses. AgentiGrid provides backends to multiple LLMs (OpenAI, Anthropic, Ollama, and Ollama cloud) augmented with context specific and task specific prompts. Key features include interactive mid-search steering, goal-type-aware post-search analysis, and concurrent variant exploration for power flow optimization. A Streamlit-based graphical launcher provides real-time visualization of iteration progress and generates reports in natural language. AgentiGrid is capable of autonomously converging transmission constrained alternating current optimal power flow in under 20 iterations, with near-perfect reliability

I. INTRODUCTION

Power-system analysis often requires time-consuming human iteration, while existing LLM agents largely use sequential simulations. AgentiGrid combines LLM-guided search with ExaGO parallel analysis and adds operator steering and reporting tools.

I. INTRODUCTION

  • Existing LLM-based power-system agents predominantly run one simulation per step, leaving parallel execution largely unexplored.The paper identifies this sequential design as incurring high token and time costs when resolving contingencies or processing scenarios.Source: §I · p. 1
  • AgentiGrid integrates ExaGO into an LLM-driven search loop that analyzes multiple scenarios or contingencies in parallel.ExaGO is described as a high-performance grid-optimization library for parallel execution on clusters and cloud systems.Source: §I · p. 1
  • Its three-layer architecture supports six power-flow and optimal-power-flow applications through a unified interface.The layers separate the LLM agent loop, simulation orchestration, and ExaGO applications.Source: §I · p. 1
  • A prompt architecture combines search history, network metadata, goal context, operator directives, and application-specific guidance.The introduction identifies these contextual prompts as a core contribution.Source: §I · p. 2
  • Operators can steer a running search, explore concurrent variants, and monitor progress through a graphical launcher that generates natural-language reports.Steering supports pause and resume at iteration boundaries without restarting; concurrent variants amortize LLM round-trip latency.Source: §I · p. 2

II. SYSTEM ARCHITECTURE OVERVIEW

AgentiGrid separates the agent, analysis orchestration, and ExaGO simulation into three communicating layers. Each iteration passes an LLM command through validation and numerical analysis, then returns results to guide the next step.

II. SYSTEM ARCHITECTURE OVERVIEW

  • The controller builds a prompt from the goal, journal, latest results, and steering directives, then parses the LLM response into structured actions.The search journal records results across iterations.Source: §II · p. 2
  • The architecture separates the Agent Loop Controller, Analysis Orchestrator, and ExaGO applications, which communicate through well-defined protocols.ExaGO applications cover power flow, optimal power flow, security-constrained optimal power flow, and stochastic optimal power flow analyses.Source: §II · p. 2, Figure 1 · p. 2
  • The orchestrator validates commands, applies them to a working copy of the network case, invokes ExaGO, parses output, and updates the search journal.The returned summary is used in the next prompt, and the loop ends on successful completion, a critical error, or the iteration limit.Source: §II · p. 2
  • After the search, a final LLM call classifies the goal type and identifies the best iteration for the results report.This provides goal-aware framing of the report.Source: §II · p. 2

A. Agent Loop Controller

The Agent Loop Controller manages the LLM-facing search cycle and post-search analysis. Users can start analyses through command-line or graphical interfaces using plain-language requests.

A. Agent Loop Controller

  • The standalone Python Agent Loop Controller prompts the LLM from user input and prior iterations, sends commands to the orchestrator, and manages post-search analysis.Its components include the user frontend, LLM backend, prompt generator, interactive steering, and report generator.Source: A. Agent Loop Controller · p. 2

1) User Frontend:

  • The command-line and web GUI let users choose the case, analysis type, LLM, ExaGO application, and configuration, then enter a plain-text request.Both interfaces offer predefined, modifiable prompts as starting points.Source: 1) User Frontend · p. 2

2) LLM Backend:

AgentiGrid accesses multiple LLM providers through a shared interface and constructs prompts from static context and iteration-dependent information. Prompt sections include the goal and network context as well as accumulated results and conditional feedback.

2) LLM Backend:

  • OpenAI, Anthropic, Ollama, and Ollama cloud backends share an interface, with low LLM temperature settings of 0.2–0.4 intended to encourage consistent structured output.The common interface exposes complete(), name(), and supports_json_mode() methods.Source: 2) LLM Backend · p. 2

3) Prompt Architecture:

  • The prompt architecture uses up to seven sections that remain static, grow, refresh, or appear conditionally as the analysis proceeds.Static sections include the system prompt, network metadata, and verbatim goal statement.Source: 3) Prompt Architecture · pp. 2–3
  • The growing search journal records each iteration’s modification, objective, feasibility, voltage range, and maximum line loading.Latest simulation results are refreshed, while operator directives and error or warning feedback can be included conditionally.Source: 3) Prompt Architecture · p. 3

4) Interactive Steering:

AgentiGrid supports steering searches while they run, generating reports, and coordinating the LLM agent with HPC applications.

4) Interactive Steering:

  • Operators can inject augmenting or replacing directives into a running search through the command line or GUI.The active directive is added to the prompt without stopping the search.Source: 4) Interactive Steering · p. 3

5) Report Generator:

  • PDF reports combine goal-aware summaries, convergence and voltage charts, solution comparisons, iteration logs, and steering history.The GUI and PDF use shared Plotly figure builders for consistent charts.Source: 5) Report Generator · p. 3

B. Analysis Orchestrator

  • The Analysis Orchestrator mediates between the LLM agent and the HPC application.The passage introduces its components but does not specify them here.Source: B. Analysis Orchestrator · p. 3

1) Modification Engine:

The system validates proposed network modifications, runs and parses ExaGO analyses, and records iteration-level search state.

1) Modification Engine:

  • The Modification Engine applies JSON commands to Matpower case files after checking them against network topology; invalid commands return feedback to the LLM.Table I is identified as the source of the supported command vocabulary.Source: 1) Modification Engine · p. 3, Table I · p. 3

2) Simulation Executor; 3) Results Parser:

  • ExaGO runs through command-line applications with a timeout guard and concurrent variant execution; dedicated parsers extract results for each application.The parsers capture objective, convergence, voltages, dispatch, branch flows, and constraint violations.Source: 3) Results Parser · p. 3, 2) Simulation Executor · p. 3

3) Results Parser:

  • Violation checks use the modified network’s Vmin and Vmax limits, and parsers produce structured data plus a compact 15–30-line prompt summary.The structured output supports visualization queries.Source: 3) Results Parser · p. 3

4) Search Journal:

  • An in-memory journal records iteration actions, outcomes, LLM reasoning, steering directives, and per-iteration values for registered objectives.Recorded outcomes include feasibility, violation count, voltage range, maximum line loading, generation, and load.Source: 4) Search Journal · p. 3

5) Goal Classification and Post-Search Analysis:

Post-search analysis classifies the goal and selects the best iteration using a goal-specific criterion.

5) Goal Classification and Post-Search Analysis:

  • The best iteration is selected by goal: lowest feasible cost, nearest feasible point to the infeasibility boundary, constraint satisfaction, or most informative feasible configuration.The system recognizes four goal types.Source: 5) Goal Classification and Post-Search… · p. 3
  • If goal classification fails, the system falls back to cost minimization, which can misidentify the best case in a feasibility-boundary search.In that example, generation cost rises as load grows, making the base case the naïve lowest-cost choice.Source: 5) Goal Classification and Post-Search… · p. 4

C. ExaGO Applications

III. USING LLM AS THE OPTIMIZER

AgentiGrid uses an LLM to propose and evaluate power-flow changes, with concurrent variant exploration designed to reduce the impact of inference latency.

III. USING LLM AS THE OPTIMIZER

  • PFLOW is a forward steady-state simulation whose LLM optimizer proposes dispatch changes, evaluates feasibility, and decides next steps.The Newton–Raphson solver finds the power-flow solution for a given network state.Source: §III · p. 4

A. Explore/Select Actions

  • Concurrent PFLOW generates 2–8 variants per explore action, simulates them in parallel, and uses an LLM select action to choose the next network state.An explore-select cycle counts as one iteration while evaluating multiple configurations.Source: A. Explore/Select Actions · p. 4

B. Pareto Front Computation

  • Pareto filtering ranks feasible candidates ahead of infeasible ones and favors candidates that are no worse on every objective and better on at least one.Objective directions can be configured for minimization or maximization.Source: B. Pareto Front Computation · p. 4

IV. EXPERIMENTAL RESULTS

  • Evaluation used ACTIVSg200, a synthetic 200-bus Illinois transmission network, on a 14-core workstation with 32 GB RAM.The network includes 246 branches, 200 loads, and 49 generators, 40 in service.Source: §IV · p. 4

A. Experimental Design

The experiments applied three distinct power-flow goals across four LLM backends, with identical prompts per application and a 20-iteration limit. All backends completed all three tasks without fatal JSON parsing failures, but differed in search strategy and conclusion depth.

A. Experimental Design

  • The three goals tested near-optimal dispatch with PFLOW, N-1 outage criticality with SCOPFLOW, and simultaneous wind-scenario feasibility with SOPFLOW.SCOPFLOW and SOPFLOW used ExaGO’s parallel EMPAR backend; PFLOW used Newton–Raphson.Source: A. Experimental Design · p. 4
  • All four backends received identical per-application goal prompts, with a maximum budget of 20 iterations and LLM temperature 0.3.The prompts instructed agents to continue exploring modified problems rather than stop at a converged but uninformative result.Source: A. Experimental Design · p. 4

B. Key Findings

  • All four backends completed all three tasks without fatal JSON parsing failures, while differing in search strategy and depth of conclusions.Table III reports the twelve searches.Source: B. Key Findings · p. 4, Table III · p. 5
  • In PFLOW, Sonnet 4.6 and GPT-5.4 recognized the already economic dispatch, while GLM-5.1 and DeepSeek-V4-Pro instead performed unit commitment, reducing cost by 36.9% and 34.9%, respectively.The base case generation cost was $27,564 and had large spinning reserve.Source: A. Experimental Design · p. 4, B. Key Findings · p. 5
  • +21.6% cost increase was agreed for the economically critical line 187→189 outage, but infeasible contingencies were missed, including line 15→16 by all four backends.Sonnet also failed to identify line 29→30 as critical.Source: B. Key Findings · p. 5
  • All agents completed SOPFLOW in 3 steps, finding feasible solutions across scenarios and identifying bus 152 as most sensitive to voltage violations.GPT-5.4 and GLM-5.1 identified 15 similarly sensitive buses, while Sonnet 4.6 and DeepSeek 4 reported only the most sensitive bus.Source: B. Key Findings · p. 5

C. Results Summary

Across the three problems, GPT-5.4 used the most steps but was reported to provide the most accurate solutions, while Claude Sonnet 4.6 used the fewest steps but missed a critical contingency. The results also identify missed infeasibility cases and variable token use as important qualifications.

C. Results Summary

  • In the SCOPFLOW security-constrained analysis, LLM agents struggled to identify the “most critical lines,” missing the line 15→16 contingency that leads to an infeasible solution.The authors say a broader contingency sweep would uncover the infeasible optimal power flow solution associated with that failure. More specific RAG criteria for line-contingency rankings could address the identification issue.Source: C. Results Summary · p. 5
  • GPT-5.4 took the most steps across all three problems but provided the most accurate solutions; Claude Sonnet 4.6 used the fewest iterations but missed a critical contingency.Fig. 2 summarizes iteration counts and divides the budget into productive simulation, concurrent explorations, and analysis-only steps; GPT-5.4’s analysis-heavy behavior reflected repeated requests for network detail absent from compact summaries.Source: C. Results Summary · pp. 5–6, Figure 2 · p. 6
  • Token-analysis cost varied significantly by problem, agent, and iteration, with Fig. 3 summarizing total token use by agent across the three problems.The supplied passages do not state comparative token totals.Source: C. Results Summary · p. 6, Figure 3 · p. 6

V. CONCLUSION

AgentiGrid connects natural-language requests to ExaGO grid-analysis applications through an interface with application-aware validation, prompt construction, and result parsing. The authors present it as a research platform, with preliminary experiments on a 200-bus case supporting further study of LLM-driven analysis with parallel computing.

V. CONCLUSION

  • AgentiGrid supports six ExaGO applications through a unified interface with application-aware command validation, prompt construction, and results parsing.The framework is intended to bridge natural-language problem specification and production-grade ExaGO solvers.Source: §V · p. 6
  • The current research platform supports concurrent LLM explorations and HPC executables for physics-based analyses, and preliminary experiments suggest the LLM-as-optimizer paradigm is viable for difficult-to-formalize power-system analysis tasks.The authors characterize the results as preliminary and say they justify further investigation.Source: §V · p. 6
  • Experiments were limited to a 200-bus optimal power flow case; scaling by system size in iterations, time, and tokens remains future work.The authors anticipate file-based analysis storage may become a performance bottleneck and expect further RAG expansion to improve agent performance.Source: §V · p. 6
Loading 2609.04544v1…