Skip to main content
Glama

CFD Mesh Independence Submit

cfd_mesh_independence_submit

Run a CFD case across multiple mesh refinements and compute the Grid Convergence Index to quantify discretization error, revealing whether results reflect the flow physics or depend on the mesh.

Instructions

Solve the same CFD case at 2-3 refined meshes and report the Grid Convergence Index — asynchronous, one job for the whole ladder. Requires OpenFOAM; degrades to {ok:false, reason, install} when it does not resolve.

Answers the question no single solve can: is this number a property of the flow, or of the mesh? On geometry with no analytic twin that band is the only error bar available, and it is what turns "a solver produced 0.31" into "0.31 ± 2 %".

Two families, dispatched like their single-solve twins:

  • the wind tunnel — pass model (or body) + velocity_m_s, plus any cfd_external_flow_submit knob. The ladder varies the background cell; the body is tessellated ONCE and shared, so the study isolates mesh error instead of mixing in a changing STL. Default metric 'cd'.

  • the straight pipe — pass diameter_mm, length_mm, velocity_m_s (or flow_rate_lpm). The ladder scales n_axial/n_radial. Default metric 'pressure_drop_pa'.

The COARSEST level is the mesh a plain submit would have built and the study refines from there (the tunnel's default cell is already the coarsest that resolves the body at all). Cost therefore grows as the cube of refinement_ratio: 3 levels at 1.5 puts roughly 11x the cells in the finest mesh, so budget accordingly. end_time is the cap for the COARSEST level and is scaled up for the finer ones — a fine mesh needs proportionally more sweeps, and a study whose finest level quietly stopped at its cap is worthless.

Returns the degradation dict, or {job_id, status, cache_hit}; poll job_result for {ok, family, metric, levels: [{label, value, cell_size_m, n_cells, converged, returncode, case_dir}], grid_convergence: {observed_order, extrapolated_value, gci_pct, monotonic, asymptotic_ratio, order_clamped, warnings, ...}, band_pct, extrapolated_value, hagen_poiseuille_pa (pipe family), warnings}.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
bodyNo
fluidNoair-20c
modelNo
levelsNo
metricNo
mu_pa_sNo
n_axialNo
end_timeNo
n_radialNo
length_mmNo
rho_kg_m3No
turbulenceNolaminar
diameter_mmNo
base_cell_mmNo
velocity_m_sNo
flow_rate_lpmNo
flow_directionNo
surface_refineNo
refinement_ratioNo

Schema Changelog

Changes observed during successful MCP inspections.

  1. First observed

TDQS

A4.6/5.0
Behavior5/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

Beyond the sparse annotations, the description discloses that execution is asynchronous, one job covers the whole refinement ladder, OpenFOAM is required, and failure degrades to a specific {ok:false, reason, install} dict. It also reveals cost growth with refinement_ratio and the end_time scaling behavior for finer levels, giving agents important expectations about job behavior and results.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness4/5

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is long but well-structured with bolded family sections, clear default values, and a detailed return-value spec. Each section adds operational value rather than padding; it is not minimal, but the length is justified by the complexity and the absence of schema-level parameter documentation.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness5/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Given a 19-parameter, 0%-schema-covered tool with no output schema, the description is exceptionally complete. It covers failure modes, parameter selection, default metrics, cost scaling, end_time behavior, and the full shape of the returned result, including the per-level fields and grid_convergence sub-dict.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters4/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

With 0% schema description coverage, the description compensates by explaining the key parameter families: model/body + velocity_m_s for external flow, diameter_mm/length_mm/velocity_m_s/flow_rate_lpm for pipe flow, default metric values, levels, refinement_ratio, and end_time semantics. It does not individually document all 19 parameters, but it covers the principal decision-driving ones and points to inherited 'knobs' for the rest.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose5/5

Does the description clearly state what the tool does and how it differs from similar tools?

The description states a specific verb and resource: 'Solve the same CFD case at 2-3 refined meshes and report the Grid Convergence Index'. It also clearly differentiates from the single-solve CFD siblings by framing this tool as answering 'the question no single solve can', establishing its distinct role in the mesh-independence workflow.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines4/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

The description gives clear selection guidance between the two supported families, the wind tunnel and the straight pipe, with explicit parameter sets for each and default metrics. It references 'single-solve twins' and cfd_external_flow_submit knobs, which implies when to use this vs single-solve tools, though it does not formally name or exclude the alternative tools.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

Deploy Server

Other Tools