2. CAE automation landscape

Before writing a single script, it helps to understand the terrain you are automating. CAE automation is not a single task but a chain of loosely coupled activities, each with its own file formats, tools, and failure modes. CLI tools are valuable precisely because they can be inserted at almost any link in that chain without requiring a monolithic platform. This section maps the typical simulation lifecycle, identifies where manual effort concentrates, and shows which stages are best served by command-line automation.

The Simulation Lifecycle as a Pipeline

A conventional structural or thermal analysis project moves through several distinct stages. Geometry is prepared in a CAD system and exported as a neutral format such as STEP or Parasolid. The mesh is generated, often in a dedicated preprocessor, producing a solver-specific input deck. Boundary conditions, material properties, and solver settings are applied. The solver runs, producing result files. Post-processing extracts scalar fields, time histories, or derived quantities. Finally, results are reported, archived, or fed into a design decision.

Each stage has a natural command-line entry point. Geometry translation can be driven by tools like gmsh or vendor-supplied converters. Meshing is frequently scriptable through gmsh -3 model.geo or through solver-native meshers. Solvers such as CalculiX (ccx), OpenFOAM (simpleFoam), or Code_Aster expose batch execution directly. Post-processing can be automated with ParaView in headless mode using pvbatch or pvpython. The key insight is that every stage already has a non-interactive interface; the automation problem is orchestration, not capability.

Where Manual Effort Actually Goes

In practice, the solver run itself is rarely the bottleneck. Modern implicit solvers handle large models efficiently, and the wall-clock time is often dominated by waiting for a single long job. The real friction lies in the surrounding activities: preparing input decks for parametric studies, renaming and organizing output files, extracting a handful of scalar values from large result databases, and repeating all of this for dozens of design points.

Consider a simple parametric study: a bracket is analyzed at five thickness values and three load magnitudes, giving fifteen load cases. Doing this manually means editing the input deck fifteen times, launching the solver fifteen times, and opening the post-processor fifteen times to record maximum von Mises stress. Each edit is an opportunity for a typo; each launch is a context switch; each post-processing session is a repetitive click sequence. A CLI-driven approach replaces this with a loop that generates decks from a template, dispatches runs, and extracts results into a single CSV file.

#!/bin/bash
# Generate and run 15 load cases for a bracket model
for t in 2.0 2.5 3.0 3.5 4.0; do
  for F in 100 200 300; do
    tag="t${t}_F${F}"
    sed -e "s/__THICKNESS__/${t}/" \
        -e "s/__LOAD__/${F}/" \
        bracket_template.inp > "run_${tag}.inp"
    ccx -i "run_${tag}" > "log_${tag}.txt" 2>&1
    echo "${t},${F},$(grep 'MAX_VM' "run_${tag}.dat" | awk '{print $2}')"
  done
done > results.csv

This script is not sophisticated, but it captures the essential pattern: a template with placeholders, a deterministic naming scheme, a solver invocation, and a result extraction step. The output results.csv can be plotted or fed into a surrogate model. The entire sweep is reproducible because the template and the loop are version-controlled.

Pain Points That CLI Tools Address Directly

Repetitive file manipulation. Renaming, copying, and editing input files is error-prone and tedious. CLI tools like sed, awk, and Python scripts handle this deterministically. A single sed command can replace a material parameter across a deck; a Python script can generate hundreds of variant decks from a YAML specification.

Lack of traceability. When a result is questioned six months later, the exact input deck, solver version, and boundary conditions must be recoverable. CLI workflows naturally produce logs and versioned inputs. A git repository containing templates and a run.sh script is a complete record of what was run and how.

Serial execution. Running one load case at a time wastes hardware. Tools like GNU parallel or xargs -P can dispatch multiple solver instances concurrently, limited only by available cores and memory. On an HPC cluster, a job array submission script achieves the same at scale.

Post-processing bottlenecks. Extracting a single number from a GUI is fast; extracting it from fifty result files is not. Headless post-processors such as pvbatch or solver-specific Python APIs can loop over result files and write structured output. The key is to define the extraction logic once and apply it uniformly.

Where CLI Tools Do Not Fit

Not every stage benefits from command-line automation. Interactive geometry repair, exploratory meshing where the engineer needs to visually inspect quality, and initial result interpretation often require a GUI. The goal is not to eliminate the GUI but to reserve it for tasks that genuinely need human judgment. A healthy workflow uses the GUI for exploration and the CLI for production runs, parametric studies, and regression testing.

A Practical Decision Framework

What This Means for the Rest of the Course

The simulation lifecycle is a pipeline with well-defined interfaces. CLI tools are most effective when they operate on those interfaces: reading and writing files, invoking solvers, and extracting data. The next sections will build on this map by introducing specific tools and patterns for each stage, starting with the shell environment and file-handling primitives that underpin all subsequent automation.