2. Mapping the end-to-end CAE workflow

Before a single line of automation code is written, the CAE workflow must be decomposed into discrete, observable, and repeatable stages. Automation succeeds or fails on the quality of this decomposition. A workflow that is mapped only at the level of "pre-processing, solving, post-processing" cannot be automated reliably, because each of those labels hides dozens of file operations, parameter decisions, and format conversions that must be handled explicitly. This chapter builds a working map of the end-to-end CAE workflow and identifies, at each stage, what the automation target actually is.

Why the Workflow Map Is the First Automation Artifact

An automation program is a contract between a process and a machine. The process side of that contract is the workflow map. If the map is incomplete, the program will silently skip steps, produce results that look plausible but are wrong, or fail at the worst possible moment — typically during a batch run overnight. A good workflow map answers four questions for every stage:

• Inputs: What files, parameters, or upstream artifacts does this stage consume?
• Operations: What transformations, decisions, or solver invocations occur?
• Outputs: What artifacts are produced, and in what format and location?
• Verification: What observable signal confirms the stage completed correctly?

These four questions are not a template to be filled in mechanically. They are a discipline that forces the engineer to distinguish between what the analyst does and what the analyst knows. Much of the tacit knowledge in CAE — "I always check the mesh quality before submitting" — becomes an explicit verification step once it is written down.

Stage 1: Geometry Preparation

Geometry preparation is the most variable and least standardized stage in the CAE workflow. Input geometry may arrive as native CAD (CATIA, NX, SolidWorks), neutral formats (STEP, IGES, Parasolid), or as a mesh from a previous analysis. The automation target here is not "clean the geometry" — that is a human judgment — but rather the deterministic subset of operations that can be scripted:

• Format conversion and import with a fixed set of import options (tolerance, unit system, healing level).
• De-featuring operations that are rule-based: removing holes below a diameter threshold, suppressing fillets below a radius threshold, collapsing small chamfers.
• Boolean operations and solid/surface partitioning driven by named selections or coordinate planes.
• Export of the prepared geometry to a neutral format with a versioned filename.

The critical automation decision is where to draw the line between scripted and manual operations. A practical rule: if the operation can be expressed as a function of geometry attributes (size, location, topology) without visual inspection, it is a candidate for automation. If it requires the analyst to judge whether a feature is "important to the physics," it should remain manual, but its output should be captured as a named selection or a metadata file that downstream stages can consume.

Stage 2: Meshing

Meshing is where automation delivers the largest time savings, because mesh generation is repetitive and parameter-driven. The automation target is a mesh recipe: a script that takes prepared geometry and produces a mesh with controlled quality metrics. Key parameters to expose in the recipe include:

The verification step is essential. After meshing, the script should extract quality metrics and compare them against thresholds. If the mesh fails the check, the automation should either retry with adjusted parameters or halt and report the failure with the specific metric that failed. A mesh that is generated but not verified is a latent error.

Stage 3: Solver Setup

Solver setup is the stage where automation most directly affects correctness. The target is a solver deck — a complete input file that can be submitted without manual editing. This includes material definitions, boundary conditions, load cases, solver controls, and output requests. The automation challenge is that many of these are analysis-type-specific. A structural static analysis and a thermal transient analysis share almost no solver keywords.

A robust approach is to separate the solver deck into a template and a parameter set. The template contains the invariant structure (element types, solver settings, output requests). The parameter set contains the values that change per run (material properties, load magnitudes, boundary condition locations). The automation program merges the two. This separation makes it possible to validate the template once and reuse it across hundreds of runs.

Stage 4: Post-Processing

Post-processing automation is often underestimated. The target is not "plot the results" but "extract the specific quantities that the engineer needs to make a decision." For a structural analysis, that might be maximum von Mises stress, location of that maximum, and a safety factor. For a thermal analysis, it might be maximum temperature and heat flux through a named surface.

The automation should produce a machine-readable results file (CSV or JSON) alongside any visual output. This file becomes the input to the reporting stage and to any downstream decision logic. A common failure mode is to automate the solver but leave post-processing manual, which means the bottleneck simply moves downstream.

Stage 5: Reporting

Reporting is the final stage and the one most often left out of automation scope. The target is a report that is generated automatically from the results file and a report template. This can be as simple as a CSV summary or as complex as a formatted PDF with embedded images. The key automation principle is that the report should be derived from the results, not manually assembled. If the engineer has to copy-paste numbers into a report, the automation is incomplete.

Visualizing the Workflow as Automation Targets

The following diagram maps the five stages as a data flow, showing the primary artifacts that move between stages and the verification gates that control whether the workflow proceeds. Each stage is annotated with its automation target and the key decision point that determines whether the stage can be fully automated or requires human input.

From Map to Automation Program

Once the workflow is mapped at this level of detail, the automation program becomes a matter of implementing each stage as a module with a defined interface. The modules communicate through files and structured data, not through shared memory or global state. This makes the program testable: each module can be run independently with a known input and its output verified against an expected result.

The map also reveals where human judgment is genuinely required. Geometry de-featuring decisions, mesh refinement strategy for complex physics, and interpretation of unexpected results are all candidates for human-in-the-loop checkpoints. The automation program should be designed to pause at these points, present the relevant data, and accept a decision before continuing. This hybrid approach — automated execution with human decision gates — is more robust than either fully manual or fully automated workflows.

The workflow map produced in this chapter is not a one-time document. It should be version-controlled alongside the automation code, and updated whenever the underlying CAE process changes. A map that is out of date is worse than no map at all, because it creates false confidence in the automation's correctness.