Skip to main content
Glama

molding_fill_submit

Run a two-phase injection-molding fill solve to check whether a geometry can mold, catching short shots and estimating fill time and peak injection pressure.

Instructions

Injection-molding FILL (+ optional PACK/COOL) solve, asynchronous — the higher- fidelity twin molding_screen escalates to. Answers can this geometry actually be molded: short-shot / fill ability (the strongest, most reliable gate), fill time, and a peak injection-pressure proxy — a real two-phase (melt + air) flow solve, not the spiral-flow correlation. Requires an OpenFOAM binary; when none resolves this returns {ok:false, reason, install} rather than raising.

Backend: when the openInjMoldSim binary resolves (GPL-3.0, a modified compressibleInterFoam on OpenFOAM-7 .org — Cross-WLF + 2-domain Tait), the worker generates and runs an OF7-org case from the params below (or runs a prepared case_dir if given) — a pressure-driven, non-isothermal plaque fill with the Cross-WLF/Tait coefficients pulled from the materials corpus for resin. Where that build is absent it falls back to a 2-D plaque-cavity interFoam VOF case on the existing OpenFOAM (.com/ESI) — same physics family, answers fill/short-shot but not packing. The GPL solver is held at the subprocess boundary (never imported).

openInjMoldSim (OF7) params: resin (corpus key, default "PS"), length_mm, wall_thickness_mm (gap), depth_mm, nx/ny, peak_pressure_mpa (gate ramp, default 2), melt_temp_c (220), mold_temp_c (60), wall_h_w_m2k (wall heat- transfer coeff; default ~adiabatic for a clean fill — raise for freeze-off), fill_end (terminate fraction, default 0.98). Pass application to force the interFoam-prepared path.

Packing/cooling (openInjMoldSim only): set stages="fill_pack" to also run the cooling continuation after fill (seal the gate, switch walls to cooling, hold). Knobs: pack_phases (default 2), cool_window_s (cooling duration; default a few× the fill time — note a 1 mm wall cools in ~seconds, so a short window gives partial cooling), eject_temp_c (for cooling-time; default 80), pack_wall_h_w_m2k (cool-side wall coeff; default 1250). The pack result adds pack:{rho_mean_final, rho_min, volumetric_shrinkage_pct, frozen_fraction, cooling_time_s, residual_pressure_pa} and pack_gate:{pass (on sink risk), score, volumetric_shrinkage_pct, expected_densification_pct (Tait-EOS), pvt_faithful, sink_risk, warnings}.

Net mold shrinkage (the cavity-sizing number; issue #116) — distinct from pack_gate's raw-PVT densification. The fill_pack result also models the packing-feed make-up (melt fed at the hold pressure until the gate freezes at the Tait no-flow transition; only the uncompensated post-gate-freeze densification is net shrinkage) and gates it against the resin's published linear band. hold_pressure_pa (effective cavity packing pressure; default = the ramp peak), room_temp_c (free-part relax temperature; default 23). Adds net_shrinkage:{net_linear_pct, net_vol_pct, raw_vol_pct, compensated_vol_pct, gate_freeze_temp_k} and shrinkage_gate:{pass (in corpus band), score, net_linear_pct, corpus_band_pct, in_band, warnings}. Plus cooling_dT_through_k — the antisymmetric through-thickness differential auto-derived from the cooling field, ready to flow straight into molding_warpage_submit (pass it, or pass this result's case_dir+nx/ny as cooling_case_dir etc.).

Asymmetric per-wall cooling (#134): set pack_wall_h_low_w_m2k and pack_wall_h_high_w_m2k (the y=0 and y=H mold-face heat-transfer coeffs) to DIFFERENT values to model an asymmetric cool — the case is meshed with split wallLow/wallHigh patches and each face cools at its own rate, freezing a real through-thickness bending differential. This is what makes the live cooling_dT_through_k nonzero (a symmetric cool correctly gives ≈0 → no warp). The part bows toward the slower-cooled (lower-h, hotter, last-to-freeze) face; the result adds asymmetric_cooling:{pack_wall_h_low_w_m2k, pack_wall_h_high_w_m2k, warps_toward}. Leave both unset (or equal) for the default symmetric cool. Feed the resulting case_dir into molding_warpage_submit to predict the warp magnitude.

Drive the interFoam path with cavity + process params:

  • length_mm (flow length, default 100), wall_thickness_mm (cavity height, default 2), depth_mm (out-of-plane, default 1), mesh nx/ny.

  • inject_velocity_m_s OR flow_rate_cm3_s (+ optional gate_height_mm for the gate area) — the melt mean inlet speed.

  • melt rheology: melt_rho_kg_m3 (default 900), melt_nu_m2_s (kinematic, default 1e-3) for Newtonian, or a carreau {nu0,nuInf,k,n} BirdCarreau dict (the shear-thinning Cross-WLF stand-in).

  • end_time_s (run bound; default ≈4× the plug-flow fill time), machine_max_pressure_pa (press limit, default 180 MPa), fill_fraction_pass (full-fill threshold, default 0.97). Or pass a prepared case_dir to run the resolved solver directly.

Returns the degradation dict, or {job_id, status, cache_hit}; poll job_result. interFoam result: {ok, returncode, backend, case_dir, expected_fill_time_s, flow_length_ratio, fill:{filled_fraction, filled_cell_fraction, front_x_frac, last_to_fill_x_frac, max_pressure_pa}, gate:{pass, score, fidelity:"solve", band_pct, short_shot, fill_time_s, max_pressure_pa, pressure_ok, warnings}}.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
nxNo
nyNo
resinNo
stagesNo
carreauNo
case_dirNo
depth_mmNo
fill_endNo
length_mmNo
end_time_sNo
applicationNo
melt_temp_cNo
mold_temp_cNo
pack_phasesNo
room_temp_cNo
eject_temp_cNo
melt_nu_m2_sNo
wall_h_w_m2kNo
cool_window_sNo
gate_height_mmNo
melt_rho_kg_m3No
flow_rate_cm3_sNo
hold_pressure_paNo
pack_wall_h_w_m2kNo
peak_pressure_mpaNo
wall_thickness_mmNo
fill_fraction_passNo
inject_velocity_m_sNo
pack_wall_h_low_w_m2kNo
pack_wall_h_high_w_m2kNo
machine_max_pressure_paNo

Schema Changelog

Changes observed during successful MCP inspections.

  1. First observed

TDQS

A4.9/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 burden and does so: it discloses the OpenFOAM binary dependency, the non-raising failure contract ({ok:false, reason, install}), the async contract ({job_id, status, cache_hit} plus poll `job_result`), the two backend physics tiers and their divergence (OF7-org compressibleInterFoam vs ESI interFoam), and the GPL subprocess isolation. This is far more than the structured fields convey.

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 with the one-line purpose before any parameter detail, and each section (backend, packing, net shrinkage, asymmetric cooling, interFoam drive, returns) is scoped. It is long and heavily bolded, but with 31 parameters and two solver backends the density is largely earned; some register text is repetitive.

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 31-parameter async solver with no output schema and no annotations, the description supplies prerequisites, failure modes, stage semantics, the full returned dict shapes (fill/gate/pack/pack_gate/net_shrinkage/shrinkage_gate) and the handoff keys to the next tool. An agent has everything needed to call 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.

Parameters5/5

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

Schema coverage is 0% (titles only), so the description must compensate for all 31 parameters — and it does, giving defaults and physical meaning for nearly every one (e.g. `wall_h_w_m2k` 'default ~adiabatic for a clean fill — raise for freeze-off', `hold_pressure_pa` ties to the ramp peak, the `pack_wall_h_low/high` pair explains the asymmetric-cooling semantics). It also clarifies mutually exclusive drivers (`inject_velocity_m_s` OR `flow_rate_cm3_s`) and the `carreau` dict shape.

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?

States a specific verb and resource (injection-molding FILL solve, asynchronous) plus the exact question it answers (can this geometry be molded, short-shot/fill ability, fill time, peak pressure proxy). It explicitly distinguishes itself from `molding_screen` as the 'higher-fidelity twin' it escalates to, so an agent can separate the two without opening a schema.

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?

Names the alternative (`molding_screen` for the lower-fidelity screen), the downstream consumer (`molding_warpage_submit`, fed by `cooling_dT_through_k` or `case_dir`), and the switch that forces a path (`application`). It also states the fallback condition (openInjMoldSim absent → interFoam) and what each stage adds, so route selection is explicit rather than inferred.

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