THERM Automation

VolcanoSnail treats THERM as a batch engine orchestrated from Grasshopper, with Rhino as the authoring and review environment.

Geometry in Rhino - Detail sections are represented as linework and boundaries the plugin understands.

THERM file generation - Scripts build valid THERM input from that geometry, with validation rules tuned to common failure modes.

Headless execution - THERM runs without on-screen UI during batch solves, reducing friction for large study sets.

Results in context - Outputs are pulled back for viewport preview and export for QA, reporting, and handoff.

Parametric sweeps - Many variants (materials, breaks, dimensions) can be studied with comparatively little manual effort, supporting faster inference and optimization of skin performance.

THERM ships without a supported API or public SDK; its formats are oriented toward interactive desktop use. The project therefore required substantial reverse engineering and careful validation.

Reliable read/write of THERM inputs and outputs across real project models - not only idealized test cases. Defensive handling of edge cases in finicky or unstable THERM models, so batch runs fail predictably rather than silently corrupting studies. Stable orchestration of the THERM process itself (CLI invocation, paths, timeouts, error surfacing back to Grasshopper). Repeatable QA so façade engineers could trust batch results for design decisions.

This is representative of ARPM's technology work: meet teams where they design, integrate with closed or legacy tools, and make analysis repeatable at production pace.