Solver Scripting & CAE Automation

The Engineering Problem

Much engineering programming is not about writing numerical software from scratch. It is about controlling, extending and automating existing CAE software — FEA solvers, CFD codes, meshers and post-processors. These solvers contain decades of validated numerical development. The engineer’s task is to drive them repeatably, extract results automatically and build workflows that connect them to the rest of the engineering process.

Why Programming Helps

Manual CAE workflows involve repeated graphical interaction — building models, applying loads, submitting jobs, extracting results, formatting reports. Each manual step is a potential source of variation and error. Scripting these steps makes the workflow repeatable, traceable and scalable from a single analysis to a parametric study of hundreds of cases.

Engineering programming often means connecting to a trusted solver rather than writing a solver from scratch.

Solver Automation Workflow

A typical automated solver workflow follows a consistent chain from parameter definition to engineering review. Each step can be scripted, with automated checks at defined gates.

Parameters → geometry/model update → mesh → loads → solve → automatic health check → result extraction → margin / plot → engineering review

Abaqus Scripting

Abaqus provides a Python-based scripting interface that allows model creation, job submission and results extraction to be fully automated. The same Python interpreter can be used to build parametric models, run studies and post-process results. User subroutines (UMAT, VUMAT) written in Fortran or C extend the solver with custom material models.

• Python scripting — model build, parameterisation, job submission, ODB extraction
• Abaqus scripting interface — access to model database (MDB), output database (ODB)
• User subroutines — UMAT, VUMAT (Fortran) for custom material models
• Input file generation — text-based .inp files can be templated and parameterised

ANSYS Automation

ANSYS provides both Workbench graphical workflows and APDL (ANSYS Parametric Design Language) for programmatic control. Modern ANSYS also offers Python-based automation through the PyANSYS library, which allows model setup, solving and results extraction from Python scripts.

• APDL — parametric input language for full solver-level control
• Workbench scripting — ACT extensions and Python automation
• PyANSYS — Python library for model interaction and results extraction
• User-defined functions — custom material models, boundary conditions

Nastran Automation

MSC Nastran input is a text-based bulk data file. Automation typically involves generating, modifying and managing these files programmatically. This can be done in any language capable of text manipulation — Python, MATLAB, or specialised pre-processor scripting.

• Bulk-data file generation — templating GRID, CQUAD4, MAT1, PSHELL cards
• Multi-load-case management — CASE CONTROL and SUBCASE generation
• Results extraction — parsing .f06 output files, .pch punch files
• DMAP — direct matrix abstraction programme for solver-level customisation

OpenFOAM Automation

OpenFOAM is an open-source CFD toolbox written in C++. Case setup uses dictionary-based configuration files. Automation involves templating these dictionaries, scripting case generation and running the solver from the command line. Custom boundary conditions, transport models and turbulence models are implemented as C++ classes compiled against the OpenFOAM libraries.

• Dictionary configuration — templated case setup files
• C++ extension — custom boundary conditions, solvers, models
• Command-line automation — shell scripting for case generation and execution
• Python integration — PyFoam or foam-control libraries for case management

MATLAB and Simulink Co-Simulation

MATLAB and Simulink can co-simulate with CAE solvers, particularly for system-level dynamics and control-structure interaction. This allows a structural model in a solver to be coupled with a control system model in Simulink, with each tool solving its portion of the problem at each time step.

APIs vs Text-File Automation

There are two fundamental approaches to solver automation: API-based interaction, where the solver exposes a programmatic interface, and text-file automation, where input and output files are generated and parsed externally. Both are valid; the choice depends on the solver’s capabilities and the workflow requirements.

Automated Health Checks

An automated solver workflow should include automated health checks at defined gates — before solver submission and after results extraction. These checks catch problems at the point where they are cheapest to correct.

• Pre-solver: units, mass, material assignment, mesh metrics, load totals
• Post-solver: solver completion, convergence, reaction balance, energy balance
• Result extraction: result bounds, missing data, expected sign of response
• Configuration: model version, input revision, solver version recorded

ENGINEERING CHECK: Does the automated workflow include checks at defined gates, or does it simply submit and extract? A workflow without health checks is faster but not more reliable.

Verification

An automated solver workflow should be verified against a manually created and reviewed baseline case. The scripted model should produce the same result as the hand-built model. Parametric variations should be checked against known trends. Automated post-processing should be verified against manual extraction for a subset of results.

• Verify scripted model against manually built baseline — Same result to within numerical tolerance
• Verify parametric variations against expected trends — e.g. thicker shell → lower stress
• Verify automated extraction against manual extraction — At least 5–10 results checked manually
• Verify health checks catch known error cases — Introduce a deliberate error and confirm detection

Key Takeaways

• Engineering programming often means connecting to a trusted solver rather than writing one
• Both API-based and text-file automation are valid — the choice depends on the solver and workflow
• Automated health checks at defined gates are a first-class part of the workflow
• Every automated workflow should be verified against a manually built baseline
• Solver automation links directly to the Engineering Automation capability