Abaqus Sim

abaqus-sim

This file is the Abaqus index. Prefer direct local evidence first: existing .inp/.odb/.dat/.sta/.msg artifacts, Abaqus/SIMULIA command launchers, installed vendor docs, or user-provided paths. Use sim-cli for solver execution and live CAE authoring when its wrapping adds useful structure.

Abaqus is a commercial finite element analysis (FEA) solver by Dassault Systemes SIMULIA. The sim plugin supports two execution styles:

1. Batch execution for complete .inp decks or Abaqus/CAE Python files.
2. CAE authoring sessions for iterative model creation, inspection, debugging, job submission, and report preparation. The default backend is file-backed; the optional bridge backend keeps one noGUI CAE process alive for faster agent loops.

It supports two script formats:

• Input decks (.inp) — keyword-driven text files defining geometry, materials, loads, BCs, and analysis steps
• Abaqus/CAE Python scripts (.py) — Python scripts using the abaqus and abaqusConstants modules for parametric model building

The driver runs these via subprocess (abaqus job=X input=file.inp interactive or abaqus cae noGUI=script.py). In CAE authoring sessions, each uv run sim exec snippet runs inside Abaqus/CAE against a saved session .cae database, then saves the database back for the next step. With --backend bridge, snippets are sent to one long-lived noGUI CAE process over a localhost command channel protected by a per-session token. Use bridge mode only in trusted workspaces owned by the session user. No Abaqus Python module is imported into the sim process.

This is not the Ansys Mechanical plugin. Do not route Abaqus .inp decks or Abaqus/CAE Python scripts through solver=mechanical; use solver=abaqus for Abaqus execution/authoring and solver=mechanical only for PyMechanical / Ansys Mechanical sessions.

base/ — always relevant

solver/2026/ — Abaqus 2026 specifics

• solver/2026/notes.md — Abaqus 2026 version notes and quirks.

Hard constraints (apply to every session)

0. Respect the Abaqus embedded-Python boundary. Ordinary file-side plotting/post-processing follows the sim-cli Python-helper environment when sim runtime is in use. Abaqus/CAE and ODB scripts are different: execute them through a real Abaqus launcher such as abaqus cae noGUI=script.py, or through uv run sim run --solver abaqus script.py when using sim runtime, so Abaqus launches its embedded Python with the vendor modules available.
1. Direct availability first. Before requiring sim-cli, look for a real Abaqus launcher through SIM_ABAQUS_COMMAND, ABAQUS_COMMAND, ABAQUS_BAT_PATH, PATH entries such as abaqus/abq20*.bat, and common SIMULIA Commands locations such as C:\SIMULIA\Commands or C:\Program Files\Dassault Systemes\SIMULIA\Commands. If sim-cli/plugin is already available or needed for deeper runtime validation, run uv run sim check abaqus. If no direct or sim runtime path is found, ask the user for an Abaqus launcher path; do not continue with fake geometry.
2. Never invent Category A defaults. Geometry, materials, BCs, analysis type, acceptance criteria — if missing, ask the user.
3. Acceptance != exit code. Validate against physics-based criteria (displacement, stress, temperature ranges), not just exit_code == 0.
4. Input deck keywords are case-insensitive but use *UPPERCASE by convention. Always include *HEADING.
5. Working directory matters. Abaqus creates output files (.dat, .odb, .msg, .sta) next to the input file. Use cwd appropriately.
6. Use the right mode. If the model is already fully specified, prefer uv run sim run --solver abaqus file.inp or uv run sim run --solver abaqus script.py. If the agent is building/debugging the model incrementally, use uv run sim connect --solver abaqus --mode cae and iterate with uv run sim exec. Use --backend bridge when repeated small snippets need a live in-memory CAE session.
7. Save and inspect after every modeling step. In CAE authoring mode, each snippet should leave the .cae database in a coherent state and then check uv run sim inspect cae.model_summary or uv run sim inspect job.diagnostics.
8. Check docs or probe before guessing APIs. If unsure about an Abaqus keyword, CAE method, command option, or output variable, follow base/reference/doc_lookup.md before editing the real model.
9. Use a case workspace for non-trivial work. Do not scatter generated scripts, .cae, .odb, diagnostics, renders, metrics, and reports across the shell cwd, temp folders, and chat history. Establish one case or run folder before modeling, and keep artifacts in predictable subfolders.

Case workspace shape

For any non-trivial Abaqus task, establish or verify a durable case workspace before creating geometry, submitting jobs, rendering results, or writing a report. A workspace is just a self-contained project folder that a future agent or human can reopen:

textCopy code
<workdir>/
  model/          # .cae database, named checkpoints, model copies
  input/          # parameters, CAD, source data, user-provided decks
  scripts/        # generated or hand-written Abaqus/CAE and ODB scripts
  run/            # solver-native job outputs: .inp, .odb, .msg, .sta, .dat
  render/         # Abaqus/CAE or Viewer PNG/MP4/viewport evidence
  output/         # metrics JSON, tables, extracted summaries
  report/         # markdown/html/pdf summary when generated

Use the user-provided folder when one exists. When starting from scratch, choose a descriptive slug such as runs/bracket_static or runs/hole_plate_modal and pass it as --workspace for CAE authoring sessions. The driver may keep its managed session.cae at the workspace root; save named review checkpoints under model/ when they help resume or compare work, for example model/hole_plate_01_geometry.cae, model/hole_plate_02_mesh.cae, and model/hole_plate_03_solved.cae.

Prefer Abaqus/CAE or Abaqus Viewer for canonical render evidence. render/ should contain solver-rendered contour images, deformed-shape views, modal views, or animations when requested. output/ should contain machine-readable metrics and extracted tables. report/ should reference those artifacts by path and state which files support each conclusion.

Long-running execution and recovery

Keep bounded Abaqus work in the foreground when it fits the active tool-call budget. Use a settled input deck, CAE noGUI script, or background process only when the run is expected to outlive that budget, must continue across agent turns, or the user explicitly asks for background execution.

For a long run, use a stable job name and absolute working/output paths so the agent can inspect it later. A shell or tool timeout ends that observation call; it does not prove Abaqus stopped. Before submitting the same job again, check the existing launcher/solver process, .sta progress, .msg and .dat diagnostics, and .odb or other expected artifact timestamps.

Confirm process ownership from the job name, executable and full command line, start time, working directory, and output targets. Prefer Abaqus-native job cancellation; otherwise stop only the exact confirmed process or process tree. Never terminate every Abaqus, Standard, or Explicit process by name.

Treat a successful process exit as only one completion signal. Confirm the Abaqus completion marker and usable expected artifacts before claiming the analysis completed. Use resume only when an Abaqus restart/checkpoint artifact can actually continue the analysis; without one, describe a new submission as a restart.

Required protocol

After direct launcher discovery or sim runtime validation confirms a real Abaqus path is available, gather Category A inputs from the user (geometry, material properties, loads, BCs, analysis type, acceptance criteria). For non-trivial work, establish the case workspace above before generating files.

For batch work: write the .inp deck or .py script, lint with uv run sim lint when sim-cli is part of the chosen runtime, execute through the smallest real path available (abaqus job=... input=..., abaqus cae noGUI=script.py, or uv run sim run --solver abaqus ... for sim runtime), then choose the post-processing path by artifact: .dat -> Python text parsing on the fetched file; ODB -> vendor Python through Abaqus/CAE noGUI or uv run sim run --solver abaqus script.py when using sim runtime. For ordinary file-side post-processing and plotting, use the host Python environment unless the sim-cli Python-helper environment is already the selected execution path. Validate against physics-based acceptance criteria. Keep source decks/scripts under input/ or scripts/, job products under run/, Abaqus-rendered images or animations under render/, and extracted metrics/tables under output/.

For modeling/debug/reporting work, choose the smallest real interactive path: attach to or use Abaqus/CAE directly when the user already has it available, or start uv run sim connect --solver abaqus --mode cae --ui-mode no_gui --workspace <workdir> when sim session management and inspection surfaces are useful, optionally adding --backend bridge for a live noGUI CAE process. Build the model in small CAE Python snippets, inspect after each major step, save checkpoints when useful, submit jobs from the session, read diagnostics, render canonical views in Abaqus/CAE or Viewer, fix the model, and produce a report that states assumptions, units, mesh, BCs, loads, solver messages, result checks, artifact paths, and acceptance status.