PaperlayerView exact revision on arXiv

Source-linked AI summary

AutoMOOSE: Use Case and Logical Views of Agentic Phase-Field Simulation Software

Sukriti Manna, Henry Chan, Subramanian Sankaranarayanan

arXiv:2608.20571v1cond-mat.mtrl-scics.SE

TL;DR

AutoMOOSE addresses the specialist effort required to translate scientific intent into valid, meaningful MOOSE phase-field simulations. This paper documents its use-case and logical architecture, showing a six-agent pipeline with separated falsification and recovery that supports portable, extensible, and inspectable simulation workflows.

  • Problem

    MOOSE phase-field simulations require specialist-authored input files, making translation from scientific intent to valid and physically meaningful simulations difficult.

  • Method

    The paper describes AutoMOOSE through Use Case and Logical architectural views, covering its six-agent pipeline, plugin layer, interfaces, and separated falsification-recovery loop.

  • Results

    The architecture is cross-consistent across roles, components, and operational sequences, documenting a portable, extensible, and inspectable framework.

  • Takeaways & Limitations

    AutoMOOSE supports interactive research, programmatic optimization workflows, and reuse as an architectural template for other scientific solvers.

  • Takeaways & Limitations

    AutoMOOSE currently supports only registered grain-growth and spinodal-decomposition plugins, with physics-specific falsification limited to defined invariants.

Abstract

from arXiv · show

AutoMOOSE is an agentic software framework that converts a natural-language request into an executed, screened, and interpreted MOOSE phase-field simulation. Here, we deploy AutoMOOSE as a agentic software, complementing our prior work which focused on development of the agentic tool. We describe our software framework and architecture through Use Case and logical views of the 1+5 architectural-views model, covering its user roles, component structure, six-agent pipeline, physics plugin layer, Model Context Protocol interface, and screening/falsification/recovery loop. Our architecture separates physical falsification from automatic repair, so corrected simulations remain inspectable and must be re-admitted before acceptance. We focus on software design, extensibility, interoperability, and reuse of the AutoMoose framework for broad utilization in multiphysics materials design problems.

1 Motivation and significance

AutoMOOSE addresses the specialist barrier to phase-field simulation by translating scientific intent into executable, screened, and interpreted MOOSE workflows. Its architecture uses six epistemically distinct agents and 1+5 Use Case and Logical views to make the framework’s structure and runtime operation explicit.

  • Motivation and significance: Phase-field simulation is widely used, but correct MOOSE input authoring requires specialist knowledge of meshes, fields, free-energy kernels, boundary conditions, solvers, and post-processors.Small input errors can be indistinguishable from physically meaningful outcomes.
  • Motivation and significance: AutoMOOSE targets researchers, students, and AI-for-science developers who need to translate scientific intent into valid, meaningful MOOSE inputs, execute simulations, diagnose failures, and interpret results.The practical barrier is solver-specific expertise rather than the underlying science.
  • Motivation and significance: Its pipeline assigns planning, input authoring, execution, screening, physics-invariant falsification, and interpretation to six language-model agents.Each agent owns one epistemic role in the workflow.
  • Motivation and significance: AutoMOOSE differs from MOOSE, workflow engines, and generic coding assistants by combining input authoring, execution, physics reasoning, and result judgment.MOOSE runs simulations without authoring or judging inputs; workflow engines assume existing inputs; generic assistants lack physical constraints.
  • Motivation and significance: The framework is documented through representative Use Case and Logical views of the 1+5 architectural-views model, covering functions, user roles, source-code structure, and runtime operation.The Use Case view names functions and roles, while the Logical view represents structure and execution with UML diagrams.

2 Software description … 2.4 Software operation

AutoMOOSE is a layered, extensible framework that turns natural-language requests into screened and falsified MOOSE simulations through a six-agent pipeline. Its operation separates execution screening, physics-based falsification, interpretation, and bounded recovery across interactive and programmatic interfaces.

  • 2.1 Software architecture: Two interface surfaces call a FastAPI backend that orchestrates AutoMOOSE’s six-agent pipeline for interactive and programmatic use.The interfaces are a React frontend and an MCP server exposing ten tools.
  • 2.1 Software architecture: The runtime order is Architect, Input Writer, Runner, Reviewer, Skeptic, then Visualization, with recovery entered only after a falsified, recoverable failure.The Skeptic falsifies before the Visualization agent interprets, and screening and falsification gate results without repairing them.
  • 2.2 Software functionalities: Three roles exercise seven functions: Researchers use the full system, AI optimizer clients access run, sweep, and interpret through MCP, and Plugin developers extend physics coverage.Screening, falsification, and recovery run automatically inside the optimizer client’s programmatic functions.
  • 2.3 Software structure: The Logical view connects frontend and MCP interface packages to the FastAPI backend, agents, plugins, model-agnostic LLM client, and external MOOSE/SLURM environment.The Runner reaches MOOSE/SLURM, while plugins provide physics resolution and recovery.py sits alongside the screening agents.
  • 2.4 Software operation: The primary operation sequences planning, input writing, execution, screening, falsification, and interpretation before returning the screened result to the Researcher.The Runner launches MOOSE through sbatch, and the recovery branch is conditional on a diagnosed recoverable time-step divergence.
  • 2.4 Software operation: Screening checks execution completeness and parseability, whereas falsification tests plugin-specific invariants and recovery applies only predefined numerical corrections without proving physical correctness.The Skeptic checks conservation, asymptotic limits, symmetry, and scaling relations; recovery remains separate from falsification and repair acceptance.
  • 2.4 Software operation: Recovery classifies log signatures or Skeptic verdicts and applies bounded, logged edits to numerical or discretization controls, capped at three attempts and never changing physical parameters.Corrections can halve the time step, extend the integration window, or refine the mesh, with each change recorded as from, to, and why.

2.5 Cross-view consistency

The 1+5 architectural views are consistent because roles and components carry across the Use Case, structure, and logical views. The logical operation view separates physics falsification from repair and requires corrected runs to pass screening again.

  • Cross-view consistency: The Researcher driving simulation generation in the Use Case view is the same actor on the sequence-diagram lifeline.This preserves role identity across the Use Case and logical views.
  • Cross-view consistency: Backend, f1–f6, recovery.py, and external MOOSE are declared structurally before appearing as lifelines in the logical views.The passage states that no lifeline is used without prior structural declaration.
  • Cross-view consistency: The f6 Skeptic tests physics invariants and returns a verdict but performs no repair.Repair is assigned to recovery.py rather than the falsification agent.
  • Cross-view consistency: On falsified divergence, recovery.py classifies the failure and applies the bounded time-step cutback Δt←αΔt.The recovery action occurs only within the alternative branch triggered by falsification.
  • Cross-view consistency: A corrected run is accepted only after it re-completes and the Skeptic re-admits it.This keeps repaired simulations subject to renewed physical screening.

2.6 Physics plugins · 2.7 Implementation and availability · 2.8 The MCP interface

AutoMOOSE supports extensible physics through auto-discovered plugins, reproducible runs through structured provenance records and saved artifacts, and programmatic control through ten MCP tools. Its architecture keeps screening, falsification, and recovery within the backend pipeline while exposing run, sweep, monitoring, and retrieval operations externally.

  • 2.6 Physics plugins: Physics plugins package metadata and input generation in per-plugin directories, with optional result parsing and automatic registry discovery at startup.Adding a plugin requires no registration call.
  • 2.6 Physics plugins: The released version includes two ready validated plugins and two development stubs intended as extension templates.The ready plugins cover conserved- and nonconserved-dynamics domains validated in the companion article.
  • 2.7 Implementation and availability: AutoMOOSE installs from source with Python backend dependencies, an optional React frontend, and configuration naming the MOOSE executable and language-model backend.The backend requires Python ≥3.10, while the optional frontend requires Node ≥18.
  • 2.7 Implementation and availability: Each run records the model provider, physics, parameters, generated input size, identifiers, status, timing, reviewer metrics, skeptic diagnosis, and recovery actions.The record ties natural-language intent to numerical output and preserves an audit trail for corrected runs.
  • 2.7 Implementation and availability: The run record, rather than a language-model re-query, is the unit of provenance and reproducibility.Re-execution uses the saved .i file, recorded parameters, and solver environment; the framework also records software, plugin, model, MOOSE, and input-hash metadata.
  • 2.8 The MCP interface: AutoMOOSE exposes ten Model Context Protocol tools covering run, sweep, monitoring, and retrieval operations for programmatic control.Equivalent FastAPI REST calls are also provided on port 8000.
  • 2.8 The MCP interface: Screening, falsification, and recovery remain backend pipeline stages rather than separately callable tools, while each sweep value launches an independent run with its own identifier, record, and fresh model context.The run_simulation and run_sweep tools invoke these internal stages.

3 Illustrative example

The illustrative example demonstrates AutoMOOSE’s end-to-end execution of a copper grain-growth request, from structured planning and input generation through run review and result assessment. The same workflow is accessible through MCP or a headless command-line orchestrator, enabling use in outer optimization loops and reporting quantitative validation behavior.

  • End-to-end session: A minimal session sends a copper grain-growth request at 450 K for a 15-grain polycrystal through planning, input writing, execution, review, and result testing.The Runner submits the job through sbatch and streams solver logs over Server-Sent Events.
  • Programmatic execution: A single MCP run_simulation call, followed by status polling and get_results, returns N(t), the Burke–Turnbull parabolic-fit R2, and the coarsening rate.The headless orchestrator can also drive the complete f1 → f6 loop from the command line.
  • Quantitative behavior: The reported quantitative behavior includes benchmark pass rates, fitted activation energy, and second-domain validation.These results are reported in reference [11].

4 Impact and reuse potential

AutoMOOSE’s architectural contribution is a structural and operational account that clarifies its roles and separates falsification from correction. The framework supports interactive, programmatic, service-oriented, and reusable architectural deployments.

  • Architectural contribution: AutoMOOSE’s Use Case and Logical views expose roles and operation that a single block diagram would hide.The framework supports interactive use by researchers and programmatic use by automated optimizers.
  • Architectural contribution: Falsification and correction are distinct steps with distinct owners, so corrected runs require independent re-admission before acceptance.This separation preserves inspectability of corrected simulations.
  • Reuse modes: AutoMOOSE supports researchers as an interactive assistant for learning or running MOOSE phase-field simulations.This is one of three identified reuse modes.
  • Reuse modes: AutoMOOSE can operate as a headless simulation service behind optimization, active-learning, or parameter-sweep workflows through MCP and REST interfaces.This service-oriented mode supports programmatic workflow integration.
  • Reuse modes: AutoMOOSE provides an architectural template for wrapping other scientific solvers with plugin-constrained agents, execution monitoring, and separated falsification and recovery.The same two architectural views also apply in this reuse mode.

5 Limitations and future work

AutoMOOSE is limited by its currently implemented physics plugins, required execution infrastructure, language-model backend, and physics-specific falsification. Future work targets broader plugin coverage, plugin-level validation hooks, expanded multiphysics falsification, and containerized reference deployments.

  • 5 Limitations and future work: AutoMOOSE currently supports only registered grain-growth and spinodal-decomposition plugins, so intents outside that coverage are unsupported.Its execution also assumes a working MOOSE installation and, for HPC runs, a SLURM scheduler.
  • 5 Limitations and future work: Agent behavior depends on the selected language-model backend and its availability, while falsification remains physics-specific.The passage identifies these dependencies as direct consequences of the framework’s design.
  • 5 Limitations and future work: Future work will broaden the plugin library to additional MOOSE modules and add plugin-level validate_metrics hooks for physics-specific falsification.This moves falsification criteria from the central Skeptic into the plugin reuse boundary governing input generation and result parsing.
  • 5 Limitations and future work: Planned extensions include falsification for additional multiphysics simulation classes and containerized reference deployments with schema validation.The supplied passage states these as future-work directions.

6 Conclusions

This section describes AutoMOOSE’s architecture using the Use Case and Logical views of the 1+5 architectural-views model. It identifies the framework’s roles, functions, six-agent component structure, dependencies, and operational sequences.

  • The Use Case view identifies seven functions and three roles in the AutoMOOSE framework.
  • The Logical view presents the six-agent pipeline, its external dependencies, and operational sequences for primary and epistemic functions.
  • The described architecture is cross-consistent across its views, linking declared roles and components.

Declaration of generative AI use

AutoMOOSE uses large language models as its agents’ reasoning engine, and the authors used an AI assistant to prepare the manuscript while verifying its technical content, architecture, and claims against source code and a companion article.

  • Declaration of generative AI use: AutoMOOSE agents use large language models as their reasoning engine.The framework’s use of large language models is described as part of its agent design.
  • Declaration of generative AI use: The authors used an AI assistant during manuscript preparation and verified all technical content, architecture, and claims against the source code and companion article.The verification covered the manuscript’s technical content, architecture, and claims.

Code and data availability

AutoMOOSE is openly available under the MIT License, with documentation and version information provided. No experimental datasets were generated for this software article, while companion-study benchmark data are documented separately.

  • Code and data availability: AutoMOOSE v0.2.0 is openly available on GitHub under the MIT License, with documentation hosted on Read the Docs.The described version corresponds to Git commit d92239c on the main branch.
  • Code and data availability: No experimental datasets were generated for this software article; benchmark data for the companion study are described in that study.A versioned Zenodo archive with a citable DOI will be provided for the accepted version.

CRediT authorship contribution statement

The authors’ contributions span conceptualization, methodology, software, validation, writing, and funding acquisition, with Sukriti Manna leading the original draft.

  • CRediT authorship contribution statement: Sukriti Manna contributed conceptualization, methodology, software, validation, and original-draft writing; Henry Chan and Subramanian Sankaranarayanan contributed review writing, with Sankaranarayanan also securing funding.The statement assigns the original draft to Manna, review writing to Chan and Sankaranarayanan, and funding acquisition to Sankaranarayanan.
Loading 2608.20571v1…