Skip to main content
Glama

acoustic_fem_submit

Submit acoustic FEM jobs to solve duct or cavity Helmholtz problems asynchronously, returning a job ID to poll for verified pressure or resonance results.

Instructions

Acoustic FEM via Elmer HelmholtzSolve (SIMULATION_NEXT Tier B1), asynchronous — the higher-order twin of acoustic_screen, gated against its exact closed forms. Requires ElmerSolver; when absent this returns {ok:false, reason, install} rather than raising.

kind='duct': a closed duct driven p=1 at x=0, rigid at x=L, at f = kL·c/(2πL) (keep kl off the quarter-wave resonances) — the rigid-end pressure has the exact oracle 1/cos(kL), so p_end_ratio ≈ 1 machine-tight. kind='cavity': a rigid lx_m × ly_m cavity excited by a corner Wave Flux source, swept ±span_pct% around the exact (mode_nx, mode_ny) eigenfrequency in n_steps Scanning steps; the in-phase corner-probe response flips sign through resonance, and the 1/A zero-crossing gives f_solved_hz with mode_ratio ≈ 1 (<0.1%). Also accepts a prepared case_dir.

Returns the degradation dict or {job_id, status, cache_hit}; poll job_result for duct {ok, p_end_re, p_end_exact, p_end_ratio (≈1), p_mean_ratio, frequency_hz, case_dir} | cavity {ok, f_solved_hz, f_exact_hz, mode_ratio (≈1), mode, case_dir}.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
klNo
nxNo
nyNo
sifNocase.sif
kindNoduct
lx_mNo
ly_mNo
c_m_sNo
mode_nxNo
mode_nyNo
n_stepsNo
case_dirNo
length_mNo
span_pctNo
n_elementsNo

Schema Changelog

Changes observed during successful MCP inspections.

  1. First observed

TDQS

A4/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 and does so well: asynchronous execution, the degradation dict on missing ElmerSolver, `{job_id, status, cache_hit}`, and the need to poll `job_result` for final outputs. It describes validation against exact oracles and expected ratios, which is unusually transparent for a simulation submit tool.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness3/5

Is the description appropriately sized, front-loaded, and free of redundancy?

The purpose and key behavior are front-loaded, but the description is long and dense, mixing physics explanations, oracle details, and return fields. While much of the detail is relevant for a complex simulation tool, it is not maximally concise or easy to parse at a glance.

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

Completeness3/5

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

It gives strong context on async behavior, dependency failure, return fields, and kind-specific validation, and there is no output schema to rely on. However, with 15 parameters and 0% schema description coverage, the lack of parameter explanations leaves an agent guessing about several inputs, so the overall definition is not complete enough.

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

Parameters2/5

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

Schema description coverage is 0% and there are 15 parameters, but the description only explains a subset (`kind`, `kl`, `lx_m`, `ly_m`, `span_pct`, `n_steps`, `mode_nx`, `mode_ny`, `case_dir`). Important parameters such as `sif`, `nx`, `ny`, `c_m_s`, `length_m`, and `n_elements` are not described, so the text does not come close to compensating for the schema 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?

The description names a specific verb and resource (Acoustic FEM via Elmer HelmholtzSolve), marks it asynchronous, and explicitly distinguishes it as the higher-order twin of `acoustic_screen` gated against exact closed forms. An agent can identify the tool's scope and its relationship to the sibling 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 states the dependency (`Requires ElmerSolver`), the fallback behavior when absent, and explains the two `kind` modes with their physical setups. It also names `acoustic_screen` as the related lower-order alternative, though it does not give explicit when-to-use-this-vs-that guidance beyond 'higher-order twin'.

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