Skip to main content
Glama
gchen19

AnkusDrive

by gchen19
OverviewSchemaSourceRelated ServersDiscussionsAdmin
Python
Local

Grid Convergence

grid_convergence
Read-only

Estimates mesh-independent simulation results and uncertainty bands from 2-3 refined meshes using Richardson extrapolation and Roache's GCI, giving the percentage band for converged answers without an analytic oracle.

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.9/5.0
Behavior5/5

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

Annotations only state readOnlyHint/openWorldHint; the description discloses substantial behavioral nuances: no solver/milliseconds, assumed vs measured order, safety factors, clamping, lower-bound behavior, and monotonicity caveats. It also clarifies the returned band is an honest estimate without an analytical oracle.

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 front-loaded and every section earns its place: definition, inputs, caveats, and return fields. It could be slightly tightened, but for a complex numerical tool with no output schema the level of detail is justified.

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?

With no output schema and bare input schema, the description is self-sufficient: it specifies mesh order, mesh-size meanings, two/three-mesh behavior, quality flags to inspect, and the complete return field list. No critical calling context is missing.

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

Parameters5/5

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

Despite 0% schema description coverage, the description explains every parameter: values as the same quantity on 2-3 meshes, cell_sizes vs cell_counts semantics including the h=N^(-1/dimensions) relation, and assumed_order. This fully compensates for the bare schema.

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 names a specific computation (Grid Convergence Index/Richardson extrapolation) with concrete output (band_pct, gci_pct), and distinguishes it from solver families as a verification tool. The opening sentence and 'no solver' signal make its role unmistakable among hundreds of sibling tools.

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?

It explicitly says to feed 2-3 systematically refined meshes, finest first, and contrasts it with cfd_mesh_independence_submit, which produces the input CFD values. It also gives conditional guidance for two vs three meshes and when the band is untrustworthy (monotonic false, asymptotic_ratio far from 1, order_clamped true).

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