2. Linux HPC cluster architecture for MADYMO

MADYMO is a nonlinear finite element and multibody solver used heavily in automotive occupant safety. A single frontal impact model with a detailed dummy, airbag, seatbelt, and trimmed body structure can easily require tens of CPU cores and tens of gigabytes of RAM for several hours. Running such models on a workstation is possible but inefficient; production teams therefore deploy MADYMO on a Linux HPC cluster. Understanding the cluster's architecture is a prerequisite for writing correct job scripts, choosing the right queue, and diagnosing performance problems. This section describes the five architectural layers that matter most in an automotive CAE environment: compute nodes, head (login) nodes, the interconnect, shared storage, and the job scheduler.

Compute Nodes

Compute nodes are the workers that actually execute the MADYMO solver. In a typical automotive cluster they are rack-mounted, diskless or minimally provisioned servers, often 2U chassis with two sockets. A representative node might carry 2 × AMD EPYC 9654 (96 cores each, 192 physical cores total) or 2 × Intel Xeon Platinum 8468, with 512 GB to 1 TB of DDR5 memory and a local NVMe scratch disk of 1–4 TB. MADYMO's SMP (shared-memory) and MPP (massively parallel processing) executables both run on these nodes; SMP uses threads within one node, while MPP uses MPI ranks that may span multiple nodes.

The key sizing rule is memory per core, not total memory. A full-vehicle model with a finely meshed dummy may need 4–8 GB per MPI rank. If a node has 192 cores but only 512 GB RAM, you cannot fill all cores with a memory-hungry model. CAE administrators therefore publish a "memory per core" guideline, and the scheduler enforces it. Nodes are usually grouped into queues or partitions by hardware generation, so that a job requesting 64 cores lands on a homogeneous set of nodes and does not suffer from the slowest member.

Head Nodes and Login Nodes

Head nodes (also called login or submit hosts) are the entry point for users. They run the SSH daemon, the scheduler client, the shared filesystem client, and the module system (typically environment-modules or Lmod). Users edit input decks, compile user subroutines, and submit jobs here. Head nodes are deliberately not used for solving: a runaway MADYMO process on a login node degrades interactive response for everyone. Most sites enforce this with CPU and memory limits via cgroups or PAM, and some disable direct solver execution entirely.

In larger installations there may be separate nodes for different functions: a dedicated license server node for MADYMO's FlexLM daemon, a visualization node with a GPU for post-processing, and a data-transfer node for staging results to the site's PLM or CAE data management system. Keeping these roles separate simplifies firewall rules and prevents a single overloaded host from blocking the whole workflow.

Interconnect

The interconnect determines how well MADYMO MPP scales beyond a single node. Two families dominate automotive clusters: InfiniBand (IB) and high-speed Ethernet (RoCEv2 or 100/200 GbE). InfiniBand HDR (200 Gb/s) or NDR (400 Gb/s) with a fat-tree or dragonfly+ topology is the common choice for tightly coupled CAE. Latency matters more than raw bandwidth for MADYMO's domain decomposition, because each MPI rank exchanges boundary data with its neighbors every time step. A cluster with 100 GbE but 20 µs latency will scale worse than one with HDR IB at 1.5 µs, even if peak bandwidth is similar.

For a job spanning multiple nodes, the scheduler must place ranks on nodes connected by the shortest path. Modern schedulers (Slurm with topology/tree or topology/block) do this automatically, but the administrator must configure the switch topology correctly. A common symptom of misconfiguration is that a 4-node job runs slower than a 2-node job, because ranks were placed across an oversubscribed uplink.

Shared Storage

MADYMO jobs read input decks, write restart files, and produce d3plot-style output and MADYMO result files. All of this must be visible from every compute node, so a shared parallel filesystem is mandatory. Three options are common:

• Lustre — mature, widely deployed, good for large sequential writes; metadata performance can be a bottleneck with many small files.
• GPFS / IBM Storage Scale — strong metadata handling, often used where CAE data management is integrated.
• BeeGFS — easier to deploy, popular in mid-size clusters.

Regardless of the product, the practical rule is: never run MADYMO with its working directory on NFS. NFS locking and small-write performance collapse under parallel I/O. Instead, stage the job to node-local NVMe scratch, run there, and copy results back to the shared filesystem at the end. Slurm supports this pattern with --tmp or a prolog/epilog script. A typical staging script looks like:

#!/bin/bash
#SBATCH --job-name=madymo_frontal
#SBATCH --partition=epyc192
#SBATCH --nodes=2
#SBATCH --ntasks-per-node=48
#SBATCH --mem=0
#SBATCH --time=08:00:00
#SBATCH --tmp=800G

module load madymo/2023.1
module load intelmpi/2021.9

export MADYMO_SCRATCH=/scratch/$SLURM_JOB_ID
mkdir -p $MADYMO_SCRATCH
cp $SLURM_SUBMIT_DIR/frontal_50kmh.xml $MADYMO_SCRATCH/
cd $MADYMO_SCRATCH

mpirun -np $SLURM_NTASKS madyamo_mpp -np $SLURM_NTASKS frontal_50kmh.xml

cp *.d3plot *.madymo $SLURM_SUBMIT_DIR/

Note the use of --mem=0, which tells Slurm to allocate all memory on each node; this is safe only when the scheduler's memory-per-core policy is enforced elsewhere. The --tmp directive requests node-local scratch, and the epilog cleans it up.

Job Schedulers

The scheduler is the cluster's traffic controller. In automotive CAE, three schedulers dominate: Slurm, PBS Professional, and LSF. Slurm is the most common in new installations because it is open source, has a clean REST API, and integrates well with Lustre and InfiniBand. PBS Pro and LSF remain in sites with long-standing vendor relationships or where CAE-specific integrations (for example, Altair PBS Works with HyperWorks) are already in place.

For MADYMO, the scheduler must support MPI job launch, memory and core accounting, and fair-share or priority queues. A typical queue layout separates short debug jobs (1 node, 30 minutes), normal production (up to 8 nodes, 24 hours), and long-running jobs (up to 32 nodes, 7 days). Licenses are a shared resource: MADYMO's FlexLM tokens must be reserved or the scheduler will start more jobs than the license allows, causing immediate failures. Slurm handles this with --licenses=madymo:4 or a licenses resource in the partition definition.

Putting It Together

The diagram below shows how the five layers connect in a representative automotive cluster. A user submits from a login node; the scheduler places the job on compute nodes; the interconnect carries MPI traffic; shared storage provides input and output; and the license server authorizes the run.

With this architecture in mind, the next practical question is how to translate a MADYMO model into a job script that the scheduler will accept and that the cluster will run efficiently. That mapping — core count, memory, queue selection, and MPI launch — is the subject of the following section.