Download - caffa3d.MB

caffa3d.MB

A fully implicit, finite volume, flow solver for th e incompressible 3D Navier-Stokes equations with gene ric scalar transport, in block structured, non-orthogon al,

body fitted grids.

Gabriel Usera 1,2

1 Dep. Enginyeria Mecànica, Universitat Rovira i Vir gili, Av. Països Catalans 26, 43007 Tarragona, España

<[email protected]>

2 Instituto de Mecánica de los Fluidos IMFIA, Univer sidad de la República, 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 th e original 'caffa.f' 2D code by M. Peric et al. Throughout this document ation, the user is assumed to be familiar with that code (which is fre ely available on the Internet), and its documentation, and with the gene ral concepts of CFD as presented in the book by J. H. Ferziger and M. Peri c, “Computational Methods for Fluid Dynamics” [3] (referred to in thi s documentation as ‘the book’). A self-contained version of this docum entation is planed for the (near) future.

The use, modification and/or distribution of this s oftware are free.

1.2 General description

The software ‘caffa3d.MB’ is a Fortran95 implementa tion of a fully implicit finite volume method for solving the 3D in compressible Navier-Stokes equations in complex geometry. Spatial discr etization is based on block-structured, non-orthogonal, body fitted, coll ocated grids with first order (UDS) and second order (CDS) schemes fo r the convective terms. For the time discretization fully implicit t wo-level first order (implicit backward Euler) and three-level second or der schemes are available. The SIMPLE algorithm is implemented for the coupling between velocity and pressure.

A generic transport equation is provided for solvin g 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 planne d.

The k-e turbulent model has been retained and adapt ed to 3D. Also a simple Smagorinsky type LES model has been introduc ed. Please note however that turbulence models are not currently co vered 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 cu rrently supported:

1. Exact, one-to-one interfaces. These are automatical ly detected and processed by the block pre-processor.

2. Exact, many-to-one interfaces. These require user i nput for pairing, which is done afterwards by the block pre-processor (not currently covered in this documentation).

3. Sliding interfaces. These are supported through use r programming of appropriate handling routines (not currently covere d in this documentation).

4. Arbitrary, many-to-many, non-matching interfaces. T hese require user input for computing, which is done afterwards by th e block pre-processor (not currently covered in this documentat ion).

Please note that same-block interfaces are treated in the same way, so O-type, H-type, and C-type grids are supported, throu gh the use of one or many blocks.

1.5 Input and Output

The input and output files used by the software pac kage are all formed by a six character ‘root’ plus a three character exten sion (except for result post processing files which change the three character extension for a correlative number).

The following are the conventions used for naming f iles:

• Grid input files (‘.ing’): mygrid.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, ... , myname .xxx

1.6 Undocumented features

A number of features are currently supported by the software package but not documented here (although they will be in futur e 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 ins ide the domain.

• OpenMP capability.

The ‘curious’ user will not find it difficult to ‘g uess’ how to use some of these features; the code should be self-explanat ory. The OpenMP capability, for example, is transparent if no ‘–ope nmp’ 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 gen erator accompanying the original ‘caffa’ package (‘gridgen.f’). As stat ed earlier the reader of this documentation is assumed to be familiar wit h the original package.

‘grid3d.MB’ currently only supports the generation of 3D grids as rectilinear ‘extrusions’ of a 2D grid into the thir d direction. Thus, it is not able to generate a spherical grid for exampl e. Please note however that the flow solver accepts general 3D block-struc tured 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 gene rated separately. Thus there will be one grid input file (‘.gin’) for eac h 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 b lock pre-processor must be run afterwards to compile the information a bout block interfaces (even if there is to be only one grid block, with n o interfaces!).

2.2 Description

The grid generation starts with the basic 2D sectio n 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' i n the 'z' direction using node distributions which are prescribed by th e 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 comp osed of two lines. The first line defines the region where the given bound ary condition is to be applied, by specifying the index interval. The seco nd line simply gives the boundary condition code (just as for the 2D ver sion: 1.-Inlet, 2-.Outlet, 3.-Symmetry, 4.-Isothermal Wall, 5.-Adiaba tic Wall, 10.-Interface) and a numeric ‘tag’ which can be used af terwards to identify the given boundary condition (very useful when prog ramming 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 cond ition within regions that were assigned previously a different BC.)

Please see annotations in ‘cavmpA.gin’ and/or sourc e code for further details.

2.3 Geometry computations

The 3D flow solver requires the knowledge of severa l geometrical properties of the grid which are computed by the gr id generator. These are the volumes of each cell and the location of it s 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 sect ion 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 wa y 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:

01. NI,NJ,NK... Number of nodes in I, J and K direc tions

02. NIJK... Total number of nodes. NIJK=NI*NJ*NK

03. NINL... Num. of boundary CV faces assigned with Inlet BC.

04. NOUT... Num. of boundary CV faces assigned with Outlet BC.

05. NSYM... Num. of boundary CV faces assigned with Symmetry BC.

06. NWAL... Num. of boundary CV faces assigned with Wall BC.

OPEN (UNIT=7,FILE=FILGRD,FORM='binary') REWIND 7 IUNIT=7 WRITE(IUNIT) * NI,NJ,NK,NIJK,NINL,NOUT,NSYM,NWAL,NO C, * 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,NIN X), * (IJI1(I) ,I=1,NINX),(IJI2(I) ,I=1,NIN X), * (IJI3(I) ,I=1,NINX),(IJI4(I) ,I=1,NIN X), * (ITAGI(I),I=1,NINX) WRITE(IUNIT) * (IJO(I) ,I=1,NOUX),(IJPO(I) ,I=1,NOU X), * (IJO1(I) ,I=1,NOUX),(IJO2(I) ,I=1,NOU X), * (IJO3(I) ,I=1,NOUX),(IJO4(I) ,I=1,NOU X), * (ITAGO(I),I=1,NOUX) WRITE(IUNIT) * (IJW(I) ,I=1,NWAX),(IJPW(I) ,I=1,NWA X), * (IJW1(I) ,I=1,NWAX),(IJW2(I) ,I=1,NWA X), * (IJW3(I) ,I=1,NWAX),(IJW4(I) ,I=1,NWA X), * (ITAGW(I),I=1,NWAX) WRITE(IUNIT) * (IJS(I) ,I=1,NSYX),(IJPS(I) ,I=1,NSY X), * (IJS1(I) ,I=1,NSYX),(IJS2(I) ,I=1,NSY X), * (IJS3(I) ,I=1,NSYX),(IJS4(I) ,I=1,NSY X), * (ITAGS(I),I=1,NSYX) WRITE(IUNIT) * (IJL(I) ,I=1,NOCX),(IJR(I) ,I=1,NOC X), * (IJOC1(I),I=1,NOCX),(IJOC2(I),I=1,NOC X), * (IJOC3(I),I=1,NOCX),(IJOC4(I),I=1,NOC X), * (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)

07. NOC ... Num. of boundary CV faces implied in O- C cuts.

08. NWALI... Num. of boundary CV faces assigned wit h Isothermal Wall BC.

09. NWALA... Num. of boundary CV faces assigned wit h Adiabatic Wall BC. (Please note that NWAL=NWALI+NWALA)

10. NINX, NOUX, NSYX, NWAX, NOCX... Used to prevent arrays of null length: NINX=MAX(NINL,1), NOUX=MAX(NOUT,1), NSYX=MA X(NSYM,1), NWAX=MAX(NWAL,1), NOCX=MAX(NOC ,1)

####################

11. LI(I)... Offset indices for I columns. LI(I)=(I -1)*NJ

12. LK(K)... Offset indices for K columns. LK(K)=(K -1)*NIJ #################### Then we have the blocks for BC. specifications. The re is one block for each BC.: Inlet, Outlet, Symmetry, Wall, OC-cuts or ‘Interfaces’. They are all similar. The block for Inlet goes like this :

13. IJI(I)... Integer array. IJK indexes to each ce ll face assigned as Inlet

14. IJPI(I)... Idem. for the interior node neighbou r to the boundary face

15. IJI1(I)...IJI4(I)... Arrays with the IJK indexe s to each corner of the boundary face given CLOCKWISE ( so that the nor mal will point outwards ).

16. ITAGI(I)... Array with the numeric boundary ide ntification ‘tag’ ####################

17. X(I),Y(I),Z(I)... Co-ordinates of grid corners

18. XC(I),YC(I),ZC(I)... Coord. of cell centres

19. FX(I), FY(I), FZ(I)... Interpolation factors

20. VOL(I)... Volume of each cell

21. SRDW(I), XNW(I), YNW(I), ZNW(I)... Info about w all BC. faces (see code)

22. SRDS(I), XNS(I), YNS(I), ZNS(I)... Info about s ymmetry BC. faces (see code)

3. Block pre-processor

Block3d.MB is a ‘new’ part of the software package, in the sense that there was not an equivalent module in the original 2D package ‘caffa’ (no need for one). This module assembles the grid block s produced by ‘grid3d.MB’, building the information structure req uired by the flow solver ‘caffa3d.MB’ for handling block-structured g rids. In particular, the interfaces between blocks are matched and liste d with the required information for the flow solver. The block pre-proc essor must be run for all problem set-ups, even if it is a one-block grid problem.

For one-to-one interfaces no additional input is re quired from the user other than the number of grid blocks and the list o f file names corresponding to the grid files (‘.grd’) for each b lock. Thus, the block input file (‘.kin’) ‘myname.kin’ must have the numb er of grid blocks in the first line, and then one line for each grid blo ck giving the corresponding file name (6 characters the extension ‘.grd’ is assumed). For example: 3 blockA blockB blockC

0

0

The two ‘0’s in the last lines indicate that there is no further input. (The opposite would be the case for many-to-one and non-matching many-to-many interfaces, but those are not currently covere d by this documentation).

A block information file (‘.bck’) 'myname.bck' is g enerated. The flow solver will then read this file first, and after th at it will read each grid block file (the geometry info for each block r emains in the original ‘.grd’ file, the ‘.bck’ file only contains indexing and connectivity information).

Also the file ‘param3d.inc’ is generated with appro priate dimension parameters for compiling the flow solver ‘caffa3d.M B’. This file should be copied to the folder containing the source files before compiling ‘caffa3d.MB’.

The process of matching one-to-one interfaces runs ‘automatically’, with no user input and no screen output. However it will fail if the grid blocks don not actually match (due to incorrect geo metry or BC. specification of one or more blocks). In this case the failing boundary faces will be listed and no block information file ‘.bck’ will be generated.

4. Flow solver

The use of the flow solver is little changed from t he original 2D version. Most of the changes, from a user point of view, are in the grid generation and the (new) block assembling step.

The input file for the flow solver (‘.cin’) has onl y minor changes. Since the multiple grid levels have been dropped for the time being, so was the KIN parameter. Also the LSG array (number of outer iterations, 'in each grid') is now a scalar. An extra logic parameter ‘L GRAD’ has been added which controls the output of gradient fields for po st-processing. Other than that some inputs have been re-arranged in diff erent lines. Of course there is an extra equation (‘W’ momentum equation) which was given number 3 (so now pressure has number ‘4’ and temperature n umber ‘5’). Equations 6 to 9 are for the turbulence models, but those are not covered in this documentation.

At the end of the file, some information about the grid blocks is added. The number of blocks, and the file name ('.grd' ass umed) for each grid block file must be listed (just as for the '.kin' f ile for the block pre-processor, please see the previous section). Again, a final ‘0’ after the last line is required (in this case to indicate tha t no ‘inner walls’ are to be considered; this feature will be documented i n future versions).

As for the solver, an option of linear equation sol ver has been added. In addition to the SIP solver (now in 3D version), a C GSTAB solver has been adapted from the code library that comes with the b ook. The choice of linear solver is made at compilation time with the appropriate -I flag. Please see the tutorial section.

The SIP solver has been adapted for fully implicit treatment of the interface terms between blocks, as described in sec tion 8.6.5 of the book. The CGSTAB solver however, currently only sup ports a semi-explicit treatment of these terms within the inner iteration s. Thus, care is advised when solving multi-block domains with the C GSTAB solver. The user may prefer to stick to the SIP solver in these case s. Still, CGSTAB can be used safely for single block domains, where it m ay give some performance advantage over the SIP solver, especial ly in very fine grids.

Other than the screen output, the solver produces t he following files:

‘myname.out’: Convergence and monitor point output .

‘myname.xxx’: Results for post-processing.

‘myname.res’: Restart file for use in following co mputations.

5. Post-processing tools

A set of Matlab scripts and functions is provided f or post-processing of the results, as well as grid visualisation previous to flow solving.

5.1 Grid visualisation

The Matlab script ‘checkGrid.m’ reads a given grid output file (‘.grd’) and allows the user to visualise the grid prior to flow calculation for verification or debugging purposes.

The user only needs to provide the correct filename (and path if necessary) in the first line of the script file:

GridFileName=['mygrid.grd'];

After execution all the grid information is loaded into the Matlab workspace. The grid boundary surfaces can be visual ised directly by using the provided ‘gridsurf.m’ function:

h=gridsurf(XC,YC,ZC,’red’,gcf);

5.2 Results visualisation

The Matlab script ‘caffa3dMBs.m’ reads a given caff a3d.MB post processing file (‘myname.xxx’) and loads into the Matlab works pace the selected grid and flow fields. The user needs to provide the corr ect filename (and path if necessary) in the first line:

Filnam=['myname.1'];

Additionally the user may want to comment the lines that correspond to those flow fields not wanted.

Grid data is loaded into the structure GR with one level (‘GR(i)’) for each grid block, and fields for each grid field (th us GR(3).XC is the array with the x-coordinate of the cell centres in the 3 rd grid block ). Analogously, the structure FL keeps the flow fields (i.e. FL(2).UU is the array with the U-component of the velocity in the 2 nd block).

Please see the tutorial section (next section) for working examples on the visualisation of results.

6. Tutorial example

This section is intended to guide the user through a first example and test case, which also serves as a validation case. The set-up, compilation, grid generation, block pre-processing, and flow solving steps will be explained.

The test case selected is the 3D lid driven cavity at Re=1000. A uniform grid with 81x81x81 cells is used (5.3x10 5 cells). This problem runs in about 197 MB of RAM and requires, to reach steady s tate, about 1hr in an AMD Athlon(tm) XP 2800+ CPU. The output and results files require about 500 MB of disk space. Results have been compared su ccessfully with those from other authors ([1], [2], please see below).

To demonstrate the set-up of multi-block grids, the domain has been splited in two along a vertical plane (not exactly the middle plane, the left block keeps 39 cells while the right block kee ps the other 42 cells). There are then two blocks, matched through a one-to-one interface.

The tutorial is intended for a Linux (or Unix) syst em. Also the free non-commercial version of Intel Fortran Compiler v 7.1 is used (appropriate compiler flags may differ for other versions or com piler brands). For the visualisation examples a graphics enabled system wi th Matlab 6.x or later is required.

The setup files for this example are included in th e distribution, in the ‘example’ folder

6.1 Unpacking the distribution

Copy the tar.gz file ‘caffa3d.MB.v.1.01.tar.gz’ to an empty folder that will host the caffa3d.MB package (assume this folde r is named ‘caffa3d’).

Decompress and extract the package with:

caffa3d $ gunzip caffa3d.MB.v.1.01.tar.gz

caffa3d $ tar –xvf caffa3d.MB.v.1.01.tar

...tar output...

caffa3d $

The following files and folder structure is created as a result:

caffa3d $ ls

block3d.MB caffa3d.MB caffa3d.MB.readme caffa3d .MB.v.1.01.tar

documentation example grid3d.MB

6.2 Compiling grid3d.MB and block3d.MB

The files ‘param3d.ing’ and ‘param3d.inb’ control d e dimension parameters for grid3d.MB and block3d.MB respectively. The curr ent parameters are ‘generous’, but for very large problems the user ma y need to increase them.

To compile ‘grid3d.MB’ change to the corresponding folder and call the compiler:

caffa3d $ cd grid3d.MB

grid3d.MB $ ifc –o ../example/grid3d.MB.lnx ./grid 3d.MB.f

...compiler output...

2095 Lines Compiled

grid3d.MB $

Analogously, to compile ‘block3d.MB’:

grid3d.MB $ cd ../block3d.MB

block3d.MB $ ifc –o ../example/block3d.MB.lnx ./bl ock3d.MB.f


1205 Lines Compiled

block3d.MB $

The ‘example’ folder should now have both ‘.lnx’ ex ecutables (in addition to the distribution provided set-up files):

block3d.MB $ cd ../example

example $ ls

block3d.MB.lnx cavmp1.cin cavmpA.gin checkGridM B.m

gridsurf.m caffa3dMBs.m cavmp1.kin cavmpB.gin grid3d.MB.lnx

6.3 Grid generation

Since the grid for this problem is made up from two blocks, we need to run the grid generator twice in the ‘example’ folde r:

example $ ./grid3d.MB.lnx

ENTER PROBLEM NAME (SIX CHARACTERS):

cavmpA

...output...

example $ ./grid3d.MB.lnx


cavmpB

...output...

example $

As a result, the grid files ‘cavmpA.grd’ and ‘cavmp B.grd’ are created in the ‘example’ folder.

To check that grid blocks were correctly generated, the following Matlab commands might be issued in a graphics enabled syst em:

example $ matlab -nodesktop –nosplash

< M A T L A B >

Using Toolbox Path Cache. Type "help toolbox_path _cache"...

To get started, type one of these: helpwin, helpde sk, or demo.

For product information, visit www.mathworks.com.

>> GridFileName='cavmpA.grd';

>> checkGridMB;

>> h=gridsurf(XC,YC,ZC,'red',gcf);

>> hold on;

>> GridFileName='cavmpB.grd';

>> checkGridMB;

>> h=gridsurf(XC,YC,ZC,'blue',gcf);

>> view(3)

A Matlab graphics window should appear with an imag e like this one:

Please quit Matlab to continue the tutorial.

>> quit example $

6.4 Block pre-processing

To run the block pre-processor :

example $ ./block3d.MB.lnx


cavmp1

example $

No screen output is produced, unless an error occur s. Two new files are created in the ‘example’ folder : cavmp1.bck and pa ram3d.inc.

6.5 Compiling caffa3d.MB

The parameter file ‘param3d.inc’ created by ‘block3 d.MB’ should be copied/moved to the ‘caffa3d.MB’ folder before comp iling. Afterwards, the compiler is called:

example $ mv ./param3d.inc ../caffa3d.MB/param3d.i nc

example $ cd ../caffa3d.MB

caffa3d.MB $

ifc –o ../example/caffa3d.MB.lnx ./caffa3 d.MB.f –IsolverSIP


11592 Lines Compiled

example $

6.6 Running the flow solver

To run the flow solver the following command needs to be issued:

caffa3d.MB $ cd ../example

example $ ./caffa3d.MB.lnx


cavmp1

11 2.9E-02 1.8E-02 6.9E-04 1.9E-02 0.0E+00 ....

11 1.5E-02 1.0E-02 6.8E-04 1.7E-02 0.0E+00 ....

....

Please note that the first line of output takes abo ut 1 min to appear in the CPU referred above for the given setup. Output from the solver is better described in the ‘.out’ file (cavmp1.out) wh ich can be checked during the computation.

6.7 Results visualisation

The provided Matlab script may be used to visualise the results. As provided, the script is configured to load the last post-processing output in the current example (cavmp1.10, see first line in ‘Caffa3dMBs.m’). The following Matlab commands may be issued in a graphics enabled system:

example $ matlab -nodesktop –nosplash

< M A T L A B >

Using Toolbox Path Cache. Type "help toolbox_path _cache"...

To get started, type one of these: helpwin, helpde sk, or demo.

For product information, visit www.mathworks.com.

>> filnam=’cavmp1.10’;

>> caffa3dMBs;

>> figure; hold on; grid on;

>> plot(GR(1).XC(42,:,42)*2-1,FL(1).VV(42,:,42),'b ','LineWidth',2)

>> plot(GR(2).XC(42,:,42)*2-1,FL(2).VV(42,:,42),'b ','LineWidth',2)

>> plot(FL(2).UU(:,3,42),GR(2).YC(:,3,42)*2-1,'b', 'LineWidth',2)

>> axis square; axis([-1,1,-1,1]);

A Matlab graphics window with a plot similar to the following one should appear. Please note that, in the figure featured he re, results from other authors as well as for other grid resolutions are a lso presented for comparison (the Matlab window should only show a pa ir of ‘blue’ U and V profiles).

7. Acknowledgements Gabriel Usera currently holds a research and teachi ng position at the Universidad de la República (Uruguay). The caffa3d. MB software package (and this documentation) was wrote during a researc h visit in the Universitat Rovira i Virgili (Catalunya), where Gab riel Usera currently pursues his PhD studies. The co-operative support f rom both Universities has been invaluable. Additionally, this work was financially supported b y grants 2002 SGR00189 from AGAUR Generalitat de Catalunya, DPI2003-06725- C02-01 from DGI, Ministerio de Ciencia y Tecnología y Fondos FEDER, assigned to the ECOMMFIT research group of the Univeritat Rovira i Virgili. Gabriel Usera also received the support of pre doct oral grants from Ministerio de Ciencia y Tecnología (Spain) and Prog rama de Desarrollo Tecnológico (Uruguay), as well as a financial aid f or research visits granted by the Universidad de la República granted through the CSIC RRHH program. Finally the authorisation of Dr. Milovan Peric for the use of his ‘caffa’ code as a basis for the caffa3d.MB package was grea tly appreciated.

8. References

[1] Iwatsu R., Hyun J.M., Kuwahara K., “ Analyses of three-dimensional flow calculations in a driven cavity ” Fluid dynamics research, 6(2):91-102,1990.

[2] Jiménez A., “ Interacció entre les estructures de flux i el trans port de materia. Aplicació a un doll pla turbulent ” PhD Thesis, Universitat Rovira i Virgili, 2003

[3] Ferziger J., Peric M., “Computational methods f or fluid dynamics” Springer-Verlag, 2002