4. CAE application inventory and dependency mapping

Before a single workload can be moved off an HPC cluster, you must know exactly what is running on it and what each application silently depends on. CAE software stacks are notoriously fragile: a solver binary compiled against one MPI implementation will not link against another, a license daemon pinned to a specific MAC address will refuse connections after migration, and a pre-processor that "works fine" on the login node may fail on compute nodes because a compiler runtime library is missing. Dependency mapping is the discipline of turning that fragility into an explicit, auditable inventory.

The goal of this chapter is not to produce a spreadsheet for its own sake. It is to produce a machine-readable map that answers three questions for every application: What does it need to run? Where does it get those things? What breaks if any of them change? That map then drives migration sequencing, compatibility testing, and rollback planning.

What to Inventory

A CAE application is never a single artifact. It is a bundle of executables, shared libraries, environment modules, license clients, and data-format assumptions. The inventory must capture all of them. The table below shows the categories that matter most in practice, with representative examples from a typical automotive CAE environment.

Each row is a dependency edge. The solver depends on the MPI library; the MPI library depends on the compiler runtime; the license client depends on network reachability to the license server. Mapping these edges explicitly is what separates a controlled migration from a series of outages.

How to Collect the Data

Manual data entry does not scale and is error-prone. Use automated discovery wherever possible, then verify. On a Linux cluster, the following commands produce the raw material for the inventory.

# List loaded modules for a running solver job
module list

# Inspect dynamic library dependencies of a solver binary
ldd /opt/lsdyna/R13.1.1/ls-dyna_smp_d_ss_1311_x86_64_centos79_ifort10.1

# Query MPI version and ABI
mpirun --version
ompi_info --param mpi all --level 9 | head -40

# Check license server reachability and feature availability
lmutil lmstat -a -c 27000@lic-srv01

# Record compiler runtime versions
strings /opt/lsdyna/R13.1.1/ls-dyna_smp_d_ss_1311_x86_64_centos79_ifort10.1 | grep -i "ifort\|gfortran" | head

The ldd output is particularly valuable because it reveals transitive dependencies that are easy to miss. A solver may link against libmpi.so.12 from Intel MPI, which in turn pulls in libfabric.so.1 and libpsm2.so.3. If the target cluster uses a different fabric library, the job will fail at MPI initialization even though the solver binary itself is unchanged.

Building the Dependency Map

A flat inventory is useful, but a dependency map is more powerful because it shows direction and coupling. The SVG below illustrates a representative CAE application dependency graph for a single solver stack. Nodes are components; edges are "requires" relationships. The colors distinguish the layers: solver, MPI, compiler runtime, license, and pre/post tools.

The dashed edges from pre/post tools to solvers represent data exchange rather than runtime linking: ANSA writes a .key or .inp file that LS-DYNA or Abaqus reads. These edges matter because a file-format change in a pre-processor upgrade can break a solver deck even when no binary dependency has changed.

From Map to Migration Plan

Once the dependency map is complete, migration sequencing becomes tractable. The key insight is that dependencies form a directed acyclic graph, and you must migrate in topological order: infrastructure first, then runtime, then applications. If you migrate a solver before its MPI library is available on the target cluster, the job will fail at startup with an error such as:

[proxy:0:0@node01] HYDU_process_mfile_token (../../utils/process/process_cb.c:563): 
unable to find mfile token
[proxy:0:0@node01] HYD_pmcd_pmip_control_cmd_cb (../../pm/pmiserv/pmip_cb.c:912): 
proxy launch failed

This is an MPI launch failure, not a solver failure. The dependency map tells you to check the MPI layer first, not the solver binary. Similarly, a license checkout failure such as Cannot connect to license server points to the infrastructure layer, and a missing libifcore.so.5 points to the compiler runtime layer.

Verification Checklist

After migration, verify each layer independently before running a full production job. The following checklist is ordered from lowest to highest layer, matching the dependency graph.

1. Infrastructure: Confirm lmutil lmstat -a -c 27000@lic-srv01 returns the expected feature count and that the license host is reachable from compute nodes.
2. Compiler runtime: Run ldd on the migrated solver binary and confirm all shared libraries resolve. Check for not found entries.
3. MPI: Execute a minimal MPI program (e.g., mpirun -np 2 hostname) and confirm both ranks launch without fabric errors.
4. Solver: Run a small benchmark deck (e.g., a 10,000-element crash box) and compare wall-clock time and energy balance against the baseline.
5. Pre/post: Open a representative model in the migrated pre-processor, export a solver deck, and confirm the solver reads it without format warnings.

The inventory and dependency map are living artifacts. Every time a solver is patched, an MPI library is upgraded, or a license server is moved, the map must be updated. Treat it as code: version it, review changes, and validate it against the running system. That discipline is what makes the difference between a migration that completes in a weekend and one that drags on for months.