2. CAE workload characterization

Capacity planning for an automotive CAE group fails when it treats every simulation as an interchangeable "job." A 4-hour NVH modal solve and a 36-hour full-vehicle crash run consume the same wall-clock day but place completely different demands on cores, memory, licensing, and I/O. Before you can schedule anything, you must characterize each workload along four axes: simulation type, solver runtime, resource profile, and parallel scaling behavior. This section builds that characterization discipline for the five dominant CAE domains in vehicle development.

Why Domain Matters More Than Job Count

Two projects can each submit 500 jobs per week, yet one saturates a 2,000-core cluster while the other barely loads a 256-core node pool. The difference is the resource profile. Crash and CFD are core-hungry and memory-moderate; NVH and durability are often memory-hungry and core-moderate; optimization is throughput-hungry, generating hundreds of short, low-fidelity runs that must be dispatched and harvested quickly. A scheduler that ignores these distinctions will either starve high-core jobs or waste memory on jobs that never use it.

Domain-by-Domain Characterization

The table below summarizes typical profiles. Values are representative planning figures for a mid-size passenger vehicle program, not measured results from a specific cluster; always calibrate against your own solver logs.

Domain Typical Solver Model Size Wall-Clock Cores/Job Memory/Job Scaling
Crash / Explicit LS-DYNA, Radioss, Abaqus/Explicit 8–20 M elements 12–48 h 64–256 60–200 GB Good to ~256 cores
NVH / Modal Nastran, OptiStruct, Abaqus/Standard 3–10 M DOF 0.5–6 h 8–32 80–400 GB Moderate; memory-bound
CFD / Aerodynamics Fluent, STAR-CCM+, OpenFOAM 50–300 M cells 8–72 h 128–512 100–500 GB Good to ~512 cores
Durability / Fatigue Abaqus, Nastran SOL 400, FE-SAFE 2–8 M DOF 2–20 h 16–64 60–250 GB Moderate
Optimization / DOE OptiStruct, modeFRONTIER, HEEDS Reduced / surrogate 5 min–2 h 4–32 8–64 GB Throughput, not scaling

Reading the Resource Profile Correctly

Three parameters drive scheduling decisions more than any others:

  • Peak RSS (resident set size) — the maximum memory a job touches. Crash jobs peak early during contact initialization; CFD jobs grow steadily as the mesh is partitioned and the linear system is assembled. If you size nodes by average memory, you will OOM-kill jobs at their worst moment.
  • Parallel efficiency curve — the point where adding cores stops helping. Explicit crash solvers scale well to 256 cores because the work is embarrassingly parallel across elements. Implicit NVH solvers hit a wall around 32 cores because the sparse direct solver becomes communication-bound. Scheduling a modal job on 128 cores wastes 96 cores and produces no speedup.
  • License token count — a single LS-DYNA MPP job may consume 1 master token plus N solver tokens. CFD jobs often hold a fixed pool of HPC tokens regardless of core count. License exhaustion, not compute, is frequently the real bottleneck.
Calibration tip: Pull the d3hsp (LS-DYNA), .out (Nastran), or solver transcript from a completed job. Extract peak memory, elapsed time, and core count. After 20–30 jobs per domain, you have an empirical profile far more reliable than vendor benchmarks.

Runtime Estimation and the Scaling Trap

Runtime is not linear in model size. For explicit crash, wall-clock scales roughly with element count divided by core count, but contact and time-step penalties add a nonlinear term. A practical first-order estimate:

t_wall ≈ (N_elem × t_elem) / (N_cores × η(N_cores)) + t_io

where:
  N_elem   = element count
  t_elem   = CPU-seconds per element (calibrate from history)
  η        = parallel efficiency at N_cores (0.85 at 64, 0.70 at 256)
  t_io     = result write + restart overhead

For a 12 M-element crash model with t_elem = 0.004 s, 128 cores, and η = 0.78, the compute term is about 480 s per simulated millisecond. A 120 ms event therefore needs roughly 16 hours of compute, plus 1–2 hours of I/O — consistent with the table above. The same model on 256 cores with η = 0.70 gives only a 1.11× speedup, which is why doubling cores rarely halves runtime.

Optimization Workloads Behave Differently

Optimization and DOE campaigns are not single long jobs; they are many short jobs with dependencies. A topology optimization might launch 200 design iterations, each a 15-minute NVH solve, with a surrogate model update between batches. The scheduling challenge is latency, not throughput: the next batch cannot start until the previous batch's results are collected and the optimizer updates. This creates a bursty load pattern that a naive FIFO queue handles poorly. The right approach is a dedicated high-priority queue with fast dispatch and a shared scratch filesystem so that intermediate results are available immediately.

CAE Workload Resource Profiles by Domain Bubble size ≈ typical wall-clock duration · Position shows core vs. memory demand Cores per job (parallel demand) → Memory per job (GB) → 64 128 256 512 50 100 200 400 Crash 12–48 h CFD 8–72 h NVH 0.5–6 h Durability 2–20 h Opt/DOE ×200 Implicit solver scaling wall (~32 cores) Scheduling implication High-core jobs → dedicated queue Memory-bound jobs → large-mem nodes

From Profile to Scheduling Policy

Once domains are characterized, the scheduling policy almost writes itself. Crash and CFD jobs belong in a high-core queue with nodes provisioned for 256–512 cores and 256–512 GB RAM. NVH and durability jobs belong in a high-memory queue with fewer cores but 512 GB–1 TB per node. Optimization campaigns belong in a throughput queue with short time limits, aggressive backfill, and a shared scratch tier. Mixing these in one undifferentiated pool guarantees that a 400 GB CFD job blocks a node that could have run twenty NVH jobs, or that a 256-core crash run sits behind a queue of 4-core modal solves.

Common failure symptom: Jobs killed with "out of memory" despite node RAM appearing sufficient. Cause: peak RSS occurs during solver initialization or contact detection, not during steady-state iteration. Fix: profile peak RSS from solver logs, not from top snapshots, and add a 20–30% headroom margin when sizing nodes.

Practical Characterization Workflow

  1. Collect solver logs from the last 3–6 months for each domain. Extract wall-clock, core count, peak memory, and exit status.
  2. Group by domain and model size band (e.g., crash: <8 M, 8–15 M, >15 M elements).
  3. Compute median and 90th-percentile runtime and memory per band. Use the 90th percentile for capacity sizing, not the median.
  4. Measure parallel efficiency by running one representative model at 32, 64, 128, and 256 cores. Plot speedup and identify the knee.
  5. Record license token consumption per job type. Multiply by expected job volume to forecast license demand.
  6. Feed the resulting profile table into your scheduler's queue definitions and node pool sizing.

The output of this exercise is a workload profile matrix — one row per domain/size band, with columns for cores, memory, runtime percentiles, scaling knee, and license tokens. That matrix is the single most valuable input to every subsequent capacity decision: how many nodes to buy, how to partition queues, what time limits to set, and where to place the next bottleneck. Without it, capacity planning is guesswork dressed as arithmetic.

← Previous 📖 Contents Next →