Skip to main content
Glama

Harmonic Response Submit

harmonic_response_submit
Destructive

Submit a harmonic forced-response simulation of a cantilever beam to compute its first resonance frequency, static compliance, and damping quality factor via Elmer StressSolve, returning a job ID for asynchronous polling.

Instructions

Harmonic forced response (FRF) via Elmer StressSolve Harmonic Analysis (SIMULATION_NEXT Tier B2), asynchronous — a plane-stress cantilever driven by a harmonic tip traction, swept one quasi-static point + n_sweep points across ±span_pct% of its first resonance, with Rayleigh β tuned to damping_ratio at f₁. Requires ElmerSolver; when absent this returns {ok:false, reason, install} rather than raising.

Three gates from the in-phase (real) response: f1_ratio — Re(H) = 0 exactly AT resonance, so the swept tip response's sign-flip locates f₁ vs the Euler-Bernoulli beam_modal closed form (within ~2%, plane-stress vs beam theory); static_ratio — the quasi-static point vs the exact tip compliance F·L³/(3EI) (within ~5%); q_ratio — max|Re|/static vs Q/2 = 1/(4ζ), the exact SDOF light-damping identity (within ~15%, sweep-sampled). Cross-links harmonic_response (the SDOF oracle) and random_vibration (same Q). Also accepts a prepared case_dir.

Returns the degradation dict or {job_id, status, cache_hit}; poll job_result for {ok, f1_solved_hz, f1_eb_hz, f1_ratio, static_solved_m, static_exact_m, static_ratio, peak_over_static, q_factor, q_ratio, frf:[[f_hz, tip_re_m]], case_dir}.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
nxNo
nyNo
sifNocase.sif
n_sweepNo
poissonNo
case_dirNo
height_mNo
length_mNo
span_pctNo
youngs_paNo
traction_paNo
damping_ratioNo
density_kg_m3No

Schema Changelog

Changes observed during successful MCP inspections.

  1. First observed

TDQS

A4.4/5.0
Behavior5/5

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

Beyond the annotations, the description discloses asynchronous submission, dependency failure behavior, three validation gates with expected tolerances, and the exact return/polling structure. It adds substantial behavioral context and does not contradict the annotations.

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 dense and information-rich, with the main purpose front-loaded and every sentence adding either behavioral, validation, or return-value detail. It is long, but not wasteful; no filler is present.

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 the tool's complexity and lack of an output schema, the description is notably complete: it explains what simulation is run, what external resources are required, which validation metrics are produced, how to poll results, and the exact keys returned in the final job result.

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

Parameters3/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 compensate. It explains n_sweep, span_pct, damping_ratio, and case_dir meaningfully, but leaves the remaining nine parameters to be inferred from names/defaults. This is partial compensation rather than complete coverage.

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 first sentence clearly identifies the tool as a harmonic forced response (FRF) analysis via Elmer StressSolve Harmonic Analysis, with a specific plane-stress cantilever setup and swept-frequency approach. It also distinguishes itself from related siblings by cross-linking harmonic_response (the SDOF oracle) and random_vibration (same Q).

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?

The description states the external requirement (ElmerSolver), the fallback behavior when it is absent, the asynchronous polling path via job_result, and the optional case_dir input. It does not give an explicit 'use this instead of X' rule, but the context makes the intended usage clear enough.

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