Fluent FAQ

This is a short FAQ on using the computational-fluid dynamics (CFD) code "Fluent" on the Sun Fire cluster. This software is only licensed for academic researchers who work in a department that is already covered by a Fluent license. The software is only made available to persons who belong to a specific Unix group. See details below.


Questions:

  1. What is "Fluent"?

  2. Where is "Fluent" located and how do I access it?

  3. How do I use "Fluent"?

  4. How do I set up and submit "Fluent" batch jobs?

  5. How do I setup and execute a "Fluent" parallel batch job?

  6. Where can I get further help?

Answers:

  1. What is "Fluent"?

    Fluent is a suite of programs that model systems in computational fluid dynamics (CFD). This includes flows in two- and three-dimensional geometries, and under a variety of conditions: compressible and incompressible; inviscid, laminar and turbulent; Newtonian and non-Newtonian. The analysis can be steady-state or transient. Fluent simulates convective, coupled and radiative heat transfer, it can account for the mixing and reaction of chemical species, and for arbitrary sources of heat, mass, turbulence and momentum. Calculations employ stationary or rotating frames of reference, and a variety of meshes.
    Fluent can be used interactively and supplies a graphical user interface. It can also run in batch mode, if the required time for solving a problem is too long for interactive use. The latter situation is the standard if you are using Fluent on the Sun Fire machines.
    The Fluent package consists of several programs: "Fluent", the solver; "prePDF", a preprocessor for modeling combustion; "GAMBIT", a preprocessor for modelling geometries and generating meshes; "TGrid", creating volume meshes from boundary meshes; several filters to import meshes from other CAD packages.

    Back to Top...

  2. Where is "Fluent " located and how do I access it?

    The present version of Fluent is 6.3. The programs in the Fluent package are located in the directory /opt/fluent/Fluent.Inc/.
    To use Fluent on the HPCVL Sun Fire's, you have to be covered by a Fluent license outside of HPCVL, i.e. you have to be a "licensed trained University User of Fluent". It is furthermore required that you read our licensing agreement, and sign a statement. We will confirm your statement, and you will then be made a member of a Unix group "fluent", which enables you to run the software. Contact us if you are in doubt of whether you will be able to run Fluent on our system.
    The Fluent license is "seat limited" and "process limited". At present, there are 24 Fluent seats available on our system, i.e. 24 separate sessions can be run simultaneously (serial or parallel). In addition, it is possible to run up to 96 "parallel only" processes in total. This means that at best you can run a parallel Fluent job using 120 processes: one process for the job, 96 additional ones in parallel, and another 23 from the remaining seats, as Fluent substitutes seat processes for parallel-only ones when it runs out of the latter. Another scenario would be 24 users have 5-process parallel jobs running, each with one master (i.e. seat) and 4 slaves (parallel only), thus using up all available Fluent resources.

    Back to Top...

  3. How do I run "Fluent" interactively?

    The following instructions assume that you are a member of the Unix group "fluent". The instructions in this section are only useful if you want to use the graphical user interface of Fluent, for instance to setup a job, or pre- and post-process a production job. If you want to run a production job, please refer to to instructions on how to start a Fluent batch job (see next section).

    The Fluent program is started by setting a system variables FLUENT_ARCH, FLUENT_INC, and FLUENT_LICENSE_FILE to let the system know about the computing platform employed (UltraSparc), the directory where the software resides and the license file used, respectively. It is also useful to include the directory with the Fluent executable in your path. Here is the command sequences to do all this:

    	(for csh)
    	setenv FLUENT_ARCH ultra
    	setenv FLUENT_INC /opt/fluent/Fluent.Inc
    	setenv FLUENT_LICENSE_FILE $FLUENT_INC/license/license.dat
    	setenv PATH $FLUENT_INC/bin:$PATH
    
    	(for ksh, bash, etc)
    	FLUENT_ARCH=ultra; export FLUENT_ARCH
    	FLUENT_INC=/opt/fluent/Fluent.Inc; export FLUENT_INC
    	FLUENT_LICENSE_FILE=$FLUENT_INC/license/license.dat
    	export FLUENT_LICENSE_FILE
    	PATH=$FLUENT_INC/bin:$PATH; export PATH
            
    These settings apply for the 32-bit version of Fluent, which is the default. Since our Sunfires are 64-bit machines, and Solaris 10 is a 64-bit operating system, there is also a Fluent version that uses a 64-bit address space. If you want to use the 64-bit version, you need to specify ultra_64 for FLUENT_ARCH. Everything else remains the same.

    There is a simple alternative for setting up your environment for the usage of Fluent: you can leave the above commands to usepackage and simply type

    		use fluent (32-bit, default), or
    		use fluent_64bit (64-bit)
    after login. This will automatically issue the above commands. You can also include the use command in your setup file (.login or .profile) if you are using fluent regularly.

    Then you invoke a graphical user interface by typing

    	fluent

    Since you are usually working from an external console, it might be necessary to set the DISPLAY environment variable to ip_address:0, where ip_address is the IP address of your local console. It might also be recommendable to write these commands into a short script file and execute that.

    The first choice you have to make is if you are solving a two- or a three-dimensional problem, and if you want to do so in single or double precision. You can do so by typing "2d", "3d", "2ddp", or "3ddp", respectively. All further commands can be typed in "by hand", or they can be issued by clicking on the toolbar on the top of the GUI and selecting the appropriate sub-choices. Note that if you want to type a command yourself, and you do not know what your choices are, simply pressing the Enter key will give you a list of applicable commands.

    It is , of course, impossible to even outline how to use Fluent appropriately. In many cases, you will want to read in a "case file", which has all the required information to describe the system you want to simulate. Such case files have the file extension .cas. Load them by issuing the /file/read-case command or selecting the corresponding menu-commands in the GUI. You can now check and display the grid, specify boundary conditions and material properties, initialize the flow, and perform calculations.

    Results are usually saved by the /file/write-case-data command. During an interactive session, it is sometimes a good idea to keep a "journal file" which records all commands that you have typed in or issued via the GUI. This journal file can later be used as a template for a batch command file. Define the journal file with the "/file/start-journal" command.

    The usage of Fluent is documented in html format on machines where Fluent is installed. On our system you can access this documentation by calling a Firefox web browser (type firefox &), and pointing it to

    file:///opt/fluent/Fluent.Inc/help/index.htm
    This documentation is also available in pdf format in
    /opt/fluent/Fluent.Inc/help/pdf
    Note that the documentation is only accessible if you are signed up as a Fluent user on our system.

    Back to Top...

  4. How do I set up and run a Fluent batch job?

    In most cases, you will run Fluent on the Sun Fire's in batch mode. Since you have to have access to Fluent outside of the HPCVL license, most interactive work can be done elsewhere, whereas the computationally intensive runs can be executed on the Sun Fire cluster.

    For this, you have to set up a batch command file that consists of a sequence of commands that you would normally issue to "Fluent" in an interactive session. To get an idea how such a batch command file looks, you can produce a journal file during an interactive session, and edit it later to eliminate unnecessary commands. Note that this needs to be done using the command line inside Fluent, not the menu buttons of the GUI. In fact, it is best to generate journal files in sessions that have been started with the -g option, i.e. that do not use the GUI at all. You also can have a look at a simple example input file here . The example file will read in a case-file from the working directory directory, initialize the flow, and run 10 iterations. It then writes out the data on a file "fan.dat" and exits. Note that every command has to be included in the batch command file, including the answer "yes" to the question if you really want to exit the program without saving the case file.

    Once you have produced a working command file, you can test it by calling

    fluent 3d -g -i example.flin
    where example.flin is the name of your command file, and we have assumed you are running a three-dimensional solver in single precision. You will have to alter those entries in different cases. Make sure that the output file for the data (in this case, fan_1.dat) does not exist before you start the job, otherwise the system will query if you want to over-write it and the answer is not in your command file.

    Once everything works you can submit this job into the background by typing

    fluent 3d -g -i example.flin>example.flout 2>&1 & (for ksh)
    This will catch standard output and standard error in a file example.flout.

    Production jobs are submitted on the Sun Fire systems via the GridEngine, which is a load-balancing software. To obtain details, read our Gridengine FAQ . For a Fluent batch job, this means that rather than issuing the above command directly, you wrap it into a GridEngine batch script. For an example for such a batch script please click here. This script needs to be altered by replacing all the relevant items enclosed in {} by the right values.

    The batch script is submitted to the GridEngine by typing

    	qsub batch_file_name
    The advantage to submit jobs via a load balancing software is that the software will automatically find the resources required and put the job onto a set of processors that have a low load. This will help executing the job faster. Note that the usage of Gridengine for all production jobs on the Sun Fire cluster is mandatory. Production jobs with a running time of more than 3 hours that are submitted outside of the load balancing software will be terminated by the system administrator.

    Back to Top...

  5. How do I setup and execute a "Fluent" parallel batch job?

    The Fluent jobs that you will want to run on the HPCVL machines are likely to be quite large. To utilize the parallel structure of the Sun Fire's, Fluent offers several options to execute the solver in a parallel environment, i.e. on several CPU's simultaneously. Currently, the default option for such runs is vendor MPI i.e., it uses the SUN native version of the “Message Passing Interface” for inter-process communication.

    To take advantage of the parallel capabilities of Fluent, you have to call the program with a series of commandline options that specify the details of your parallel run. Here is a short overview:

    • -tn where n is the number of processors requested, e.g. if you want to run with 8 processors, you would use the option -t8
    • -pvmpi specifies that the (default) vendor MPI communication system is to be used. May be omitted.
    • -g specifies that the GUI should be surpressed. Required for batch jobs.

    Parallel jobs should only be run in batch using the Grid Engine. In fact, the use of GridEngine is mandatory on the Sun Fire cluster for all production jobs. To submit a parallel job to Grid Engine the command line appears in a submit script, for which we have an example here. It has to be altered by replacing all items enclosed in {} by the applicable values. The number of processors specified in this script appears only once, after #$ -pe fluent.pe, which is where you let the Gridengine know how many processors to allocate to run the program. The internal environment variable $NSLOTS will automatically be set to this value and can then be used in the fluent command line. It is necessary to source a setup file which resides in /opt/fluent/Fluent.Inc/ and is called setup.sh for the 32-bit version. This will set various environment variables and enable the Fluent program to properly interact with Grid Engine. If you are interested, take a look. The file is readable. If you are using the 64-bit version of Fluent, you have to alter the batch script to source the /opt/fluent/Fluent.Inc/setup_64bit.sh file instead.

    In the above script, the parallel environment fluent.pe is for Fluent jobs only, and is used to keep track of the available licenses. The licensing situation can also be checked interactively by typing:

    flulic

    Grid Engine is able to interact with the license manager of Fluent (FlexLM) to check if sufficient licenses are available for running. This will keep the scheduler from starting jobs because enough processors are available, just to be stopped again because there is not enough licenses. Grid Engine keeps an internal counter of available "license slots" which gets updated frequently. Everytime Grid Engine attempts to schedule a Fluent job and is kept from doing so because not enough licenses are available, it will "requeue" the job. Since this causes the issue of an email if notification was requested, we recommend to remove the email notification line(s) (e.g. #$ -m be).

    All processes are allocated within a single node. This is to make communication more efficient and to avoid problems with the control by Gridengine. The effect of this is that, while still using MPI, Fluent employs a so-called shared-memory layer for communication. The disadvantage is that it takes longer until the required resources (dedicated processors) are available, i.e. you spend more time on the Grid Engine waiting queue.

    Once the script has been adapted, it can be submitted to the Gridengine by

    qsub batch_file_name
    from sfnode0 (which is the GridEngine submit host). Note that the job will appear as a parallel job on the GridEngine's qstat or qmon. Note also that submission of a parallel job in this way is only profitable for large systems that use many CPU cycles, since the overhead for assigning processes, preparing nodes, and communication between them is considerable.

    There is an easier way to do this: We are supplying a small perl script called that can be called directly, and will ask a few basic questions, such as the name for the job to be submitted and the number of processes to be used in the job. Simply type

    FluentSubmit
    and answer the questions. The script expects a Fluent input file with "file extension" .flin to be present and will do everything else automatically. This is meant for simple Fluent job submissions. More complex job submissions are better done manually.

    Back to Top...

  6. Where can I get further help?

    Fluent is a very complex software package, and requires some practice to be used efficiently. In this FAQ we can not explain it use in any detail. Online documentation for the programs is available on machines where Fluent is installed. On the Sun Fire, it can be accessed by a webbrowser under

    	file:///opt/fluent/Fluent.Inc/help/index.htm
    You can also use the pdf documentation in
    	/opt/fluent/Fluent.Inc/help/pdf
    if you prefer a printed version. Fluent documentation is subject to the same license terms as the software itself, i.e. you have to be signed up as a Fluent user in order to access it.

    If you are experiencing trouble running a batch command script, check carefully if the sequence of commands is exactly "in sync" with the program. This might mean typing them in interactively as a test. If you have problems with the GridEngine, read our FAQ on that subject, and maybe consult the manual for that software which is accessible as a PDF file. HPCVL also provide user support in the case of technical problems. Contact us here, we might be able to help, or pass you on to someone who can.

    Back to Top...


 
 
   
© HPCVL 2007