1. Automotive CAE workload landscape

Before migrating any CAE cluster, you need a precise picture of what that cluster actually runs. Automotive CAE is not a single workload — it is a portfolio of solvers with radically different memory footprints, scaling behaviors, licensing models, and I/O patterns. A migration plan built on a generic "HPC cluster" assumption will fail at the first checkpoint restart or license storm. This chapter establishes the workload taxonomy that drives every later decision about scheduler configuration, storage tiering, interconnect selection, and node sizing.

The Five Dominant Simulation Domains

Crash and occupant safety dominates raw core-hour consumption in most OEM environments. Explicit dynamics solvers — LS-DYNA, Pam-Crash, Radioss, and increasingly Abaqus/Explicit — integrate millions of shell and solid elements at small stable time steps. A full-vehicle frontal impact model typically contains 8–20 million elements and runs for 80–150 ms of physical time. Because the explicit time step is governed by the smallest element, mesh quality directly controls cost. These jobs scale well to 64–256 cores but exhibit diminishing returns beyond that due to communication overhead in contact algorithms. Memory demand is moderate per core (1.5–3 GB), but the aggregate is large, and checkpoint files (d3plot, binout) can reach hundreds of gigabytes per run.

NVH (noise, vibration, harshness) workloads are dominated by implicit frequency-domain and modal solvers: Nastran SOL 103/108/111, OptiStruct, and Abaqus/Standard. The characteristic operation is a large sparse matrix factorization, which is memory-bandwidth-bound rather than compute-bound. A trimmed body modal analysis with 10–30 million DOF may need 200–600 GB of RAM on a single node and scales poorly across nodes — often only 2–4 nodes are effective. NVH jobs are therefore "fat node" workloads, and they are frequently license-limited rather than hardware-limited.

CFD and thermal workloads split into two families. External aerodynamics (PowerFLOW, Fluent, STAR-CCM+, OpenFOAM) uses transient, pressure-based or Lattice-Boltzmann solvers on meshes of 200 million to over 1 billion cells. These are the most scalable jobs in the portfolio, routinely running on 1,000–4,000 cores with strong parallel efficiency, but they generate enormous transient output — terabytes per run if not carefully managed. Underhood thermal and conjugate heat transfer add radiation and solid conduction, increasing memory per cell and coupling complexity. Battery thermal runaway and cabin HVAC simulations are smaller but highly transient and often require coupled electro-thermal solvers.

Durability and fatigue covers static strength, modal superposition fatigue (FEMFAT, nCode, fe-safe), and nonlinear implicit analysis. These jobs are moderate in size but extremely numerous — thousands of load cases per program — making throughput and license utilization the binding constraints rather than peak performance.

Solver Mix and Resource Signatures

The table below summarizes the resource signature of each domain. These are representative planning figures, not vendor specifications; every site must calibrate against its own models.

Cluster Demand Patterns

Aggregating these profiles produces three distinct demand patterns that a modernized cluster must serve simultaneously.

Burst demand. Crash and CFD campaigns arrive in waves tied to vehicle program milestones. During a safety sign-off window, a single program may submit 300–800 LS-DYNA jobs in a week, saturating the interconnect and the parallel file system. The cluster must absorb these bursts without starving steady-state workloads.

Steady throughput demand. Durability and NVH load cases run continuously across many programs. These jobs are individually small but collectively consume 30–50% of total core-hours. They are sensitive to scheduler fairness and license availability, not to peak FLOPS.

Fat-node demand. NVH and coupled thermal jobs require nodes with 512 GB–1.5 TB of RAM. If the cluster is built entirely from 128 GB compute nodes, these jobs either fail or run out-of-core with catastrophic slowdown. A heterogeneous partition strategy is mandatory.

Visualizing the Workload-to-Resource Mapping

The following diagram maps each simulation domain to its dominant resource bottleneck and the cluster subsystem it stresses. Use it as a diagnostic reference when a migration reveals performance regressions in a specific domain.

Practical Profiling: What to Measure Before Migration

Do not rely on vendor benchmarks or generic HPC assumptions. Extract the actual workload profile from the existing cluster's scheduler accounting and job logs. The following commands illustrate the data collection on a Slurm-based system; adapt the equivalents for PBS, LSF, or Grid Engine.

# Core-hour consumption by partition and user group (last 90 days)
sacct -S 2024-01-01 -E 2024-03-31 -o Partition,Account,AllocCPUS,Elapsed,State \
  --parsable2 | awk -F'|' '$5=="COMPLETED"{split($4,t,":"); h=t[1]+t[2]/60; \
  coreh[$1"\t"$2]+=$3*h} END{for(k in coreh) print k"\t"coreh[k]}' | sort -k3 -nr

# Peak memory per job (identify fat-node demand)
sacct -S 2024-01-01 -o JobID,Partition,ReqMem,MaxRSS,AllocCPUS,State \
  --parsable2 | awk -F'|' '$6=="COMPLETED"{print $2"\t"$4"\t"$5}' | sort -k2 -nr | head -50

# Job size distribution (core count histogram)
sacct -S 2024-01-01 -o AllocCPUS --parsable2 --noheader | sort -n | uniq -c | \
  awk '{print $2"\t"$1}' | sort -k1 -n

Three outputs matter most. First, the core-hour breakdown by partition tells you which domain dominates and therefore which subsystem must not be undersized. Second, the MaxRSS distribution reveals whether fat-memory nodes are genuinely required or whether a few outlier jobs can be re-architected. Third, the job-size histogram determines the optimal node granularity — if 70% of jobs use fewer than 32 cores, building only 128-core nodes wastes capacity through fragmentation.

From Profile to Migration Requirements

The workload landscape translates directly into non-negotiable migration requirements. Crash and CFD demand a low-latency, high-bandwidth fabric — downgrading from InfiniBand to Ethernet will degrade explicit solver scaling by 30–50% at 256 cores. NVH demands fat-memory nodes; consolidating them into standard nodes forces out-of-core solving and can increase runtime by an order of magnitude. CFD and thermal demand a parallel file system capable of sustained multi-GB/s writes per job; a single NAS head will become the bottleneck within the first week. Durability demands license server redundancy and scheduler fairness policies that prevent large crash jobs from monopolizing tokens.

Document these requirements as a formal workload profile before selecting any hardware or cloud instance type. The profile becomes the acceptance criteria for the migrated cluster: if a domain regresses beyond an agreed threshold, the migration is not complete. In the next chapter, we will use this profile to evaluate migration strategies — lift-and-shift, re-platforming, and hybrid cloud burst — against the specific demands of each simulation domain.