Skip to main content
Glama

thermal_radiation_submit

Run asynchronous diffuse-gray radiation FEM jobs via Elmer for two-plate enclosures or prepared cases, returning job IDs and results.

Instructions

Diffuse-gray radiation FEM via Elmer, asynchronous — the radiation sibling of thermal_transient_submit. Requires ElmerSolver + the ViewFactors binary (apt elmerfem-csc / conda); when absent this returns {ok:false, reason, install} rather than raising. Two modes:

  • Build the two-plate enclosure case (no case prep): pass t1_c, t2_c (°C) and the two surface emissivities emissivity_1/emissivity_2 (default 0.8). The handler writes a 2-D pair of parallel plates radiating across an unmeshed vacuum gap, runs ViewFactors then ElmerSolver, and extracts the net radiative exchange — directly gated against the exact two infinite parallel plates oracle q = σ(T₁⁴−T₂⁴)/(1/ε₁+1/ε₂−1) (oracle_ratio ≈ 1). Mesh/geometry knobs: width_m, gap_m, plate_thickness_m, n_x, k_plate.

  • Run a prepared case_dir containing its .sif + mesh (ViewFactors is run first when no factor file is present).

Returns the degradation dict, or {job_id, status, cache_hit}; poll job_result for {ok, returncode, solver, case_dir, stdout_tail} plus, for the plate case, {flux_w_m2, q_net_w, two_plate_flux_w_m2, oracle_ratio, t1_c, t2_c, emissivity_1, emissivity_2} (or {scalars_final} for a prepared case).

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
n_xNo
sifNocase.sif
t1_cNo
t2_cNo
gap_mNo
k_plateNo
width_mNo
case_dirNo
emissivity_1No
emissivity_2No
plate_thickness_mNo

Schema Changelog

Changes observed during successful MCP inspections.

  1. First observed

TDQS

A4.4/5.0
Behavior4/5

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

With no annotations, the description carries the full burden and does so well: it discloses async execution, the non-raising degradation return ({ok:false, reason, install}), the ephemeral job handle ({job_id, status, cache_hit}), and that results must be polled via job_result. It omits any timeout/rate-limit/resource-cost context, keeping it out of the top tier.

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?

Front-loaded lead sentence carries the essential domain, method, and async nature; the two modes are cleanly bulleted and the return contract is compressed into a single sentence. It is dense but every sentence contributes, with only the inline oracle formula adding slight bulk.

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?

For a complex, 11-parameter, no-annotation, no-output-schema tool, the description covers usage modes, preconditions, fallback behavior, and the full async lifecycle including downstream job_result fields (flux_w_m2, q_net_w, oracle_ratio, etc.). Nothing critical an agent needs to call and interpret it is missing.

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%, so the description must supply meaning, and it does for most inputs: physics meaning of t1_c/t2_c (temperatures in °C), emissivity_1/2 (with default 0.8), and the geometry knobs width_m/gap_m/plate_thickness_m/n_x. The `sif` parameter is only indirectly implied via the '.sif' mention and `k_plate` is oddly grouped under 'mesh/geometry knobs' (it is thermal conductivity), leaving minor gaps.

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?

Opens with a specific verb+resource+method ('Diffuse-gray radiation FEM via Elmer, asynchronous') and immediately differentiates from the sibling thermal_transient_submit by naming the relationship. An agent can identify the tool's domain and its distinction from near-neighbors 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?

Explicitly lays out two operating modes (build the two-plate enclosure case with t1_c/t2_c/emissivities, vs. run a prepared case_dir) with the parameter preconditions for each. It also states the software precondition (ElmerSolver + ViewFactors) and the fallback behavior. It stops short of naming when *not* to use this over alternatives, so it's not a full 5.

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