AnkusDrive

Overview Schema Source Related Servers Discussions Admin

CFD Internal Flow Submit

cfd_internal_flow_submit

Destructive

Submit internal-flow CFD cases to compute pressure drop in pipes, channels, or CAD solids via OpenFOAM or SU2. Returns pressure drop, validation ratios, and job status for async polling.

Instructions

Internal-flow CFD (pressure drop) 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 pipe and geometry-bridge modes need OpenFOAM specifically — they emit OpenFOAM dictionaries — but channel_height_mm builds a NATIVE SU2 case, which is why solve_capabilities counts SU2 toward the cfd family (issue #237). On Apple Silicon that is the difference between needing a Multipass VM and not. turbulence='kOmegaSST' upgrades the pipe validation case to RANS (SIMULATION_NEXT B3): wall-function k/ω/ν_t with first-cell y+ targeted at ~30–100, developed dp/dx fitted over the second half of a ≥40·D pipe, gated BANDED against Colebrook (colebrook_ratio ≈ 1 ± 10 % — the Moody correlation is itself a band, never an exact gate). Four modes:

Build the native SU2 plane-channel case (no OpenFOAM, no VM): pass channel_height_mm, optionally channel_length_mm (default 10× the height), velocity_m_s (default Re 50), a fluid or mu_pa_s+rho_kg_m3 (default a light oil — holding Re low with water means millimetres per second, where SU2's incompressible pseudo-time is badly scaled), nx/ny, max_iterations. Gated against the EXACT plane-Poiseuille closed form Δp = 12·μ·U·L/h², returning poiseuille_ratio ≈ 1. The inlet is the fully developed parabolic profile, so there is no entrance-length error to drown out with a long domain.
Build the straight-pipe validation case (no case prep): pass diameter_mm, length_mm, and velocity_m_s (or flow_rate_lpm), with a fluid name or explicit mu_pa_s+rho_kg_m3 (mesh density via n_axial/n_radial, iterations via end_time). The handler builds the axisymmetric laminar pipe, runs blockMesh+simpleFoam, and returns the solved Δp next to the Hagen–Poiseuille analytic reference (cfd_pipe_flow) — the kickoff's exact CFD gate, hp_ratio≈1.
Solve a real FreeCAD solid — the geometry bridge: pass a body handle plus inlet_face/outlet_face (1-based indices into the solid's faces; every other face becomes a no-slip wall) and velocity_m_s (applied along the inlet face's inward normal). The solid tessellates into a multi-region STL and meshes with blockMesh + snappyHexMesh; base_cell_mm sets the background cell size, location_in_mesh_mm the kept-region seed point (default: bbox centre — set it for non-convex solids), stl_tolerance_mm the tessellation sag. Use the developed-profile pressure_drop_pa; also pass diameter_mm+length_mm to get an hp_ratio reference for pipe-like bodies.
Run a prepared case_dir (optionally an application, e.g. 'simpleFoam'/'foamRun'); for OpenFOAM its environment is sourced before the run, while 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. Pipe/body cases: {ok, returncode, pressure_drop_pa (developed), pressure_drop_inlet_pa, hagen_poiseuille_pa?, hp_ratio?, n_cells, case_dir}; RANS pipe adds {dpdx_pa_m, dpdx_colebrook_pa_m, colebrook_ratio, y_plus_estimate, band_pct}. Prepared case: {ok, returncode, solver, application, case_dir, kind, stdout_tail}.

Input Schema

TableJSON Schema

Name	Required	Default
`body`	No
`fluid`	No	water-20c
`mu_pa_s`	No
`n_axial`	No
`case_dir`	No
`end_time`	No
`n_radial`	No
`length_mm`	No
`rho_kg_m3`	No
`inlet_face`	No
`turbulence`	No	laminar
`application`	No
`diameter_mm`	No
`outlet_face`	No
`base_cell_mm`	No
`velocity_m_s`	No
`flow_rate_lpm`	No
`max_iterations`	No
`stl_tolerance_mm`	No
`channel_height_mm`	No
`channel_length_mm`	No
`location_in_mesh_mm`	No

Schema Changelog

Changes observed during successful MCP inspections.

First observedSep 13, 2026

TDQS

A4.7/5.0

Behavior5/5

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

Beyond the annotations, it discloses the non-raising failure contract ({ok:false, reason, install}), async job semantics, solver-specific environment sourcing, RANS wall-function targeting with y+ and banded Colebrook gating, and the per-mode return payloads. Nothing in the description contradicts readOnlyHint=false, openWorldHint=false, or destructiveHint=true.

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 highly structured: a summary sentence, solver prerequisites, four bullet modes, then per-mode return shapes, with important constraints front-loaded. It is not truly concise—issue references, B3 labels, and some Apple Silicon digressions could be trimmed—but every paragraph earns its place in a dense, complex tool.

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

Completeness4/5

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

For a 22-parameter async tool with no output schema, it is nearly complete: prerequisites, mode selection, units, failure behavior, polling, and exact result shapes are all present. It loses a point only because it never states that exactly one mode configuration is required, and the fluid-default contradiction adds ambiguity.

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 for nearly all 22 parameters, including mode selectors, physical inputs, mesh controls, iteration limits, and units/defaults. It earns less than 5 because it cites nx/ny that are absent from the schema, and its 'default a light oil' statement conflicts with the schema's fluid default of water-20c.

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 line states the exact operation—internal-flow CFD pressure drop via OpenFOAM or SU2, asynchronous—and the four bullet modes make the target resource and invocation style unmistakable. The 'internal' qualifier and the reference to the cfd family separate it from external-flow and analytic-analysis siblings.

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?

Provides explicit decision rules: channel_height_mm selects native SU2 with no OpenFOAM or VM, pipe and geometry-bridge modes require OpenFOAM specifically, and prepared case_dir runs either solver with environment handling. It also tells the agent when to add diameter_mm+length_mm for an hp_ratio reference and to poll job_result for async completion.

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

Deploy Server

CFD Internal Flow Submit

Instructions

Input Schema

Schema Changelog

TDQS

Other Tools