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

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

arXiv:2608.20571v1 [cond-mat.mtrl-sci] 20 Aug 2026

Sukriti Manna1,2 , Henry Chan2 , and Subramanian Sankaranarayanan1, 2 1

Department of Mechanical and Industrial Engineering, University of Illinois Chicago, Chicago, IL 60607, USA 2 Center for Nanoscale Materials, Argonne National Laboratory, Lemont, IL 60439, USA smanna@anl.gov, skrssank@anl.gov

Abstract 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.

Keywords: agentic AI; scientific computing automation; software architecture; 1+5 architectural views; phase-field method; MOOSE

Code metadata Code metadata description

Details

Current code version

0.2.0

Permanent link to code / repository used for this version

https://github.com/sukritimanna/AutoMOOSE

Permanent link to Reproducible Capsule

Zenodo archive deposited on acceptance

Legal code license

MIT License

Code versioning system used

git

Software code languages, tools, and services used

Python (≥3.10), JavaScript/React (Vite); FastAPI, Starlette/uvicorn (backend); Model Context Protocol (MCP)

Compilation requirements, operating environments, dependencies

Python ≥3.10, Node.js ≥18; a compiled MOOSE phase_field-opt binary; SLURM (HPC execution only); a language-model backend (hosted or open-weights) 1

1

Code metadata description

Details

Link to developer documentation / manual

https://automoose.readthedocs.io

Support email for questions

smanna@anl.gov

Motivation and significance

Phase-field simulation is a workhorse of computational materials science [1, 2, 3], yet driving a general multiphysics solver such as the Multiphysics Object-Oriented Simulation Environment (MOOSE) [4, 5] requires a hand-written input file that encodes the mesh, the field variables, the free-energy kernels, the boundary conditions, the solver settings, and the post-processors. Authoring a correct input file is a specialist task, and a small error is often indistinguishable from a physically meaningful result until the run is inspected by eye. AutoMOOSE removes that barrier: it converts a single natural-language request into an executed and screened MOOSE phase-field simulation, with no manual editing of solver input. AutoMOOSE is aimed at computational materials researchers, students, and AI-for-science workflow developers who use — or would like to use — MOOSE for phase-field problems but are slowed by input authoring rather than by the science. It addresses a practical barrier: translating a scientific intent into a syntactically valid and physically meaningful MOOSE input file, executing it, diagnosing failure modes, and interpreting the result all require solver-specific expertise. Unlike a generic languagemodel prompt, AutoMOOSE couples language-model reasoning to a constrained software architecture — physics plugins, execution control, verification agents, and persistent run records — so that the product is not a draft input file but an executed, screened, and interpreted simulation. This agentic approach mirrors recent autonomous-experimentation systems in chemistry [6, 7], applied here to phasefield simulation and coupled to a constrained simulation architecture. Our framework is a pipeline of six language-model agents, each owning one epistemic role — planning, input authoring, solver execution, run screening, physics-invariant falsification, and interpretation. Its distinctive feature is that the agent which detects a physically implausible result is separated from the module that corrects a recoverable failure: the Skeptic agent falsifies but never repairs, and a separate closed-loop module acts on its verdict. The scientific evaluation of the framework — a pre-registered 25-task grain-growth benchmark [8, 9], recovery of an activation energy from an ensemble Arrhenius analysis, and validation on a second, conserved-dynamics domain (Fe–Cr spinodal decomposition [10]) — is reported in the companion article [11]. This work is concerned primarily with the software architecture: what the package does, who uses it, how its source is structured, and how its parts interact at run time. AutoMOOSE sits between three nearby categories of software. MOOSE by itself is a solver framework: it runs a phase-field problem but neither authors the input file nor judges the result. Workflow engines such as Parsl [12], FireWorks [13], and AiiDA [14] orchestrate and provenance-track simulation campaigns, but they assume the inputs already exist and do not reason about the physics. Generic language-model coding assistants can draft an input file from a prompt, but they are not constrained by a solverspecific plugin layer, do not execute or screen the run, and leave no auditable record. AutoMOOSE combines these concerns: plugin-constrained language-model authoring, solver execution and screening, physics-invariant falsification, and a persistent run record, all reachable through an MCP interface. We describe that architecture using a representative use case and logical views of the 1+5 architecturalviews model [15, 16]. The model defines six views, but two of them apply to every software package, and we use both. The Use Case view names the package’s functions and the roles that exercise them. The Logical view does two jobs: it shows the source-code structure (as UML class or component diagrams) 2

and the run-time operation (as UML sequence diagrams) [16]. The model also requires the views to agree: every role named in the "Use Case" view, and every component named in the structure, must reappear on the lifelines of the sequence diagrams. This discipline is what makes the two views worth the effort for an agentic framework. Such systems are easy to sketch as a single high-level block diagram; the 1+5 views instead force an account that is at once structural and operational.

2

Software description

2.1

Software architecture

AutoMOOSE is organized as four layers. A request enters through one of two interface surfaces — a React frontend (App.jsx) for interactive use, or a Model Context Protocol (MCP) server (mcp_server.py, ten tools) for programmatic clients — both of which call a FastAPI backend (server.py, port 8000). The backend orchestrates the six-agent pipeline 𝑆 = 𝑓5 ∘ 𝑓6 ∘ 𝑓4 ∘ 𝑓3 ∘ 𝑓2 ∘ 𝑓1 (𝑈 ),

(1)

where 𝑈 is the user request, 𝑓1 is the Architect (plan), 𝑓2 the Input Writer, 𝑓3 the Runner, 𝑓4 the Reviewer (execution screen), 𝑓5 the Visualization agent, and 𝑓6 the Skeptic (falsification). The composition is read right to left: 𝑓1 is applied first and 𝑓5 last, so the run-time order is 𝑓1 → 𝑓2 → 𝑓3 → 𝑓4 → 𝑓6 → 𝑓5 — the Skeptic falsifies before the Visualization agent interprets — with the recovery branch entered only on a falsified, recoverable failure (Section 2.4). Physics is resolved through a plugin layer (plugin_registry.py, loading the grain_growth and spinodal plugins), and the language-model calls route through a provider-independent client (llm/), keeping the framework model-agnostic. For local runs the Runner executes the MOOSE solver directly; for HPC it submits through SLURM. Listing 1 shows the pipeline as the backend realizes it: a linear hand-off 𝑓1 → 𝑓2 → 𝑓3 → 𝑓4 → 𝑓6 , with early exits when a stage cannot proceed. The backend orchestration ends after the Skeptic’s admission and the assembly of the run record; the Visualization/Interpretation agent (𝑓5 ) then consumes that record in the client application layer to render the figures and generate the natural-language interpretation. # automoose/agents/orchestrator.py (condensed) def orchestrate(physics, params, backend): row = {"backend": backend, "provider": PROVIDER, "physics": physics, "params": params} f1_architect(physics, params) # plan i = f2_input(physics, params) # write .i → input_ok, input_lines if not i["input_ok"]: return _finish(row, ...) # early exit: input rejected r = f3_run(physics, params) # execute → run_id, completed, wall_s if not r["completed"]: return _finish(row, ...) # early exit: run failed f4_review(r["run_id"]) # screen → review, valid, metrics f6_skeptic(r["run_id"], physics, params) # falsify → credible, falsified_by return _finish(row, ...) # f5 consumes record in the app layer

Listing 1: The six-agent pipeline as orchestrated by the backend (condensed from orchestrator.py). Each 𝑓𝑖 enriches a shared run record; screening (𝑓4 ) and falsification (𝑓6 ) gate the result but never repair it.

2.2

Software functionalities

With the layered architecture sketched, we now develop it through the two applicable 1+5 views in turn — first the Use Case view (the functions and the roles that exercise them), then the Logical view (the 3

Figure 1: Use Case view. UML use case diagram of AutoMOOSE. Three roles (UML actors) — Researcher, AI optimizer client, and Plugin developer — exercise seven functions. The Researcher reaches the full set; the AI optimizer client reaches the run, sweep, and interpret functions programmatically through the Model Context Protocol (MCP) (dashed), with screening, falsification, and recovery running automatically inside them; the Plugin developer reaches the extension function. Teal use cases are the epistemic functions (falsification and recovery) distinctive to the framework. source structure and the run-time operation). AutoMOOSE offers seven functions (use cases) to three roles (UML actors). The roles are the Researcher, who drives the simulation functions interactively; an AI optimizer client, which reaches the run, sweep, and interpret functions programmatically through MCP — for example, an outer Bayesian-optimization loop; and a Plugin developer, who extends the physics coverage. Figure 1 depicts the Use Case view. The Researcher reaches the full set of functions: generating a simulation from a prompt, running a single simulation, running a parameter sweep, screening and falsifying a result, recovering from a failure, and interpreting and visualizing output. The AI optimizer client reaches the run/sweep/interpret subset through MCP, with screening, falsification, and recovery running automatically inside those functions. The Plugin developer reaches only the extension function, registering a physics plugin. This mirrors the way the example real-estate package of [16] assigns its functions to Seller and Buyer roles, here generalized to a programmatic third actor.

4

Figure 2: Logical view: structure. UML component diagram of AutoMOOSE. Two interface packages (frontend, mcp) depend on the FastAPI backend, which orchestrates the agents package; the six agents 𝑓1 –𝑓6 realize the pipeline 𝑆 = 𝑓5 ∘ 𝑓6 ∘ 𝑓4 ∘ 𝑓3 ∘ 𝑓2 ∘ 𝑓1 (𝑈 ), with the closed-loop recovery.py module alongside the screening agents. The agents package depends on the plugins package (physics resolution) and the model-agnostic llm client. The 𝑓3 Runner reaches the external MOOSE/SLURM environment. Dashed open arrows denote «use» dependencies. The Visualization/Interpretation agent (𝑓5 ) appears as the sixth pipeline role; its figures and interpretation are rendered in the frontend from the completed run record.

2.3

Software structure

The Logical view first shows the source-code structure. AutoMOOSE is larger than a single package, so we describe it at the component level — an abstraction the 1+5 model explicitly permits. The external MOOSE/SLURM environment here plays the role that the external java package plays in the worked example of [16]. Figure 2 reads top-down as a chain of «use» dependencies: both interface packages depend on the backend; the backend depends on the agents package; and the agents package depends on the plugins package (physics resolution) and on the llm client (model-agnostic inference). The six agents 𝑓1 –𝑓6 are the classes inside the agents package, with the closed-loop recovery.py module alongside the screening agents. Just as the example package’s model depends on the external java package, the 𝑓3 Runner depends on the external MOOSE solver and the SLURM scheduler.

2.4

Software operation

The Logical view also shows operation, as a sequence of method invocations realizing each function. Following the model, we present one sequence diagram per function and give the two most architecturally revealing here. Figure 3 realizes the primary “generate and run simulation from prompt” function. The backend sequences 𝑓1 → 𝑓2 → 𝑓3 ; the Runner launches MOOSE through sbatch; and the screening– 5

Figure 3: Logical view: operation (primary function). UML sequence diagram realizing the “generate and run simulation from prompt” use case of Fig. 1. The backend sequences 𝑓1 → 𝑓2 → 𝑓3 ; the Runner launches MOOSE through sbatch; and the screening–falsification–interpretation trio (𝑓4 screen, 𝑓6 falsify, 𝑓5 interpret) runs before the screened result returns. The alt fragment is the conditional recovery branch, entered only when the Skeptic diagnoses time-step divergence. falsification–interpretation trio — 𝑓4 screening, 𝑓6 falsification, 𝑓5 interpretation — runs before the screened result returns to the Researcher. The alt fragment is the conditional recovery branch, entered only when the Skeptic diagnoses a recoverable time-step divergence. Figure 4 isolates the function with no analogue in a conventional CRUD application and central to this framework: the screen/falsify-and-recover loop. The 𝑓6 Skeptic tests physics-grounded invariants — conservation, asymptotic limits, symmetry, and scaling relations — and returns a credible-or-falsified verdict, but it performs no repair. The alt fragment fires only on a falsified divergence, where recovery.py classifies the failure and applies the bounded time-step cutback Δ𝑡 ← 𝛼 Δ𝑡 with 𝛼 = 0.5; the corrected input is regenerated and re-run, and a corrected run is accepted only if it independently re-completes and the Skeptic re-admits it. Recovery is bounded in three ways: a hard cap of three attempts per task; corrections that touch only numerical and discretization controls (the time step, floored at a minimum value, the mesh refinement, and the integration window) and never the physical parameters of the problem; and a change record written for every correction. Although these edits change the discretization, and therefore the resolution at which the simulation is integrated, they never alter the material constants or free-energy coefficients set by the user input. This division of labor — detection separated from correction — is the structural expression of the framework’s epistemic design. The three checks have distinct, deliberately narrow scopes. Screening (𝑓4 ) is an execution-level check — did the run complete and is its output present and parseable? Falsification (𝑓6 ) applies plugin-specific physics invariants that can reject a result when a declared invariant is violated; these are bounded, software-encoded rejection criteria, not a proof of physical correctness. Recovery applies only predefined numerical corrections for diagnosed recoverable failures, and is kept separate from falsification. Listing 2 shows two of the grain-growth invariants as the Skeptic implements them.

6

# T1 monotonicity: grain count must not spontaneously increase big_jumps = sum(1 for a, b in zip(n, n[1:]) if b > a + 1) net_rise = n[-1] - min(n) sustained = net_rise > max(1, 0.1 * max(n)) tests["T1_monotonicity"] = {"pass": big_jumps == 0 and not sustained} # T3 parabolic (Burke-Turnbull): 1/N linear in t, R^2 >= 0.90 pts = [(ti, 1.0 / ni) for ti, ni in zip(t, n) if ti > 0 and ni > 0] slope, _, r2 = _linfit([p[0] for p in pts], [p[1] for p in pts]) tests["T3_parabolic"] = {"pass": r2 >= 0.90 and slope > 0, "R2": r2}

Listing 2: Two Skeptic invariants for grain growth (condensed from skeptic.py): T1 forbids spontaneous grain nucleation; T3 tests Burke–Turnbull parabolic kinetics (1/𝑁 linear in 𝑡, 𝑅2 ≥ 0.90). The recovery module turns a falsified or incomplete run into a bounded, logged correction. Listing 3 shows the two halves: classify_failure maps a real MOOSE log signature or a Skeptic verdict to a failure class, and apply_correction edits only numerical and discretization controls — each within a hard bound and recorded as a {from, to, why} entry. # automoose/agents/recovery.py (condensed) MAX_ATTEMPTS = 3 # generate → run → verify attempts per task MIN_DT0 = 1.0 # ns; never reduce the initial timestep below this def classify_failure(log_text, completed, skeptic_verdict): # map a MOOSE log signature or a Skeptic verdict to a failure class, e.g. # SOLVER_DIVERGENCE, KINETICS_NOT_ASYMPTOTIC, NONPHYSICAL_NUCLEATION ... def apply_correction(params, diagnosis): """Return (new_params, change_record); pure, bounded, logged.""" p = dict(params) # never mutate the input cls = diagnosis["class"] if cls in ("SOLVER_DIVERGENCE", "NAN_DETECTED"): dt0 = float(params.get("dt_start", DEFAULT_DT_START)) p["dt_start"] = max(MIN_DT0, dt0 / 2.0) # halve, floored elif cls == "KINETICS_NOT_ASYMPTOTIC": p["end_time"] = min(MAX_END_TIME, float(params["end_time"]) * 2) elif cls == "NONPHYSICAL_NUCLEATION": p["uniform_refine"] = min(MAX_REFINE, params.get("uniform_refine", 1) + 1) return p, {"class": cls, "edits": _diff(params, p)} # {from, to, why}

Listing 3: Bounded, logged recovery (condensed from recovery.py): corrections halve the time step (floored at MIN_DT0), extend the integration window (capped at MAX_END_TIME), or refine the mesh (capped at MAX_REFINE), never the physical parameters; the loop is capped at MAX_ATTEMPTS.

2.5

Cross-view consistency

The description meets the consistency that the 1+5 model requires [16], and it does so in three ways. First, the roles carry across: the Researcher who drives “generate and run simulation from prompt” in the Use Case view (Fig. 1) is the same actor on the lifeline of Fig. 3. Second, the components carry across: backend, 𝑓1 –𝑓6 , recovery.py, and the external MOOSE are all declared in the structure (Fig. 2) before they appear as lifelines in Figs. 3 and 4; no lifeline is used that the structure did not first introduce. Third, each use case maps to a sequence diagram: “generate and run simulation from prompt” to Fig. 3, and “screen/falsify” and “recover from failure” to Fig. 4. The remaining functions — run sweep, interpret, and register plugin — would each take their own sequence diagram to complete the Logical view.

7

Figure 4: Logical view: operation (epistemic loop). UML sequence diagram realizing the “screen/falsify” and “recover from failure” use cases of Fig. 1. The 𝑓6 Skeptic tests the physics invariants and returns a verdict but performs no repair; the alt fragment fires only on a falsified divergence, where recovery.py classifies the failure and applies the bounded time-step cutback Δ𝑡 ← 𝛼 Δ𝑡. A corrected run is accepted only if it re-completes and the Skeptic re-admits it.

2.6

Physics plugins

The two views establish what AutoMOOSE is and how it operates. Three further concerns govern how it is reused in practice: how new physics is added, how the framework is installed and what each run records, and how it is driven programmatically. We take these in turn, beginning with physics extension. Physics coverage lives in a plugin layer that the agents never need to know the internals of. A plugin is a directory under automoose/plugins/ containing a plugin.py that exposes a PLUGIN metadata dictionary (label, status, parameters, and sweepable fields) together with a module-level generate_input(**params) → str; an optional parse_results(csv_data) → dict maps solver output to metrics. The registry (plugin_registry.py) auto-discovers every such directory at start-up, so adding physics requires no change to the agents or the backend (Listing 4). Table 2 lists the released plugins. A stub plugin guards against accidental use on two levels: its generate_input raises NotImplementedError, and the backend rejects any generate or run request for a stub-status plugin with an HTTP 400 response before the pipeline starts.

8

Table 2: Physics plugins in the released version. The two “ready” plugins are the conserved- and nonconserved-dynamics domains validated in the companion article [11]; two further plugins are stubs in development, included as extension templates rather than validated physics capabilities of this release. Plugin

Physics domain

Status

Key parameters

grain_growth spinodal solidification ferro

Allen–Cahn grain growth Cahn–Hilliard phase separation dendritic solidification ferroelectric (Landau–Devonshire)

ready ready stub stub

num_grains, T, GBenergy, GBmob0, op_num c0, kappa, M, W, noise, end_time — —

# automoose/plugins/myphysics/plugin.py PLUGIN = { "label": "My Physics", "status": "ready", # "ready" | "stub" "params": {...}, # name → {default, range, ...} "sweepable": ["T", "..."], # parameters a sweep may vary "executable_key": "MOOSE_EXEC", # env var holding the solver path } def generate_input(**params) → str: """Return a complete MOOSE .i input file as a string.""" ... def parse_results(csv_data) → dict: # optional """Map MOOSE postprocessor CSV to a metrics dict.""" ...

Listing 4: A physics plugin is a PLUGIN dict and a generate_input function in a per-plugin plugin.py; the registry auto-discovers it, with no registration call.

2.7

Implementation and availability

The second concern is getting the framework running and making each run reproducible. AutoMOOSE installs from source. After cloning the repository, the backend is set up with pip install -r requirements.txt (FastAPI, uvicorn, the Anthropic SDK, and Pydantic; Python ≥3.10), and the optional React interface with npm install in frontend/ (Node ≥18). A config.env file names the compiled MOOSE executable (MOOSE_EXEC) and the language-model backend. Because reasoning is routed through a provider-agnostic client (llm/), the same pipeline runs on different model backends — for example Claude, Qwen, or Llama — by editing config.env rather than the code. The command bash start.sh launches the FastAPI backend (port 8000) and the frontend; the MCP server (automoose/mcp_server.py) runs in stdio mode for Claude Desktop or in SSE mode on port 8001. A new user can confirm a working installation by setting MOOSE_EXEC, launching the backend, calling the MCP health_check tool, and running the grain-growth example of Listing 6; a successful install returns a run_id, a completed status, parsed coarsening metrics, and a run record. Failures are surfaced at well-defined points: health_check catches a missing executable before any run, the Reviewer marks a run failed when output is absent or unparseable, the Skeptic rejects a result that violates an invariant, and stop_run terminates an active job. Every run produces a structured record that ties natural-language intent to numerical output. The orchestrator emits, per run, the model backend and provider, the physics and parameters, the generated input size, the run identifier and terminal status, the wall-clock time, the Reviewer’s verdict with extracted metrics, and the Skeptic’s verdict (credible, falsified_by, and a diagnosis). Recovery actions are logged alongside, so an automatically corrected run carries an audit trail from prompt to 9

Table 3: The ten MCP tools exposed by mcp_server.py. Screening, falsification, and recovery execute inside the backend pipeline rather than as separately callable tools. MCP tool

Function

Typical caller

health_check list_plugins generate_input run_simulation run_sweep get_run_status get_results list_runs get_log_tail stop_run

verify backend and MOOSE executables are found list physics plugins, parameters, and sweep fields preview a MOOSE .i file without running launch one simulation; returns a run_id launch a parallel sweep over a parameter list poll status: pending / running / done / failed retrieve metrics (𝑁 (𝑡), 𝑅2 , d𝑁/d𝑡, . . . ) browse run history with optional filters read the last 𝑁 lines of the solver log terminate an active simulation

any any researcher / optimizer researcher / optimizer optimizer optimizer researcher / optimizer researcher / optimizer researcher researcher / optimizer

accepted result. Listing 5 lists the fields the orchestrator writes for every run. record = { "backend": str, "provider": str, "model": str, # language-model identity "physics": str, "params": dict, # what was requested (f1) "input_ok": bool, "input_lines": int, # generated-input size (f2) "run_id": str, "run_status": str, "wall_s": float, # execution (f3) "review": str, "valid": bool, "metrics": dict, # screening + observables (f4) "credible": bool, "falsified_by": list, # falsification verdict (f6) "skeptic_diagnosis": str, }

Listing 5: Fields written to each run record (from orchestrator.py), grouped by the agent that produces them. The record, not a re-query of the language model, is the unit of provenance and reproducibility. Because language-model outputs may vary across providers and model versions, AutoMOOSE treats the generated MOOSE input file together with the run record as the reproducible artifacts. Re-executing an accepted simulation therefore does not require re-querying the language model: it requires the saved .i file, the recorded parameters, and the solver environment. Recording the software commit, plugin version, language-model identity, the MOOSE version, a hash of the generated .i file, and the random seed where the initial condition is stochastic further tightens this guarantee and is recommended when results are to be archived.

2.8

The MCP interface

The third concern is driving the framework programmatically: it exposes ten Model Context Protocol tools (Table 3). These cover the run, sweep, monitoring, and retrieval surface that an outer optimization loop needs; falsification and recovery are not separate tools but run inside the backend pipeline that run_simulation and run_sweep invoke. A sweep launches one independent pipeline run per parameter value — each with its own run identifier, run record, and fresh model context — so language-model context does not accumulate across the sweep, and long solver logs are exposed through get_log_tail rather than fed back in full.

10

# Via the MCP tools (e.g. from an outer optimization loop) run_simulation(physics="grain_growth", params={"T": 450, "num_grains": 15, "dim": 2}) get_run_status(run_id) get_results(run_id)

# → run_id # → "done" # → metrics

# Equivalent over the FastAPI REST backend (port 8000) import httpx started = httpx.post("http://localhost:8000/run", json={"physics": "grain_growth", "params": {"T": 450, "num_grains": 15}}).json() run_id = started["run_id"] status = httpx.get(f"http://localhost:8000/runs/{run_id}").json()["status"]

Listing 6: Driving a simulation programmatically: the MCP tools (top) and the equivalent FastAPI REST calls on port 8000 (bottom).

3

Illustrative example

A minimal session exercises the primary function end-to-end. The Researcher submits a request such as “simulate copper grain growth at 450 K on a 15-grain polycrystal and report the coarsening kinetics.” The Architect (𝑓1 ) produces a structured simulation plan; the Input Writer (𝑓2 ) emits a complete MOOSE input file; the Runner (𝑓3 ) submits the job through sbatch and streams the solver log back over Server-Sent Events; the Reviewer (𝑓4 ) confirms the run completed; the Skeptic (𝑓6 ) tests the result against the grain-growth invariants (grain-count monotonicity, Burke–Turnbull parabolic scaling, and numerical integrity); and the Visualization agent (𝑓5 ) returns the fitted kinetics with a natural-language interpretation. Each run leaves a self-contained directory of artifacts: the generated .i input, the solver logs, the postprocessor CSV files, the parsed metrics, and record.json. Programmatically, the same simulation is a single MCP run_simulation call (Listing 6), after which get_run_status polls to completion and get_results returns the metrics (the grain-count trajectory 𝑁 (𝑡), the Burke–Turnbull [17] parabolic-fit 𝑅2 , and the coarsening rate). Equivalently, the headless orchestrator drives the whole 𝑓1 → 𝑓6 loop from the command line, python -m automoose.agents.orchestrator \ --physics grain_growth --params ’{"T": 450, "num_grains": 15}’ which is how an outer optimization loop uses the framework without the user interface. The quantitative behavior of these runs — benchmark pass rates, fitted activation energy, and the second-domain validation — is reported in [11].

4

Impact and reuse potential

The architectural contribution of AutoMOOSE is to give an agentic scientific-computing framework an account that is both structural and operational, rather than a single block diagram. Describing the framework in the Use Case and Logical views makes three things explicit that a block diagram hides. First, the roles: the framework is usable both interactively by a researcher and programmatically by an automated optimizer, and the Use Case view names that second actor as a first-class user rather than an afterthought. Second, the structure: the model-agnostic llm client and the plugin layer are separate dependencies of the agents package, which is what makes the framework portable across languagemodel backends and extensible to new physics without touching the agents. Third, the operation: the

11

sequence diagrams show that falsification and correction are distinct steps with distinct owners, which is the property that lets a corrected run be accepted only after independent re-admission. Concretely, AutoMOOSE supports three reuse modes. It can serve as an interactive assistant for researchers learning or running MOOSE phase-field simulations; as a headless simulation service behind optimization, active-learning, or parameter-sweep workflows through the MCP and REST interfaces; and as an architectural template for wrapping other scientific solvers with plugin-constrained agents, execution monitoring, and separated falsification and recovery. In that third mode the same two views describe any pipeline that turns a natural-language request into a screened and recorded artifact through a chain of specialized agents, not only phase-field simulation: the plugin and backend-client seams generalize directly to other solvers and model providers. Concretely, the agent orchestration is designed to be solver-agnostic: porting AutoMOOSE to a different solver would primarily require replacing the plugin layer and the Runner’s execution backend, while reusing the same high-level Architect–Writer– Reviewer–Skeptic–recovery pattern. Because a plugin’s generate_input returns the solver input as an opaque string, a target that consumes XML or JSON rather than MOOSE’s .i format is accommodated entirely within the plugin: the agents and backend never parse the input deck and are unaffected by its syntax. The framework is released under the MIT License with documentation, so the architecture described here is directly inspectable, reusable, and extensible through the documented plugin and MCP interfaces.

5

Limitations and future work

AutoMOOSE has scope limits that follow directly from its design. Its physics coverage is bounded by the plugins currently implemented (grain growth and spinodal decomposition); an intent that falls outside a registered plugin is not supported. The framework assumes a working MOOSE installation and, for HPC execution, a SLURM scheduler. Because the agents reason through a language model, their behavior depends on the chosen backend and its availability. Falsification is physics-specific: the Skeptic falsifies a result only against the invariants currently defined for that physics (grain growth and spinodal), so a domain without such invariants cannot be screened automatically. Automatic recovery is deliberately conservative — it is limited to failure modes for which a bounded correction can be justified, such as time-step divergence — and human inspection remains advisable when extending the framework to new physics or producing publication-grade results. Software maturity is still developing, though the test infrastructure is in place: the repository ships a 25-task grain-growth evaluation set (run by run_evalset.py and scored by score_evalset.py), recovery-validation scripts, and an offline unit-test suite run under continuous integration (GitHub Actions). The suite covers plugin discovery, PLUGIN schema validation, MCP tool contracts, run-record serialization, and the physics invariants; its contract and schema tests run against a deterministic mock model backend, so they execute offline in CI without incurring language-model API calls. Broadening this coverage — for example towards end-to-end, solver-in-the-loop integration tests — remains ongoing. Future work will broaden the plugin library to further MOOSE modules and make falsification invariants part of the plugin contract through a plugin-level validate_metrics hook, moving physics-specific falsification criteria out of the central Skeptic and into the same reuse boundary that already controls input generation and result parsing. We also plan to extend the falsification layer to additional classes of multiphysics simulation, add containerized reference deployments and schema-validated agent outputs for reproducibility, and strengthen support for offline, open-weight model backends.

12

6

Conclusions

We have described the architecture of AutoMOOSE, an agentic framework for phase-field simulation, the Use Case and Logical views of the 1+5 architectural-views model. The Use Case view names seven functions and three roles; the Logical view depicts the component structure of the six-agent pipeline together with its external dependencies, and the operational sequences that realize its primary and epistemic functions. The description is cross-consistent: roles and components declared in one view reappear in the others. The scientific validation of the framework is reported separately [11]; the architecture documented here is what makes that framework portable, extensible, and inspectable.

Declaration of competing interest The authors declare that they have no known competing financial interests or personal relationships that could have appeared to influence the work reported in this paper.

Declaration of generative AI use The AutoMOOSE framework itself uses large language models as the reasoning engine of its agents, as described above. The authors also used an AI assistant during the preparation of this manuscript; all technical content, architecture, and claims were verified by the authors against the source code and the companion article.

Code and data availability AutoMOOSE is openly available at https://github.com/sukritimanna/AutoMOOSE under the MIT License, with documentation at https://automoose.readthedocs.io. The version described here is AutoMOOSE v0.2.0, corresponding to Git commit d92239c on the main branch. A versioned Zenodo archive with a citable DOI will be provided for the accepted version. No experimental datasets were generated for this software article; the benchmark data underlying the companion study [11] are described there.

CRediT authorship contribution statement Sukriti Manna: Conceptualization, Methodology, Software, Validation, Writing — original draft. Henry Chan: Writing — review. Subramanian Sankaranarayanan: Funding acquisition, Writing — review.

Acknowledgements This work was supported by the DOE Office of Science, Basic Energy Sciences under the AI-Pathfinder project. Work at the Center for Nanoscale Materials, a U.S. DOE Office of Science User Facility, was supported under Contract No. DE-AC02-06CH11357. This work used NERSC, supported by the DOE Office of Science under Contract No. DE-AC02-05CH11231. We acknowledge LCRC computing facilities at Argonne.

13

References [1] Long-Qing Chen. Phase-field models for microstructure evolution. Annual Review of Materials Research, 32:113–140, 2002. doi: 10.1146/annurev.matsci.32.112001.132041. [2] Nele Moelans, Bart Blanpain, and Patrick Wollants. An introduction to phase-field modeling of microstructure evolution. Calphad, 32(2):268–294, 2008. doi: 10.1016/j.calphad.2007.11.003. [3] Sukriti Manna, Henry Chan, Avishek Ghosh, Tamoghna Chakrabarti, and Subramanian KRS Sankaranarayanan. Understanding and control of zener pinning via phase field and ensemble learning. Computational Materials Science, 229:112384, 2023. [4] Derek Gaston, Chris Newman, Glen Hansen, and Damien Lebrun-Grandié. MOOSE: A parallel computational framework for coupled systems of nonlinear equations. Nuclear Engineering and Design, 239(10):1768–1778, 2009. doi: 10.1016/j.nucengdes.2009.05.021. [5] Cody J. Permann, Derek R. Gaston, David Andrš, et al. MOOSE: Enabling massively parallel multiphysics simulation. SoftwareX, 11:100430, 2020. doi: 10.1016/j.softx.2020.100430. [6] Daniil A. Boiko, Robert MacKnight, Ben Kline, and Gabe Gomes. Autonomous chemical research with large language models. Nature, 624:570–578, 2023. doi: 10.1038/s41586-023-06792-0. [7] Andres M. Bran, Sam Cox, Oliver Schilter, Carlo Baldassari, Andrew D. White, and Philippe Schwaller. Augmenting large language models with chemistry tools. Nature Machine Intelligence, 6:525–535, 2024. doi: 10.1038/s42256-024-00832-8. [8] Samuel M. Allen and John W. Cahn. A microscopic theory for antiphase boundary motion and its application to antiphase domain coarsening. Acta Metallurgica, 27(6):1085–1095, 1979. doi: 10.1016/0001-6160(79)90196-2. [9] Danan Fan and Long-Qing Chen. Computer simulation of grain growth using a continuum field model. Acta Materialia, 45(2):611–622, 1997. doi: 10.1016/S1359-6454(96)00200-5. [10] John W. Cahn and John E. Hilliard. Free energy of a nonuniform system. I. interfacial free energy. Journal of Chemical Physics, 28(2):258–267, 1958. doi: 10.1063/1.1744102. [11] Sukriti Manna, Henry Chan, and Subramanian KRS Sankaranarayanan. Automoose: An agentic ai for autonomous phase-field simulation. arXiv preprint arXiv:2603.20986, 2026. [12] Yadu Babuji, Anna Woodard, Zhuozhao Li, et al. Parsl: Pervasive parallel programming in Python. In Proc. 28th Int. Symp. on High-Performance Parallel and Distributed Computing (HPDC ’19), pages 25–36. ACM, 2019. doi: 10.1145/3307681.3325400. [13] Anubhav Jain, Shyue Ping Ong, Wei Chen, et al. FireWorks: a dynamic workflow system designed for high-throughput applications. Concurrency and Computation: Practice and Experience, 27(17): 5037–5059, 2015. doi: 10.1002/cpe.3505. [14] Giovanni Pizzi, Andrea Cepellotti, Riccardo Sabatini, Nicola Marzari, and Boris Kozinsky. AiiDA: automated interactive infrastructure and database for computational science. Computational Materials Science, 111:218–230, 2016. doi: 10.1016/j.commatsci.2015.09.013. [15] Tomasz Górski. The 1+5 architectural views model in designing blockchain and IT system integration solutions. Symmetry, 13(11):2000, 2021. doi: 10.3390/sym13112000.

14

[16] Tomasz Górski. Software architecture description in original software publications. Software Impacts, 27:100802, 2026. doi: 10.1016/j.simpa.2025.100802. [17] J. E. Burke and D. Turnbull. Recrystallization and grain growth. Progress in Metal Physics, 3: 220–292, 1952. doi: 10.1016/0502-8205(52)90009-9.

15

Related documents

• AutoMOOSE: Use Case and Logical Views of Agentic Phase-Field Simulation Software#659135
• AutoMOOSE: Use Case and Logical Views of Agentic Phase-Field Simulation Software#656999
• Grid-Orch: An LLM-Powered Orchestrator for Distribution Grid Simulation and Analytics#180732
• Grid-Orch: An LLM-Powered Orchestrator for Distribution Grid Simulation and Analytics#1105048
• exa-PD: A scalable high-performance workflow for multi-element phase diagram construction#381718