Appa.doc

Selecting CFD Software
A. Selecting CFD Software
A.1 Preamble
This appendix outlines the procedure that was undertaken in selecting a suitable A.2 Specification of the CFD Package
A list of desired features was compiled after consulting various publications (e.g. Jones and Whittle (1992), Fawcett (1991), and Shaw (1992)) and holding conversations with experienced CFD users. The features were divided into six groups: pre-processing capabilities; physical modelling capabilities; the solver; post- processing capabilities; user friendliness and user support. A.2.1 Pre-Processing Capabilities
This is the interface through which the user defines the simulation. It includes geometry and mesh generation and enables specification of boundary conditions, physical models, and numerical parameters used in the solution procedure. Features • 2D and 3D modelling; • cartesian and cylindrical coordinate systems with body-fitted coordinates (this capability enables grids to be distorted to fit the geometry in question); • large mesh capacity (up to about 100 000 cells) - this upper limit is often • specification of complex boundary conditions, such as transient conditions, and pressure boundaries with discharge coefficients; and • access to ‘Fortran User Routines’ to add or modify physical models. A.2.2 Physical Modelling Capabilities
This section identifies the desired numerical methods for representing the various facets of airflow. In addition to mass, momentum and energy transfer, the following • transient and steady state modelling; • a selection of turbulence models, including the standard k − ε model of • particle tracking - smoke particles, dust particles, and ‘clouds’ of particles (many particles), the latter may be better represented using a multi-species • multi-phase modelling, e.g. evaporation of water in air; and A.2.3 The Solver
Once the various physical models have been specified and the boundary conditions defined, it is the job of the solver to ‘organise’ all of this information and solve the governing flow equations (Eq. (D-1) and Table D.1) to find values for all of the variables in each cell of the user-defined mesh (§D.2) such that the physical models and boundary conditions are simultaneously satisfied. In solving the equations it is necessary to reduce them to a numerical form that can be understood by a computer. This technique is called discretisation. There are three main methods for doing this: the Finite Difference Method (FDM); the Finite Element Method (FEM); and the Finite The FDM uses Taylor series expansions (Smith 1985) to express first and second order derivatives in terms of differences in the dependent variables at spatial positions only a small distance apart. The FEM has its origins in stress and strain analysis of solid structures. In brief, the domain of interest is divided into small elements and a certain variation for the dependent variable assumed. Various numerical analysis techniques (Zienkiewicz and Taylor (1989)) are then employed to determine expressions for first and second order derivatives of the dependent variable. This is carried out for every element of the domain after which all of the equations are collated and solved. Since each element is considered individually, additional computation is necessary in generating a ‘look-up’ table containing the connectivity information of the elements. The most popular technique for discretising the governing CFD equations is the FVM. This method represents a more physical approach to transforming the differential equations. The flow domain is divided into control volumes (defined using the cells of the mesh) and the governing conservation equations are integrated over each one. In doing this, physical processes such as convection, diffusion and sources/sinks are dealt with explicitly. Inherent in its method, the FVM draws on features taken from both the finite element and finite difference methods. The FVM is the most favoured discretisation technique for CFD code developers and was the method sought when selecting CFD software. The method is described in more detail in Appendix D, but its origins can be found in Patankar (1980). A good introductory text to its methods and associated algorithms can be found in Versteeg Two mesh types can be used in CFD programs - structured and unstructured. A structured mesh comprises six-sided cells arranged in a regular topology to form a cuboid. A structured mesh is necessary for implementation of the FDM. In an unstructured mesh, cells do not have to be six-sided and are often tetrahedral in shape. Since the FEM uses a unique variation of the dependent variables for every cell, the method lends itself well to unstructured meshes. The FVM is used mainly with structured meshes, although algorithms are now available that use the FVM with an unstructured mesh (e.g. Lonsdale (1993) and Computational Dynamics Ltd. (1991)). In this selection process, a code employing the FVM with a structured mesh When using the FVM, values for pressure are calculated at the cell centres. Velocity components are then calculated either at cell faces (a staggered grid) or, along with pressure, at the cell centres (a co-located grid). The latter produces a more accurate results field but requires the use of the Rhie and Chow interpolation algorithm (Rhie and Chow (1983)) to prevent pressure and velocity decoupling. A.2.4 Post-Processing Capabilities
This is the aspect of the CFD package dedicated to results analysis. CFD codes produce large amounts of data in their results files. The quickest and most effective way to view this data is graphically. Most CFD packages can produce contours (line contours and shaded contours), line graphs and vectors. Some packages also enable the superposition of two of these variables, for example, velocity vectors and Although graphical analysis is probably the most useful method for viewing results, it is important to check whether or not the package gives access to the results in ASCII format. This is very useful for comparing results with experimental data or other CFD codes as it enables exact properties such as flow rates through openings to be found. It may also be helpful if the software can interface with other visualisation packages such as PV-WAVE (Precision Visuals (1988)). A CFD package with all or most of these capabilities was sought. A.2.5 User-Friendliness
The ease with which the user is able to operate the software is determined by the design of the user interface. The more friendly a package appears, the shorter the learning curve will be and the quicker users will be able to obtain meaningful results. Ideally, the type of interface sought was that depicted in Figure A.1. Figure A.1 Structure of a flexible pre-processor.
The GUI provides a very easy introduction to the software and enables basic problems to be set up very quickly using both mouse and keyboard. Less simple problems can be defined using a command language which ‘sits beneath’ the GUI. This enables files, that are normally produced automatically using the top level menu, to be written (and edited) by the user using a very high level and logical language. The command language offers users much more freedom in defining geometries, meshes, boundary conditions, etc. However, if the command language is still not flexible enough, it is necessary for the user to access User Fortran Routines. These are sub-sections of the main CFD code in which users can write Fortran routines to tailor their simulation. For example, to define new physical models, specify complex boundary conditions, define additional output variables, etc. Two features sought in the solver interface were solution monitoring and the facility to carry out a restart simulation. The first enables users to interactively analyse the solution procedure by viewing, sometimes both graphically and numerically, the equation residuals and the values of the variables at a point. The residuals are the errors between the right-hand and left-hand sides of the discretised governing equations (see Appendix D) and, in a successful solution process, should fall. A restart facility enables the solution from one simulation to be used as the initial guess for the first iteration of another simulation. This is very useful, for example, if the user wishes to investigate the effects of changes in the operating conditions such as inlet A.2.6 User-Support
When using CFD software to address difficult problems, it is helpful if good user support is available via an immediate, rapid response method, such as fax, email or telephone. Some vendors also set up email user groups which enable users to send an advice request to all current users of that CFD code. Most companies offer training courses to new and potential users enabling them to overcome some of the initial difficulties and get the most from the software in a shorter period of time. To gain an insight into the quality of user-support, there is much to be gained from visiting potential suppliers before selecting a software vendor. A.3 Evaluating the Available Packages
Seven packages were chosen for investigation. These were considered against a list of ‘strongly-desired-features’ (Table A.1), following which, it was decided to investigate FLOW3D (now called CFX), FLUENT, and PHOENICS in more detail. This choice was based on elimination of those packages which did not posses one or more of the strongly desired features. Table A.1 Comparison between CFD codes and the strongly-desired-features.
PHOENICS
FVM - finite volume method, FEM - finite element method, STR - structured mesh, UNS - unstructured mesh, Y - features are available, N - features are not available, ? - conflicting views exist. The three leading packages selected for further investigation were assessed using a concise list of features drawn from section A.2 (Table A.2). Table A.2 Comparison between CFD codes and the strongly-desired features
FEATURE
FLOW3D (version 3.2)
FLUENT (version 4.11)
PHOENICS (version 1.6 and ‘FLAIR’)
Very (command interface or Fortran k − ε , low Re no. k − ε , ASM, RSM, k − ε , k-l, constant eddy viscosity, RSM “Unfriendly, but manuals are good” (1,3) “Excellent. A very good way to get “Not that good” (1). “Not brilliant” (3). 2600 (inc. training for 1 person per year) k − ε - two-equation model of Launder and Spalding (1974), ASM - algebraic stress model, RSM - Reynolds stress model, DSM - differential stress model, RNG - Renormalisation Group theory k − ε model. (1) Present academic users of the code. (2) Present commercial users of the code. (3) Past academic users of the code. (4) Vendors of the code. # Refers to all those capabilities mentioned in §A.2.4. * Extra cost items. • Academic price per user at April 1993. Following the compilation of Table A.2 and conversations with each vendor and users of each code, it was decided to purchase FLOW3D. This package comprised all of the features sought after including highly commended user-support and a very active team of people working on research and development which is indicative of a commercially stable company. FLOW3D also possessed a multi-block technique which enables many individual rectangular meshes to be joined together, enabling complex geometries to be defined with ease. This avoids the computational overhead of ‘blocking off’ cells which are not part of the flow domain but which are part of the rectangular meshes inherent in other (single block) codes such as

Source: https://civil.lboro.ac.uk/new/www/staff/docs/227/appendices/appa.pdf