AnkusDrive

Overview Schema Source Related Servers Discussions Admin

cfd_internal_flow_submit

Submit asynchronous internal-flow CFD pressure-drop jobs through OpenFOAM or SU2, covering plane-channel, pipe, RANS, and FreeCAD solid geometry cases.

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.6/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 behavioral burden. It discloses asynchronous execution, OpenFOAM/SU2 binary requirements, that a missing binary returns {ok:false, reason, install} rather than raising, environment sourcing for OpenFOAM, direct SU2 subprocess behavior on Windows, and output shapes including degradation dicts and job polling. It also describes solver-side behavior like y+ targeting and banded Colebrook gating.

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-loads the purpose and then uses four bulleted modes to organize the remaining detail. Most sentences carry useful invocation guidance, though some internal references like issue #237 and SIMULATION_NEXT B3 may not aid an agent. It is dense but not padded.

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 22-parameter asynchronous tool with no output schema and no annotations, the description covers mode selection, required and optional inputs, failure behavior, solver requirements, and return shapes for degradation, pipe/body cases, RANS cases, and prepared case runs. An agent has enough context to invoke it correctly and interpret the result.

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% with 22 parameters, so the description must compensate, and it does explain most parameters in mode-specific narratives: channel_height_mm, velocity_m_s, fluid/mu_pa_s/rho_kg_m3, body/inlet_face/outlet_face, base_cell_mm, location_in_mesh_mm, stl_tolerance_mm, turbulence, case_dir, and application. However, a few parameters such as nx/ny are only named without explanation, and the fluid default is ambiguous relative to the schema default of water-20c. Overall it adds substantial meaning beyond 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 opens with a specific verb+resource: 'Internal-flow CFD (pressure drop) via OpenFOAM or SU2, asynchronous.' It then enumerates four distinct modes, making clear this is not the same as external-flow or analytic pipe-flow siblings. An agent can distinguish it from cfd_external_flow_submit and cfd_pipe_flow 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 Guidelines4/5

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

It gives detailed conditions for each of the four modes, including which parameters trigger native SU2, pipe validation, geometry bridge, or prepared case_dir execution. It references cfd_pipe_flow as an analytic reference and solve_capabilities for solver counting, but it does not explicitly state when to avoid this tool or choose a sibling instead. The usage context is clear, though no explicit exclusions are provided.

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