Simulation Software on HPC Clusters

---

Running simulation software on HPC clusters means connecting to a shared university computer over SSH, writing a job script for a scheduler called SLURM, and submitting your ANSYS, Abaqus, or COMSOL run to a queue instead of running it directly on your laptop. This guide covers the actual commands for simulation software on HPC clusters, not just the concept.

Simulation software on HPC clusters — the quick answer:

• SSH is how you connect to the cluster: ssh yourusername@cluster.university.edu.
• SLURM is the job scheduler nearly every university cluster runs. You submit a script with sbatch myjob.sh, check its status with squeue -u yourusername, and cancel it with scancel <job_id>.
• module load <software>/<version> loads the specific version of ANSYS, Abaqus, or COMSOL your job needs before it runs.
• Each of the three major simulation tools has its own batch command syntax, covered with real examples below.

By the Engicompass Team · Last updated: August 2026

What are HPC clusters actually for?

A university HPC (high-performance computing) cluster is a shared pool of powerful computers, accessed remotely, built for jobs too large or too slow for a personal laptop. Instead of running ANSYS on your own machine for six hours, you submit the same job to the cluster, where it runs on dedicated hardware while you do something else entirely.

The trade-off is real: you don’t get instant results. Your job waits in a queue, managed by a scheduler, until enough compute resources free up. For a simulation that would otherwise take days on a laptop, a queue wait of a few hours is still a clear win.

What are the basic SSH and SLURM concepts?

SSH (Secure Shell) is how you connect to the cluster’s login node from your own computer. The basic command is:

ssh yourusername@cluster.university.edu

You’ll be prompted for your password, or in many setups, an SSH key does this automatically. Once connected, you’re working directly on the cluster’s login node — a shared machine meant for light tasks like editing files and submitting jobs, not for running your actual simulation.

SLURM (Simple Linux Utility for Resource Management) is the job scheduler that decides when and where your job actually runs. You never run a heavy simulation directly on the login node. Instead, you write a batch script and hand it to SLURM.

A basic SLURM script looks like this:

bash

#!/bin/bash
#SBATCH --job-name=my_simulation   # a label for this run
#SBATCH --nodes=1                  # how many machines to use
#SBATCH --ntasks=8                 # how many parallel processes
#SBATCH --time=04:00:00            # job gets killed after this long
#SBATCH --output=result_%j.out
#SBATCH --error=result_%j.err

module purge
module load ansys/2024R1

# Your actual job command goes here

The module purge and module load lines set up the software environment, since clusters host many software versions side by side and won’t load one automatically.

Three commands cover most of what you’ll need day to day. Submit a job by running sbatch myjob.sh. Once it’s queued or running, check on it with squeue -u yourusername, which lists your jobs and their current state. If something’s wrong and you need to stop it, scancel <job_id> ends it right away, using the job ID that squeue just showed you.

How do you run ANSYS on a cluster?

ANSYS on a cluster typically runs through its command-line batch mode, called MAPDL, or through Fluent for fluid dynamics work. Here’s a real, working SLURM script for a basic ANSYS MAPDL job:

bash

#!/bin/bash
#SBATCH --job-name=ansys_test
#SBATCH --nodes=1
#SBATCH --ntasks=16
#SBATCH --time=04:00:00
#SBATCH --output=ansys_%j.out

module purge
module load ansys/2024R1

ansys232 -b -i inputfile.inp -o outputfile.out

The -b flag runs ANSYS in batch mode, without a graphical interface. -i and -o specify your input and output files. For distributed jobs across more cores, add -dis -mpi openmpi -np $SLURM_NTASKS to spread the work using SLURM’s own task count.

Running ANSYS Fluent specifically uses a different command, built around a journal file:

bash

module load ansys/2024R1
fluent 3ddp -g -t$SLURM_NTASKS -i fluent.jou -o fluent.out

3ddp specifies 3D double-precision. -g disables the graphical interface. -t$SLURM_NTASKS tells Fluent how many processes to use, pulling that number directly from your SLURM job’s resource request rather than hardcoding it.

How do you run Abaqus on a cluster?

Abaqus uses a simpler, more direct command-line syntax than ANSYS:

bash

#!/bin/bash
#SBATCH --job-name=abaqus_test
#SBATCH --nodes=1
#SBATCH --ntasks=8
#SBATCH --time=04:00:00
#SBATCH --output=abaqus_%j.out

module purge
module load abaqus/2024

abaqus job=myjob input=myinput.inp cpus=8

job= names the run. input= points to your input file. cpus= sets how many cores Abaqus uses, which should match the --ntasks value in your SLURM directives above it — mismatching these two numbers is a common, avoidable source of wasted allocation.

How do you run COMSOL on a cluster?

COMSOL’s batch syntax centers on two flags: -inputfile and -outputfile, plus a scheduler flag when running under SLURM specifically:

bash

#!/bin/bash
#SBATCH --job-name=comsol_test
#SBATCH --nodes=1
#SBATCH --ntasks=16
#SBATCH --time=04:00:00
#SBATCH --output=comsol_%j.out

module purge
module load comsol/6.3

comsol batch -mpibootstrap slurm -inputfile model.mph -outputfile results.mph

The -mpibootstrap slurm flag tells COMSOL to coordinate directly with SLURM for multi-node runs, rather than managing its own process distribution. For a parametric sweep — running the same model across several values of one variable — COMSOL supports this directly from the command line:

bash

comsol batch -inputfile model.mph -outputfile out.mph -pname L -plist 8[cm],10[cm],12[cm]

This runs the study three times, once for each listed value of the parameter L, without needing three separate job scripts.

What are the most common problems running simulation software on HPC clusters?

“Command not found” after loading a module. Run module avail to see exactly which versions are installed, since your script’s version string has to match exactly. module load ansys/2024R1 fails silently different from module load ansys/2024r1 on some clusters — capitalization matters.

Job stays pending in the queue far longer than expected. Run squeue -u yourusername and check the REASON column. Priority means you’re waiting your turn normally. Resources means the cluster is genuinely full. ReqNodeNotAvail usually means your job is requesting more resources than any available node actually has — check your --nodes and --ntasks values against your cluster’s documented limits.

Job fails immediately with no useful error. Check both the .out and .err files your script generated — the real error is very often in the .err file, not the general output. A mismatched cpus= value against --ntasks, or a typo in a file path, are the two most common causes.

ANSYS or COMSOL license errors. Most university clusters share a limited pool of floating licenses across the whole department. A “license not available” error often just means someone else’s job is using the last one — check with your department’s HPC support on current license availability before assuming your script is broken.

Common mistakes to avoid when running simulation software on HPC clusters

Running a heavy simulation directly on the login node instead of submitting it through SLURM. Login nodes are shared, lightweight machines. A large job run here slows down everyone else connected to the cluster, and most universities actively monitor for and kill processes doing this.

Forgetting module purge before module load. Without it, leftover modules from a previous session can conflict with the one you’re trying to load, causing confusing version-mismatch errors that have nothing to do with your actual job.

Mismatching your software’s core count against your SLURM resource request. If your Abaqus cpus= value or your Fluent -t value doesn’t match --ntasks in your SBATCH directives, you either waste allocated cores or fail to get the parallelism you requested.

Not checking your cluster’s specific documentation before assuming these examples work as-is. Every university cluster configures partitions, module names, and default limits slightly differently. Treat these scripts as a real, working starting point, not a universal template that needs zero adjustment.

FAQ

Do I need to know Linux to use an HPC cluster? Basic command-line comfort helps a lot, but you don’t need deep Linux expertise. Connecting via SSH, navigating directories with cd and ls, and editing a script with a simple text editor covers most of what day-to-day cluster use actually requires.

How do I know which SLURM partition to use? Run sinfo to see all available partitions and their current status. Your university’s HPC documentation almost always specifies which partition to use for which kind of job — check that first rather than guessing.

Can I run ANSYS Workbench’s graphical interface on the cluster? Some clusters support this through X11 forwarding or a remote desktop tool, but it’s slower and less reliable than batch mode. For real production runs, batch mode with a proper input file is the standard, faster approach.

What happens if my job runs out of time before finishing? SLURM kills it at the --time limit you specified, and any unsaved progress is lost unless your software supports checkpointing. Estimate generously, and consider running a short test job first to gauge actual runtime before committing to a long production run.