AnkusDrive

Overview Schema Source Related Servers Discussions Admin

CFD External Flow Submit

cfd_external_flow_submit

Destructive

Submit external flow CFD jobs to compute drag and lift with OpenFOAM or SU2. Handles wind-tunnel analysis of a solid model, flat-plate validation, or running an existing case directory.

Instructions

External-flow CFD (drag/lift) via OpenFOAM or SU2, asynchronous. Requires an OpenFOAM (apt/conda) or SU2 binary; when none resolves this returns {ok:false, reason, install} rather than raising. The two case-BUILDING modes below need OpenFOAM specifically — they emit OpenFOAM dictionaries; SU2 only ever runs a case_dir you prepared yourself, which is why solve_capabilities does not count it toward the cfd family's any_available (issue #237). Three modes:

Put a real solid in the virtual wind tunnel (issue #223): pass a model (or body) handle + velocity_m_s. The solid's faces tessellate into an STL, a farfield box is auto-sized around it by standard practice (5L upstream / 10L downstream / 5L lateral, overridable via upstream_factor/downstream_factor/ lateral_factor; the reported blockage_ratio warns past 5 %), snappyHexMesh carves the body out, and the forces function object integrates pressure + viscous traction over it. Cd/Cl/Cm come back on the MEASURED frontal silhouette along flow_direction (default +x; exact for a convex body — override with frontal_area_mm2 for a re-entrant one) and reference_length_mm (default: the largest bbox dimension). Mesh knobs: base_cell_mm (default L/2 — a coarser cell is REJECTED, since snappy would then mesh an empty tunnel and report ~0 drag), surface_refine [min,max] levels, wake_refine, stl_tolerance_mm, end_time. Trust: the laminar path is gated live against the sphere drag curve at Re=1 and Re=100 (within ~2 %); turbulence='kOmegaSST' runs but has no verified oracle for arbitrary bodies and comes back gated:false. Past Re≈1000 a laminar request is flagged in warnings rather than silently answered.
Build the flat-plate validation case (no model): pass velocity_m_s, with optional plate_length_mm (default 100), a fluid name ('air-20c','water-20c',…) or explicit mu_pa_s+rho_kg_m3, and mesh knobs nx_plate/n_y/end_time. THIS MODE SOLVES A FLAT PLATE, never the caller's geometry: a 2-D laminar plate with a clean leading edge (slip→plate→slip, far-field top), whose wall-shear drag is integrated from the converged U field and returned next to the Blasius reference Cf=1.328/√Re_L (blasius_ratio≈1, ~15 %). turbulence='kOmegaSST' upgrades it to RANS (default plate_length 1000 mm so Re_L > transition), gated BANDED against the mixed-transition Cf = 0.074·Re^(−1/5) − A/Re.
Run a prepared case_dir (optionally an application); OpenFOAM runs with its environment sourced, an SU2 case (*.cfg + *.su2 mesh) runs as a direct native subprocess — no bash/WSL needed, including on Windows.

Returns the degradation dict, or {job_id, status, cache_hit}; poll job_result. Body mode: {ok, returncode, cd, cl, cm, drag_force_n, drag_pressure_n, drag_viscous_n, lift_force_n, force_total_n, moment_total_nm, force_drift_pct, n_force_samples, reynolds, reference_length_m, frontal_area_m2, frontal_area_source, moment_reference_m (the bbox centre moments are taken about, not the global origin), blockage_ratio, base_cell_m, converged, gated, warnings, case_dir}. Flat plate: {ok, returncode, reynolds_l, cd, cf_solved, cf_blasius, blasius_ratio, drag_force_n, drag_momentum_n, drag_blasius_n, n_cells, case_dir}; RANS plate swaps the gate fields for {cf_solved (momentum), cf_mixed_ref, cf_mixed_ratio, cf_turbulent_ref, cf_wall_corrected, y_plus_estimate, band_pct}. Prepared case: {ok, returncode, solver, application, case_dir, kind, stdout_tail}.

Input Schema

TableJSON Schema

Name	Required	Default
`n_y`	No
`body`	No
`fluid`	No	air-20c
`model`	No
`mu_pa_s`	No
`case_dir`	No
`end_time`	No
`nx_plate`	No
`rho_kg_m3`	No
`turbulence`	No	laminar
`application`	No
`wake_refine`	No
`base_cell_mm`	No
`velocity_m_s`	No
`flow_direction`	No
`lateral_factor`	No
`surface_refine`	No
`plate_length_mm`	No
`upstream_factor`	No
`frontal_area_mm2`	No
`stl_tolerance_mm`	No
`downstream_factor`	No
`reference_length_mm`	No

Schema Changelog

Changes observed during successful MCP inspections.

First observedSep 13, 2026

TDQS

A4.9/5.0

Behavior5/5

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

Annotations only supply destructiveHint=true; the description carries the full burden and does so richly: it returns {ok:false, reason, install} rather than raising when no solver binary resolves, discloses async/poll behavior via job_result, explains gating against known curves (sphere drag within ~2%, Blasius reference, banded RANS gate), warns that laminar past Re≈1000 is flagged in `warnings`, notes `base_cell_mm` rejection to avoid empty-tunnel meshes, and details exact return payloads per mode including the `moment_reference_m` gotcha.

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 the tool is genuinely complex (three modes, 23 params, two solvers), and the bullet structure with bolded mode headers keeps it navigable. It is front-loaded with the core purpose. Minor redundancy (defaults restated in prose) and overall density justify a 4 rather than 5.

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, the description must enumerate return values itself and does so for all three modes, including degradation dict and cache_hit paths. Async workflow (poll job_result), solver environment requirements (OpenFOAM env sourced, SU2 native subprocess no bash/WSL), trust/validation caveats, and cross-references to solve_capabilities are all covered. Nothing an agent needs to invoke correctly 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?

Schema description coverage is 0%, so the description must fully compensate — and it does. All 23 parameters are explained with defaults and constraints: `base_cell_mm` (default L/2, coarser rejected), `upstream_factor`/`downstream_factor`/`lateral_factor` (5L/10L/5L defaults), `plate_length_mm` (default 100, or 1000 for RANS), `flow_direction` (default +x), `frontal_area_mm2` (override for re-entrant bodies), `reference_length_mm` (largest bbox dimension), plus mesh knobs and fluid/mu/rho options.

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 opening sentence states a specific verb and resource: 'External-flow CFD (drag/lift) via OpenFOAM or SU2, asynchronous.' This immediately distinguishes it from siblings like cfd_internal_flow_submit and cfd_pipe_flow via the 'external-flow' qualifier, and the three explicitly bulleted modes make the tool's scope unambiguous.

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?

The description gives explicit selection criteria for each of the three modes: pass a `model`/`body` + `velocity_m_s` for the solid mode, omit `model` for the flat-plate validation case, or pass `case_dir` for the prepared-case mode. It also states when NOT to expect something ('THIS MODE SOLVES A FLAT PLATE, never the caller's geometry') and solver-specific constraints (OpenFOAM needed for case building; SU2 only runs a prepared `case_dir`).

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

Deploy Server

CFD External Flow Submit

Instructions

Input Schema

Schema Changelog

TDQS

Other Tools