download Document

of 16

  • date post

  • Category


  • view

  • download


Embed Size (px)

Transcript of Document

caffa3d.MBA fully implicit, finite volume, flow solver for the incompressible 3D Navier-Stokes equations with generic scalar transport, in block structured, non-orthogonal, body fitted grids.

Gabriel Usera1


Dep. Enginyeria Mecnica, Universitat Rovira i Virgili, Av. Pasos Catalans 26, 43007 Tarragona, Espaa Instituto de Mecnica de los Fluidos IMFIA, Universidad de la Repblica, J. Herrera y Reissig 565, 11300, Montevideo, Uruguay


Content 1. Introduction 2. Grid generator: grid3d.MB 3. Block pre-processor: block3d.MB 4. Flow solver: caffa3d.MB 5. Post-processing tools 6. Tutorial example 7. Acknowledgements 8. References

1. Introduction 1.1 Acknowledgement and disclaimer. This documentation describes the software package caffa3d.MB, which is an extension to 3D and block-structured grids of the original 'caffa.f' 2D code by M. Peric et al. Throughout this documentation, the user is assumed to be familiar with that code (which is freely available on the Internet), and its documentation, and with the general concepts of CFD as presented in the book by J. H. Ferziger and M. Peric, Computational Methods for Fluid Dynamics [3] (referred to in this documentation as the book). A self-contained version of this documentation is planed for the (near) future. The use, modification and/or distribution of this software are free. 1.2 General description The software caffa3d.MB is a Fortran95 implementation of a fully implicit finite volume method for solving the 3D incompressible NavierStokes equations in complex geometry. Spatial discretization is based on block-structured, non-orthogonal, body fitted, collocated grids with first order (UDS) and second order (CDS) schemes for the convective terms. For the time discretization fully implicit two-level first order (implicit backward Euler) and three-level second order schemes are available. The SIMPLE algorithm is implemented for the coupling between velocity and pressure. A generic transport equation is provided for solving transport of different scalars. In particular, heat transport is implemented together with buoyancy effects on the momentum equations. Unlike the original 2D version, only one grid level has been retained, although a future extension to multi-grid is planned. The k-e turbulent model has been retained and adapted to 3D. Also a simple Smagorinsky type LES model has been introduced. Please note however that turbulence models are not currently covered by this documentation. 1.3 Software components. The software is in fact composed of three modules: 1. Grid generator (grid3d.MB). 2. Block pre-processor (block3d.MB). 3. Flow solver (caffa3d.MB). A chapter is devoted to the description of each of these modules. Additionally, a set of Matlab post-processing tools is provided for visualisation of grid and results. 1.4 Block interfaces The following interfaces between grid blocks are currently supported: 1. 2. Exact, one-to-one interfaces. These are automatically detected and processed by the block pre-processor. Exact, many-to-one interfaces. These require user input for pairing, which is done afterwards by the block pre-processor (not currently covered in this documentation).


Sliding interfaces. These are supported through user programming of appropriate handling routines (not currently covered in this documentation). Arbitrary, many-to-many, non-matching interfaces. These require user input for computing, which is done afterwards by the block preprocessor (not currently covered in this documentation).


Please note that same-block interfaces are treated in the same way, so Otype, H-type, and C-type grids are supported, through the use of one or many blocks. 1.5 Input and Output The input and output files used by the software package are all formed by a six character root plus a three character extension (except for result post processing files which change the three character extension for a correlative number). The following are the conventions used for naming files: Grid input files (.ing): Grid (output) files (.grd): mygrid.grd Block input file (.kin) : myname.kin Block output file (.bck) : myname.bck Solver input file (.cin) : myname.cin Solver output file (.out) : myname.out Solver restart file (.res) : myname.res Post-processing : myname.1, myname.2, ... ,

1.6 Undocumented features A number of features are currently supported by the software package but not documented here (although they will be in future versions of this documentation). These are: Many-to-one, non-matching many-to-many, and sliding block interfaces. Turbulence models Inner boundary conditions, as thin walls placed inside the domain. OpenMP capability.

The curious user will not find it difficult to guess how to use some of these features; the code should be self-explanatory. The OpenMP capability, for example, is transparent if no openmp switch is used when compiling, and requires little more than the openmp switch to work. The code is extensively annotated and should help in this task.

2. Grid generator: grid3d.MB 2.1 Introduction The grid generator was adapted from the 2D grid generator accompanying the original caffa package (gridgen.f). As stated earlier the reader of this documentation is assumed to be familiar with the original package. grid3d.MB currently only supports the generation of 3D grids as rectilinear extrusions of a 2D grid into the third direction. Thus, it is not able to generate a spherical grid for example. Please note however that the flow solver accepts general 3D block-structured grids, so the user can provide its own grid generator. In section 2.4 the required format for the binary grid files is explained. For block-structured grids, each grid block is generated separately. Thus there will be one grid input file (.gin) for each grid block, the grid generator needs to be run once for each grid block and one grid file (.grd) will be created for each grid block. The block pre-processor must be run afterwards to compile the information about block interfaces (even if there is to be only one grid block, with no interfaces!). 2.2 Description The grid generation starts with the basic 2D section very much the same as for the original gridgen.f. Also the input for this section is almost the same, except for the boundary conditions, which are specified at the end in a separate block. Once the 2D section is generated it is 'extruded' in the 'z' direction using node distributions which are prescribed by the user in the same manner as for 2D grid edges. Finally the boundary conditions are specified in a separate input block after the geometry is defined. Boundary conditions can be specified in as many 'sections' as required. Each 'section' is composed of two lines. The first line defines the region where the given boundary condition is to be applied, by specifying the index interval. The second line simply gives the boundary condition code (just as for the 2D version: 1.-Inlet, 2.Outlet, 3.-Symmetry, 4.-Isothermal Wall, 5.-Adiabatic Wall, 10.Interface) and a numeric tag which can be used afterwards to identify the given boundary condition (very useful when programming boundary conditions, sliding interfaces, etc). Please note that if any boundary cell face appears repeated in more than one boundary condition specification, only the last one counts (this is useful to define windows of a given boundary condition within regions that were assigned previously a different BC.) Please see annotations in cavmpA.gin and/or source code for further details. 2.3 Geometry computations The 3D flow solver requires the knowledge of several geometrical properties of the grid which are computed by the grid generator. These are the volumes of each cell and the location of its centre, and for each boundary face the location of the cell face centre and the normal surface vector. All these are computed as described in section 8.6.4 of the book. (Note however that the flow solver itself currently computes some of these properties, something I intend to sort one way or the other in the future)

2.4 Grid file format In order to allow the use of other grid generators, the required format for the grid file(s) is described in this section. To do so in an expedited way the statements that write the grid file are presented and annotated next:OPEN (UNIT=7,FILE=FILGRD,FORM='binary') REWIND 7 IUNIT=7 WRITE(IUNIT) * NI,NJ,NK,NIJK,NINL,NOUT,NSYM,NWAL,NOC, * NWALI,NWALA,NINX,NOUX,NSYX,NWAX,NOCX WRITE(IUNIT) * (LI(I),I=1,NI),(LK(K),K=1,NK) WRITE(IUNIT) * (IJI(I) ,I=1,NINX),(IJPI(I) ,I=1,NINX), * (IJI1(I) ,I=1,NINX),(IJI2(I) ,I=1,NINX), * (IJI3(I) ,I=1,NINX),(IJI4(I) ,I=1,NINX), * (ITAGI(I),I=1,NINX) WRITE(IUNIT) * (IJO(I) ,I=1,NOUX),(IJPO(I) ,I=1,NOUX), * (IJO1(I) ,I=1,NOUX),(IJO2(I) ,I=1,NOUX), * (IJO3(I) ,I=1,NOUX),(IJO4(I) ,I=1,NOUX), * (ITAGO(I),I=1,NOUX) WRITE(IUNIT) * (IJW(I) ,I=1,NWAX),(IJPW(I) ,I=1,NWAX), * (IJW1(I) ,I=1,NWAX),(IJW2(I) ,I=1,NWAX), * (IJW3(I) ,I=1,NWAX),(IJW4(I) ,I=1,NWAX), * (ITAGW(I),I=1,NWAX) WRITE(IUNIT) * (IJS(I) ,I=1,NSYX),(IJPS(I) ,I=1,NSYX), * (IJS1(I) ,I=1,NSYX),(IJS2(I) ,I=1,NSYX), * (IJS3(I) ,I=1,NSYX),(IJS4(I) ,I=1,NSYX), * (ITAGS(I),I=1,NSYX) WRITE(IUNIT) * (IJL(I) ,I=1,NOCX),(IJR(I) ,I=1,NOCX), * (IJOC1(I),I=1,NOCX),(IJOC2(I),I=1,NOCX), * (IJOC3(I),I=1,NOCX),(IJOC4(I),I=1,NOCX), * (ITAGOC(I),I=1,NOCX) WRITE(IUNIT) * (X(I) ,I=1,NIJK),(Y(I) ,I=1,NIJK),(Z(I) ,I=1,NIJK), * (XC(I),I=1,NIJK),(YC(I),I=1,NIJK),(ZC(I),I=1,NIJK), * (FX(I),I=1,NIJK),(FY(I),I=1,NIJK),(FZ(I),I=1,NIJK), * (VOL(I),I=1,NIJK), * (SRDW(I),I=1,NWAX), * (XNW(I),I=1,NWAX),(YNW(I),I=1,NWAX),(ZNW(I),I=1,NWAX), * (SRDS(I),I=1,NSYX), * (XNS(I),I=1,NSYX),(YNS(I),I=1,NSYX),(ZNS(I),I=1,NSYX), * (FOC(I),I=1,NOCX) CLOSE(UNIT=7)

01. NI,NJ,NK... Number of nodes in I, J and K directions 02. NIJK... Total number of nodes. NIJK=NI*NJ*NK 03. NINL... Num. of boundary C