2. HPC capacity fundamentals for CAE

Before you can optimize CAE solver licenses against HPC capacity, you need a precise mental model of what "capacity" actually means on a cluster. A CAE job does not consume a single fungible resource — it simultaneously demands CPU cores, memory per core, interconnect bandwidth, scratch storage, and a scheduler slot. Any one of these can become the binding constraint, and the license is only useful if all of them are available at the same time. This section builds that model from the hardware up, then introduces the three metrics that govern every capacity decision: capacity, utilization, and throughput.

Node anatomy: the unit of allocation

A compute node is the smallest schedulable hardware unit. Typical CAE clusters mix node classes deliberately, because implicit structural solvers and explicit crash simulations have opposite hardware appetites. A representative mid-size cluster might contain:

Two ratios matter more than raw counts. Memory per core determines whether a job can actually use the cores it requests: an implicit solver needing 8 GB per core cannot run 64-way on a 256 GB node, no matter how many cores are free. Core count per node sets the granularity of allocation — requesting 40 cores on a 64-core node wastes 24 cores unless the scheduler can backfill another job into them.

Interconnect: the scaling ceiling

For distributed-memory CAE solvers (MPI-based), interconnect latency and bandwidth decide how far a model scales before adding cores stops helping. A useful rule of thumb: explicit solvers with small messages tolerate 100 GbE Ethernet, while implicit solvers doing frequent dense matrix operations benefit measurably from InfiniBand with RDMA. The practical consequence for capacity planning is that a job's effective core demand is bounded by the interconnect domain it lands in. If the scheduler scatters a tightly coupled 256-core job across four racks on oversubscribed Ethernet, wall-clock time inflates and the license sits idle in wall-clock terms even though cores are busy.

Storage tiers: where jobs stall silently

CAE jobs touch storage in three distinct patterns, and conflating them causes most "the cluster is slow" complaints:

• Scratch (node-local NVMe): solver temporary files, restart files, and out-of-core spills. Fast, but invisible to other nodes and wiped between jobs.
• Parallel shared filesystem (Lustre, GPFS, Weka): input decks, results, and cross-node MPI I/O. Bandwidth is shared, so ten simultaneous jobs writing 50 GB result files can saturate it.
• Archive/home (NFS or object store): long-term storage, not for active solver I/O.

A common failure mode: a job configured to write results to the shared filesystem instead of node-local scratch. It runs fine alone, then collapses when the cluster is busy — throughput drops without any CPU or memory metric showing saturation.

Job schedulers: Slurm, PBS, LSF

The scheduler is the arbiter of capacity. All three major schedulers — Slurm, PBS Professional, and IBM Spectrum LSF — implement the same core concepts with different syntax:

• Partitions/queues: logical pools of nodes with limits (max walltime, max nodes per job, priority).
• Resource requests: cores, memory, GPUs, walltime, and often licenses.
• Backfill: small jobs fill gaps ahead of large queued jobs without delaying them, provided the small job's walltime fits the gap.
• Fair-share / priority: historical usage decays over time to prevent any one user or group from monopolizing capacity.

A Slurm submission for an implicit CAE job illustrates how resource requests encode the hardware model:

#!/bin/bash
#SBATCH --job-name=abaqus_implicit
#SBATCH --partition=fatmem
#SBATCH --nodes=2
#SBATCH --ntasks-per-node=24
#SBATCH --mem=0                 # request all memory on each node
#SBATCH --gres=license:abaqus:48
#SBATCH --time=24:00:00
#SBATCH --output=%x_%j.log

module load abaqus/2023
abaqus job=crash_tower cpus=48 mp_mode=mpi scratch=/scratch/$SLURM_JOB_ID interactive

The equivalent PBS directive is #PBS -l select=2:ncpus=24:mem=1500gb:license=abaqus:48, and LSF uses #BSUB -n 48 -R "span[ptile=24] rusage[mem=1500GB]". The syntax differs; the semantics — nodes, tasks per node, memory, license tokens, walltime — are identical. Note the --gres=license line: schedulers can track license tokens as a consumable resource, which is the mechanism that later chapters use to co-schedule solver licenses with compute.

Capacity vs. utilization vs. throughput

These three terms are often used interchangeably and should not be. They answer different questions:

• Capacity — the maximum work the cluster could deliver in a period. Measured in core-hours, node-hours, or license-hours. Example: 200 nodes × 64 cores × 720 hours = 9,216,000 core-hours per month.
• Utilization — the fraction of capacity actually consumed. If 6,500,000 core-hours were allocated, utilization is 70.5%. High utilization is not automatically good: a cluster at 95% utilization has almost no headroom for urgent jobs and long queue times.
• Throughput — the rate of useful completed work: simulations finished per week, or design iterations per sprint. Throughput is what the business actually buys.

The distinction matters because the three can move in opposite directions. Adding nodes raises capacity but may lower utilization if the workload cannot scale. Raising utilization by packing jobs tighter can lower throughput if memory contention slows every job. And a cluster with 60% utilization can have higher throughput than one at 90% if the 60% cluster runs larger, better-scaling jobs.

Reading the metrics together

Consider a concrete example. A cluster has 9,216,000 core-hours of monthly capacity. Last month it allocated 6,500,000 core-hours (70.5% utilization) and completed 1,240 simulations. The engineering team wants 1,800 simulations next month. Adding nodes is one option, but before buying hardware, check the binding constraint: if 340 jobs sat in the queue waiting for license tokens rather than cores, the fix is license scheduling, not capacity. If jobs ran but scaled poorly beyond 64 cores, the fix is solver configuration or interconnect topology. Only after those are addressed does adding capacity raise throughput proportionally.

With this foundation — node anatomy, interconnect limits, storage tiers, scheduler mechanics, and the capacity/utilization/throughput triad — you can now reason about where licenses fit. The next step is mapping solver license behavior onto this model, because a license token is simply another consumable resource that must be co-scheduled with the hardware it enables.