Fluent
Getting started with Ansys Fluent¶
If you have no previous experience with Ansys Fluent, we recommend that you first learn about the software on your own computer before trying it out on DelftBlue. You are also expected to have some background in fluid mechanics and Computational Fluid Dynamics. To get started with Fluent, for instance try the tutorials from Cornell University. You have to register but it is free of charge.
It is most efficient to do the tutorials locally, on your own desktop or laptop. Ansys Fluent can be downloaded from BrightSpace.
An example on DelftBlue¶
To show how a case can be run in the queue on DelftBlue, we have made available a working (runnable) example, which you can download from HERE. It simulates the 2D instationary flow over a square cylinder using incompressible flow.
The fluent parameters are in file script, which is read in by fluent.
The queue/SLURM parameters are in file runme, the batch script.
The job is submitted by typing
sbatch runme
followed by enter.
Note, that fluent runs either on part of one node, or on a number of complete nodes. The number of nodes needs to be specified, just specifying the number of cores or tasks does not work, at least for fluent versions 2023 and lower.
When the job runs properly, output will be similar to the file example_output. You can see that several actions are taken:
-- the case and data file are read in -- a number of time-steps is taken, for each time-step a number of iterations are performed. -- at the end of the job, case and data are written
Some rules of thumb for memory (RAM) and core usage:
-- fluent uses between 2-5GB of total RAM per million grid points. Take this into account when you determine how much RAM your job needs.
-- fluent may run faster on more cores, but note that when you calculate on more nodes the cores also need to communicate more with each other. You will note that when you keep increasing the number of cores, after a certain amount of cores the model hardly goes faster; it may even become slower if the communication costs start to dominate! It is recommended to have at least between 50.000 and 100.000 grid points per core (it depends on the kind of solver) so that the communication costs do not dominate over the calculation costs. It is recommended to try out (for instance) using 1 core, 2cores, 4 cores etc and then see how many cores still make sense. The result may look like this:
time #cores 120 1 60.5 2 32 4 19 8 18 16
note that I wrote "time", not "CPU time"; on a parallel machine (=machine with multiple cores), you get "access time" or "residence time" on a core rather than "CPU time"; you make a reservation for a number of cores, and then nobody else can use them, whether you actually calculate on the or not; for this reason, you are charged for "residence time" rather than "CPU time"
as you see in the table, going from 8 to 16 cores hardly makes a difference in time; then it is more efficient to do two jobs on 8 cores instead of a job on 16, and the second one after that also on 16
How well a code speeds up with the number of cores is described as "parallel efficiency" The parallel efficiency of codes like OpenFOAM and ansys Fluent is moderate (not really bad, but also not really good).
Also note, that if you ask a lot of cores without making your code faster, other people cannot use the cores you use. Moreover, if you needlessly ask for more cores, your job has to wait longer before it starts.