Fluent

Overview

Ansys Fluent is a computational fluid dynamics application. Fluent version v19.3 (i.e. 2019r1) is available.

Restrictions on Use

Only users who have been added to the Fluent group can run the application. Owing to licence restrictions, only users from the School of MACE and one specific CEAS Research Group can be added to this group. Requests to be added to the Fluent group should be submitted please via our form.

The maximum job size is 16 cores (this is a limitation imposed by the license).

Fluent jobs must not be run on the login node. If you need to run an interactive job please use srun as detailed below.

Set Up Procedure

Once you have been added to the Fluent group, you will be able to access the executables by using one of the following module commands:

module load fluent/2024R2
module load fluent/2022R1
module load fluent/19.3
module load fluent/19.2

Required Input Files

To run a fluent job you will need a fluent journal file, a fluent case file and usually a data file which the case file will load.

Journal (.jou) files

The journal file can be created either by asking fluent to write it while using the fluent GUI (which can be run from the CSF or from a desktop PC installation). Alternatively, the journal file can be written by hand. This is common – they are often very simple files which load the case and data files, then start the simulation. Here are two examples:

For transient cases:

rc filename.cas
rd filename.dat
solve dual-time-iterate 40000 200

where 40000 is the number of time steps and 200 is the max number of iterations per time step.

For steady-state cases. This also demonstrates how to use gzip compressed .cas and .dat files:

rc filename.cas.gz
rd filename.dat.gz
it 200

where 200 is the number of iterations. The case and data files were first compressed using the following commands to reduce the size of the files. When the job runs, Fluent will be able to uncompress the files to read them:

gzip filename.cas
gzip filename.dat

UDF Files

If you need to compile a User Defined Function (UDF) file, this should be done on the CSF. Fluent will usually do this automatically when your job runs provided you have saved the case file with the UDF enabled in the GUI (See the Define / User-Defined / Function Hooks menu. You can check your case has the correct line in it as follows:

# For an normal (uncompressed) .cas file
grep libudf filename.cas

# For a compressed .cas.gz file
zgrep libudf filename.cas.gz

These commands should print something similar to the following if you are using a UDF

(udf/compile/files (("libudf" (source "/scratch/username/my_project/my_udf.c") (header))))

Note that the path to the .c file will need to be correct for the CSF, otherwise fluent will not be able to find the file. If you saved your case file on a Windows PC it could have a path that is only valid on that PC. You DO NOT need to edit your .cas file to add the above line. You can use the Fluent GUI to re-save your case file on the CSF with the correct path.

Alternatively, you might be able to add some lines to the journal file. However, there are many possible options – too many to list here – so we recommend using the Fluent GUI to make the settings. However, here is an example of lines added to the .jou file for a specific type of UDF:

# Add the following to the .jou file to enable the UDF
/define user-defined compiled-functions compile libudf yes my_udf.c
/define user-defined compiled-functions load
/define user-defined function-hooks DPM_BC my_udf::libudf
                                      #
                                      # This example uses a Discrete Phase Model
                                      # Boundary Condition UDF

Compiling the UDF code

You UDF source code (e.g., my_udf.c) must be compiled in to a library that Fluent can read. Please note, if you have compiled it on a Windows PC, the library will NOT work on the CSF. You must recompile it on the CSF.

You can either let Fluent compile the UDF code when your job runs, or you can compile it on the CSF before your job runs then fluent won’t need to do it itself. This is also a good way to check your UDF code actually compiles! If you wait until fluent compiles it (when your job runs), any mistakes in your code will mean you have to fix the code then resubmit the job. It is much easier to try to compile the UDF on the login node before the job runs and make any corrections to the code if you need to do so.

If you wish to check your UDF code compiles on the CSF before submitting a job to the batch system, you can run a helper script named csf_compile_udf on the CSF to do the UDF compilation:

csf_compile_udf simtype1 simtype1_node simtype1_host ...

# Example 1: Compile for a 3ddp (3D double-precision) simulation:
csf_compile_udf 3ddp 3ddp_node 3ddp_host

# Example 2: Compile for a 2d (2D single-precision) simulation:
csf_compile_udf 2d 2d_node 2d_host

# For more info:
csf_compile_udf --help

This script will compile your my_udf.c file (the script searches for .c files in the current directory and checks whether they appear to be Fluent UDF files) in to a libudf.so file. It will create a new sub-directory named libudf in the current directory (where you run the script). Each simulation type (2d, 3ddp, …) will have its own libudf.so file in directories inside the libudf/ sub-dir.

Running Fluent in Parallel in batch

Please note: the versions of fluent available do not currently support automatic job-submission to SLURM. Hence you must write a SLURM jobscript and submit it using the sbatch command.

For example, the following jobscript file named fluent-batch.slurm:

#!/bin/bash --login
# Job will run in the current directory by default
#SBATCH -n 8            # 8 cores. Can also use --ntasks=8
#SBATCH -p multicore    # Single-node parallel job

# The default output file will be slurm-JOBID.out. To use a SGE-style filename:
#SBATCH -o %x.o%j       # Output file similar to CSF3: jobscriptname.oJOBID

# Choose your required version
module load fluent/19.3

fluent 3d -g -t$SLURM_NTASKS -i input.jou
        #                             #
        #                             #
        #                             # Replace input.jou with your input file.
        #
        # If using an UDF this must match the type used for compilation
        # (e.g., 2d or 3d or 3ddp). You should not use the _node or _host
        # type here.

Submit the job using:

sbatch fluent-batch.slurm

You can then check on the status of the job using

squeue --me

The maximum job size you can request is 16 due to licensing restrictions.

Running Serial Interactive Jobs via srun

The running of serial, interactive jobs is tolerated. This is mainly used to set up a simulation which can then be saved to file and run in batch. You may need to use the GUI to set up a UDF. If you are setting up a parallel UDF please contact us via our form.

You may run fluent interactively using the srun option which has a time limit of 1 hour.

Starting Fluent interactively

srun -n 1 --pty bash

Then, once srun has returned a commandline on a compute node, load the appropriate environment module and start Fluent:

module load fluent/19.3          # Load the modulefile for the version you require
fluent &     ## The & ensures you get your command line and the GUI at the same time.

Notes:

1. Linux: if the render window section of the GUI does not display your model try setting the following before running fluent:

   export LIBGL_ALWAYS_INDIRECT=1

2. alternatively run fluent using:

   fluent -driver x11

3. Windows: if the render window is slow to redraw or flashes try running fluent using:

   fluent -driver x11

Note: For the GUI to work you must have an X server running on your PC. See the instructions on the using GUI based applications page.

Further Information

Further information on Fluent and other CFD applications may be found by visiting the MACE CFD Forum.

More information about srun on the CSF.