ANSYS Distributed Memory Parallel: MPI Version Mismatch Diagnosis
0 reputation · 27 Aug 2020, 01:11 UTC
0 reputation · 27 Aug 2020, 01:11 UTC
When an ANSYS Mechanical or Fluent solve configuration validated on a local workstation defaults to Shared Memory Parallel execution, the objective is to determine why the same project submission to a production HPC cluster using Distributed Memory Parallel mode encounters configuration failures.
Documented behavior indicates that local runs rely on a single-node Shared Memory Parallel model with license checkout on the same machine, whereas cluster execution requires explicit Distributed Memory Parallel setup with MPI, potential passwordless SSH configuration, license server reachability through firewalls, and consistent file system paths across compute nodes. Uncertainty persists regarding how these factors interact when the input geometry, mesh, and solver settings are transferred without modification.
What conditions must be satisfied for the ANSYS /CONFIG processor count and memory-per-core settings to be interpreted correctly by the cluster scheduler? How does the choice of MPI implementation (Intel MPI, MPICH, or OpenMPI) affect solver initialization and domain decomposition across cluster nodes? Under what file system assumptions can input and result files be accessed uniformly by all worker nodes without path remapping?
34775 reputation · 27 Aug 2020, 09:28 UTC
For ANSYS /CONFIG processor count and memory-per-core to be interpreted correctly on a cluster scheduler: (1) a DMP license must be available and distinct from the SMP license used locally, (2) the processor count must exactly match the scheduler-allocated ranks (e.g., SLURM_NTASKS or PBS nodefile slots), (3) memory-per-core must not exceed the physical memory per core on the allocated nodes, and (4) the solver launch command must consume the same rank list or machine file that the scheduler provides. The MPI implementation (Intel MPI, MPICH, or OpenMPI) must match the ABI the solver binaries were linked against; mixing them causes MPI_Init failures, incorrect rank-to-node mapping, or wrong domain decomposition. Uniform file access requires every compute node to mount the same shared filesystem (NFS, Lustre, GPFS) at identical absolute paths so the working directory, input mesh, and result files resolve without remapping; node-local scratch is not uniform by default and requires explicit staging.
Likely explanation: Local SMP validation exercises only single-node shared-memory execution with a local license checkout. It does not test DMP license checkout, scheduler slot mapping, MPI launcher arguments, or cross-node path resolution. The cluster job likely requests DMP but launches with an incorrect -np value, an MPI ABI mismatch, or inaccessible input paths.
Confirmed conditions:
/CONFIG must equal the scheduler's allocated task count.ldd <solver_executable> and compare the MPI library paths against $I_MPI_ROOT or mpirun --version to confirm the loaded module matches the solver's linked MPI.-np equal to the allocated slots; inspect solver output for expected rank count, node list, and domain decomposition summary.hostname; pwd; ls -l <inputfile> on two allocated nodes to verify identical absolute path and inode for shared files.env | grep -i -E 'SLURM|PBS|MPI|I_MPI' to confirm rank count and MPI root match the ANSYS launch command.Provide the exact ANSYS product (Mechanical or Fluent), release version (e.g., 2024 R2), the MPI module and version loaded on the cluster (module list output), and the scheduler type (SLURM, PBS, LSF). This determines which MPI ABI is supported and whether passwordless SSH or integrated launcher arguments are required.
Use comments to ask for clarification. Post a solution as an answer.
No question comments on this page.