1. CAE solver deployment landscape

CAE (Computer-Aided Engineering) solvers are not generic microservices. Before containerizing them, you must understand three interlocking dimensions: workload characteristics, licensing models, and infrastructure requirements. Getting any one of these wrong produces a platform that either wastes expensive hardware, violates license terms, or fails under real solver load. This chapter establishes the baseline model that every later chapter builds on.

Workload Characteristics

CAE solvers such as Ansys Fluent, Abaqus, OpenFOAM, LS-DYNA, and COMSOL exhibit a workload profile that differs sharply from web services. The dominant traits are:

• Long-running, non-interactive jobs. A single CFD transient case may run for 6–72 hours. The container must survive node reboots, scheduler preemption, and checkpoint/restart cycles.
• MPI-centric parallelism. Most solvers scale via MPI ranks across cores and nodes. Rank-to-core binding, shared memory segments, and interconnect (InfiniBand/RoCE) access are performance-critical.
• Bursty, license-gated concurrency. Jobs cannot start without a license token. A 64-core job may consume 64 HPC tokens simultaneously, so license availability directly caps cluster throughput.
• Heavy I/O and memory footprint. Solver working sets routinely reach tens to hundreds of GB. Scratch I/O can saturate local NVMe or parallel filesystems (Lustre, GPFS, Weka).
• Mixed CPU/GPU execution. GPU-accelerated solvers (e.g., Fluent GPU solver, Altair AcuSolve) require NVIDIA drivers, CUDA runtime, and NCCL, which constrains the container base image.

These traits mean a CAE container is closer to an HPC batch workload than a Kubernetes stateless pod. The container image must bundle the solver binaries, MPI implementation, math libraries (MKL, OpenBLAS), and vendor runtime — but not the kernel driver, which must come from the host.

Licensing Models and Their Container Implications

Licensing is the single most common source of deployment failure. CAE vendors use several models, each with distinct containerization constraints:

The practical rule: never bake license credentials into the image. Inject them at runtime via environment variables or mounted secrets, and ensure the container's network identity (MAC/hostname) is stable enough for FlexLM hostid checks. For floating licenses, the container must reach the license server; for node-locked, you must pin the pod to a specific node.

Infrastructure Requirements

The infrastructure stack must satisfy four layers simultaneously:

1. Compute: CPU pinning (cpuset), hugepages for MPI shared memory, and NUMA-aware scheduling. GPU nodes need the NVIDIA Container Toolkit and matching driver/CUDA versions.
2. Network: RDMA-capable fabric for multi-node MPI. In Kubernetes this means SR-IOV or MacVLAN CNI plugins, plus the MPI operator or a similar launcher.
3. Storage: A parallel filesystem mounted into the container for case data and scratch. Local NVMe for checkpoint staging reduces restart time.
4. Orchestration: Kubernetes with the MPI Operator, Volcano, or Slurm-on-Kubernetes for gang scheduling — all ranks must start together or the job deadlocks.

The diagram below maps how these dimensions interact for a representative multi-node Fluent job.

Putting It Together: A Minimal Validation Checklist

Before scaling to production, validate the platform with a single-node smoke test. The following checklist captures the minimum viable verification for a Fluent-style MPI solver:

With this landscape established — workload shape, license mechanics, and the four infrastructure layers — subsequent chapters can drill into image construction, MPI orchestration, license sidecar patterns, and performance tuning. The key takeaway is that CAE containers are stateful, license-bound, fabric-dependent workloads, and every design decision must respect those three constraints simultaneously.