How to Build HPC Clusters for Ansys Mechanical

For organizations using Ansys Mechanical, a well-designed HPC (high-performance computing) cluster can help reduce solve times, handle larger finite element analysis (FEA) models, and increase simulation throughput. However, building an effective cluster requires engineers and IT administrators to balance CPU performance, memory capacity, network bandwidth, storage, solver configuration, software licensing, and workload scheduling. This guide explains how to plan, size, configure, and optimize an HPC cluster for Ansys Mechanical, from hardware selection to distributed solving and deployment.

1. Determine Whether You Need a Cluster

Before selecting hardware, identify the problem you want HPC to solve. An HPC cluster can accelerate individual simulations, support larger models, or run multiple jobs concurrently, but each goal places different demands on the infrastructure.

Start by reviewing three workload characteristics.

Model size: Large finite element models can require substantial RAM to assemble and solve their systems of equations. Memory capacity often determines whether a model fits in memory or requires slower out-of-core solving.
Solver behavior: Different solver types scale differently across CPU cores and compute nodes. A solver that performs well on a single workstation may not produce similar acceleration when distributed across a cluster.
Simulation throughput: If engineers regularly run design studies, optimization loops, or multiple independent load cases, scheduling several jobs across available compute nodes may provide more value than dedicating the entire cluster to one simulation.

Workstation vs. HPC Cluster

A workstation may be sufficient when engineers run relatively small models or need interactive access to simulation tools. A cluster becomes more attractive when workloads exceed a single machine's practical compute or memory capacity, or when multiple engineers need access to shared compute resources.

Requirement	Workstation	HPC cluster
Compute resources	One machine	Multiple compute nodes, where needed
Memory	Limited to installed system RAM	Each node has its own RAM; distributed solving can use resources across nodes
Scaling	Primarily within one machine	Within nodes and, for supported workflows, across nodes
Job Scheduling	Local execution or background runs	Centralized queues and resource allocation
Infrastructure	Simpler to administer	Requires additional networking, storage, software, and administration

A cluster does not automatically make every simulation faster. For some models, a well-configured single node can outperform a multi-node setup because distributed solving introduces communication overhead. Benchmark representative models before committing to a large cluster.

2. Select the HPC Cluster Architecture

Once you understand the workload, choose an architecture that fits the required compute resources and operating model. Most Ansys Mechanical HPC deployments fall into two broad categories: a single powerful compute node or a multi-node cluster.

Single-Node HPC

A single-node configuration uses a server with multiple CPU cores, substantial RAM, and fast local storage. It can be a practical starting point for large simulations that benefit from shared-memory processing without requiring communication between multiple machines.

Consider this architecture when:

Most simulations fit within one node's memory capacity.
The solver scales effectively across the node's available cores.
You want to simplify network and cluster administration.
Multi-node communication would provide limited performance gains.

Multi-Node HPC

A multi-node cluster connects several compute servers so supported distributed-memory solvers can use resources across the nodes. Each node has its own CPU, RAM, and local resources. The nodes communicate through a network interconnect while the solver distributes parts of the computation across participating processes.

Multi-node configurations are useful when a workload benefits from additional compute resources, distributed memory, or greater overall job capacity. However, additional nodes introduce network, storage, and administration requirements. Solver compatibility, model size, communication overhead, and resource balance impact performance.

Cloud-Based HPC

Cloud infrastructure offers another deployment option. Teams can provision compute resources when needed rather than purchasing and maintaining all cluster hardware themselves.

Ansys documents an AWS-based deployment workflow using Ansys Remote Solve Manager (RSM) clusters. The process includes selecting the operating system and cluster package, configuring licensing and working directories, choosing node types, and specifying the number of compute nodes.

For Mechanical workloads, Ansys recommends Elastic Fabric Adapter (EFA)-enabled instances for multi-node clusters in this deployment workflow. The specific instance families listed in that guide are deployment-specific; check current AWS availability and Ansys compatibility before selecting a configuration.

3. Size CPU Resources for Ansys Mechanical

CPU selection should balance core count, per-core performance, memory bandwidth, and licensing. A processor with more cores can increase parallel compute capacity, but it will not necessarily deliver proportional reductions in solve time. The solver must be able to use the additional cores effectively, and the rest of the system must supply data fast enough to keep them occupied.

Core Count and Clock Speed

Higher core counts can benefit simulations with sufficient parallel work. Clock speed also matters, particularly when some operations do not scale well across additional cores.

When comparing server CPUs, benchmark the types of analyses your engineers actually run. Consider the time spent assembling matrices, solving equations, and calculating results rather than relying solely on published core counts.

Memory Bandwidth

Memory bandwidth determines how quickly processors can access data in RAM. Structural solvers can become constrained by memory bandwidth, so a CPU with many cores may underperform if the memory subsystem cannot keep those cores supplied with data.

Physical Cores and Hyper-Threading

Do not assume that logical CPU counts represent the number of cores Ansys can use most effectively. Hyper-Threading or simultaneous multithreading may provide benefits for some workloads, but those benefits depend on the solver and configuration.

The Ansys cloud cluster guide states that hyper-threading is automatically disabled for the HPC nodes in its documented deployment. For other environments, confirm the recommended configuration for your Ansys release and benchmark accordingly.

4. Calculate RAM Requirements

Memory capacity is one of the most important factors in cluster sizing because it affects which models you can solve and how efficiently they run.

Finite element analysis memory requirements depend on several factors, including:

Degrees of freedom (DOF): Larger models generally require more memory, although the relationship varies with the solver and model formulation.
Solver type: Sparse direct, iterative, and eigenvalue solvers have different memory requirements.
Element formulation and analysis settings: Contact, nonlinear behavior, and other modeling choices can change computational and memory demands.
Result storage: Transient analyses and requests for extensive result output can increase storage and I/O requirements.

There is no universal RAM-per-million-DOF ratio that applies to every Mechanical simulation. Use memory measurements from representative models to estimate capacity, then allow headroom for solver workspace, operating-system needs, and concurrent jobs.

Avoid Out-of-Core Performance Bottlenecks

When a simulation cannot keep the data it needs in physical memory, the solver may use disk-based storage for some operations. This can increase I/O and substantially extend solve time.

For that reason, do not size a cluster around CPU core count alone. A system with more cores but insufficient RAM may deliver worse performance than a smaller, properly balanced configuration.

5. Configure High-Speed Networking and Storage

Networking and storage become especially important when simulations span multiple compute nodes.

Network Interconnects

Distributed-memory solving uses message passing to exchange data between processes. The network therefore affects how efficiently compute nodes coordinate their work.

For multi-node configurations, evaluate:

Bandwidth: The amount of data the interconnect can transfer.
Latency: The delay involved in communicating between nodes.
Network compatibility: The interconnect, drivers, MPI implementation, and cluster software must work together.
Solver communication patterns: Some simulations exchange more data between processes than others.

Shared File Storage

Cluster nodes need a consistent way to access input files, working directories, and completed results. Shared network storage can provide this access without requiring engineers to manage separate copies of project data on each node.

The Ansys cloud deployment guide supports a shared Network File System (NFS) working directory as an option. It also describes using storage on the cluster's head node as a staging directory instead. The appropriate choice depends on the deployment's availability, performance, and data-management requirements.

Local Scratch Storage

Local NVMe storage can help when a solver generates substantial temporary data or performs frequent disk operations. Separate high-performance scratch storage from long-term project storage when the workload warrants it.

For best results, measure I/O performance during representative solves. A fast network alone will not eliminate a storage bottleneck, and fast storage cannot compensate for insufficient memory or poor solver scaling.

6. Configure Ansys Mechanical Parallel Processing

Once the hardware is available, configure the software to use the intended compute resources. Ansys offers shared-memory parallel processing and distributed-memory parallel processing. The correct option depends on the solver, analysis type, and cluster architecture.

Shared-Memory Parallel Processing (SMP)

SMP uses multiple CPU cores that share a single memory address space. It is commonly used on a workstation or a single compute node. SMP can be an effective choice when the simulation fits within one node's RAM and scales well across its cores.

Distributed-Memory Parallel Processing (DMP)

DMP uses multiple solver processes that communicate through the Message Passing Interface (MPI). It can run on a single multi-core machine or across multiple nodes in a cluster.

For supported Mechanical APDL analyses, DMP can distribute solution work across processes and make use of resources on multiple machines. However, not every analysis type, solver option, or feature supports distributed processing. Some operations may fall back to shared-memory processing or require a different configuration.

Engineers should verify that the specific solver and analysis are supported for distributed execution before planning around multi-node scaling.

Remote Solve Manager (RSM)

Remote Solve Manager provides a way to submit supported Workbench and Mechanical jobs to remote compute resources.

A typical RSM workflow involves:

Configuring the remote cluster and its job queue.
Defining the appropriate solve process settings.
Selecting the RSM queue for the Mechanical job.
Configuring the maximum number of cores and whether distributed solving is permitted.
Submitting the solution and retrieving results when the job completes.

7. Set Up MPI and Job Scheduling

For multi-node solving, the MPI implementation and scheduler must be configured consistently with the Ansys environment. MPI enables solver processes to communicate across compute nodes. The scheduler manages resource allocation, queueing, job execution, and completion.

Common scheduler integrations documented by Ansys RSM include Windows HPC, LSF, PBS Pro, SLURM, and UGE (SGE), alongside Ansys RSM cluster configurations. Availability depends on the deployment and release.

On a Linux HPC system, engineers may submit non-interactive jobs through a scheduler such as SLURM. A job script typically specifies the required resources, working directory, software environment, and solver command. The exact command-line arguments depend on whether the job uses Mechanical APDL or another supported workflow.

8. Plan for Ansys Licensing

Licensing should be part of the cluster design from the beginning. A cluster's physical capacity does not determine how many cores a simulation can use; the available Ansys license entitlements and configuration also matter.

Review the following before purchasing hardware or provisioning cloud resources:

Solver core limits: Determine how many cores your license permits for the intended workload.
HPC entitlements: Verify which HPC products or increments are required for the target core count and solver.
Concurrent jobs: Estimate how many licenses are needed when multiple simulations run simultaneously.
Remote execution: Confirm the licensing requirements for the client, remote solve environment, and selected cluster workflow.
GPU acceleration: If you intend to use supported GPU solver features, verify the relevant hardware and licensing requirements.

9. Benchmark and Optimize Cluster Performance

After configuring the cluster, validate it with representative Mechanical simulations before moving production workloads to it. A structured benchmark helps identify whether the main constraint is compute, memory, storage, network communication, or software configuration.

Establish a Baseline

Run a representative model on a single node and record its solve time, memory usage, and I/O behavior. This gives you a reference point for comparing larger configurations.

Increase Core Counts Gradually

Repeat the same model with different core counts. Measure elapsed time rather than assuming more cores will always improve performance.

Compare Single-Node and Multi-Node Solving

If the analysis supports DMP, compare a single-node configuration with a multi-node configuration. The results will show whether the workload benefits from additional nodes after accounting for communication overhead.

Monitor Memory and Storage

Check whether the solver approaches available RAM capacity or spends significant time performing disk I/O. If memory or storage limits performance, adding more CPU cores may provide little benefit.

Test Concurrent Workloads

If the cluster will serve multiple engineers, benchmark multiple jobs running at the same time. This helps establish practical queue policies and resource allocations without allowing a single simulation to monopolize the system.

Common Mistakes When Building Ansys Mechanical HPC Clusters

Several common design mistakes can reduce the return on an HPC investment.

Buying too many CPU cores: More cores do not guarantee proportional speedup, particularly when solver scaling or licensing limits become a constraint.
Underestimating RAM: Insufficient memory can restrict model size and lead to expensive disk I/O.
Ignoring network performance: Multi-node configurations can lose efficiency when the interconnect cannot support the solver's communication demands.
Using unsuitable storage: Slow scratch storage or shared-file bottlenecks can extend solve times.
Assuming every solver supports DMP: Distributed execution has solver- and analysis-specific limitations.
Overlooking licensing: Hardware capacity is useful only when the available entitlements support the intended parallel workload.
Skipping benchmarks: Without testing representative models, teams cannot reliably determine whether additional nodes will improve performance.

Building an effective HPC cluster for Ansys Mechanical requires a balanced approach to compute, memory, networking, storage, software configuration, and licensing. Start with the models and workloads your team needs to solve. Use those requirements to decide between a powerful single node, a multi-node cluster, or cloud-based compute. Then validate the architecture with representative simulations, paying attention to memory use, I/O, solver compatibility, and scaling efficiency.