4. Capacity planning fundamentals

Capacity planning in automotive CAE answers a deceptively simple question: can we deliver the required simulation workload within the program timeline, and if not, what must change? Unlike manufacturing capacity, which is measured in units per shift, CAE capacity is a composite of four coupled resources — engineers, skills, software licenses, and compute hardware. A shortage in any one of them stalls the entire chain, because a crash solver license is useless without an engineer who can interpret the result, and a skilled engineer is idle without a solver token or a node to run on. This chapter establishes the vocabulary and the quantitative mechanics for reasoning about all four together.

The Four Resource Dimensions

A resource pool is a named, countable group of interchangeable capacity. Typical pools in a vehicle development CAE department include:

• Body structure crash analysts — LS-DYNA / PAM-CRASH, frontal, side, rear, pole impact
• NVH & durability analysts — Nastran, Abaqus, modal and fatigue workflows
• CFD thermal analysts — STAR-CCM+, Fluent, underhood and cabin thermal
• Optimization / MDO specialists — modeFRONTIER, OptiStruct, HEEDS
• Pre/post-processing technicians — meshing, model assembly, report generation

Each pool has a headcount, a calendar availability (FTE, vacation, training), and an efficiency factor. A pool of 8 engineers at 0.85 effective utilization yields 6.8 FTE of usable capacity — not 8. This distinction matters because planning against nominal headcount is the most common source of overcommitment.

Skill Matrices: Capacity Is Not Fungible

Headcount alone overstates capacity. A skill matrix maps each engineer against each required competency and a proficiency level. A practical five-level scale used in many OEM CAE groups is:

Capacity should be counted only at level ≥ 2 for independent delivery, with level 3+ required for novel load cases or correlation work. If a frontal crash workload of 40 load cases must be delivered and only three engineers are at level ≥ 2 in LS-DYNA, the effective pool is three, regardless of department size. The skill matrix therefore converts headcount into qualified capacity and exposes single-point-of-failure risks — for example, a single level-4 expert owning the pedestrian protection method.

Software Licenses: Tokens, Queues, and Contention

Commercial CAE licenses are usually floating tokens served by a license manager (FlexNet, DSLS, RLM). Two parameters dominate planning:

• Token count — the maximum concurrent jobs of a given solver feature
• Token cost per job — some solvers consume multiple tokens for parallel execution or advanced features (e.g., implicit, multi-physics)

If LS-DYNA SMP is licensed at 64 tokens and each 16-core job consumes 4 tokens, the concurrency ceiling is 16 simultaneous jobs. License capacity is therefore a hard cap independent of hardware. A useful planning formula for a solver pool is:

max_concurrent_jobs = floor(available_tokens / tokens_per_job)
license_limited_throughput = max_concurrent_jobs × jobs_per_day_per_slot

Where jobs_per_day_per_slot derives from average wall-clock time. A 6-hour crash job on a dedicated slot yields roughly 4 jobs/day; a 30-minute modal job yields far more. License contention typically appears as queue wait time in the scheduler, not as a hard error, so it must be monitored explicitly.

Hardware Constraints: Cores, Memory, and I/O

Compute capacity is expressed in core-hours, but the binding constraint is often memory or interconnect rather than raw cores. Key parameters:

• Cores per node — determines maximum MPI rank count per job
• Memory per node — implicit and CFD models frequently need 64–256 GB; a memory-starved job either fails or swaps catastrophically
• Scratch / I/O bandwidth — explicit crash decks write large d3plot files; slow storage throttles otherwise idle cores
• Interconnect — InfiniBand vs. Ethernet materially changes scaling efficiency above ~32 ranks

Scaling is sublinear. A job that takes 10 hours on 8 cores may take only 3.5 hours on 32 cores — a speedup of 2.9×, not 4×. Planning must use measured scaling curves, not ideal linear extrapolation. The following diagram shows how the four dimensions combine into deliverable capacity and where bottlenecks propagate.

Demand–Supply Balancing

Balancing is a periodic reconciliation between a demand forecast and the four supply constraints. The demand side is built from the program timing plan: each milestone (e.g., digital buck, first prototype, homologation) pulls a defined set of load cases. Convert load cases into core-hours and engineer-hours using historical averages, then distribute across the calendar weeks preceding each milestone.

A worked example for one crash pool in a single week:

Here the binding constraint is engineer-hours: 102 available versus 240 required, a shortfall of 138 hours — roughly 3.4 additional qualified engineers for the week. Hardware and licenses are not limiting. The correct response is therefore not to buy more nodes but to add or upskill engineers, defer non-critical load cases, or outsource. This is the central insight of capacity planning: the bottleneck determines the intervention, and interventions applied to non-binding resources waste money.

Practical Balancing Levers

1. Level the demand — shift load cases earlier or later within the milestone window to smooth peaks.
2. Increase qualified capacity — training level-1 engineers to level 2 is often cheaper and faster than hiring.
3. Improve efficiency — template decks, automated meshing, and standardized load-case libraries reduce engineer-hours per case.
4. Add hardware or licenses — only effective if that dimension is the binding constraint.
5. Outsource or defer — a valid release valve when internal capacity cannot be expanded in time.

Monitoring and Feedback

Capacity plans decay quickly. Track actual versus planned engineer-hours per case, license queue wait times, and cluster utilization weekly. When actual engineer-hours per case drift above the historical average — a common symptom when a new vehicle architecture introduces unfamiliar load cases — the demand forecast must be revised upward before the milestone slips. The plan is a living model, not a one-time calculation.