updated: 2004-04-15 RE
This document describes how to run all Fluent programs (Fluent, Mixsim, Icepack, Airpack, Polyflow and Fidap) on local PC's running MS-Windows and Linux, and on the NTNU HPC machines gridur.ntnu.no and embla.ntnu.no. The document also describes how to best combine pre- and post-processing on MS-Windows and Linux plattforms with simulations done on the NTNU HPC machines. Contributions by Arild Gustavsen (NTNU), Jørn Amundsen (NTNU), Paal Skjetne (SINTEF) and Rune Engeskaug (SINTEF).
Check fluent license usage here.
NB! You need to be a member of the fluent group and load the fluent modulefile for Fluent to work as described on the NTNU HPC machines.
Fluent and Gambit are easily installed on your local PC's on the MS-Windows platform. You can obtain the programs either from "progdisk" or on a CD-rom (Software distribution). Then it is just to install the Fluent programs you need on your system. But remember, if you wish to use Gambit, you also need the Xwindow program "Exceed" on your local computer (also on progdisk/CD-rom).
After installation of the programs, you have to do one of the following two things:
Voilà! Fluent and Gambit works on your PC (Gambit has to be started from "Command prompt" in WinXX). This is tested on Win 2000/XP (Win NT is not supported anymore).
Fluent and Gambit are easily installed on your local PC's on the Linux platform. You can obtain the programs either from "progdisk" or on a CD-rom (Software distribution). Then it is just to install the Fluent programs you need on your system following the cookbook on how to do it in Linux, which is found here: How to install Fluent & Gambit on Linux.
After installation of the programs, you have to do the following task:
(You have to change the licensefile once a year. The licensefile is located on balder.ntnu.no.)
Voilà! Fluent & Gambit works on your Linux PC. This is tested on Linux Redhat 7.2.
Users need SSH to be able to login on the different machines (e.g. gridur.ntnu.no, embla.ntnu.no or balder.ntnu.no). We recommend F-Secure SSH if you login from MS-Windows 95/98/NT/2000/ME/XP.
If you are running under MS Windows 95/98/NT/2000/ME/XP you need Xwindow software (e.g. Exceed or PC-Xware) to be able to display the graphical output from FLUENT. The Xwindow server has to be started under Windows before you start FLUENT or GAMBIT in the SSH terminal window on gridur/embla.
You may need to tell the system which workstation you are using:
- Under bash you do this by: gridur@user> export DISPLAY=xxx.xxx.xxx.xxx:0
- and with tcsh: gridur@user> setenv DISPLAY xxx.xxx.xxx.xxx:0
where xxx.xxx.xxx.xxx is your IP number (use the command "ipconfig" in the command prompt window to find the IP number). Notice that the DISPLAY variable should be set correctly by SSH on login, and you should normally not need to change this.
If the DISPLAY variable not is correctly set on login when using F-Secure SSH, this can be accomplished by checking "Tunnel X11 connections" under Settings. You should, however, notice that automatically setting of the DISPLAY variable through SSH results in an encrypted connection. We have noticed that using the DISPLAY variable automatically set up by SSH (as opposed to using the IP-number) results in a considerably slower connection when it comes to transferring graphical data across the network. Using the IP-number DISPLAY variable may for instance decrease the time required to start GAMBIT by a factor of 5! If you use Linux, we suggest a solution that can be found here.
Users planning to run large problems on several (more than 5) processors should post a message on the NTNU Fluent newsgroup (see Resources below).
Commands that may be of interest:
bqueues shows queue usage status displays the machine job mix bjobs or bjobs -l status (long status) on your jobs bkill to terminate a running job top ( -U username) top processes (machine load)
Type "man command" to learn more about the above commands.
Version selection is conducted by issuing "module load ver". Currently the following versions may be selected:
fluent.5.4.8 fluent.6.0.12 fluent.6.1.22 (Fluent 4.5 is not supported anymore, but if you have any particular interest in this fluent version, please contact Rune Engeskaug)
The module command may either be issued at the command prompt or in batch scripts. In addition, to ease module loading, the following links currently exist:
fluent -> fluent.6.1.22 fluent5 -> fluent.5.4.8 fluent6 -> fluent.6.1.22 (fluent.6.0.12 -> fluent.6.0.12)
That means that "module load fluent", "module load fluent6" and "module load fluent.6.1.22" currently load the same module. Note that the above links may change without notice (check this web-page frequently to see the latest current configuration).
Note that interactive processes will be terminated after 30 cpu-minutes. That also includes processes started as a background process ("program &"). Programs need to be started with the batch system LSF to run for a longer period of time (more then 30 CPU-minutes).
Users need SSH to be able to login on the different machines. To start FLUENT the user needs to run:
user@gridur> module load fluent
once after login. To start FLUENT in interactive mode with GUI (Graphical User Interface) write:
user@gridur> fluent
Now chose desired solver by File -> Run
That's it! You are ready to get some work done!
Tip: Neither gridur nor embla handles interactive prosesses very well. The reason for this is that these are number crunching machines, noting else. So, the recommended procedure for running fluent or gambit are as follows:
(See chapter 3.6 Pre- and post-processing on MS-Windows 95/98/NT/2000/ME/XP or Linux)
Below we describe how to run FLUENT as a batch job in parallel. The user should note that simulating a case in parallel is not necessary for smaller problems, taking less than about 10 minutes to simulate. These problems can either be simulated interactively (without using the parallel solver) or submitted to the batch system sequentially. A small section describing how this can be done can be found after the paragraph below.
To be able to use the batch program you need to start FLUENT without GUI. Issuing the following command can do this:
gridur@user> fluent 3ddp -p -t10 -g
Here we start FLUENT's 3D double precision solver (3ddp) in parallel modus (-p). We tell FLUENT to use 10 processes, or processors, (-t10), and to run without using the GUI (-g). Other options are also available. These are described in FLUENT's Users Manual Chapter 1.5.4 and 23. (Running FLUENT on a cluster of workstations require other parameters!)
Above we just started a parallel version of FLUENT without a GUI. To run FLUENT as a batch job we also need to tell FLUENT what to do. This is done with journal files (described in detail in Chapter 3.8 of FLUENT's Users Guide). A journal file contains a sequence of FLUENT commands, arranged as they would be typed interactively into the program or entered through the GUI. However there is a small "problem" with using journal files. A journal file is just a simple playback facility, it knows nothing about the state in which it will be played. If, for instance, you are trying to save a file and that file already exists you will need to confirm with a "yes", before you continue with your commands. If the file not exists you do not include the "yes" statement. An example journal file (fluent.jou) is shown below (the comments in brackets should not be included in the original file):
file read-cas-data test_file [Reading both a case and a data file]
solve dual-time-iterate [Solving a transient problem]
2000 [Number of timesteps]
40 [Number of iterations per timestep, maximum]
yes [Answer yes to a question whether I want to
append data to monitor file 1 or not]
yes [Answer yes to a question whether I want to
append data to a monitor file 2 or not]
file write-case-data test_file [Save case and data files after simulation]
exit [exit FLUENT]
The two yes commands would not be there if the monitor files not existed. As you understand it is a good idea to walk trough the process manually before starting a journal file. The problem above has here been set up in advance with an initial solution in the data file. The problem to be solved in the journal file above then needs to be submitted to the batch system. Writing the following script does this (fluent.bsub):
#! /bin/sh #BSUB -q monster [Specifies type of queue] #BSUB -o fluent.out [Specifies standard output file] #BSUB -e fluent.err [Specifies error file] #BSUB -k "/cpr 999999" [Turn off automatic checkpointing] #BSUB -n 10 [Number of processes] module load fluent [Loads the fluent module] fluent 3ddp -i fluent.jou -p -t10 -g [Start FLUENT]
The number of processes in the 6th line should match the number of processes started with FLUENT in the last line. The 5th line must be included since FLUENT to this date does not work with automatic checkpointing. (Checkpointing allows a job to be restarted from a checkpoint image if the machine goes down or is shut down in the middle of a job execution.) The last line in the script shows how FLUENT reads the journal file. We now start the FLUENT job with:
gridur@user> bsub <fluent.bsub
The fluent.bsub file above tells bsub to save both output and error files. However, these files are not saved until the job has completed. To check how your process is doing it sometimes is necessary to look at the output files during execution. This can be done by looking at your standard output and standard error files in the /work directory. To do this, type "bjobs" to list your jobs. Then look at the output file by typing:
gridur@user> less /work/*<id>.out
where <id> is the numeric job id returned from "bjobs". The error output is stored in a file with .err suffix. By using the monitoring options in FLUENT (see e.g. chapter 17.15 in the FLUENT User's Guide) it is also possible to check how your job is doing.
New, New, New:
Due to a recent change in the Notur system, please read and follow this paragraph. (Later this spring a rewritten chapter 3.4, where the topic in this paragrah is taken in account, will be posted)
To make I/O more efficient always copy your inputfiles to the /work/$LOGNAME directory. Also temporary store outputfiles at this location. After job execution move the outputfiles to your home directory. Notice that files which have not been accessed for a certain amount of time, normally 14 days, will be automatically deleted, this is subject to change but it is not expected to be less than a week.
For more information of this subject read: http://notur.ntnu.no/support/batch.html#Sample
Smaller problems do not require parallel execution. To start the serial version of FLUENT (using only one processor) instead of the parallel version the user will have to omit the -p -t10 options used above. Thus, to start the three-dimensional double precision version of FLUENT in interactive mode without GUI write:
gridur@user> fluent 3ddp -g
The problems can be submitted to the batch system similar to the example described above. If the user has two (or more) cases that are to be simulated, each just taking about 5 minutes on one processor, the following journal file can be used (leave out comments in brackets):
file read-cas-data test_file1 [Reading both a case and a data file]
solve iterate [Solving a stationary problem]
200 [Maximum number of iterations]
file write-case-data test_file1 [Save case and data files after simulation]
yes [Answer yes to question whether or not to
overwrite current case and data files]
file read-cas-data test_file2 [Reading both a case and a data file]
solve iterate [Solving a stationary problem]
200 [Maximum number of iterations]
file write-case-data test_file2 [Save case and data files after simulation]
yes [Answer yes to question whether or not to
overwrite current case and data files]
exit [exit FLUENT]
This journal file requires the following batch script:
#! /bin/sh #BSUB -q quick [Specifies type of queue] #BSUB -o fluent.out [Specifies standard output file] #BSUB -e fluent.err [Specifies error file] #BSUB -k "/cpr 999999" [Turn off automatic checkpointing] #BSUB -n 1 [Number of processes] module load fluent [Loads the fluent module] fluent 3ddp -i fluent.jou -g [Start FLUENT]
New, New, New:
Due to a recent change in the Notur system, please read and follow this paragraph.
To make I/O more efficient always copy your inputfiles to the /work/$LOGNAME directory. Also temporary store outputfiles at this location. After job execution move the outputfiles to your home directory. Notice that files which have not been accessed for a certain amount of time, normally 14 days, will be automatically deleted, this is subject to change but it is not expected to be less than a week.
For more information of this subject read: http://notur.ntnu.no/support/batch.html#Sample
When running GAMBIT and Fluent on MS-Windows 95/98/NT/2000/ME/XP or Linux, the license file has to be copied to the license directory inside your fluent directory. The license file has to be dowloaded from balder.ntnu.no (see chapters 1. MS-Windows or 2. Linux).
Pre- and post-processing and test simulations should generally be done on local workstations. When your case files are ready, they can be transferred to gridur.ntnu.no/embla.ntnu.no. Notice the following when MS-Windows is used for pre- and post-processing:
Exceed is not needed if you use Linux. Further:
A complete example with all files, including Fluent case- and data-files, can be found on balder/gridur, located in the directory $FLUENT_INC/Fluent_Tutor. Copy the necessary files with "cp" on balder\gridur or use wget to download from the web server (type wget --help for help).
This case is similar to the problem described above, but is two-dimensional. Further it is partitioned in three instead of ten and is run in the normal queue. Thus, we only use three processes to solve this problem. The *.out files are monitor files (defined under Solve->Monitor->Surface) that have been created in a previous run. Also the data file are from the previous run. If there had been no previous run we would not need the two yes statements in fluent.jou, telling FLUENT to append data to the monitor files. Also note that if we had saved the simulated results in a file with the same name as the data/case files from before the simulation, we would need another "yes" statement before the "exit" command.
NB! You need to uncompress .gz files with "gunzip" before use !
Our campus-licenses for Fluent and Gambit (and any other Fluent products) are for academic research only. But they can, with special precautions, be used in commercial projects by NTNU/SINTEF employees. Prices for running Fluent software in commercial projects with the campus-licenses are as follows:
| One week | 8000 |
| Two weeks | 13080 |
| One month | 22050 |
| Tree months | 56700 |
| Six months | 94500 |
| One year | 189000 |
All prices are for one node/license, in SEK (Swedish kroner) and they are valid for 2004 (they could be changed without warning). For more information about this, please contact either: Rune Engeskaug, Paal Skjetne or Jørn Amundsen.
Software shall be obtained through the FLUENT contact at your department (see below). Contacts may dowload software from progdisk (local software distribution server at NTNU) or Fluent User Services Center. The contact may also obtain a CD-ROM from Rune Engeskaug or Jørn Amundsen.
| Institutt/Avdeling | Lisenser | Kontaktperson |
|---|---|---|
| Inst. for bygg- og anleggsteknikk | 4 | Arild Gustavsen |
| Inst. for energi og prosessteknikk | 12 | Ole Martin Hansen |
| Inst. for kjemisk prosessteknologi | 4 | Rune Engeskaug (for Hallvard Svendsen) |
| Inst. for produktutvikling og materialer | ? | Claes-Gøran Gustafson |
| Inst. for marin teknikk | 3 | Bjørnar Pettersen |
| Inst. for materialteknologi og elektrokjemi | 2 | Leiv Kolbeinsen |
| Inst. for materialteknologi | ? | Torsten Berning |
| Inst. for teknisk kybernetikk | ? | Thor I. Fossen |
| SINTEF Bygg og miljø, Arkitektur og byggteknikk | 1 | Bjørn Jenssen Wachenfeldt |
| SINTEF Energiforskning AS | 3 | Øyvind Langørgen |
| SINTEF Materialer og kjemi | 8 | Leif Rune Hellevik & Paal Skjetne |
| SINTEF Materialteknologi | 1 | Terje Glomsaker |