Skip to main content
Glama

grid_convergence

Estimate mesh discretization error: give the same solved quantity on 2–3 refined meshes to fit the observed order of convergence and return the Richardson-extrapolated GCI confidence band.

Instructions

Grid Convergence Index — how much of a solved number is the MESH (no solver, milliseconds). Give it the same quantity solved on 2-3 systematically refined meshes, FINEST FIRST, and it fits the observed order of convergence, Richardson-extrapolates to zero cell size, and returns the percentage band inside which the mesh-independent answer lies. Roache's GCI as codified in ASME V&V 20.

This is the honest band_pct for a result with no analytic oracle — the verification counterpart to every validation ratio in the solver families — and it is deliberately family-agnostic: three CFD drag coefficients, three FEM peak stresses and three modal frequencies are all valid input; only you know what the mesh size means. cfd_mesh_independence_submit is the driver that produces the three CFD values for you.

Describe the meshes with either cell_sizes (representative cell length, same order as values) or cell_counts (total cells; h = N^(-1/dimensions)). With THREE values the order is measured and the safety factor is 1.25; with TWO it must be assumed (assumed_order, default 2.0) and the factor triples to 3.0 — a much wider band, which is the honest price of the missing mesh.

Watch three fields before quoting the band: monotonic False means the solutions oscillate and the extrapolation is not meaningful (usually an unconverged level, not a mesh effect); asymptotic_ratio far from 1 means the meshes have not reached the range where the theory holds, so gci_pct is a LOWER bound; order_clamped True means the fitted order was unphysical and a clamped one was used.

Returns {n_levels, values, cell_sizes, refinement_ratios, observed_order, order_used, order_clamped, extrapolated_value, gci_pct, gci_coarse_pct, band_pct, relative_error_pct, monotonic, asymptotic_ratio, safety_factor, converged_fit, fidelity, warnings}.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
valuesYes
cell_sizesNo
dimensionsNo
cell_countsNo
assumed_orderNo

Schema Changelog

Changes observed during successful MCP inspections.

  1. First observed

TDQS

A4.8/5.0
Behavior5/5

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

With no annotations, the description carries the full burden and does: no solver / milliseconds, the safety-factor difference (1.25 with three values, 3.0 with two), and three caveat fields (`monotonic`, `asymptotic_ratio` as a lower bound, `order_clamped`) with their failure interpretations. This is unusually rich behavioral disclosure.

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?

Front-loaded with the purpose and the practical rule (finest first, 2-3 levels) before the caveats, and every paragraph is doing work. It is dense and on the long side, but the length tracks the genuine complexity of the computation rather than padding.

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?

No output schema exists, yet the description enumerates the returned fields and explains the ones that matter for interpretation (`gci_pct`, `band_pct`, `order_clamped`, `monotonic`, `asymptotic_ratio`). Combined with the input guidance, an agent has everything needed to call and interpret it.

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?

Schema description coverage is 0%, so the description must compensate and largely does: `cell_sizes` (representative cell length, same order as `values`), `cell_counts` (total cells, h = N^(-1/`dimensions`)), and `assumed_order` (default 2.0, only with two values) are all explained. `dimensions` is only covered implicitly through the h formula, which is the one small gap.

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?

States a specific verb (fits order, Richardson-extrapolates, returns a band) on a specific resource (mesh convergence / GCI of a solved quantity), and explicitly differentiates from the sibling it could be confused with (`cfd_mesh_independence_submit` is the driver that produces the CFD values). An agent knows exactly what this computes without opening the schema.

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

Usage Guidelines5/5

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

Explicitly says when to use it (a result with no analytic oracle, the verification counterpart to validation ratios) and names the alternative workflow (cfd_mesh_independence_submit feeding the three CFD values). Also gives the 2-vs-3-level tradeoff that determines whether you should call it at all with sparse data.

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