4. Compute node hardware selection

Explicit crash solvers such as LS-DYNA, Radioss, and Pam-Crash advance the solution with an explicit central-difference time integrator. The stable time step is governed by the smallest element in the mesh and the material wave speed, so the solver performs an enormous number of very cheap element updates rather than a modest number of expensive matrix solves. This single fact reshapes every hardware decision: the workload is latency-tolerant but bandwidth-hungry, scales almost linearly with core count until memory or interconnect saturates, and rarely benefits from the large last-level caches that make implicit FEA or CFD shine. Selecting a compute node for crash CAE therefore means optimizing for sustained memory bandwidth per core, predictable NUMA behavior, and a clock speed high enough to keep the floating-point pipelines fed.

CPU architecture: cores, SIMD width, and memory channels

Modern server CPUs from AMD (EPYC 9004/9005 "Genoa"/"Turin") and Intel (Xeon Scalable "Sapphire Rapids"/"Emerald Rapids") both deliver strong explicit-solver performance, but they differ in how bandwidth is distributed. AMD's chiplet design places 8–16 cores on a Core Complex Die (CCD) with a shared 32 MB L3 slice, and 8–12 CCDs on an I/O die that fans out to 12 DDR5 channels. Intel's monolithic die exposes 8 memory channels and a shared L3 that is partitioned per tile. For explicit crash, the practical metric is bytes per second per core: a 96-core EPYC 9654 with 12 channels of DDR5-4800 provides roughly 460 GB/s, or about 4.8 GB/s per core, which is comfortable. A 128-core part on the same 12 channels drops to 3.6 GB/s per core and can starve the solver during contact-heavy phases.

SIMD width matters because the element kernel is vectorized. AVX-512 (Intel) and AVX2 (AMD) both accelerate the constitutive and hourglass-control loops, but the gain is typically 10–20% rather than 2×, since the kernel is memory-bound. Do not pay a large premium for AVX-512 alone; prioritize memory channels and core count balance instead.

Core frequency and the turbo budget

Explicit solvers are sensitive to single-core frequency because the critical path includes serial sections (contact search setup, time-step recalculation, I/O). A node with a high all-core turbo (3.5–3.7 GHz) will finish a 20 ms crash model noticeably faster than a 2.4 GHz part with more cores, especially when the model has fewer than ~2 million elements. As a rule of thumb, keep the ratio of cores to memory channels at or below 8:1 for DDR5 platforms, and prefer CPUs whose all-core turbo stays within 15% of the single-core turbo. Thermal design power (TDP) is a proxy: 280–400 W parts sustain higher all-core clocks under a well-provisioned cooling solution.

Cache hierarchy: why L3 is not the bottleneck

Crash models stream element data (coordinates, connectivity, stress, strain) through the CPU with little temporal reuse. The working set per core is small—typically a few hundred kilobytes of element state—so L1 and L2 hit rates are high, but L3 is largely a staging buffer for the memory controller. A 32 MB L3 per CCD is sufficient; a 256 MB L3 does not meaningfully improve explicit performance. What does matter is L2 capacity per core (1–2 MB is ideal) and cache latency, which affects the contact and material loops. When comparing CPUs, look at L2/L3 latency benchmarks rather than L3 size alone.

Memory bandwidth and NUMA topology

NUMA is the single most common source of disappointing crash-solver scaling. On a dual-socket node, each socket owns half the DIMMs and half the memory channels. If a process on socket 0 allocates memory that lands on socket 1, every access crosses the inter-socket link (UPI or Infinity Fabric), adding 80–150 ns of latency and consuming link bandwidth. LS-DYNA's hybrid MPI+OpenMP mode is especially vulnerable: MPI ranks pinned to one socket but sharing memory with ranks on the other socket will stall.

The fix is to bind memory and threads to the same NUMA domain. On Linux, use numactl --cpunodebind=0 --membind=0 for a single-socket run, or launch one MPI rank per socket with --membind set to that socket. For OpenMP, set OMP_PROC_BIND=close and OMP_PLACES=cores so threads stay on their home socket. Verify placement with numastat -p <pid>; a healthy run shows nearly all memory allocated on the local node.

Putting it together: a selection checklist

When specifying a crash-CAE compute node, work through the following in order. First, count memory channels and confirm the core-to-channel ratio is at most 8:1. Second, check all-core turbo frequency and ensure it is within 15% of single-core turbo. Third, verify L2 per core is at least 1 MB. Fourth, confirm the platform supports 1 DIMM per channel at the target speed (2 DIMMs per channel often forces a speed drop from 4800 to 4400 MT/s). Fifth, plan NUMA binding in the job script before the node is purchased, because a node that cannot be cleanly partitioned is a node that will not scale.

The diagram above shows the correct binding pattern for a dual-socket crash node. Each MPI rank owns one socket, its OpenMP threads are pinned to that socket's cores, and all memory is allocated locally. The Infinity Fabric link is used only for MPI halo exchange, not for memory traffic. When this pattern is followed, a 4-million-element crash model that runs at 1.0× on a single socket typically reaches 1.8–1.9× on two sockets. When it is violated—ranks sharing memory across sockets—scaling collapses to 1.2–1.4× and the node looks "slow" even though the hardware is fine.

In summary, choose a CPU with a balanced core-to-channel ratio, high all-core turbo, and at least 1 MB L2 per core. Provision 1 DIMM per channel at the highest supported speed. Then treat NUMA binding as a first-class part of the node specification, not an afterthought in the job script. A well-chosen node that is correctly bound will outperform a more expensive node that is left to the operating system's default scheduler.