Ansys/fr
TRANSLATOR'S NOTE FROM JULY 2026: This page is currently being reviewed.
Ansys is a software suite for engineering simulation and 3-D design. It includes packages such as Ansys Fluent and Ansys CFX.
Licensing
The Alliance is a hosting provider for Ansys. This means that we have the software installed on our clusters, but we do not provide a generic license accessible to everyone. However, many institutions, faculties, and departments already have licenses that can be used on our clusters. Once the legal aspects are worked out for licensing, there will be remaining technical aspects. The license server on your end will need to be reachable by our compute nodes. This will require our technical team to get in touch with the technical people managing your license software. In some cases, this has already been done. You should then be able to load the Ansys module, and it should find its license automatically. If this is not the case, please contact our technical support to arrange this.
Configuring your license file
Our module for Ansys is designed to look for license information in a few places. One of those places is your /home folder. You can specify your license server by creating a file named $HOME/.licenses/ansys.lic as shown below. Customize the file by replacing FLEXPORT and LICSERVER with the appropriate values for your server.
| setenv("ANSYSLMD_LICENSE_FILE", "FLEXPORT@LICSERVER") |
The following table provides established values for the SHARCNET license server.
| License | System/Cluster | LICSERVER | FLEXPORT | NOTES |
|---|---|---|---|---|
| SHARCNET | Nibi/Fir/Narval/Rorqual/Trillium | license1.computecanada.ca
|
1055
|
currently operational |
Local license servers
Before a local institutional Ansys license server can be used on our clusters, firewall changes will need to be done on both the server and the cluster sides. For many Ansys servers, this work has already been done and they can be used by following the steps in the Ready to use section below. For Ansys servers that have never been used on our clusters, an additional step must be done as shown in the Setup required section also below.
Ready to use
To use a local institutional Ansys license server with an Alliance cluster whose network/firewall connections have already been set up, contact your Ansys server administrator and get the following pieces of information for the license server
1) the Ansys flex port (FLEXPORT) number, commonly 1055 2) the fully qualified hostname (LICSERVER)
Now, configure your ~/.licenses/ansys.lic file by plugging in the values, and you are done.
Setup required
To use a local Ansys license server with an Alliance cluster whose network/firewall connection have never been set up before, you will also need to get the following from your ANSYS server administrator:
3) the statically configured Ansys vendor port (VENDPORT) number.
Send items 1 → 3 by email to technical support and mention which Alliance cluster you want to run Ansys jobs on. An Alliance system administrator will then open the outbound cluster firewall (if necessary) so license checkout requests can reach your license server from the cluster's compute nodes. A range of IP addresses (known as cluster NAT nodes) will then be sent back to you. Give these IP addresses to your local network administrator and request the local server firewall FLEXPORT and VENDPORT ports be opened to allow connections from all of them. Also ask the administrator to check that the line containing SERVER <servername> <host id> <lmgrd port> found at the top of the Ansys license file contains either LICSERVER or IP_ADDRESS for the <servername> value as this must be resolvable from the remote cluster.
Checking out a license
To test if your ansys.lic is configured and working properly with your license server, run the following sequence of commands on the cluster where you will be submitting jobs.
[login-node:~] cd /tmp
[login-node:/tmp] salloc --time=1:0:0 --mem=1000M --account=def-YOURUSERID
[compute-node/tmp] module load StdEnv/2023; module load ansys/2025R2.04
[compute-node:/tmp] $EBROOTANSYS/v$(echo ${EBVERSIONANSYS:2:2}${EBVERSIONANSYS:5:1})/licensingclient/linx64/lmutil lmstat -c $ANSYSLMD_LICENSE_FILE | grep "ansyslmd: UP" 1> /dev/null && echo Success || echo Fail
Success output indicates license checkouts should work when jobs are submitted to the queue.
Fail output indicates a problem with the licensing setup somewhere, and jobs will likely fail.
If there is an Ansys license server checkout problem, the following message will appear in Slurm output files when Fluent jobs are started by Slurm scripts in the queue *OR* when Fluent is started interactively, simply by doing the following:
[compute-node:/tmp] fluent -g 2d -n 2
Connected License Server List: <Shared_Web_License_Server> Hit return to exit.
Version compatibility
Ansys simulations are typically forward compatible, but NOT backward compatible. This means that simulations created using an older version of Ansys can be expected to load and run fine with any newer version. For example, a simulation created and saved with ansys/2022R2 should load and run smoothly with ansys/2023R2. but NOT the other way around. While it may be possible to start a simulation running with an older version, random error messages or crashing will likely occur. Regarding Fluent simulations, if you cannot recall which version of Ansys was used to create your case file, try grepping it as follows to look for clues:
$ grep -ia fluent combustor.cas
(0 "fluent15.0.7 build-id: 596")
$ grep -ia fluent cavity.cas.h5
ANSYS_FLUENT 24.1 Build 1018
Platform support
Ansys provides detailed platform support information describing software/hardware compatibility for the current and previous releases. This is of special interest since it shows which packages are supported under Windows, but not under Linux, and thus not on the Alliance clusters (e.g., SpaceClaim).
What's new
Information for the latest Ansys release can be found here (Ansys 2026 R1, as of May 2026). Posts for previous releases can be found on the Ansys blog and then scrolling down to the FILTERS search bar. Inputting for example What’s New Fluent 2024 GPU should pull up a document containing the latest GPU support information for that release. The Press Release search bar is also a good way to find release-specific information.
Service packs
Starting with Ansys 2024, a separate Ansys module will appear on the clusters with a decimal and two digits following the release number whenever a service pack is installed over the initial release. For example, the initial 2024 release with no service pack applied may be loaded with module load ansys/2024R1 while a module with service pack 3 applied will be loaded with module load ansys/2024R1.03. If a service pack is already available by the time a new release is to be installed, only a module for that service pack number will most likely be installed, unless a request to install the initial release is also received.
Most users will likely want to load the latest module version equipped with the latest installed service pack, which can be achieved with module load ansys. While it's not expected service packs will impact numerical results, the changes they make are extensive and so, if computations have already been done with the initial release or an earlier service pack, some groups may prefer to continue using it. Having separate modules for each service pack makes this possible. Starting with Ansys 2024R1, a detailed description of what each service pack does can be found by searching this link for Service Pack Details. Future versions will presumably be similarly searchable by manually modifying the version number.
Cluster batch job submission
Plusieurs implémentations MPI incluses dans la suite Ansys permettent le calcul parallèle, mais aucune n'est compatible avec l'ordonnanceur Slurm (voir Exécuter des tâches). Pour cette raison, il faut utiliser des directives particulières à chaque paquet Ansys pour lancer une tâche parallèle. Vous trouverez ci-dessous quelques scripts de soumission pour ce faire. Ils fonctionneront sur toutes les grappes, mais sur Trillium, vous devrez peut-être faire certains ajustements.
Fluent
La procédure suivante est habituellement utilisée pour exécuter Fluent sur nos grappes :
- Sur votre ordinateur, préparez votre tâche avec Fluent du Ansys Workbench jusqu'au point où les calculs seraient exécutés.
- Exportez le fichier de cas avec File > Export > Case… ou localisez le répertoire dans lequel Fluent enregistre les fichiers pour votre projet. Le nom des fichiers de cas a souvent un format tel que FFF-1.cas.gz.
- Si vous voulez poursuivre avec des données d'un calcul effectué précédemment, exportez aussi un fichier de données avec File > Export > Data… ou trouvez-le dans le même répertoire /project (FFF-1.dat.gz).
- Transférez le fichier de cas (et le fichier de données s'il y a lieu) dans le système de fichiers /project ou /scratch. Quand les fichiers sont exportés, sauvegardez-les avec des noms plus faciles à repérer que FFF-1.* ou renommez-les au téléversement.
- Créez un fichier de journalisation dont le but est de charger les fichiers de cas (et le fichier de données s'il y a lieu), lancer le solveur et enregistrer les résultats. Voyez les exemples ci-dessous et n'oubliez pas d'ajuster les noms des fichiers et le nombre d'itérations.
- S'il arrive fréquemment que les tâches ne démarrent pas en raison d'un manque de licence (et que de les soumettre de nouveau manuellement ne convient pas), vous pouvez modifier votre script pour que votre tâche soit remise en file d'attente (au plus 4 fois) comme c'est le cas pour le script sous l'onglet Plusieurs nœuds (par cœur + remise en attente) plus loin. Cependant, ceci remet aussi en attente les simulations qui ont échoué pour d'autres raisons que l'absence de licence (par exemple la divergence), gaspillant ainsi du temps de calcul. Il est donc fortement recommandé de vérifier les fichiers de sortie de l'ordonnanceur pour savoir si chaque tentative de remise en attente est ou non due à un problème de licence. Si vous découvrez que la remise en attente est due à un problème avec la simulation, annulez immédiatement la tâche avec
scancel jobidet corrigez le problème. - Lorsque la tâche est terminée, vous pouvez télécharger le fichier de données et le retourner dans Fluent avec File > Import > Data….
Scripts pour l'ordonnanceur Slurm
Utilisation générale
La plupart des tâches Fluent devraient utiliser le script par nœud ci-dessous pour minimiser le temps d'attente et maximiser la performance avec le moins de nœuds possible. Les tâches demandant beaucoup de cœurs CPU pourraient attendre moins longtemps dans la queue avec le script par cœur, mais le démarrage d’une tâche utilisant plusieurs nœuds peut prendre beaucoup plus de temps, ce qui en diminue l'intérêt. Il faut aussi tenir compte du fait qu'exécuter des tâches intensives sur un nombre indéterminé de nœuds pouvant être très élevé fait en sorte que ces tâches seront beaucoup plus susceptibles de planter si un des nœuds de calcul fait défaut pendant la simulation. Les scripts suivants utilisent la mémoire partagée pour les tâches utilisant un seul nœud et la mémoire distribuée (avec MPI et l’interconnexion CHP appropriée) pour les tâches en utilisant plusieurs.
Les deux onglets pour Narval peuvent ètre une alternative plus robuste si Fluent plante pendant la phase initiale de partitionnement automatique du maillage lors de l'utilisation des scripts Intel standards avec le solveur parallèle. L'autre option serait d'effectuer manuellement le partitionnement du maillage dans l'interface graphique de Fluent, puis d'essayer d'exécuter à nouveau la tâche sur la grappe avec les scripts Intel. Ainsi, vous pouvez inspecter les statistiques de partitionnement et spécifier la méthode pour obtenir un résultat optimal. Le nombre de partitions de maillage doit être un multiple entier du nombre de cœurs; pour une efficacité optimale, assurez-vous d'avoir au moins 10 000 cellules par cœur.
#!/bin/bash
#SBATCH --account=def-group # Specify account name
#SBATCH --time=00-03:00 # Specify time limit dd-hh:mm
#SBATCH --nodes=1 # Specify number of compute nodes (narval 1 node max)
#SBATCH --ntasks-per-node=32 # Specify upto maximum number of cores per compute node
#SBATCH --mem=0 # Specify memory per compute node (0 allocates all memory)
#SBATCH --cpus-per-task=1 # Do not change
module load StdEnv/2023 # Do not change
module load ansys/2023R2 # or newer versions
MYJOURNALFILE=sample.jou # Specify your journal file name
MYVERSION=3d # Specify 2d, 2ddp, 3d or 3ddp
# ------- do not change any lines below --------
if [[ "$CC_CLUSTER" == narval ]]; then
module load intel/2023 intelmpi
export INTELMPI_ROOT=$I_MPI_ROOT
unset I_MPI_ROOT
fi
if [[ ("${EBVERSIONANSYS//R*}" -ge 2025 && "${CC_CLUSTER}" == nibi) || "${CC_CLUSTER}" == narval ]]; then
export I_MPI_HYDRA_BOOTSTRAP=ssh
unset I_MPI_HYDRA_BOOTSTRAP_EXEC_EXTRA_ARGS
fi
slurm_hl2hl.py --format ANSYS-FLUENT > /tmp/machinefile-$SLURM_JOB_ID
NCORES=$SLURM_NTASKS
if [ "$SLURM_NNODES" == 1 ]; then
fluent -g $MYVERSION -t $NCORES -mpi=intel -pshmem -i $MYJOURNALFILE
else
if [[ "${CC_CLUSTER}" == nibi ]]; then
fluent -g $MYVERSION -t $NCORES -mpi=intel -peth -cnf=/tmp/machinefile-$SLURM_JOB_ID -i $MYJOURNALFILE
else
fluent -g $MYVERSION -t $NCORES -mpi=intel -pib -cnf=/tmp/machinefile-$SLURM_JOB_ID -i $MYJOURNALFILE
fi
fi
#!/bin/bash
#SBATCH --account=def-group # Specify account
#SBATCH --time=00-03:00 # Specify time limit dd-hh:mm
##SBATCH --nodes=1 # Uncomment to specify (narval 1 node max)
#SBATCH --ntasks=16 # Specify total number of cores across all nodes
#SBATCH --mem-per-cpu=4G # Specify memory per core
#SBATCH --cpus-per-task=1 # Do not change
module load StdEnv/2023 # Do not change
module load ansys/2023R2 # or newer versions
MYJOURNALFILE=sample.jou # Specify your journal file name
MYVERSION=3d # Specify 2d, 2ddp, 3d or 3ddp
# ------- do not change any lines below --------
if [[ "$CC_CLUSTER" == narval ]]; then
module load intel/2023 intelmpi
export INTELMPI_ROOT=$I_MPI_ROOT
unset I_MPI_ROOT
fi
if [[ ("${EBVERSIONANSYS//R*}" -ge 2025 && "${CC_CLUSTER}" == nibi) || "${CC_CLUSTER}" == narval ]]; then
export I_MPI_HYDRA_BOOTSTRAP=ssh
unset I_MPI_HYDRA_BOOTSTRAP_EXEC_EXTRA_ARGS
fi
slurm_hl2hl.py --format ANSYS-FLUENT > /tmp/machinefile-$SLURM_JOB_ID
NCORES=$SLURM_NTASKS
if [ "$SLURM_NNODES" == 1 ]; then
fluent -g $MYVERSION -t $NCORES -mpi=intel -pshmem -i $MYJOURNALFILE
else
if [[ "${CC_CLUSTER}" == nibi ]]; then
fluent -g $MYVERSION -t $NCORES -mpi=intel -peth -cnf=/tmp/machinefile-$SLURM_JOB_ID -i $MYJOURNALFILE
else
fluent -g $MYVERSION -t $NCORES -mpi=intel -pib -cnf=/tmp/machinefile-$SLURM_JOB_ID -i $MYJOURNALFILE
fi
fi
#!/bin/bash
#SBATCH --account=def-group # Specify account name
#SBATCH --time=00-03:00 # Specify time limit dd-hh:mm
#SBATCH --nodes=1 # Specify number of compute nodes (1 or more)
#SBATCH --ntasks-per-node=64 # Specify number of cores per node (narval 64 or less)
#SBATCH --mem=0 # Do not change (allocate all memory per compute node)
#SBATCH --cpus-per-task=1 # Do not change
module load StdEnv/2023 # Do not change
module load ansys/2023R2 # or newer versions
MYJOURNALFILE=sample.jou # Specify your journal file name
MYVERSION=3d # Specify 2d, 2ddp, 3d or 3ddp
# ------- do not change any lines below --------
export OPENMPI_ROOT=$EBROOTOPENMPI
slurm_hl2hl.py --format ANSYS-FLUENT > /tmp/mf-$SLURM_JOB_ID
for i in `cat /tmp/mf-$SLURM_JOB_ID | uniq`; do echo "${i}:$(cat /tmp/mf-$SLURM_JOB_ID | grep $i | wc -l)" >> /tmp/machinefile-$SLURM_JOB_ID; done
NCORES=$SLURM_NTASKS
if [ "$SLURM_NNODES" == 1 ]; then
fluent -g $MYVERSION -t $NCORES -mpi=openmpi -pshmem -i $MYJOURNALFILE
else
export FI_PROVIDER=verbs
fluent -g $MYVERSION -t $NCORES -mpi=openmpi -pib -cnf=/tmp/machinefile-$SLURM_JOB_ID -i $MYJOURNALFILE
fi
#!/bin/bash
#SBATCH --account=def-group # Specify account name
#SBATCH --time=00-03:00 # Specify time limit dd-hh:mm
##SBATCH --nodes=1 # Uncomment to specify number of compute nodes (1 or more)
#SBATCH --ntasks=16 # Specify total number of cores across all nodes
#SBATCH --mem-per-cpu=4G # Specify memory per core
#SBATCH --cpus-per-task=1 # Do not change
module load StdEnv/2023 # Do not change
module load ansys/2023R2 # or newer versions
MYJOURNALFILE=sample.jou # Specify your journal file name
MYVERSION=3d # Specify 2d, 2ddp, 3d or 3ddp
# ------- do not change any lines below --------
export OPENMPI_ROOT=$EBROOTOPENMPI
slurm_hl2hl.py --format ANSYS-FLUENT > /tmp/mf-$SLURM_JOB_ID
for i in `cat /tmp/mf-$SLURM_JOB_ID | uniq`; do echo "${i}:$(cat /tmp/mf-$SLURM_JOB_ID | grep $i | wc -l)" >> /tmp/machinefile-$SLURM_JOB_ID; done
NCORES=$SLURM_NTASKS
if [ "$SLURM_NNODES" == 1 ]; then
fluent -g $MYVERSION -t $NCORES -mpi=openmpi -pshmem -i $MYJOURNALFILE
else
export FI_PROVIDER=verbs
fluent -g $MYVERSION -t $NCORES -mpi=openmpi -pib -cnf=/tmp/machinefile-$SLURM_JOB_ID -i $MYJOURNALFILE
fi
#!/bin/bash
#SBATCH --account=def-group # Specify account name
#SBATCH --time=00-03:00 # Specify time limit dd-hh:mm
#SBATCH --nodes=1 # Specify number of compute nodes (1 or more)
#SBATCH --ntasks-per-node=16 # Specify number cores per node (max 192 on trillium)
##SBATCH --mem=0 # Do not uncomment (be default trillium uses all memory per node)
#SBATCH --cpus-per-task=1 # Do not change (required parameter)
#SBATCH --output=slurm-%j.out # Writes to slurm-$SLURM_JOB_ID.out
cd $SLURM_SUBMIT_DIR # Submit from $SCRATCH/some/dir
module load StdEnv/2023 # Do not change
module load ansys/2025R2.04 # only 2025R2 or newer works on trillium
MYJOURNALFILE=sample.jou # Specify your journal file name
MYVERSION=3d # Specify 2d, 2ddp, 3d or 3ddp
# ------- do not change any lines below --------
slurm_hl2hl.py --format ANSYS-FLUENT > $SLURM_SUBMIT_DIR/machinefile-$SLURM_JOB_ID
NCORES=$SLURM_NTASKS
if [ ! -L "$HOME/.ansys" ]; then
echo "ERROR: A link to a writable .ansys directory does not exist."
echo 'Remove ~/.ansys if one exists and then run: ln -s $SCRATCH/.ansys ~/.ansys'
echo "Then try submitting your job again. Aborting the current job now!"
elif [ ! -L "$HOME/.fluentconf" ]; then
echo "ERROR: A link to a writable .fluentconf directory does not exist."
echo 'Remove ~/.fluentconf if one exists and run: ln -s $SCRATCH/.fluentconf ~/.fluentconf'
echo "Then try submitting your job again. Aborting the current job now!"
elif [ ! -L "$HOME/.flrecent" ]; then
echo "ERROR: A link to a writable .flrecent file does not exist."
echo 'Remove ~/.flrecent if one exists and then run: ln -s $SCRATCH/.flrecent ~/.flrecent'
echo "Then try submitting your job again. Aborting the current job now!"
else
mkdir -pv $SCRATCH/.ansys
mkdir -pv $SCRATCH/.fluentconf
touch $SCRATCH/.flrecent
if [ "$SLURM_NNODES" == 1 ]; then
fluent -g $MYVERSION -t $NCORES -mpi=intel -pshmem -i $MYJOURNALFILE
else
fluent -g $MYVERSION -t $NCORES -mpi=intel -pib -cnf=$SLURM_SUBMIT_DIR/machinefile-$SLURM_JOB_ID -i $MYJOURNALFILE
fi
fi
Remise en file d'attente pour obtenir la licence
Les scripts suivants ne doivent être utilisés qu'avec des tâches Fluent qui sont connues pour se terminer normalement sans générer d'erreurs en sortie, mais qui nécessitent généralement plusieurs tentatives de remise en file d'attente pour obtenir la licence. Ils ne sont pas recommandés pour les tâches Fluent qui peuvent 1) s'exécuter pendant une longue période avant de planter 2) s'exécuter jusqu'à la fin mais contenir des avertissements de journalisation; dans les deux cas, les simulations seront répétées depuis le début jusqu'à ce que le nombre maximal de tentatives de remise en file d'attente spécifié par la valeur array soit atteint. Pour ces types de tâches, les scripts à usage général (ci-dessus) doivent être utilisés.
#!/bin/bash
#SBATCH --account=def-group # Specify account
#SBATCH --time=00-03:00 # Specify time limit dd-hh:mm
#SBATCH --nodes=1 # Specify number of compute nodes (narval 1 node max)
#SBATCH --ntasks-per-node=32 # Specify upto maximum number of cores per compute node
#SBATCH --mem=0 # Specify memory per compute node (0 allocates all memory)
#SBATCH --cpus-per-task=1 # Do not change
#SBATCH --array=1-5%1 # Specify number of requeue attempts (2 or more, 5 is shown)
module load StdEnv/2023 # Do not change
module load ansys/2023R2 # Specify version (or newer)
MYJOURNALFILE=sample.jou # Specify your journal file name
MYVERSION=3d # Specify 2d, 2ddp, 3d or 3ddp
# ------- do not change any lines below --------
if [[ "$CC_CLUSTER" == narval ]]; then
module load intel/2023 intelmpi
export INTELMPI_ROOT=$I_MPI_ROOT
unset I_MPI_ROOT
fi
if [[ ("${EBVERSIONANSYS//R*}" -ge 2025 && "${CC_CLUSTER}" == nibi) || "${CC_CLUSTER}" == narval ]]; then
export I_MPI_HYDRA_BOOTSTRAP=ssh
unset I_MPI_HYDRA_BOOTSTRAP_EXEC_EXTRA_ARGS
fi
slurm_hl2hl.py --format ANSYS-FLUENT > /tmp/machinefile-$SLURM_JOB_ID
NCORES=$SLURM_NTASKS
if [ "$SLURM_NNODES" == 1 ]; then
fluent -g $MYVERSION -t $NCORES -mpi=intel -pshmem -i $MYJOURNALFILE
else
if [[ "${CC_CLUSTER}" == nibi ]]; then
fluent -g $MYVERSION -t $NCORES -mpi=intel -peth -cnf=/tmp/machinefile-$SLURM_JOB_ID -i $MYJOURNALFILE
else
fluent -g $MYVERSION -t $NCORES -mpi=intel -pib -cnf=/tmp/machinefile-$SLURM_JOB_ID -i $MYJOURNALFILE
fi
fi
if [ $? -eq 0 ]; then
echo "Job completed successfully! Exiting now."
scancel $SLURM_ARRAY_JOB_ID
else
echo "Job attempt $SLURM_ARRAY_TASK_ID of $SLURM_ARRAY_TASK_COUNT failed due to license or simulation issue!"
if [ $SLURM_ARRAY_TASK_ID -lt $SLURM_ARRAY_TASK_COUNT ]; then
echo "Resubmitting job now …"
else
echo "All job attempts failed exiting now."
fi
fi
#!/bin/bash
#SBATCH --account=def-group # Specify account
#SBATCH --time=00-03:00 # Specify time limit dd-hh:mm
##SBATCH --nodes=1 # Uncomment to specify (narval 1 node max)
#SBATCH --ntasks=16 # Specify total number of cores
#SBATCH --mem-per-cpu=4G # Specify memory per core
#SBATCH --cpus-per-task=1 # Do not change
#SBATCH --array=1-5%1 # Specify number of requeue attempts (2 or more, 5 is shown)
module load StdEnv/2023 # Do not change
module load ansys/2023R2 # Specify version (or newer)
MYJOURNALFILE=sample.jou # Specify your journal file name
MYVERSION=3d # Specify 2d, 2ddp, 3d or 3ddp
# ------- do not change any lines below --------
if [[ "$CC_CLUSTER" == narval ]]; then
module load intel/2023 intelmpi
export INTELMPI_ROOT=$I_MPI_ROOT
unset I_MPI_ROOT
fi
if [[ ("${EBVERSIONANSYS//R*}" -ge 2025 && "${CC_CLUSTER}" == nibi) || "${CC_CLUSTER}" == narval ]]; then
export I_MPI_HYDRA_BOOTSTRAP=ssh
unset I_MPI_HYDRA_BOOTSTRAP_EXEC_EXTRA_ARGS
fi
slurm_hl2hl.py --format ANSYS-FLUENT > /tmp/machinefile-$SLURM_JOB_ID
NCORES=$SLURM_NTASKS
if [ "$SLURM_NNODES" == 1 ]; then
fluent -g $MYVERSION -t $NCORES -mpi=intel -pshmem -i $MYJOURNALFILE
else
if [[ "${CC_CLUSTER}" == nibi ]]; then
fluent -g $MYVERSION -t $NCORES -mpi=intel -peth -cnf=/tmp/machinefile-$SLURM_JOB_ID -i $MYJOURNALFILE
else
fluent -g $MYVERSION -t $NCORES -mpi=intel -pib -cnf=/tmp/machinefile-$SLURM_JOB_ID -i $MYJOURNALFILE
fi
fi
if [ $? -eq 0 ]; then
echo "Job completed successfully! Exiting now."
scancel $SLURM_ARRAY_JOB_ID
else
echo "Job attempt $SLURM_ARRAY_TASK_ID of $SLURM_ARRAY_TASK_COUNT failed due to license or simulation issue!"
if [ $SLURM_ARRAY_TASK_ID -lt $SLURM_ARRAY_TASK_COUNT ]; then
echo "Resubmitting job now …"
else
echo "All job attempts failed exiting now."
fi
fi
Redémarrage
Les deux scripts suivants automatisent le redémarrage de tâches intensives qui exigent plus que le maximum de sept jours d'exécution permis sur la plupart des grappes. Le redémarrage se fait à partir des fichiers de valeur de pas de temps les plus récemment sauvegardés. Une exigence de base est que le premier pas puisse être terminé avant la fin du temps demandé dans le vecteur de tâches (défini dans le haut du script) quand une simulation est lancée à partir d'un champ initialisé. Nous supposons que la valeur du pas est fixe. Pour commencer, sample.cas, sample.dat et sample.jou doivent être présents. Modifiez le fichier sample.jou pour qu'il contienne /solve/dual-time-iterate 1 et /file/auto-save/data-frequency 1. Créez ensuite un fichier de journalisation avec cp sample.jou sample-restart.jou et modifiez le fichier sample-restart.jou pour qu'il contienne /file/read-cas-data sample-restart plutôt que /file/read-cas-data sample et mettez en commentaire la ligne pour l'initialisation en la précédant d’un point-virgule, par exemple ;/solve/initialize/initialize-flow. Si votre deuxième pas et les pas qui suivent sont exécutés deux fois plus vite que le pas initial, modifiez sample-restart.jou en spécifiant /solve/dual-time-iterate 2. De cette façon, la solution ne sera redémarrée qu'après que les deux pas suivant le pas initial soient terminés. Un fichier de résultats pour chaque pas sera enregistré dans le sous-répertoire de sortie. La valeur 2 est arbitraire, mais elle devrait être utilisée pour que la durée de deux pas soit moindre que la durée allouée au vecteur de tâches. Ceci limitera le nombre de redémarrages qui consomme beaucoup de ressources. Si le premier pas de sample.jou est fait à partir d'une solution précédente, choisissez 1 plutôt que 2 puisque tous les pas auront probablement besoin du même temps d'exécution. En supposant que 2 est choisi, la durée totale de la simulation sera 1*Dt+2*Nrestart*Dt où Nrestart est le nombre de redémarrages défini dans le script Slurm. Le nombre total de pas (de même que le nombre de fichiers de résultats générés) sera ainsi 1+2*Nrestart. La valeur pour le temps demandé devrait être choisie afin que le pas initial et les pas suivants se terminent dans la fenêtre de temps de Slurm, qui peut aller jusqu'à #SBATCH --time=07-00:00 jours.
#!/bin/bash
#SBATCH --account=def-group # Specify account
#SBATCH --time=07-00:00 # Specify time limit dd-hh:mm
#SBATCH --nodes=1 # Specify number of compute nodes (narval 1 node max)
#SBATCH --ntasks-per-node=32 # Specify upto maximum number of cores per compute node
#SBATCH --mem=0 # Specify memory per compute node (0 allocates all memory)
#SBATCH --cpus-per-task=1 # Do not change
#SBATCH --array=1-5%1 # Specify number of solution restarts (2 or more, 5 is shown)
module load StdEnv/2023 # Do not change
module load ansys/2023R2 # Specify version (or newer)
MYVERSION=3d # Specify 2d, 2ddp, 3d or 3ddp
MYJOUFILE=sample.jou # Specify your journal filename
MYJOUFILERES=sample-restart.jou # Specify journal restart filename
MYCASFILERES=sample-restart.cas.h5 # Specify cas restart filename
MYDATFILERES=sample-restart.dat.h5 # Specify dat restart filename
# ------- do not change any lines below --------
if [[ "$CC_CLUSTER" == narval ]]; then
module load intel/2023 intelmpi
export INTELMPI_ROOT=$I_MPI_ROOT
unset I_MPI_ROOT
fi
if [[ ("${EBVERSIONANSYS//R*}" -ge 2025 && "${CC_CLUSTER}" == nibi) || "${CC_CLUSTER}" == narval ]]; then
export I_MPI_HYDRA_BOOTSTRAP=ssh
unset I_MPI_HYDRA_BOOTSTRAP_EXEC_EXTRA_ARGS
fi
slurm_hl2hl.py --format ANSYS-FLUENT > /tmp/machinefile-$SLURM_JOB_ID
NCORES=$SLURM_NTASKS
if [ "$SLURM_NNODES" == 1 ]; then
if [ "$SLURM_ARRAY_TASK_ID" == 1 ]; then
fluent -g 2ddp -t $NCORES -mpi=intel -pshmem -i $MYJOUFILE
else
fluent -g 2ddp -t $NCORES -mpi=intel -pshmem -i $MYJOUFILERES
fi
else
if [ "$SLURM_ARRAY_TASK_ID" == 1 ]; then
if [[ "${CC_CLUSTER}" == nibi ]]; then
fluent -g $MYVERSION -t $NCORES -mpi=intel -peth -cnf=/tmp/machinefile-$SLURM_JOB_ID -ssh -i $MYJOUFILE
else
fluent -g $MYVERSION -t $NCORES -mpi=intel -pib -cnf=/tmp/machinefile-$SLURM_JOB_ID -ssh -i $MYJOUFILE
fi
else
if [[ "${CC_CLUSTER}" == nibi ]]; then
fluent -g $MYVERSION -t $NCORES -mpi=intel -peth -cnf=/tmp/machinefile-$SLURM_JOB_ID -ssh -i $MYJOUFILERES
else
fluent -g $MYVERSION -t $NCORES -mpi=intel -pib -cnf=/tmp/machinefile-$SLURM_JOB_ID -ssh -i $MYJOUFILERES
fi
fi
fi
if [ $? -eq 0 ]; then
echo
echo "SLURM_ARRAY_TASK_ID = $SLURM_ARRAY_TASK_ID"
echo "SLURM_ARRAY_TASK_COUNT = $SLURM_ARRAY_TASK_COUNT"
echo
if [ $SLURM_ARRAY_TASK_ID -lt $SLURM_ARRAY_TASK_COUNT ]; then
echo "Restarting job with the most recent output dat file …"
ln -sfv output/$(ls -ltr output | grep .cas | tail -n1 | awk '{print $9}') $MYCASFILERES
ln -sfv output/$(ls -ltr output | grep .dat | tail -n1 | awk '{print $9}') $MYDATFILERES
ls -lh cavity* output/*
else
echo "Job completed successfully! Exiting now."
scancel $SLURM_ARRAY_JOB_ID
fi
else
echo "Simulation failed. Exiting …"
fi
#!/bin/bash
#SBATCH --account=def-group # Specify account
#SBATCH --time=00-03:00 # Specify time limit dd-hh:mm
##SBATCH --nodes=1 # Uncomment to specify (narval 1 node max)
#SBATCH --ntasks=16 # Specify total number of cores
#SBATCH --mem-per-cpu=4G # Specify memory per core
#SBATCH --cpus-per-task=1 # Do not change
#SBATCH --array=1-5%1 # Specify number of restart aka time steps (2 or more, 5 is shown)
module load StdEnv/2023 # Do not change
module load ansys/2023R2 # Specify version (or newer)
MYVERSION=3d # Specify 2d, 2ddp, 3d or 3ddp
MYJOUFILE=sample.jou # Specify your journal filename
MYJOUFILERES=sample-restart.jou # Specify journal restart filename
MYCASFILERES=sample-restart.cas.h5 # Specify cas restart filename
MYDATFILERES=sample-restart.dat.h5 # Specify dat restart filename
# ------- do not change any lines below --------
if [[ "$CC_CLUSTER" == narval ]]; then
module load intel/2023 intelmpi
export INTELMPI_ROOT=$I_MPI_ROOT
unset I_MPI_ROOT
fi
if [[ ("${EBVERSIONANSYS//R*}" -ge 2025 && "${CC_CLUSTER}" == nibi) || "${CC_CLUSTER}" == narval ]]; then
export I_MPI_HYDRA_BOOTSTRAP=ssh
unset I_MPI_HYDRA_BOOTSTRAP_EXEC_EXTRA_ARGS
fi
slurm_hl2hl.py --format ANSYS-FLUENT > /tmp/machinefile-$SLURM_JOB_ID
NCORES=$SLURM_NTASKS
if [ "$SLURM_NNODES" == 1 ]; then
if [ "$SLURM_ARRAY_TASK_ID" == 1 ]; then
fluent -g $MYVERSION -t $NCORES -mpi=intel -pshmem -I $MYFILEJOU
else
fluent -g $MYVERSION -t $NCORES -mpi=intel -pshmem -I $MYFILEJOURES
fi
else
if [ "$SLURM_ARRAY_TASK_ID" == 1 ]; then
if [[ "${CC_CLUSTER}" == nibi ]]; then
fluent -g $MYVERSION -t $NCORES -mpi=intel -peth -cnf=/tmp/machinefile-$SLURM_JOB_ID -i $MYJOUFILE
else
fluent -g $MYVERSION -t $NCORES -mpi=intel -pib -cnf=/tmp/machinefile-$SLURM_JOB_ID -i $MYJOUFILE
fi
else
if [[ "${CC_CLUSTER}" == nibi ]]; then
fluent -g $MYVERSION -t $NCORES -mpi=intel -peth -cnf=/tmp/machinefile-$SLURM_JOB_ID -i $MYJOUFILERES
else
fluent -g $MYVERSION -t $NCORES -mpi=intel -pib -cnf=/tmp/machinefile-$SLURM_JOB_ID -i $MYJOUFILERES
fi
fi
fi
if [ $? -eq 0 ]; then
echo
echo "SLURM_ARRAY_TASK_ID = $SLURM_ARRAY_TASK_ID"
echo "SLURM_ARRAY_TASK_COUNT = $SLURM_ARRAY_TASK_COUNT"
echo
if [ $SLURM_ARRAY_TASK_ID -lt $SLURM_ARRAY_TASK_COUNT ]; then
echo "Restarting job with the most recent output dat file"
ln -sfv output/$(ls -ltr output | grep .cas | tail -n1 | awk '{print $9}') $MYCASFILERES
ln -sfv output/$(ls -ltr output | grep .dat | tail -n1 | awk '{print $9}') $MYDATFILERES
ls -lh cavity* output/*
else
echo "Job completed successfully! Exiting now."
scancel $SLURM_ARRAY_JOB_ID
fi
else
echo "Simulation failed. Exiting now."
fi
Fichiers de journalisation
Les fichiers de journalisation peuvent contenir toutes les commandes de l'interface TUI (Text User Interface) de Fluent; elles peuvent être utilisées pour modifier des paramètres de simulation comme la température, la pression ou la vitesse du flux. Vous pouvez ainsi effectuer une série de simulations sous différentes conditions simplement en modifiant les paramètres du fichier de journalisation. Consultez le guide d'utilisation de Fluent pour plus d'information ainsi que pour connaître la liste des commandes. Les fichiers qui suivent sont configurés avec /file/cff-file no pour utiliser les formats de fichiers .cas/.dat qui sont les formats par défaut pour les modules jusqu'à 2019R3. Pour utiliser les formats .cas.h5/.dat.h5 plus efficaces des versions à partir de 2020R1, la configuration est /file/cff-files yes.
; SAMPLE FLUENT JOURNAL FILE - STEADY SIMULATION
; ----------------------------------------------
; lines beginning with a semicolon are comments
; Overwrite files by default
/file/confirm-overwrite no
; Preferentially read/write files in legacy format
/file/cff-files no
; Read input case and data files
/file/read-case-data FFF-in
; Run the solver for this many iterations
/solve/iterate 1000
; Overwrite output files by default
/file/confirm-overwrite n
; Write final output data file
/file/write-case-data FFF-out
; Write simulation report to file (optional)
/report/summary y "My_Simulation_Report.txt"
; Cleanly shutdown fluent
/exit
; SAMPLE FLUENT JOURNAL FILE - STEADY SIMULATION
; ----------------------------------------------
; lines beginning with a semicolon are comments
; Overwrite files by default
/file/confirm-overwrite no
; Preferentially read/write files in legacy format
/file/cff-files no
; Read input files
/file/read-case-data FFF-in
; Write a data file every 100 iterations
/file/auto-save/data-frequency 100
; Retain data files from 5 most recent iterations
/file/auto-save/retain-most-recent-files y
; Write data files to output sub-directory (appends iteration)
/file/auto-save/root-name output/FFF-out
; Run the solver for this many iterations
/solve/iterate 1000
; Write final output case and data files
/file/write-case-data FFF-out
; Write simulation report to file (optional)
/report/summary y "My_Simulation_Report.txt"
; Cleanly shutdown fluent
/exit
; SAMPLE FLUENT JOURNAL FILE - TRANSIENT SIMULATION
; -------------------------------------------------
; lines beginning with a semicolon are comments
; Overwrite files by default
/file/confirm-overwrite no
; Preferentially read/write files in legacy format
/file/cff-files no
; Read the input case file
/file/read-case FFF-transient-inp
; For continuation (restart) read in both case and data input files
;/file/read-case-data FFF-transient-inp
; Write a data (and maybe case) file every 100 time steps
/file/auto-save/data-frequency 100
/file/auto-save/case-frequency if-case-is-modified
; Retain only the most recent 5 data (and maybe case) files
/file/auto-save/retain-most-recent-files y
; Write to output sub-directory (appends flowtime and timestep)
/file/auto-save/root-name output/FFF-transient-out-%10.6f
; ##### Settings for Transient simulation : #####
; Set the physical time step size
/solve/set/time-step 0.0001
; Set the number of iterations for which convergence monitors are reported
/solve/set/reporting-interval 1
; ##### End of settings for Transient simulation #####
; Initialize using the hybrid initialization method
/solve/initialize/hyb-initialization
; Set max number of iters per time step and number of time steps
;/solve/set/max-iterations-per-time-step 75
;/solve/dual-time-iterate 1000 ,
/solve/dual-time-iterate 1000 75
; Write final case and data output files
/file/write-case-data FFF-transient-out
; Write simulation report to file (optional)
/report/summary y Report_Transient_Simulation.txt
; Cleanly shutdown fluent
/exit
Fonctions UDF
La première étape est de transférer vers la grappe votre UDF (User-Defined Function), soit le fichier source sampleudf.c et tous les fichiers de dépendance supplémentaires. Lors du téléchargement à partir d'une machine Windows, assurez-vous que le mode texte de votre client de transfert est utilisé, sinon Fluent ne pourra pas lire correctement le fichier sur la grappe qui, elle, exécute Linux. L'UDF doit être placée dans le répertoire où résident vos fichiers de journalisation, cas et dat. Ajoutez ensuite l'une des commandes suivantes dans votre fichier de journalisation avant les commandes qui lisent vos fichiers de simulation cas/dat. Que vous utilisiez l'approche UDF interprétée ou compilée, avant de télécharger votre fichier de cas, vérifiez que les boîtes de dialogue Interpreted UDFs et UDF Library Manager ne sont pas configurées pour utiliser un UDF; ceci garantira que lorsque les tâches sont soumises, seules les commandes du fichier de journalisation auront le contrôle.
Interprété
Pour indiquer à Fluent d'interpréter votre UDF au moment de l'exécution, ajoutez la ligne de commande suivante dans votre fichier journal avant que les fichiers cas/dat soient lus ou initialisés. Remplacez le nom de fichier sampleudf.c par le nom de votre fichier source. La commande reste la même, que la simulation soit exécutée séquentiellement ou en parallèle. Pour vous assurer que l'UDF se trouve dans le même répertoire que le fichier de journalisation, ouvrez votre fichier cas dans l'interface graphique Fluent, supprimez toutes les définitions gérées et réenregistrez-le. Ceci garantira que seule la commande/méthode suivante est en contrôle lors de l'exécution de Fluent. Pour utiliser une UDF interprétée avec des tâches parallèles, elle devra être parallélisée comme décrit dans la section ci-dessous.
define/user-defined/interpreted-functions "sampleudf.c" "cpp" 10000 no
Compilé
Pour utiliser cette approche, votre UDF doit être compilée sur une de nos grappes au moins une fois. Ceci créera une structure de sous-répertoire libudf contenant la bibliothèque partagée libudf.so requise. Le répertoire libudf ne peut pas être simplement copié d'un système distant (comme votre ordinateur portable) vers l'Alliance car les dépendances de la bibliothèque partagée ne seront pas satisfaites, ce qui fera planter Fluent au démarrage. Cela dit, une fois que vous avez compilé votre UDF sur une de nos grappes, vous pouvez transférer la libudf nouvellement créée vers n'importe quelle autre de nos grappes, à condition que votre compte charge la même version du module d'environnement StdEnv. Une fois copiée, l'UDF peut être utilisée en supprimant le commentaire de la deuxième ligne (load) libudf ci-dessous dans votre fichier de journalisation quand une tâche est soumise. Les deux lignes libudf (compile et load) ne doivent pas être laissées sans commentaire lors de la soumission de tâches, sinon votre UDF sera automatiquement (re)compilée pour chaque tâche. Non seulement cette méthode est très inefficace, mais elle peut également entraîner des conflits de build de type racetime si plusieurs tâches sont exécutées à partir du même répertoire. Outre la configuration de votre fichier de journalisation pour construire votre UDF, l'interface graphique de Fluent peut également être utilisée. Pour ce faire, ajoutez le fichier source UDF dans la boîte de dialogue Compiled UDFs, et cliquez sur Build. Lorsque vous utilisez une UDF compilée avec des tâches parallèles, votre fichier source doit être parallélisé comme indiqué dans la section ci-dessous.
define/user-defined/compiled-functions compile libudf yes sampleudf.c "" ""
et/ou
define/user-defined/compiled-functions load libudf
Parallèle
Avant qu'une UDF puisse être utilisée avec une tâche parallèle Fluent (SMP à nœud unique et MPI à nœuds multiples), elle doit être parallélisée. En procédant ainsi, nous contrôlons comment/quels processus (hôte et/ou calcul) exécutent des parties spécifiques du code UDF lorsque Fluent est exécuté en parallèle sur la grappe. La procédure d'instrumentation consiste à ajouter des directives de compilation, des prédicats et des macros de réduction dans votre UDF séquentielle. Si vous ne le faites pas, Fluent fonctionnera lentement, au mieux, ou plantera immédiatement, au pire. Le résultat final sera une UDF unique qui s'exécute efficacement lorsque Fluent est utilisé à la fois en mode séquentiel et en mode parallèle. Le sujet est décrit en détail dans Fluent Customization Manual, Part I: Chapter 7: Parallel Considerations].
DPM
Les UDF peuvent être utilisées pour personnaliser les modèles de phase discrète (DPM pour Discrete Phase Models) comme décrit dans
- 2024R2 Fluent Users Guide: Part III: Solution Mode | Chapter 24: Modeling Discrete Phase | 24.2 Steps for Using the Discrete Phase Models| 24.2.6 User-Defined Functions, and
- 2024R2 Fluent Customization Manual: Part I: Creating and Using User Defined Functions | Chapter 2: DEFINE Macros | 2.5 Discrete Phase Model (DPM) DEFINE Macros.
Avant qu'une UDF basée sur DMP puisse être utilisée dans une simulation, l'injection d'un ensemble de particules doit être définie en spécifiant des Point Properties avec des variables telles que la position de la source, la trajectoire initiale, le débit massique, la durée, la température, etc., en fonction du type d'injection. Ceci se fait dans l'interface graphique en cliquant sur le panneau Physics--> Discrete Phase, puis en cliquant sur le bouton Injections. Cela ouvrira la boîte de dialogue Injections dans laquelle une ou plusieurs injections peuvent être créées avec le bouton Create. La boîte de dialogue Set Injection Properties contient le menu déroulant Injection Type avec les quatre premiers types disponibles (single, group, surface, flat-fan-atomizer). Si vous sélectionnez l'un de ces types, vous pouvez alors sélectionner l'onglet Point Properties pour saisir les champs de valeurs correspondants. Une autre façon de spécifier les Point Properties est de lire un fichier texte d'injection. Pour ce faire, sélectionnez File dans le menu déroulant Injection Type, spécifiez le nom de l'injection à créer, puis cliquez sur le bouton File (situé à côté du bouton OK en bas de la boîte de dialogue Set Injection Properties). Ici, vous pouvez sélectionner un fichier d'échantillon d'injection (avec l'extension .dpm) ou un fichier texte d'injection créé manuellement. Pour ce faire, dans la boîte de dialogue Select File, sélectionnez All Files (*), puis mettez en surbrillance le fichier qui pourrait avoir n'importe quel nom arbitraire mais qui a généralement une extension .inj; cliquez sur OK. En supposant qu'il n'y ait aucun problème avec le fichier, aucun message d'erreur ou d'avertissement de la console n'apparaîtra dans Fluent. En revenant à la boîte de dialogue Injection, vous devriez voir le même nom d'injection que celui que vous avez spécifié dans la boîte de dialogue Set Injection Properties et pouvoir répertorier ses particules et propriétés dans la console. Ouvrez ensuite la boîte de dialogue Discrete Phase Model et sélectionnez Interaction with Continuous Phase qui permettra de mettre à jour les termes sources DPM à chaque itération de flux. Ce paramètre peut être enregistré dans votre fichier cas ou ajouté via le fichier de journalisation comme indiqué. Une fois que l'injection est confirmée comme fonctionnant dans l'interface graphique, les étapes peuvent être automatisées en ajoutant des commandes au fichier de journalisation après l'initialisation de la solution, par exemple
/define/models/dpm/interaction/coupled-calculations yes /define/models/dpm/injections/delete-injection injection-0:1 /define/models/dpm/injections/create injection-0:1 no yes file no zinjection01.inj no no no no /define/models/dpm/injections/list-particles injection-0:1 /define/models/dpm/injections/list-injection-properties injection-0:1
where a basic manually created injection steady file format might look like
$ cat zinjection01.inj (z=4 12) ( x y z u v w diameter t mass-flow mass frequency time name ) (( 2.90e-02 5.00e-03 0.0 -1.00e-03 0.0 0.0 1.00e-04 2.93e+02 1.00e-06 0.0 0.0 0.0 ) injection-0:1 )
notant que les fichiers d'injection pour les simulations DPM sont généralement configurés pour un suivi stationnaire ou instable de particules, le format du premier étant décrit dans 2024R2 Fluent Customization Manual Part III: Solution Mode | Chapter 24: Modeling Discrete Phase | 24.3. Setting Initial Conditions for the Discrete Phase | 24.3.13 Point Properties for File Injections | 24.3.13.1 Steady File Format.
CFX
Scripts pour l'ordonnanceur Slurm
Le résumé des options de ligne de commande peut être affiché avec cfx5solve -help. La version du module chargée dans votre script pour l'ordonnanceur doit d'abord être chargée manuellement. Par défaut, cfx5solve s'exécute en simple précision (-single). Pour exécuter cfx5solve en double précision, ajoutez l'option -double, sachant que cela doublera également les besoins en mémoire. Par défaut, cfx5solve prend en charge les maillages jusqu'à 80 millions d'éléments structurés ou 200 millions d'éléments non structurés. Pour les maillages plus grands (jusqu'à 2 milliards d'éléments), ajoutez l'option -large. Différentes combinaisons de ces options peuvent être uitilisées pour le partitionneur, l'interpolateur ou le solveur. Consultez Ansys CFX-Solver Manager User's Guide pour plus de détails.
#!/bin/bash
#SBATCH --account=def-group # Specify account name
#SBATCH --time=00-03:00 # Specify time limit dd-hh:mm
#SBATCH --nodes=1 # Do not change
#SBATCH --ntasks-per-node=4 # Specify number of cores
#SBATCH --mem=16G # Specify total memory
#SBATCH --cpus-per-task=1 # Do not change
#module load StdEnv/2020 # Uncomment to use (deprecated)
#module load 2021R2 # Specify 2021R2 only
module load StdEnv/2023
module load ansys/2023R2 # Or newer module versions
# append additional cfx5solve command line options as required
if [[ "$CC_CLUSTER" = narval || "$CC_CLUSTER" == fir ]]; then
cfx5solve -def YOURFILE.def -start-method "Open MPI Local Parallel" -part $SLURM_CPUS_ON_NODE
else
cfx5solve -def YOURFILE.def -start-method "Intel MPI Local Parallel" -part $SLURM_CPUS_ON_NODE
fi
#!/bin/bash
#SBATCH --account=def-group # Specify account name
#SBATCH --time=00-03:00 # Specify time limit dd-hh:mm
#SBATCH --nodes=2 # Specify multiple compute nodes (2 or more)
#SBATCH --ntasks-per-node=192 # Use all cores per compute node (do not change)
#SBATCH --mem=0 # Use all memory on each compute node (do not change)
#SBATCH --cpus-per-task=1 # Do not change
#module load StdEnv/2020 # Uncomment to use (deprecated)
#module load 2021R2 # Specify 2021R2 only
module load StdEnv/2023
module load ansys/2023R2 # Or newer module versions
NNODES=$(slurm_hl2hl.py --format ANSYS-CFX)
# append additional cfx5solve command line options as required
if [[ "$CC_CLUSTER" = narval || "$CC_CLUSTER" == fir ]]; then
cfx5solve -def YOURFILE.def -start-method "Open MPI Distributed Parallel" -par-dist $NNODES
else
export I_MPI_HYDRA_BOOTSTRAP=ssh
unset I_MPI_HYDRA_BOOTSTRAP_EXEC_EXTRA_ARGS
cfx5solve -def YOURFILE.def -start-method "Intel MPI Distributed Parallel" -par-dist $NNODES
fi
Workbench
Avant de soumettre une tâche Workbench à la file d'attente avec un script Slurm, vous devez l'initialiser une fois, comme décrit dans les étapes suivantes.
- Sur la grappe où vous soumettrez les tâches Workbench, OnDemand | ouvrez un bureau OnDemand.
- Une fois le bureau affiché, ouvrez une fenêtre de terminal et accédez au répertoire contenant votre fichier YOURPROJECT.wbpj.
- Supprimez l'ancien répertoire cache de /projet en exécutant
rm -rf _ProjectScratch, car il peut être très volumineux suite à des exécutions précédentes. - Ouvrez une fenêtre de terminal et chargez la version du module que vous utiliserez dans votre script Slurm, par exemple
module load ansys/2025R2.04. - Ouvrez l'interface graphique de Workbench avec votre fichier de /projet. Pour ce faire, exécutez directement la commande
runwb2 -f YOURPROJECT.wbpjvia la ligne de commande. Si une fenêtre contextuelle apparaît vous demandant Do you want to recover the project before opening ? (Any changes made since the last save will be lost.), répondez No. - Dans le menu contextuel qui devrait apparaître au centre de la fenêtre Project Schematic, cliquez avec le bouton droit sur Model et sélectionnez Reset. Lorsqu'Ansys Workbench affiche l'avertissement This operation will delete the operations local and generated data, cliquez sur OK pour accepter et continuer.
- Dans le menu déroulant de la barre de menu supérieure, sélectionnez 'File -> Save puis File -> Exit pour fermer Workbench.
- Dans la fenêtre contextuelle Ansys Workbench qui affiche The current project has been modified. Do you want to save it? cliquez sur No.
- Quittez Workbench et soumettez la tâche avec un des scripts ci-dessous.
Puisqu'il est désormais possible de réserver un nœud de calcul doté de jusqu'à 96 cœurs, 768Go de mémoire et 8 heures d'autonomie pour une session de bureau OnDemand, exécutez vos simulations Workbench directement de l'interface graphique native de Workbench lorsque cela est possible; il s'agit d'une option plus intuitive que de soumettre la tâche à la file d'attente via un script Slurm
Scripts pour l'ordonnanceur Slurm
Pour soumettre un fichier de projet à la queue, personnalisez les scripts suivants et lancez la commande sbatch script-wbpj-202X.sh.
#!/bin/bash
#SBATCH --account=def-account
#SBATCH --time=00-03:00 # Time (DD-HH:MM)
#SBATCH --mem=16G # Specify total memory
#SBATCH --ntasks=4 # Specify number of cores
#SBATCH --nodes=1 # Do not change (multi-node not supported)
##SBATCH --exclusive # Uncomment ONLY for scaling testing
##SBATCH --constraint=broadwell # Uncomment to specify an available node type
module load StdEnv/2023 ansys/2023R2 # OR newer Ansys module versions
if [ "$SLURM_NNODES" == 1 ]; then
MEMPAR=0 # Set to 0 for SMP (shared memory parallel)
else
MEMPAR=1 # Set to 1 for DMP (distributed memory parallel)
fi
rm -fv *_files/.lock
MWFILE=~/.mw/Application\ Data/Ansys/`basename $(find $EBROOTANSYS/v* -maxdepth 0 -type d)`/SolveHandlers.xml
sed -re "s/(.AnsysSolution>+)[a-zA-Z0-9]*(<\/Distribute.)/\1$MEMPAR\2/" -i "$MWFILE"
sed -re "s/(.Processors>+)[a-zA-Z0-9]*(<\/MaxNumber.)/\1$SLURM_NTASKS\2/" -i "$MWFILE"
sed -i "s!UserConfigured=\"0\"!UserConfigured=\"1\"!g" "$MWFILE"
export KMP_AFFINITY=disabled
export I_MPI_HYDRA_BOOTSTRAP=ssh
runwb2 -B -E "Update();Save(Overwrite=True)" -F YOURPROJECT.wbpj
#!/bin/bash
#SBATCH --account=def-account
#SBATCH --time=00-03:00 # Time (DD-HH:MM)
#SBATCH --mem=16G # Specify total memory
#SBATCH --ntasks=4 # Specify number of cores
#SBATCH --nodes=1 # Do not change (multi-node not supported)
##SBATCH --exclusive # Uncomment ONLY for scaling testing
##SBATCH --constraint=broadwell # Uncomment to specify an available node type
module load StdEnv/2020 ansys/2022R2 # OR older Ansys module versions
if [ "$SLURM_NNODES" == 1 ]; then
MEMPAR=0 # Set to 0 for SMP (shared memory parallel)
else
MEMPAR=1 # Set to 1 for DMP (distributed memory parallel)
fi
rm -fv *_files/.lock
MWFILE=~/.mw/Application\ Data/Ansys/`basename $(find $EBROOTANSYS/v* -maxdepth 0 -type d)`/SolveHandlers.xml
sed -re "s/(.AnsysSolution>+)[a-zA-Z0-9]*(<\/Distribute.)/\1$MEMPAR\2/" -i "$MWFILE"
sed -re "s/(.Processors>+)[a-zA-Z0-9]*(<\/MaxNumber.)/\1$SLURM_NTASKS\2/" -i "$MWFILE"
sed -i "s!UserConfigured=\"0\"!UserConfigured=\"1\"!g" "$MWFILE"
export KMP_AFFINITY=disabled
export I_MPI_HYDRA_BOOTSTRAP=ssh
runwb2 -B -E "Update();Save(Overwrite=True)" -F YOURPROJECT.wbpj
Pour ne pas écrire la solution lorsqu'une tâche en cours se termine avec succès, remplacez Save(Overwrite=True) par Save(Overwrite=False) dans la dernière ligne du script Slurm ci-dessus. Cela facilitera l'évaluation de la mise à l'échelle de la simulation lorsque la valeur de #SBATCH --ntasks est augmentée, car la solution initialisée ne sera pas écrasée par chaque tâche de test.
Mechanical
Le fichier d'entrée peut être généré dans votre session interactive Workbench Mechanical en cliquant sur Solution -> Tools -> Write Input Files et en spécifiant File name: pour YOURAPDLFILE.inp et Save as type: APDL Input Files (*.inp).. Les tâches APDL peuvent ensuite être soumises à la queue avec la commande sbatch script-name.sh.
Scripts pour l'ordonnanceur Slurm
Les lignes qui commencent par ##SBATCH sont des commentaires.
#!/bin/bash
#SBATCH --account=def-account # Specify your account
#SBATCH --time=00-03:00 # Specify time (DD-HH:MM)
#SBATCH --mem=32G # Specify memory for all cores
#SBATCH --nodes=1 # Do not change
#SBATCH --tasks=8 # Specify number of cores
#SBATCH --cpus-per-task=1 # Do not change
module load StdEnv/2023
#module load ansys/2023R2
module load ansys/2024R1.03
mkdir outdir-$SLURM_JOBID
[[ "$CC_CLUSTER" = cedar ]] && export LD_LIBRARY_PATH=$EBROOTGCC/../lib/gcc
mapdl -smp -b nolist -np $SLURM_NTASKS -dir outdir-$SLURM_JOBID -i YOURAPDLFILE.inp
#!/bin/bash
#SBATCH --account=def-account # Specify your account
#SBATCH --time=00-03:00 # Specify time (DD-HH:MM)
#SBATCH --mem-per-cpu=4G # Specify memory per core
##SBATCH --nodes=2 # Specify number of nodes (optional)
#SBATCH --ntasks=8 # Specify number of cores
##SBATCH --ntasks-per-node=4 # Specify cores per node (optional)
#SBATCH --cpus-per-task=1 # Do not change
module load StdEnv/2023
#module load ansys/2023R2
module load ansys/2024R1.03
mkdir outdir-$SLURM_JOBID
if [[ "$CC_CLUSTER" = cedar ]]; then
ln -s $EBROOTGCC/../lib/gcc/libstdc++.so.6.0.29 $PWD/outdir-$SLURM_JOBID/libstdc++.so.6.0.29
export LD_LIBRARY_PATH=$PWD/outdir-$SLURM_JOBID
fi
if [[ "$CC_CLUSTER" = beluga ]]; then
export KMP_AFFINITY=none
mapdl -dis -mpi intelmpi -b nolist -np $SLURM_NTASKS -dir outdir-$SLURM_JOBID -i YOURAPDLFILE.inp
else
mapdl -dis -mpi openmpi -b nolist -np $SLURM_NTASKS -dir outdir-$SLURM_JOBID -i YOURAPDLFILE.inp
fi
#!/bin/bash
#SBATCH --account=def-account # Specify your account
#SBATCH --time=00-03:00 # Specify time (DD-HH:MM)
#SBATCH --mem=32G # Specify memory for all cores
#SBATCH --ntasks=8 # Specify number of cores
#SBATCH --nodes=1 # Do not change
#SBATCH --cpus-per-task=1 # Do not change
#SBATCH --gpus-per-node=1 # Specify [gputype:]quantity
##SBATCH --gpus-per-node=h100:1 # Temporarily required on mini-graham
##SBATCH --partition=debug # Temporarily required on mini-graham
module load StdEnv/2023
#module load ansys/2023R2
module load ansys/2024R1.03
mkdir outdir-$SLURM_JOBID
[[ "$CC_CLUSTER" = cedar ]] && export LD_LIBRARY_PATH=$EBROOTGCC/../lib/gcc
export ANSGPU_PRINTDEVICES=1
mapdl -smp -acc nvidia -na $SLURM_GPUS_ON_NODE -b nolist -np $SLURM_NTASKS -dir outdir-$SLURM_JOBID -i YOURAPDLFILE.inp
#!/bin/bash
#SBATCH --account=def-account # Specify your account
#SBATCH --time=00-03:00 # Specify time (DD-HH:MM)
#SBATCH --mem-per-cpu=4G # Specify memory per core
#SBATCH --nodes=1 # Specify number of nodes
#SBATCH --ntasks-per-node=8 # Specify cores per node
#SBATCH --cpus-per-task=1 # Do not change
#SBATCH --gpus-per-node=1 # Specify [gputype:]quantity
##SBATCH --gpus-per-node=h100:1 # Temporarily required on mini-graham
##SBATCH --partition=debug # Temporarily required on mini-graham
module load StdEnv/2023
#module load ansys/2023R2
module load ansys/2024R1.03
mkdir outdir-$SLURM_JOBID
if [[ "$CC_CLUSTER" = cedar ]]; then
ln -s $EBROOTGCC/../lib/gcc/libstdc++.so.6.0.29 $PWD/outdir-$SLURM_JOBID/libstdc++.so.6.0.29
export LD_LIBRARY_PATH=$PWD/outdir-$SLURM_JOBID
fi
export ANSGPU_PRINTDEVICES=1
if [[ "$CC_CLUSTER" = beluga ]]; then
export KMP_AFFINITY=none
mapdl -dis -acc nvidia -na $SLURM_GPUS_ON_NODE -mpi intelmpi -b nolist -np $SLURM_NTASKS -dir outdir-$SLURM_JOBID -i YOURAPDLFILE.inp
else
mapdl -dis -acc nvidia -na $SLURM_GPUS_ON_NODE -mpi openmpi -b nolist -np $SLURM_NTASKS -dir outdir-$SLURM_JOBID -i YOURAPDLFILE.inp
fi
Par défaut, Ansys alloue aux tâches APDL 1024Mo de mémoire totale et 1024Mo de mémoire pour les bases de données. Ces valeurs peuvent être définies manuellement (ou modifiées) avec l'ajout des arguments-m 1024 et/ou -db 1024 sur la dernière ligne de commande mapdl des scripts ci-dessus. Si vous utilisez à distance un serveur de licence de votre établissement qui a plusieurs licences Ansys, il pourrait être nécessaire d'ajouter des arguments comme -p aa_r ou -ppf anshpc, selon le module que vous utilisez. Comme d'habitude, effectuez des tests détaillés de mise à l'échelle avant de lancer des tâches en production pour vous assurer que vous utilisez le nombre optimal de cœurs et la bonne quantité minimale de mémoire. Les scripts pour nœud simple avec mémoire parallèle partagée (SMP pour Shared Memory Parallel) offriront une meilleure performance que les scripts pour plusieurs nœuds avec mémoire parallèle distribuée (DMP pour Distributed Memory Parallel) et devraient être utilisés autant que possible. Pour prévenir les problèmes de compatibilité, le module qui est chargé dans votre script devrait idéalement correspondre à la version employée pour générer le fichier en entrée.
[gra-login2:~/testcase] cat YOURAPDLFILE.inp | grep version
! ANSYS input file written by Workbench version 2019 R3
Rocky
Nous présentons ici des exemples de scripts Slurm pour résoudre des simulations Rocky autonomes et non couplées dans la file d'attente d'une grappe. Les deux scripts sont configurés avec RESUME=0, ce qui par défaut permet de résoudre les simulations depuis le début. Pour redémarrer une simulation partiellement terminée, spécifiez RESUME=1 et soumettez à nouveau le script à la file d'attente. Pour obtenir la liste complète des options de ligne de commande, exécutez Rocky -h après avoir chargé le module Ansys. Un fichier de verrouillage étant généré à chaque lancement de simulation, une seule tâche doit être soumise à la fois dans le même répertoire. Concernant le choix du script, bien que toutes les simulations doivent être testées indépendamment, pour un cas de test simple, le script utilisant uniquement le GPU s'est avéré 3,5 fois plus performant que le script utilisant uniquement le CPU. Des augmentations supplémentaires de ressources au-delà de 6 cœurs (pour le script utilisant uniquement le CPU) ou de 2 cœurs + 1Go (1/7 d'un GPU H100 pour le script utilisant le GPU) n'ont apporté aucun gain de vitesse supplémentaire, d'après les tests de passage à l'échelle pour l'un ou l'autre script. Au vu de ces résultats, il est probable que le script basé sur le GPU offre des temps de calcul nettement plus rapides que l'utilisation exclusive du CPU pour les autres simulations Rocky autonomes. Comme indiqué sur la page wiki de chaque grappe, ou résumé dans la section Ratios dans les bundles, toutes les grappes, à l'exception de Narval, sont équipées de GPU H100. Par conséquent, lors de l'utilisation du script GPU sur Narval, l'option Slurm --gpus doit être modifiée pour demander un GPU a100. Veuillez noter qu'en mai 2026, seuls les modules ansys/2025R2|2.04 de Rocky ont été testés, et non les modules ansys/2025R1|1.02.
Scripts pour l'ordonnanceur Slurm
#!/bin/bash
#SBATCH --account=account # Specify account (def or rrg)
#SBATCH --time=00-02:00 # Specify time (DD-HH:MM)
#SBATCH --mem=24G # Specify total memory for cores
#SBATCH --cpus-per-task=6 # Specify number of cores to use
#SBATCH --nodes=1 # Request one node (do not change)
module load StdEnv/2023 ansys/2025R2.04 # Specify 2025R1 or newer versions
INPUTFILE="mySim.rocky" # Specify input filename
rm -f $INPUTFILE.lock # Removes old lock files
RESUME=0 # Specify 0 or 1
if [ $RESUME -eq 0 ]; then
rm -rf $INPUTFILE.files/simulation # Removes previous results
Rocky --headless --simulate --resume=0 --ncpus=$SLURM_CPUS_PER_TASK --use-gpu=0 $INPUTFILE
else
Rocky --headless --simulate --resume=1 --ncpus=$SLURM_CPUS_PER_TASK --use-gpu=0 $INPUTFILE
fi
#!/bin/bash
#SBATCH --account=account # Specify account (def or rrg)
#SBATCH --time=00-01:00 # Specify time (DD-HH:MM)
#SBATCH --mem=24G # Specify total memory for cores
#SBATCH --cpus-per-task=2 # Specify number of cores to use
#SBATCH --gpus=h100_1g.10gb:1 # Specify a100_1g.5gb:1 on narval
#SBATCH --nodes=1 # Request one node (do not change)
module load StdEnv/2023 ansys/2025R2.04 # Specify 2025R1 or newer versions
INPUTFILE="mySim.rocky" # Specify input filename
rm -f $INPUTFILE.lock # Removes old lock files
RESUME=0 # Specify 0 or 1
if [ $RESUME -eq 0 ]; then
rm -rf $INPUTFILE.files/simulation # Removes previous results
Rocky --headless --simulate --resume=0 --ncpus=$SLURM_CPUS_PER_TASK --use-gpu=1 $INPUTFILE
else
Rocky --headless --simulate --resume=1 --ncpus=$SLURM_CPUS_PER_TASK --use-gpu=1 $INPUTFILE
fi
Electronics
Voir les exemples de scripts pour l'ordonnanceur dans notre page wiki AnsysEDT.
Graphical use
Pour utiliser un programme Ansys en mode graphique, cliquez sur un des liens ci-dessous.
NIBI,https://ondemand.sharcnet.caFIR,https://jupyterhub.fir.alliancecan.caRORQUAL,https://jupyterhub.rorqual.alliancecan.caNarval,https://jupyterhub.narval.alliancecan.ca/TRILLIUM,https://ondemand.scinet.utoronto.ca
Une page web de soumission de tâche devrait s'afficher dans votre navigateur. Configurez les ressources nécessaires à votre session de bureau interactive et cliquez sur Launch ou Start. Si vous prévoyez d'effectuer des calculs ou des rendus graphiques accélérés dans votre session de bureau, spécifiez une ressource GPU. Chargez un module Ansys sur le bureau. Si vous avez lancé un bureau JupyterLab, cliquez sur l'icône correspondante dans le menu de gauche; autrement, si vous avez lancé un bureau OnDemand manuellement, entrez module load ansys/version dans la ligne de commande. Pour lancer l'un des programmes Ansys courants tels que Fluent, CFX, Workbench, etc., reportez-vous aux sections suivantes qui fournissent des conseils sur la configuration des variables d'environnement et des arguments requis par les environnements graphiques VirtualGL ou Mesa, selon qu'un nœud avec GPU a été spécifié ou non.
Fluent
Pour utiliser Ansys Fluent à partir de la ligne de commande sur un bureau OnDemand, ouvrez une fenêtre de terminal et exécutez
module load StdEnv/2023 ansys/2025R2.04fluent
Lorsque le panneau de sélection du lanceur Fluent apparaît, cliquez sur l'onglet Environment et copiez-collez les paramètres des variables d'environnement de l'une des deux sous-sections suivantes, selon que vous ayez démarré votre session OnDemand avec un GPU ou non. N'incluez pas le texte entre parenthèses, car il s'agit de commentaires, et n'ajoutez pas `export` devant le nom d'une variable. Si la fenêtre de la console graphique est corrompue au démarrage de l'interface graphique, redémarrez Fluent en définissant `HOOPS_PICTURE=null` pour désactiver la création du panneau graphique.
Nœud de calcul (sans GPU)
I_MPI_HYDRA_BOOTSTRAP=ssh(requis sur Nibi avec intelmpi)HOOPS_PICTURE=opengl2-mesa(versions 2025R1 et suivantes)HOOPS_PICTURE=x11/lin(versions 2024R2.04 ou précédentes)- Cliquez sur le bouton Start.
Nœud de calcul (avec GPU)
Pour utiliser l'accélération graphique avec Fluent sur Nibi, sélectionnez un t4 (15Go) dans la liste déroulante de sélection du GPU pour votre session de bureau OnDemand. Ceci fait en sorte que les variables d'environnement utilisées par VirtualGL pour activer l'accélération des appels OpenGL sont automatiquement configurées dans votre environnement de bureau pour la session en cours. Une fois votre bureau affiché, ouvrez une fenêtre de terminal et lancez Workbench comme suit :
I_MPI_HYDRA_BOOTSTRAP=ssh(requis sur Nibi)HOOPS_PICTURE=opengl2(versions 2025R1 ou suivantes)HOOPS_PICTURE=opengl(versions 2024R2.04 ou précédentes)- Cliquez sur le bouton Start.
REMARQUE : Lors de l’exécution de Fluent sur Nibi, la variable d’environnement I_MPI_HYDRA_BOOTSTRAP=ssh doit être définie manuellement, autrement Fluent plantera au démarrage dans les sessions OOD si IntelMPI est utilisé. Un message d’erreur similaire au suivant sera généré. Si cela se produit, quittez complètement Fluent, fermez Workbench proprement et redémarrez-le.
[mpiexec@g4.nibi.sharcnet] poll_for_event (../../../../../src/pm/i_hydra/libhydra/demux/hydra_demux_poll.c:157): check exit codes error [mpiexec@g4.nibi.sharcnet] HYD_dmx_poll_wait_for_proxy_event (../../../../../src/pm/i_hydra/libhydra/demux/hydra_demux_poll.c:206): poll for event error [mpiexec@g4.nibi.sharcnet] HYD_bstrap_setup (../../../../../src/pm/i_hydra/libhydra/bstrap/src/intel/i_hydra_bstrap.c:1063): error waiting for event [mpiexec@g4.nibi.sharcnet] Error setting up the bootstrap proxies
CFX
Au lancement de CFX à partir d'un bureau OnDemand, les arguments suivants peuvent être spécifiés dans la ligne de commande de la fenêtre de terminal. Utilisez ogl si vous avez demandé un GPU au démarrage du bureau et mesa dans le cas contraire.
cfx5 -graphics mesa(sans GPU )cfx5 -graphics ogl(avec GPU)
Mapdl
Pour démarrer l'interface graphique de Mechanical APDL à partir de la ligne de commande d'une fenêtre de terminal, les étapes suivantes devraient fonctionner, que vous ayez démarré votre bureau OnDemand sur un nœud de calcul avec ou sans GPU.
module load StdEnv/2023 ansys/2022R2(ou versions plus récentes)mapdl -g, oulauncherpuis cliquez sur le bouton Run
Workbench
Nous décrivons ici comment démarrer Workbench (et éventuellement Fluent) sur un bureau OnDemand ou un bureau JupyterLab.
Bureau OnDemand
Nœud de calcul (sans GPU) ou bureau de base
Si l'accélération graphique n'est pas requise pour votre session de bureau, spécifiez GPU Node pour sélectionner un nœud de calcul sans GPU pour votre session OOD. Ceci utilise l'émulation logicielle Mesa pour les appels OpenGL, au lieu d'exécuter le programme sur un nœud GPU plus coûteux et plus difficile à réserver.
module load StdEnv/2023 ansys/2025R2.04runwb2
Pour lancer Fluent à partir de Workbench, cliquez sur Fluid Flow (Fluent) ou Fluent with Fluent Meshing dans le menu de gauche Analysis puis cliquez sur Setup au centre de la fenêtre contextuelle Fluid Flow (Fluent). Dans le panneau de sélection Fluent Launcher affiché, cliquez sur l'onglet Environment et copiez-collez les paramètres de variables d'environnement suivants :
I_MPI_HYDRA_BOOTSTRAP=ssh(requis uniquement sur Nibi pour l'utilisation d'IntelMPI)HOOPS_PICTURE=opengl2-mesa(facultatif pour 2025R1 ou versions suivantes)- Cliquez sur le bouton Start.
Nœud de calcul (avec GPU)
Pour utiliser l'accélération graphique sur Nibi, sélectionnez un t4 (15Go) dans la liste déroulante de sélection du GPU pour votre session de bureau OnDemand. Ceci fait en sorte que les variables d'environnement utilisées par VirtualGL pour activer l'accélération des appels OpenGL sont automatiquement configurées dans votre environnement de bureau pour la session en cours. Une fois votre bureau affiché, ouvrez une fenêtre de terminal et lancez Workbench comme suit :
module load StdEnv/2023 ansys/2025R2.04runwb2
Pour lancer Fluent à partir de Workbench, cliquez sur Fluid Flow (Fluent) ou Fluent with Fluent Meshing dans le menu de gauche Analysis puis cliquez sur Setup au centre de la fenêtre contextuelle Fluid Flow (Fluent). Dans le panneau de sélection Fluent Launcher affiché, cliquez sur l'onglet Environment et copiez-collez les paramètres de variables d'environnement suivants :
I_MPI_HYDRA_BOOTSTRAP=ssh(requis uniquement sur Nibi)HOOPS_PICTURE=opengl2-mesa(facultatif pour 2025R1 ou versions suivantes)- Cliquez sur le bouton Start.
Bureau JupyterHub
Nœud de calcul (sans GPU)
1. Dans le menu du bureau à gauche, cliquez pour charger Ansys/2025R1 (ou une version plus récente).
2. Cliquez sur l'icône Workbench (VNC) située dans la fenêtre centrale de JupyterLab.
- Si l'affichage d'une application (comme Fluent) lancée depuis Workbench semble corrompu et inutilisable, suivez les étapes suivantes pour créer une icône personnalisée runwb2 sur le bureau afin de pouvoir démarrer Workbench en mode Mesa. Si l'une des applications que vous allez lancer dans Workbench est Fluent, vous pouvez également essayer de
- définir la variable
HOOPS_PICTURE=opengl2-mesadans la fenêtre Fluent Launcher au lancement de Fluent - définir la variable
HOOPS_PICTURE=opengl2-mesadans la fenêtre Fluent Launcher.
- définir la variable
3. Quittez Workbench et ouvrez une fenêtre de terminal. Copiez/collez la commande suivante dans le Remote Clipboard situé en haut à droite de votre bureau Jupyter cd ~/Desktop; cp -p $(realpath workbench.desktop) workbench-mesa.desktop.
4. Ouvrez le fichier nouvellement créé dans un éditeur de texte tel que nano avec
nano ~/Desktop/workbench-mesa.desktop
5. Modifiez toutes les occurrences de runwb2 et fermez l'éditeur en enregistrant les modifications.
6. Actualisez le bureau Jupyter en appuyant sur la combinaison de touches Ctrl+R. La nouvelle icône devrait maintenant apparaître sur le bureau, à côté de l'icône Workbench d'origine. Double-cliquez dessus pour démarrer Workbench. La nouvelle icône restera affichée pour les sessions suivantes jusqu'à ce que vous la supprimiez manuellement avec
rm -f ~/Desktop/workbench-mesa.desktop
Nœud de calcul (avec GPU)
- Dans le menu du bureau, cliquez sur ansys/2025R1 (ou versions suivantes).
- Dans le menu au centre du bureau Jupyter, cliquez sur l'icône Workbench (VNC).
Ensight
module load StdEnv/2023 ansys/2022R2; A=222; B=5.12.6export LD_LIBRARY_PATH=$EBROOTANSYS/v$A/CEI/apex$A/machines/linux_2.6_64/qt-$B/libensight -X
Rocky
Chargez les modules sivants :
module load StdEnv/2023 ansys/2025R2.04 (ou 2025R1, 2025R1.02, 2025R2)
- La commande
Rockylance Rocky en mode graphique. - La commande
RockySolverexécute le solveur directement sur la ligne de commande. - La commande
RockySchedularlance une interface graphique pour soumettre et exécuter des tâches sur le nœud actif.
Electronics
Voir notre page wiki AnsysEDT.
Site-specific usage
SHARCNET license
The SHARCNET Ansys license is free for academic use by any Alliance researcher on any Alliance system. The installed software does not have any solver or geometry limits. The SHARCNET license may be used for Publishable Academic Research, but not for any private/commercial purposes as this is strictly prohibited by the license terms. The SHARCNET Ansys license is based on the Multiphysics Campus Solution and includes products such as: HF, EM, Electronics HPC, Mechanical, CFD, ROCKY and LS-DYNA as described here. Lumerical software is included in recent Ansys module versions, however it is NOT covered by the SHARCNET license. SpaceClaim software is not installed with any Ansys module since there is no Linux version available; it is technically covered by the SHARCNET license however.
License limits
The SHARCNET Ansys license is made available on a first come first serve basis. It currently permits each researcher to run a maximum of simultaneous 16 jobs using a total of up to 512 HPC cores across all clusters, therefore any of the following maximum job size combinations can be run simultaneously: 1x512, 2x256, 4x128, 8x64, 16x32 or more commonly one of these full node combinations: 1x384, 2x192 or 1x192 cores. Note however that the SHARCNET license is oversubscribed so there is potential for jobs to fail on startup if all (or nearly all) of the 1986 anshpc licenses in the SHARCNET license pool are in use. Should this occur, you will need to manually resubmit your job to the queue. As there have been an increasing number of license shortage (DENIED) instances where jobs fail on startup, the total anshpc core limit per researcher will be decreased from 512 to 384 on April 1, 2026. If you need to use more than 384 HPC cores for your research, either use the local Ansys License server at your institution if one is available, OR open a ticket to request purchasing additional licenses for the SHARCNET license and these would be reserved for your own or your groups exclusive use.
License file
As of February 2026, the license3.sharcnet.ca license server has been permanently shut down. To use the SHARCNET Ansys license on any Alliance cluster, simply configure your ansys.lic file as follows
[username@cluster:~] cat ~/.licenses/ansys.lic
setenv("ANSYSLMD_LICENSE_FILE", "1055@license1.computecanada.ca")License query
To show the number of Ansys licenses in use by your username and the total in use by all users, run
ssh nibi.alliancecan.ca
module load ansys
$EBROOTANSYS/v$(echo ${EBVERSIONANSYS:2:2}${EBVERSIONANSYS:5:1})/licensingclient/linx64/lmutil \
lmstat -c $ANSYSLMD_LICENSE_FILE -a | grep "Users of\|$USER" | grep -v " Total of 0 licenses in use"Example
Consider the case where a user submits an 8-core Fluent job and 32-core Fluent job. Once both jobs start running, the user runs the lmutil query command and the output shown below is generated. Here, we see that a total of (8-4) + (32-4) = 32 anshpc licenses are used by the two jobs. As a result the total number of licenses increases from 1568 to 1600 so that only (1986-1600) = 386 of them remain available for additional jobs submitted by all users. Therefore, if a 400-core parallel job attempts to start at that moment, it will fail to start since (400-4) = 396 anshpc licenses would be required. The user has two options, either wait for a sufficient number of licenses to come available OR reduce the job size to 390 cores or less and resubmit immediately. This example focuses on the anshpc feature since it is most generously overcommitted to allow any user to submit the largest job possible, but it also shows that the actual number of licenses available per user may sometimes be far less than the 512 per user limit would suggest.
[l2(nibi):~] sq
JOBID USER ACCOUNT NAME ST TIME_LEFT NODES CPUS MIN_MEM NODELIST (REASON)
10161023 roberpj cc-debug_cpu script-flu-int R 2:57:19 4 8 N/A 4G c[630-633] (None)
10161033 roberpj cc-debug_cpu script-flu-int R 2:58:25 16 32 N/A 4G c[627-628,630-633,637,642,645,655,657,662,665,667,669,682] (None)
[l2(nibi):~]
[l2(nibi):~] module load ansys
[l2(nibi):~]
[l2(nibi):~] $EBROOTANSYS/v$(echo ${EBVERSIONANSYS:2:2}${EBVERSIONANSYS:5:1})/licensingclient/linx64/lmutil \
lmstat -c $ANSYSLMD_LICENSE_FILE -a | grep "Users of\|$USER" | grep -v " Total of 0 licenses in use"
Users of anshpc: (Total of 1986 licenses issued; Total of 1600 licenses in use)
roberpj c630 c630.nibi.sharcnet 1238925 (v2025.0506) (license1.computecanada.ca/1055 2579), start Wed 3/11 16:46, 4 licenses, PID: 1239140
roberpj c627 c627.nibi.sharcnet 509821 (v2025.0506) (license1.computecanada.ca/1055 5716), start Wed 3/11 16:48, 28 licenses, PID: 510058
Users of cfd_base: (Total of 275 licenses issued; Total of 19 licenses in use)
roberpj c630 c630.nibi.sharcnet 1238925 (v2025.0506) (license1.computecanada.ca/1055 10327), start Wed 3/11 16:46, PID: 1239140
roberpj c627 c627.nibi.sharcnet 509821 (v2025.0506) (license1.computecanada.ca/1055 7171), start Wed 3/11 16:47, PID: 510058
Users of cfd_preppost: (Total of 275 licenses issued; Total of 1 license in use)
Users of cfd_preppost_pro: (Total of 275 licenses issued; Total of 1 license in use)
Users of cfd_solve_level1: (Total of 275 licenses issued; Total of 18 licenses in use)
roberpj c630 c630.nibi.sharcnet 1238925 (v2025.0506) (license1.computecanada.ca/1055 7994), start Wed 3/11 16:46, PID: 1239140
roberpj c627 c627.nibi.sharcnet 509821 (v2025.0506) (license1.computecanada.ca/1055 6200), start Wed 3/11 16:47, PID: 510058
Users of cfd_solve_level2: (Total of 275 licenses issued; Total of 18 licenses in use)
roberpj c630 c630.nibi.sharcnet 1238925 (v2025.0506) (license1.computecanada.ca/1055 10520), start Wed 3/11 16:46, PID: 1239140
roberpj c627 c627.nibi.sharcnet 509821 (v2025.0506) (license1.computecanada.ca/1055 375), start Wed 3/11 16:47, PID: 510058
Users of elec_solve_hfss: (Total of 275 licenses issued; Total of 1 license in use)
Users of elec_solve_level1: (Total of 275 licenses issued; Total of 1 license in use)
Users of elec_solve_level2: (Total of 275 licenses issued; Total of 1 license in use)
🕵 A rare situation can occur where the output from the license query command reveals there are some Ansys licenses unexpectedly still in use by your username on some desktop or compute node. This would happen if for instance an Ansys GUI program run on a remote desktop node was not shut down cleanly, leaving some Ansys processes still running, or an Ansys program crashes on a cluster compute node inside ansallocsession that was being run interactively from the command line, once again leaving some rogue Ansys processes still running. To kill all potentially responsible Ansys rogue processes, either close the desktop,scancelthesallocsession, or simply open a terminal window on the affected node and issue thepkill -9 -e -u $USER -f "ansys"command. Any Ansys licenses that were being held open should immediately be returned to the SHARCNET license server and become available for use again by yourself or other researchers.
Additive Manufacturing
To get started, configure your ~/.licenses/ansys.lic file to point to a license server that has a valid Ansys Mechanical license. This must be done on all systems where you plan to run the software.
Enabling Additive
This section describes how to make the Ansys Additive Manufacturing ACT extension available for use in your project. The steps must be performed on each cluster for each Ansys module version where the extension will be used. Any extensions needed by your project will also need to be installed on the cluster as described below. If you get warnings about missing un-needed extensions (such as ANSYSMotion), uninstall them from your project.
Downloading extensions
- download AdditiveWizard.wbex from https://catalog.ansys.com/,
- upload AdditiveWizard.wbex to the cluster where it will be used.
Starting Workbench
- follow the Workbench section in Graphical use above,
- File -> Open your project file (ending in .wbpj) into the Workbench GUI.
Opening the extensions manager
- click on the ACT start page and the ACT home page tab will open,
- click Manage Extensions and the extensions manager will open.
Installing extensions
- click on the box with the large + sign under the search bar,
- navigate to select and install your AdditiveWizard.wbex file.
Loading extensions
- click to highlight the AdditiveWizard box (loads the AdditiveWizard extension for the current session only),
- click on the lower right corner arrow in the AdditiveWizard box and select Load extension (loads the extension for current AND future sessions).
Unloading extensions
- click to un-highlight the AdditiveWizard box (unloads extension for the current session only),
- click on the lower right corner arrow in the AdditiveWizard box and select Do not load as default (extension will not load for future sessions).
Running Additive
OnDemand
You can run a single Ansys Additive Manufacturing job in a graphical OnDemand session by following these steps:
- Start Workbench as described above in Enabling Additive;
- click on File -> Open, select test.wbpj and click on Open;
- click on View -> reset workspace if you get a grey screen;
- start Mechanical, clear generated data, tick Distributed, specify cores;
- click on File -> Save Project -> Solve.
Check utilization
- open another terminal and run
top -u $USER**OR**ps u -u $USER | grep ansys, - kill rogue processes from previous runs with
pkill -9 -e -u $USER -f "ansys|mwrpcss|mwfwrapper|ENGINE".
Please note that rogue Ansys-related processes can persistently tie up valuable licenses inside a running OnDemand login node session if an Ansys GUI session (Fluent, Workbench, Mechanical, etc.) is not cleanly terminated or is terminated unexpectedly by a network outage or a hung filesystem. If the latter is to blame, the processes may not by killable until normal disk access is restored.
Cluster
Project preparation
Before submitting a newly uploaded Additive project to a cluster queue (with sbatch scriptname), certain preparations must be done. To begin, open your simulation with the Workbench GUI (as described in the Enabling Additive section above) in the same directory that your job will be submitted from and then save it again. Be sure to use the same Ansys module version that will be used for the job. Next, create a Slurm script (as explained in the Cluster Batch Job Submission - WORKBENCH section above). To perform parametric studies, change Update() to UpdateAllDesignPoints() in the Slurm script. Determine the optimal number of cores and memory by submitting several short test jobs. To avoid needing to manually clear the solution and recreate all the design points in Workbench between each test run, either 1) change Save(Overwrite=True) to Save(Overwrite=False) or 2) save a copy of the original YOURPROJECT.wbpj file and corresponding YOURPROJECT_files directory. Optionally, create and then manually run a replay file on the cluster in the respective test case directory between each run, noting that a single replay file can be used in different directories by opening it in a text editor and changing the internal FilePath setting.
module load ansys/2019R3
rm -f test_files/.lock runwb2 -R myreplay.wbjn
Resource utilization
Once your Additive job has been running for a few minutes, a snapshot of its resource utilization on the compute node(s) can be obtained with the srun command. Sample output corresponding to an eight-core submission script is shown next. We see that two nodes were selected by the scheduler:
[gra-login1:~] srun --overlap --jobid=myjobid top -bn1 -u $USER | grep R | grep -v top
PID USER PR NI VIRT RES SHR S %CPU %MEM TIME+ COMMAND 22843 demo 20 0 2272124 256048 72796 R 88.0 0.2 1:06.24 ansys.e 22849 demo 20 0 2272118 256024 72822 R 99.0 0.2 1:06.37 ansys.e 22838 demo 20 0 2272362 255086 76644 R 96.0 0.2 1:06.37 ansys.e PID USER PR NI VIRT RES SHR S %CPU %MEM TIME+ COMMAND 4310 demo 20 0 2740212 271096 101892 R 101.0 0.2 1:06.26 ansys.e 4311 demo 20 0 2740416 284552 98084 R 98.0 0.2 1:06.55 ansys.e 4304 demo 20 0 2729516 268824 100388 R 100.0 0.2 1:06.12 ansys.e 4305 demo 20 0 2729436 263204 100932 R 100.0 0.2 1:06.88 ansys.e 4306 demo 20 0 2734720 431532 95180 R 100.0 0.3 1:06.57 ansys.e
Scaling tests'
After a job completes, its wall-clock time can be obtained with seff myjobid. Using this value, scaling tests can be performed by submitting short test jobs with an increasing number of cores. If the wall-clock time decreases by ~50% when the number of cores is doubled, additional cores may be considered.
Help resources
The official full documentation for recent versions Ansys 202[4|5]R[1|2] is available here. Documentation for older versions such as Ansys 2023R[1|2] however requires login. Developer documentation can be found in the Ansys Developer Portal. Additional learning resources include the Ansys HowTo videos, the Ansys Educator Hub and the Ansys Webinar series.
XoverSSH Legacy Note: Some programs can be run remotely on a cluster compute node by forwarding X over SSH to your local desktop. Unlike VNC, this approach is not tested and not supported since it relies on a properly set up X display server for your particular operating system OR the selection, installation and configuration of a suitable X client emulator package such as MobaXterm. Most users will find interactive response times unacceptably slow for basic menu tasks, let alone for more complex tasks such as those involving graphics rendering. Startup times for GUI programs can also be very slow depending on your Internet connection. For example, in one test it took 40 minutes to fully start the GUI over SSH while starting it with vncviewer required only 34 seconds. Despite the potential slowness, using this method to connect may still be of interest if your only goal is to open a simulation and perform some basic menu operations or run some calculations, and response delays can be tolerated. The basic steps are given here as a starting point: 1) ssh -Y username@alliancecan.ca 2) salloc --x11 --time=1:00:00 --mem=16G --cpus-per-task=4 [--gpus-per-node=1] --account=def-mygroup; 3) once connected onto a compute node, try running xclock. If the clock appears on your desktop, proceed to load the desired Ansys module and try running the program.