OpInf-LLM: Parametric PDE Solving with LLMs via Operator Inference

Hanjiang Hu; Saviz Mowlavi; Xiyu Deng; Yorie Nakahira; Zhuoyuan Wang

arxiv: 2602.01493 · v2 · submitted 2026-02-02 · 💻 cs.LG · cs.AI

OpInf-LLM: Parametric PDE Solving with LLMs via Operator Inference

Zhuoyuan Wang , Hanjiang Hu , Xiyu Deng , Saviz Mowlavi , Yorie Nakahira This is my paper

Pith reviewed 2026-05-16 08:13 UTC · model grok-4.3

classification 💻 cs.LG cs.AI

keywords operator inferenceparametric PDEslarge language modelsreduced-order modelinggeneralizationnumerical accuracyfeature parameterization

0 comments

The pith

OpInf-LLM applies operator inference to small solution datasets so LLMs can solve diverse parametric PDEs accurately, including for unseen parameters and boundary conditions.

A machine-rendered reading of the paper's core claim, the machinery that carries it, and where it could break.

The paper presents OpInf-LLM as a framework that pairs operator inference with large language models to handle parametric partial differential equations. It shows that limited solution data suffices for accurate predictions across varied PDE instances and configurations. Integration with LLMs enables natural language task descriptions and physics-guided selection of features for parameterization. The resulting pipeline runs with low computation and delivers high success rates even when parameters or boundaries differ from training cases.

Core claim

OpInf-LLM leverages small amounts of solution data to enable accurate prediction of diverse PDE instances, including unseen parameters and configurations, and provides seamless integration with LLMs for natural language task specification and physics-based reasoning of proper feature parameterization. Its low computational demands and unified solution pipeline further enable a high execution success rate across heterogeneous settings.

What carries the argument

Operator inference applied to small solution datasets, integrated with LLM-driven feature parameterization and reasoning.

Load-bearing premise

Operator inference applied to small solution datasets produces numerically accurate predictions for unseen parameters and boundary conditions when LLMs manage feature parameterization.

What would settle it

Apply the method to a test PDE with parameters or boundary conditions outside the training range and check whether the relative error against a high-fidelity reference solution stays below a chosen numerical threshold.

Figures

Figures reproduced from arXiv: 2602.01493 by Hanjiang Hu, Saviz Mowlavi, Xiyu Deng, Yorie Nakahira, Zhuoyuan Wang.

**Figure 1.** Figure 1: Trade-offs in prediction error and success rate. under strict accuracy and robustness requirements. As a result, there is growing interest in automated and generalizable PDE solvers that can flexibly adapt to new problem instances without extensive manual intervention or retraining (Karniadakis et al., 2021; Li et al., 2020; Lu et al., 2019; Sun et al., 2025; Ye et al., 2024; Liu et al., 2024a). Large la… view at source ↗

**Figure 2.** Figure 2: Overall diagram of the OpInf-LLM framework. In the offline stage, shared basis and reduced-order operators are obtained from limited amounts of PDE solution data via proper orthogonal decomposition (POD) and least-squares optimization. In the online stage, LLM parses natural language instructions, generates code or calls agentic tools for operator regression and reduced-order ODE integration, to predict PD… view at source ↗

**Figure 3.** Figure 3: Heat equation predictions for ν = 1.0 and ν = 3.0. All plots share the same color scale. Results are shown for CodePDE, LLM and OpInf-LLM with GPT-4.1. stream function formulation ωt + v1 ωp1 + v2 ωp2 = 1 Re (ωp1p1 + ωp2p2 ), (16) ∆ψ = −ω, (17) where ω is the vorticity, x = (p1, p2) ∈ [0, 1]2 denotes the two-dimensional spatial coordinate, subscripts p1 and p2 indicate corresponding partial derivatives, an… view at source ↗

**Figure 5.** Figure 5: Lid-driven cavity predictions for Re = 80 and Re = 120 at t = 1 and t = 2. All plots share the same color scale. Results are shown for CodePDE, LLM and OpInf-LLM with GPT-4.1. ablation to evaluate the physical reasoning capability of OpInf-LLM. In standard parametric OpInf, simple regression structures (e.g., linear dependence on parameters) are often assumed a priori (McQuarrie et al., 2023). However, th… view at source ↗

**Figure 6.** Figure 6: Heat equation predictions of different ν. 37 [PITH_FULL_IMAGE:figures/full_fig_p037_6.png] view at source ↗

**Figure 7.** Figure 7: Burgers’ equation predictions of different ν. 38 [PITH_FULL_IMAGE:figures/full_fig_p038_7.png] view at source ↗

**Figure 8.** Figure 8: Cavity results across Reynolds numbers. 39 [PITH_FULL_IMAGE:figures/full_fig_p039_8.png] view at source ↗

**Figure 9.** Figure 9: Cavity results across Reynolds numbers. 40 [PITH_FULL_IMAGE:figures/full_fig_p040_9.png] view at source ↗

read the original abstract

Solving diverse partial differential equations (PDEs) is fundamental in science and engineering. Large language models (LLMs) have demonstrated strong capabilities in code generation, symbolic reasoning, and tool use, but reliably solving PDEs across heterogeneous settings remains challenging. Prior work on LLM-based code generation and transformer-based foundation models for PDE learning has shown promising advances. However, a persistent trade-off between execution success rate and numerical accuracy arises, particularly when generalization to unseen parameters and boundary conditions is required. In this work, we propose OpInf-LLM, an LLM parametric PDE solving framework via operator inference. The proposed framework leverages small amounts of solution data to enable accurate prediction of diverse PDE instances, including unseen parameters and configurations, and provides seamless integration with LLMs for natural language task specification and physics-based reasoning of proper feature parameterization. Its low computational demands and unified solution pipeline further enable a high execution success rate across heterogeneous settings, opening new possibilities for generalizable reduced-order modeling in LLM-based PDE solving.

Editorial analysis

A structured set of objections, weighed in public.

Desk editor's note, referee report, simulated authors' rebuttal, and a circularity audit. Tearing a paper down is the easy half of reading it; the pith above is the substance, this is the friction.

Desk Editor's Note private letter to a colleague

OpInf-LLM adds operator inference to an LLM pipeline for parametric PDEs from small data, but the accuracy claim for unseen parameters rests on an untested extension of standard OpInf.

read the letter

OpInf-LLM pairs an LLM for natural-language problem specification and feature reasoning with operator inference on limited solution snapshots to produce predictions for new PDE instances. The goal is to keep the high execution success rate of LLM code tools while gaining numerical accuracy that pure transformer models often miss on parametric cases. The pipeline is presented as low-cost and unified, which is a practical angle for users who want to describe problems in words and get reduced-order results without full-scale simulation runs. The paper does a reasonable job laying out this hybrid structure and noting the small-data requirement, which aligns with real engineering constraints where collecting many full solutions is expensive. That part of the framing is straightforward and points to a usable workflow if the pieces fit together. The main weakness is the handling of unseen parameters and boundary conditions. Standard operator inference learns reduced operators from snapshots of one fixed system. Extending it to a family of instances without explicit parameter embedding in the operator or training across multiple cases usually leads to poor extrapolation. The abstract gives no equations, no description of how parameters enter the inferred operators, and no error metrics on held-out configurations, so the claim that it works accurately on diverse unseen cases stays unverified. If the full paper includes concrete experiments with quantitative validation on new parameters, that would close the gap. Otherwise the central promise depends on an assumption that needs direct testing. This is aimed at researchers in scientific machine learning who are testing LLM hybrids for simulation tasks. A reader already working on reduced-order modeling or data-driven PDE methods could extract the pipeline idea and try adapting it. The work has enough of a concrete proposal and timely combination to go to peer review rather than a desk reject, though any referee would likely ask for clearer parametric mechanics and stronger held-out accuracy numbers.

Referee Report

2 major / 1 minor

Summary. The paper proposes OpInf-LLM, a framework that integrates operator inference (OpInf) with large language models (LLMs) to solve parametric partial differential equations (PDEs). It claims to leverage small amounts of solution data for accurate predictions across diverse PDE instances, including unseen parameters and boundary conditions, while using LLMs for natural language task specification, physics-based feature parameterization, and achieving high execution success rates with low computational cost.

Significance. If the central claims hold with rigorous validation, the work could meaningfully advance hybrid LLM-reduced-order modeling approaches for PDEs by addressing the accuracy-success trade-off in prior LLM-based solvers, enabling more reliable generalization in heterogeneous settings and opening avenues for natural-language-driven scientific computing pipelines.

major comments (2)

[Abstract / Method] The abstract and method overview provide no equations, error metrics, or explicit description of how standard OpInf (typically for fixed instances) is extended to parametric families; without details on parameter embedding in the inferred operators or multi-instance training (as required to support extrapolation), the claim of accurate prediction for unseen parameters rests on an unverified assumption and cannot be assessed for soundness.
[Results / Experiments] No quantitative results, tables, or baseline comparisons are referenced in the abstract to support the stated accuracy and high success rate; the manuscript must include specific norms (e.g., relative L2 errors on held-out parameter values) and ablation studies to substantiate the generalization performance.

minor comments (1)

[Abstract] The abstract is overly high-level and omits any mention of concrete PDE examples, dataset sizes, or implementation details, which hinders immediate evaluation of the contribution.

Simulated Author's Rebuttal

2 responses · 0 unresolved

We thank the referee for the constructive comments. We address each major point below and will revise the manuscript to improve clarity and presentation of results.

read point-by-point responses

Referee: [Abstract / Method] The abstract and method overview provide no equations, error metrics, or explicit description of how standard OpInf (typically for fixed instances) is extended to parametric families; without details on parameter embedding in the inferred operators or multi-instance training (as required to support extrapolation), the claim of accurate prediction for unseen parameters rests on an unverified assumption and cannot be assessed for soundness.

Authors: We agree that the abstract and high-level method overview lack explicit equations and details on the parametric extension. The full method section describes the extension of standard OpInf via multi-instance training on solution data from multiple parameter values, with parameters embedded as additional features in the inferred reduced operators to enable extrapolation. We will revise the abstract and method overview to include the key equations for the parametric operator inference step and a concise description of the multi-instance training procedure. Error metrics will also be added to the abstract. revision: yes
Referee: [Results / Experiments] No quantitative results, tables, or baseline comparisons are referenced in the abstract to support the stated accuracy and high success rate; the manuscript must include specific norms (e.g., relative L2 errors on held-out parameter values) and ablation studies to substantiate the generalization performance.

Authors: The results section contains tables reporting relative L2 errors on held-out parameter values, baseline comparisons, and ablation studies demonstrating generalization. We will update the abstract to explicitly reference these quantitative norms, success rates, and key findings from the tables and ablations so that the claims are supported at the abstract level as well. revision: yes

Circularity Check

0 steps flagged

No significant circularity; claims rest on empirical generalization of OpInf to parametric cases

full rationale

The abstract and described framework present OpInf-LLM as combining operator inference on small solution snapshots with LLM-driven feature parameterization to predict solutions for unseen parameters. No equations, fitted parameters, or self-citations are shown that reduce the 'prediction' of unseen instances to a definitional equivalence or tautological fit of the training data. The central accuracy claim for diverse/unseen PDE instances is framed as an empirical outcome of the unified pipeline rather than a self-referential reduction. This is the normal non-circular case for a methods paper whose load-bearing step is the (unverified here) extrapolation property of the combined technique.

Axiom & Free-Parameter Ledger

0 free parameters · 1 axioms · 0 invented entities

The central claim rests on the domain assumption that operator inference from limited data yields generalizable reduced models for heterogeneous PDEs when paired with LLM reasoning.

axioms (1)

domain assumption Operator inference from small solution datasets produces accurate predictions for unseen parameters and boundary conditions
This is the load-bearing premise that enables the claimed generalization without large data or heavy computation.

pith-pipeline@v0.9.0 · 5483 in / 1171 out tokens · 46129 ms · 2026-05-16T08:13:51.646849+00:00 · methodology

discussion (0)

Lean theorems connected to this paper

Citations machine-checked in the Pith Canon. Every link opens the source theorem in the public Lean library.

IndisputableMonolith/Cost/FunctionalEquation.lean washburn_uniqueness_aczel unclear

?

unclear
Relation between the paper passage and the cited Recognition theorem.

OpInf learns a ROM approximating the PDE dynamics within a finite r-dimensional subspace... da/dt = A(ξ)a + H(ξ)(a⊗a) + B(ξ)u + c(ξ)
IndisputableMonolith/Foundation/AlphaCoordinateFixation.lean alpha_pin_under_high_calibration unclear

?

unclear
Relation between the paper passage and the cited Recognition theorem.

reduced dynamics operators for any unseen ξ can be obtained via polynomial regression among the existing operators

What do these tags mean?

matches: The paper's claim is directly supported by a theorem in the formal canon.
supports: The theorem supports part of the paper's argument, but the paper may add assumptions or extra steps.
extends: The paper goes beyond the formal theorem; the theorem is a base layer rather than the whole result.
uses: The paper appears to rely on the theorem as machinery.
contradicts: The paper's claim conflicts with a theorem or certificate in the canon.
unclear: Pith found a possible connection, but the passage is too broad, indirect, or ambiguous to say the theorem truly supports the claim.

Reference graph

Works this paper leans on

33 extracted references · 33 canonical work pages

[1]

Computes the fixed initial condition for the given spatial grid

work page
[2]

Solves the heat equation forward in time while enforcing the time-varying boundary conditions

work page
[3]

Returns the solution of shape [batch_size, T+1, N] where N=1023 (interior spatial points) In particular, your code should be tailored to the case where $\\nu={opinf_heat_nu}$, i.e., optimizing it particularly for this use case. **Important implementation notes **: - Use **1023 interior spatial points ** (not including boundaries at x=0 and x=1) - The doma...

work page
[4]

Computes the initial condition from $w_1(0)$ and $w_2(0)$

work page
[5]

Evaluates the spatial source profile $s(x)$ on the grid

work page
[6]

Solves the Burgers equation forward in time with boundary conditions and source term

work page
[7]

type": 60,

Returns the solution of shape [batch_size, T+1, N] where N is the number of spatial grid points In particular, your code should be tailored to the case where $\\nu={opinf_burgers_nu}$, i.e., optimizing it particularly for this use case. **Important implementation notes **: - Spatial discretization: 1001 points uniformly spaced in [0,1] (including boundari...

work page 2025
[8]

‘analyze_parameter_range(nu_train, nu_query)‘: Check if \nu={query_nu} is interpolation or extrapolation {step_2}

work page
[9]

‘validate_operators(operators, equation_type)‘: Check physical constraints **Instructions**:

work page
[10]

First, call analyze_parameter_range({nu_train}, {query_nu}) to understand the problem {instruction_2}

work page
[11]

{ equation_type}

Finally, call validate_operators with the returned operators and equation_type="{ equation_type}" Please solve this step-by-step using the tools. if method == "regression": step_2 = f"2. ‘simple_linear_regress(nu_query)‘: Get regressed operators (just pass nu_query={query_nu})" instruction_2 = f"2. Then, call simple_linear_regress({query_nu}) to get the o...

work page
[12]

A": [matrix_at_nu1, matrix_at_nu2, ...], 19

-> Dict[str, Any]: 12""" 13Interpolate OpInf operators to a new parameter value. 14 15Args: 16nu_train: Training parameter values (e.g., [0.1, 0.5, 2.0]) 17operators_train: Dict of operator matrices at each nu_train 18Format: {"A": [matrix_at_nu1, matrix_at_nu2, ...], 19"B": [...], "C": [...]} 20nu_query: Target parameter value 21method: Interpolation met...

work page
[13]

"" 74Linear regression of operators vs normalized nu. 75Fits y = a *z + b per entry, where z = (nu - mean) / std. 76

-> Dict[str, Any]: 73""" 74Linear regression of operators vs normalized nu. 75Fits y = a *z + b per entry, where z = (nu - mean) / std. 76""" 77nu_array = np.array(nu_train, dtype=float) 78nu_mean = float(nu_array.mean()) 79nu_std = float(nu_array.std()) if float(nu_array.std()) > 1e-12 else 1.0 80z = (nu_array - nu_mean) / nu_std 81z_q = (float(nu_query)...

work page
[14]

""Batch linear regression for multiple nu values

-> Dict[str, Any]: 117"""Batch linear regression for multiple nu values.""" 118outputs = {} 119for nu_query in nu_queries: 120outputs[str(nu_query)] = linear_regress_operators(nu_train, operators_train, nu_query) 121return { 122"nu_queries": nu_queries, 123"method": "regression", 124"predictions": outputs, 125"success": True, 126} 127 128 129def analyze_p...

work page
[15]

below" 161elif nu_query > nu_max: 162extrapolation_distance = abs(nu_query - nu_max) 163extrapolation_direction =

-> Dict[str, Any]: 133""" 134Analyze whether query is interpolation or extrapolation. 135 136Args: 137nu_train: Training parameter values 138nu_query: Query parameter value 139 140Returns: 141Analysis of parameter range 142""" 143nu_min = min(nu_train) 144nu_max = max(nu_train) 145 146is_interpolation = nu_min <= nu_query <= nu_max 147 148# Calculate rela...

work page
[16]

"" 196validations = {} 197 198for op_name, op_data in operators.items(): 199op_array = np.array(op_data[

-> Dict[str, Any]: 186""" 187Validate physical constraints on operators. 188 189Args: 190operators: Interpolated operators with ’values’ field 191equation_type: Type of equation (heat, burgers, etc.) 192 193Returns: 194Validation results 195""" 196validations = {} 197 198for op_name, op_data in operators.items(): 199op_array = np.array(op_data["values"]) ...

work page
[17]

Load model from: {model_path}

work page
[19]

Compute operators for the query parameter using method={method}

work page
[20]

nu", "A",

Integrate the ROM and save output to: {output_path} USE_JSON={str(use_json)} {coeff_block} 27 OpInf-LLM: Parametric PDE Solving with LLMs via Operator Inference MODEL STRUCTURE (IMPORTANT): - pickle with keys: per_nu_models (list of dicts), phi, x_grid or x_fine, t_eval - Each per_nu_models item has keys: "nu", "A", "B", "C" and for Burgers also "H" - The...

work page
[21]

Load model, extract nu_train and operator arrays per entry

work page
[22]

For each operator tensor: flat = arr.reshape(-1); stack across nu; interp/regress each entry; reshape to op_shapes

work page
[23]

Ensure U_ref is (n_inputs x time)

Load Y_ref/U_ref; if Y_ref.shape[0] != phi.shape[0] or Y_ref.shape[0] == len(t_eval), transpose. Ensure U_ref is (n_inputs x time)

work page
[24]

Return only the complete Python code (no explanations)

Integrate ROM; save output. Return only the complete Python code (no explanations). """ Cavity: Generate Python code to:

work page
[25]

Load cavity model from: {model_path}

work page
[26]

Load case data from: {data_path}

work page
[27]

Compute operators for the query Re using method={method}

work page
[28]

Re", "H",

Integrate ROM with RK4 and save output to: {output_path} MODEL STRUCTURE (IMPORTANT): - pickle with keys: per_Re_models (list of dicts), phi, x, y, t_eval - Each per_Re_models item has keys: "Re", "H", "A", "B", "C" - There is NO nested "operators" key. - Operator shapes (must match exactly): {op_shapes} - phi shape: {phi_shape} (state x r) CASE DATA (.np...

work page
[29]

Load model, extract Re_train and operator arrays per entry

work page
[30]

For each operator tensor: flat = arr.reshape(-1); stack across Re; interp/regress each entry; reshape to op_shapes

work page
[31]

Load Y_omega/Y_psi; build Y_fom; project with phi to get a0 (r x 1)

work page
[32]

Integrate a(t) with RK4 in r-dim; then Y_rom = phi @ a_traj

work page
[33]

Split Y_rom into omega/psi using n = Y_omega.shape[0]

work page
[34]

temperature moving through a metal rod in a cooling line

Save outputs. Return only the complete Python code (no explanations). """ C. Additional Results C.1. Ablation on Natural Language Parsing Diversity In this section, we conduct ablation experiments to demonstrate that the LLM is a critical component for robustly interpreting diverse and unstructured natural language descriptions of PDE problems, compared t...

work page 2024

[1] [1]

Computes the fixed initial condition for the given spatial grid

work page

[2] [2]

Solves the heat equation forward in time while enforcing the time-varying boundary conditions

work page

[3] [3]

Returns the solution of shape [batch_size, T+1, N] where N=1023 (interior spatial points) In particular, your code should be tailored to the case where $\\nu={opinf_heat_nu}$, i.e., optimizing it particularly for this use case. **Important implementation notes **: - Use **1023 interior spatial points ** (not including boundaries at x=0 and x=1) - The doma...

work page

[4] [4]

Computes the initial condition from $w_1(0)$ and $w_2(0)$

work page

[5] [5]

Evaluates the spatial source profile $s(x)$ on the grid

work page

[6] [6]

Solves the Burgers equation forward in time with boundary conditions and source term

work page

[7] [7]

type": 60,

Returns the solution of shape [batch_size, T+1, N] where N is the number of spatial grid points In particular, your code should be tailored to the case where $\\nu={opinf_burgers_nu}$, i.e., optimizing it particularly for this use case. **Important implementation notes **: - Spatial discretization: 1001 points uniformly spaced in [0,1] (including boundari...

work page 2025

[8] [8]

‘analyze_parameter_range(nu_train, nu_query)‘: Check if \nu={query_nu} is interpolation or extrapolation {step_2}

work page

[9] [9]

‘validate_operators(operators, equation_type)‘: Check physical constraints **Instructions**:

work page

[10] [10]

First, call analyze_parameter_range({nu_train}, {query_nu}) to understand the problem {instruction_2}

work page

[11] [11]

{ equation_type}

Finally, call validate_operators with the returned operators and equation_type="{ equation_type}" Please solve this step-by-step using the tools. if method == "regression": step_2 = f"2. ‘simple_linear_regress(nu_query)‘: Get regressed operators (just pass nu_query={query_nu})" instruction_2 = f"2. Then, call simple_linear_regress({query_nu}) to get the o...

work page

[12] [12]

A": [matrix_at_nu1, matrix_at_nu2, ...], 19

-> Dict[str, Any]: 12""" 13Interpolate OpInf operators to a new parameter value. 14 15Args: 16nu_train: Training parameter values (e.g., [0.1, 0.5, 2.0]) 17operators_train: Dict of operator matrices at each nu_train 18Format: {"A": [matrix_at_nu1, matrix_at_nu2, ...], 19"B": [...], "C": [...]} 20nu_query: Target parameter value 21method: Interpolation met...

work page

[13] [13]

"" 74Linear regression of operators vs normalized nu. 75Fits y = a *z + b per entry, where z = (nu - mean) / std. 76

-> Dict[str, Any]: 73""" 74Linear regression of operators vs normalized nu. 75Fits y = a *z + b per entry, where z = (nu - mean) / std. 76""" 77nu_array = np.array(nu_train, dtype=float) 78nu_mean = float(nu_array.mean()) 79nu_std = float(nu_array.std()) if float(nu_array.std()) > 1e-12 else 1.0 80z = (nu_array - nu_mean) / nu_std 81z_q = (float(nu_query)...

work page

[14] [14]

""Batch linear regression for multiple nu values

-> Dict[str, Any]: 117"""Batch linear regression for multiple nu values.""" 118outputs = {} 119for nu_query in nu_queries: 120outputs[str(nu_query)] = linear_regress_operators(nu_train, operators_train, nu_query) 121return { 122"nu_queries": nu_queries, 123"method": "regression", 124"predictions": outputs, 125"success": True, 126} 127 128 129def analyze_p...

work page

[15] [15]

below" 161elif nu_query > nu_max: 162extrapolation_distance = abs(nu_query - nu_max) 163extrapolation_direction =

-> Dict[str, Any]: 133""" 134Analyze whether query is interpolation or extrapolation. 135 136Args: 137nu_train: Training parameter values 138nu_query: Query parameter value 139 140Returns: 141Analysis of parameter range 142""" 143nu_min = min(nu_train) 144nu_max = max(nu_train) 145 146is_interpolation = nu_min <= nu_query <= nu_max 147 148# Calculate rela...

work page

[16] [16]

"" 196validations = {} 197 198for op_name, op_data in operators.items(): 199op_array = np.array(op_data[

-> Dict[str, Any]: 186""" 187Validate physical constraints on operators. 188 189Args: 190operators: Interpolated operators with ’values’ field 191equation_type: Type of equation (heat, burgers, etc.) 192 193Returns: 194Validation results 195""" 196validations = {} 197 198for op_name, op_data in operators.items(): 199op_array = np.array(op_data["values"]) ...

work page

[17] [17]

Load model from: {model_path}

work page

[18] [19]

Compute operators for the query parameter using method={method}

work page

[19] [20]

nu", "A",

Integrate the ROM and save output to: {output_path} USE_JSON={str(use_json)} {coeff_block} 27 OpInf-LLM: Parametric PDE Solving with LLMs via Operator Inference MODEL STRUCTURE (IMPORTANT): - pickle with keys: per_nu_models (list of dicts), phi, x_grid or x_fine, t_eval - Each per_nu_models item has keys: "nu", "A", "B", "C" and for Burgers also "H" - The...

work page

[20] [21]

Load model, extract nu_train and operator arrays per entry

work page

[21] [22]

For each operator tensor: flat = arr.reshape(-1); stack across nu; interp/regress each entry; reshape to op_shapes

work page

[22] [23]

Ensure U_ref is (n_inputs x time)

Load Y_ref/U_ref; if Y_ref.shape[0] != phi.shape[0] or Y_ref.shape[0] == len(t_eval), transpose. Ensure U_ref is (n_inputs x time)

work page

[23] [24]

Return only the complete Python code (no explanations)

Integrate ROM; save output. Return only the complete Python code (no explanations). """ Cavity: Generate Python code to:

work page

[24] [25]

Load cavity model from: {model_path}

work page

[25] [26]

Load case data from: {data_path}

work page

[26] [27]

Compute operators for the query Re using method={method}

work page

[27] [28]

Re", "H",

Integrate ROM with RK4 and save output to: {output_path} MODEL STRUCTURE (IMPORTANT): - pickle with keys: per_Re_models (list of dicts), phi, x, y, t_eval - Each per_Re_models item has keys: "Re", "H", "A", "B", "C" - There is NO nested "operators" key. - Operator shapes (must match exactly): {op_shapes} - phi shape: {phi_shape} (state x r) CASE DATA (.np...

work page

[28] [29]

Load model, extract Re_train and operator arrays per entry

work page

[29] [30]

For each operator tensor: flat = arr.reshape(-1); stack across Re; interp/regress each entry; reshape to op_shapes

work page

[30] [31]

Load Y_omega/Y_psi; build Y_fom; project with phi to get a0 (r x 1)

work page

[31] [32]

Integrate a(t) with RK4 in r-dim; then Y_rom = phi @ a_traj

work page

[32] [33]

Split Y_rom into omega/psi using n = Y_omega.shape[0]

work page

[33] [34]

temperature moving through a metal rod in a cooling line

Save outputs. Return only the complete Python code (no explanations). """ C. Additional Results C.1. Ablation on Natural Language Parsing Diversity In this section, we conduct ablation experiments to demonstrate that the LLM is a critical component for robustly interpreting diverse and unstructured natural language descriptions of PDE problems, compared t...

work page 2024