Skip to main content
Glama

Molding Fill Submit

molding_fill_submit
Destructive

Run asynchronous injection-molding fill analysis to determine if a geometry can be molded, providing fill time, short-shot risk, and peak injection pressure via two-phase flow simulation.

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?

Annotations already indicate a non-read-only, potentially destructive tool, and the description adds substantial behavioral context: asynchronous execution with job_id polling, graceful {ok:false, reason, install} return when OpenFOAM is absent, a GPL solver isolated at the subprocess boundary, fallback to a different solver, and detailed result shapes. This goes well beyond the structured 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 long, but it is structured with bolded sections and front-loaded with the core purpose in the first paragraph. Given 31 undocumented parameters and complex backend behavior, the length is largely justified. A few implementation details (GPL licensing, issue numbers) could be trimmed, but they do not obscure the main usage guidance.

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?

With no output schema, the description compensates by detailing return payloads for both solver paths, including pack, shrinkage, gate, and asymmetric-cooling result keys. It also covers async submission, polling, required binaries, fallback behavior, and cross-tool data flow. An agent has enough context to invoke and interpret this complex tool correctly.

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%, so the description is the only source of parameter meaning, and it delivers: nearly all 31 parameters are explained with units, defaults, grouping by backend, and choices (e.g., inject_velocity_m_s OR flow_rate_cm3_s, pack_wall_h_low/high for asymmetric cooling). It also distinguishes openInjMoldSim params from interFoam params.

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-and-resource statement: an injection-molding FILL solve with optional PACK/COOL, asynchronous. It explicitly positions itself as the higher-fidelity twin molding_screen escalates to, and states the core questions it answers (short-shot/fill ability, fill time, peak injection-pressure proxy). This clearly separates it from sibling molding tools.

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?

It names molding_screen as the lower-fidelity predecessor and says this tool is what it escalates to, giving a concrete when-to-use signal. It also states prerequisites (OpenFOAM binary), the fallback path, and how to force the interFoam path via application. Downstream hand-off to molding_warpage_submit is also described.

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