---
name: nxopen-simcenter-thermal
description: Use when working with Siemens NX / Simcenter 3D thermal analysis through NXOpen. Covers session discovery, thermal model inspection, boundary condition and load editing, thermal coupling and optical property updates, solve orchestration, result extraction, and optional DOE or batch dataset generation. Prefer generic object discovery and unit-safe edits over project-specific names, paths, or file layouts.
---

# NXOpen Simcenter Thermal

## Overview

This skill guides NXOpen-based automation for Simcenter 3D thermal analysis.
It is for generic thermal workflows, not one project. Use it to inspect a
thermal model, locate relevant objects, modify thermal inputs safely, run
solves, export results, and optionally organize repeated studies or dataset
generation.

## Working Stance

- Start by discovering the current NX session and active thermal context.
- Prefer enumerating objects over assuming names already exist.
- Preserve units from the current property table before writing new scalar values.
- Separate discovery, edit, solve, and export into distinct steps.
- Treat DOE, sweeps, and LHS as optional recipes layered on top of the core
  thermal workflow.

## Local Wrapper Preference

- If the current workspace already contains NXOpen thermal wrappers, prefer
  importing and extending them instead of rewriting the same NXOpen sequences.
- Search the workspace for existing modules around session setup, parameter
  editing, solve orchestration, and result export before creating new helpers.
- If local wrappers are project-specific, extract the reusable core into small
  generic helpers and keep project assumptions in a thin outer layer.
- In this workspace, local NXOpen completion stubs are available under
  `NXOpen_intellisence/NXOpen` and `NXOpen_intellisence/NXOpenUI`.
- Use those local stub packages for signature lookup, API surface inspection,
  and import-path discovery when the real NX runtime is unavailable in the
  current shell.
- Treat the stub packages as a reference and completion aid, not as proof that
  a given API call will succeed at runtime inside NX.

## Quick Routing

- Need the NX object model or wrapper boundaries: read `references/architecture.md`.
- Need to find solutions, loads, constraints, groups, or result sources: read
  `references/object-discovery.md`.
- Need to edit heat loads, temperature constraints, thermal couplings, optical
  properties, or solar vectors: read `references/parameter-editing.md`.
- Need to run or monitor solves safely: read `references/solving.md`.
- Need to export temperatures, element results, or radiation-like outputs:
  read `references/results.md`.
- Need batch studies, parameter sweeps, LHS, or dataset generation: read
  `references/doe-recipes.md`.

## Standard Workflow

### 1. Discover Context

- Get `Session`, `UI`, `BaseWork`, `Simulation`, and `ActiveSolution`.
- Confirm the active part is a thermal simulation context before editing.
- Enumerate candidate loads, constraints, simulation objects, groups, and
  result sources.

### 2. Select Targets

- Match objects by exact name first.
- If exact names are unknown, search by type plus partial name and report
  candidates.
- Do not silently change the first matching object when multiple plausible
  matches exist.

### 3. Edit Parameters Safely

- Read the current property value and unit from NX before writing.
- Reuse the existing unit object when setting new scalar values.
- For modeling-object-based properties, handle shell and solid collectors
  differently.
- Log what changed: object name, property name, old value, new value, and unit.

### 4. Orchestrate Solves

- Use the active solution unless the user explicitly wants clone or rename
  behavior.
- Prefer visible timeout handling, progress logging, and post-solve checks over
  blind sleeps.
- Treat file locks and partially written solver outputs as normal operational
  hazards on Windows.

### 5. Extract Results

- Decide whether the source is the active solution or an existing `.bun` file.
- Detect steady-state versus transient behavior before choosing export logic.
- Distinguish node-oriented outputs from element or group-oriented outputs.
- Export tabular results with enough metadata to reconstruct sample conditions.

### 6. Scale to Repeated Studies

- Only add DOE, sweeps, or LHS once a single case works end to end.
- Persist the sample table and per-run parameter log so reruns are reproducible.
- Support resume from the last completed sample when practical.

## Guardrails

- Keep the skill generic. Avoid hard-coded project roots, CSV names, FE
  occurrence IDs, or group naming conventions unless the current workspace
  proves they are required.
- Prefer adapting existing wrappers in the workspace if they already cover part
  of the requested task.
- When a requested property path is uncertain, inspect the object and property
  table first instead of guessing.
- When exporting results, include enough identifiers to trace each row back to
  the solution, load case, iteration, group, and result quantity.
- If the user asks for a helper library, factor reusable operations into small
  wrappers rather than embedding long NXOpen sequences in one script.

## Deliverables

When using this skill, aim to leave behind:

- reusable wrappers for repeated NXOpen operations;
- a clear separation between discovery, edit, solve, and export code;
- logs or CSV outputs that make reruns and audits possible;
- brief notes on object names, units, assumptions, and failure points.