Gambit example: model a 2D channel

"CFD example: laminar flow along a 2D channel" applied SALOME to model and mesh a 2D channel geometry for Code_Saturne to perform the simulation. However, someone likes to use Gambit, a product from ANSYS Fluent, and of course, the same example can also be made with the help of Gambit. Furthermore, similar to SALOME using Python for automatisation, Gambit has Journal file to automatise the manual procedure. The present post aims to translate the previous example into Gambit Journal file in order to show an illustration for beginners.

Basic instructions

1. comments. A comment line in Gambit Journal is headed with a forward slash, /.

/ This line is commented.

2. variables. One is able to define a variable with a name beginning with $. The variable represents a float point value.

$length = 0.1

3. arrays. Array names are also begun with $. In Gambit Journal, array is indexed by a 1 based number, which is quoted by a pair of square parenthesis, []. The index range of an array should be given at the definition declaration of the array itself.

declare $points[1 : 3]
$points[1] = 1.0
$points[2] = 0.0
$points[3] = 0.0

4. For the construction method of points, edges and faces, it is quite concise as well. Please refer to the simple example given in the next section.

The example

Once again, according to the philosophy of executing commands on terminals, Gambit Journal scripts are used to illustrate the example.

///////////////////////////////////////////////////////////////////////
/ Geometry construction and meshing creation for a typical
/ 2d channel flow between two infinite parallel plates.
/
/ Written by: salad
/ Manchester, UK
/ 06/12/2009
///////////////////////////////////////////////////////////////////////
/
/ L = 0.1 m, D = 0.005 m
/
/     C  --------- B
/       |         |
/ -->   |         |
/     O  --------- A
/
/ V_in = 0.05 m/s
/ t    = 50 degree C
///////////////////////////////////////////////////////////////////////

Define the variables and points, and then construct edges and faces accordingly.

/ Variable Definition
$length = 0.1
$height = 0.005

/ points
vertex create "O" coordinates 0
vertex create "A" coordinates $length
vertex create "B" coordinates $length $height
vertex create "C" coordinates 0 $height

/ edges
edge create "OA" straight "O" "A"
edge create "AB" straight "A" "B"
edge create "BC" straight "B" "C"
edge create "CO" straight "C" "O"

/ faces
face create "DUCT" wireframe "OA" "AB" "BC" "CO"

After the geometry is constructed, build the mesh, define the boundaries, and then create a zone corresponding to the 2D face "DUCT". Note that, differing from the SALOME example, here the 2D model is not extruded along the z axis, because originally, I wrote the script for Fluent to use at that moment.

/ mesh
edge mesh "CO" intervals 50
edge mesh "OA" intervals 250
face mesh "DUCT"

/ boundary
physics create "inlet" btype "VELOCITY_INLET" edge "CO"
physics create "bottom" btype "WALL" edge "OA"
physics create "top" btype "WALL" edge "BC"
physics create "outlet" btype "PRESSURE_OUTLET" edge "AB"

/ zones
physics create "duct_v" ctype "FLUID" face "DUCT"

Finally, export the mesh file for future use.

/ export
export uns "2d_duct_flow.msh"


MEI is easy to use and works like a charm!

The most expected feature coming from Code_Saturne 2.0-rc1 is the better supported MEI functions. With help of the small CFD calculation case, I tested the feature and have to say that MEI is truly easy to use and works like a charm. Before when I used COMSOL I defined the fluid properties by writting simple MATLAB expressions; (COMSOL is easy to be integrated into MATLAB because originally it is a third party toolbox for MATLAB). It is as easy as you can imagine, and now, within Code_Saturne we are also able to have the same fun.

I used two methods to define the fluid density and viscosity expressions: FORTRAN user routines and MEI expressions. By comparing the results, both methods actually have the same effect. Because I already talked about the first method in the previous tutorial post, I focus on the second one here. Before following, make sure you read "Installation of Code_Saturne 2.0-rc1 on Ubuntu 9.10" and installed 2.0-rc1 with MEI properly.

With the SaturneGUI program, when using 'Physical properties > Fluid properties' to define fluid properties, we have options 'constant', 'user law' and 'user subroutine(usphyv)'. If the property is a constant, fill a value below as a reference value. If select 'user law', MEI expressions can be inputted by clicking the following edit button. Finally, as mentioned previously, the option 'user subroutine' is for using FORTRAN routines to define the properties.


Click the edit button, and see a dialog as the figure below shows. I input a simple density expression as an illustration. Actually there are three tabpages here and the third one also contains an example. TempC is a pre-defined variable, which can be looked up from the second tabpage 'Predefined symbols'. Most operators like +, -, *, /, and ^ can be used, and even simple statements like if ... else can be applied.


Then we don't need to define the temperture dependent density in FORTRAN user routines any more. Obviously this MEI method is more straightforward. I don't say more about the viscosity part, because it is almost the same.

Re-use density value when calculating dynamic viscosity

Dynamic viscosity is the product of density and kinematic viscosity . Sometimes when only a kinematic viscosity expression is available, we need to calculate the dynamic viscosity value with the help of the correlation, .

When using FORTRAN user routines of Code_Saturne, it is possible to realise the correlation directly, which actually implies the previously calculated density value could be read for the viscosity calculating part to use. However, on the other hand, within MEI we don't have a pre-defined symbol, for example rho, to express density when defining a dynamic viscosity mu, and thus we have to expand the rho expression with its original and complicated form into the mu definition expression.

Fortunately, Alexandre gives a patch to implement the idea (see the conversation). After apply the patch accordingly, re-compile ncs, a pre-defined variable rho can then be used for the mu definition. I tested the patch and it works properly.

Post-processing with ParaView

In order to judge whether both methods yield the same effect, the calculation results are analysed. If select to export results into 'EnSight Gold' format, ParaView is going to be used.

ParaView is a cross-platform tool to perform post-processing of numerical simulations. For a beginner I guess it slightly confusing about the mouse controls to move its camera view; at least for me it was true. Actually, select the menu item 'Edit > Settings...' and in the 'Options' dialog ship into the category 'Render View > Camera', can find and modify the controls.


It is not difficult to use ParaView to see the surface plot of a specific parameter, for example, temperature. Select the cell data TempC from the toolbar and the view can then be like this:


From the picture we can see the development of the thermal boundary layer attched to the top and the bottom surfaces of the channel. From the legend the temperature range is found to be 50 to 91.7293 degree C (50 degree C is the inlet temperature), which actually implies the density and viscosity ranges. With MATLAB I estimated them.

>> TempC = [50, 91.7293];
>> rho = 895 ./ (1 + 6.5e-4 .* (TempC - 20))

rho =

  877.8813  855.1304

>> visc = rho .* (0.75857 * (1.8 .* TempC + 32).^-2.34)

visc =

    0.0087    0.0028

Select the data Density and LamVisc in ParaView and see their ranges are 855.12872 to 877.88129 and 0.0027963 to 0.0087367, respectively. They match the results given by MATLAB very well expect the density at 91.7293 degree C, for which there is a very small error, 0.0002%. Thereby, we are happy to see Code_Saturne correctly used the parameter expressions as we expected.

Meanwhile, I compared the results from MEI and FORTRAN user routines, and found their results match exactly, which could imply they have the same effect.

Velocity development along the centreline

Using the filter 'Plot Over Line' we can examine the fluid flow velocity along the centreline of the 2D channel.


Apparently, the velocity rises rapidly at the beginning stage of the channel flow, and then gradually falls. The rise stage is actually within the entrance distance for the flow to be fully developed. On the other hand, the gradual reduction is because of the temperature dependency of the fluid viscosity, as discussed in the previous post "CFD tutorial: laminar flow along a 2D channel - Part I".

Installation of Code_Saturne 2.0-rc1 on Ubuntu 9.10

NEW - A post "Installation of Code_Saturne 2.0-rc1 on Ubuntu 10.04 (64 bit)" was recently published and recommended if you have already updated to Ubuntu 10.04.

NEW - On the Code_Saturne forum, David Monfort made very good and useful comments on this post. Please don't miss them.

Code_Saturne 2.0-rc1 is recently released (see the announce, from which all the source packages can be downloaded), and thanks to David's helpful comments on my previous post "Installation of Code_Saturne 2.0.0 on Ubuntu 9.04", I quickly reviewed the installation procedure of this new release, 2.0-rc1. Probably, there can be some interesting points to share with you.

1. Regarding using apt-get to install HDF5 and MED libraries

As advised by David, I found it is easy to install HDF5 and MED by apt-get. libhdf5-dev is a virtual package provided by either one from these:
libhdf5-serial-dev
libhdf5-openmpi-dev
libhdf5-mpich-dev
libhdf5-lam-dev

I explicitly selected libhdf5-openmpi-dev to install. Additionally, hdf5-tools is also necessary to provide h5dump if want to manually compile MED.

$ sudo apt-get install libhdf5-openmpi-dev hdf5-tools

Regarding MED, libmedc-dev is the right one, which depends on another two packages: libmedc1 and libhdf5-serial-1.6.6-0.

sudo apt-get install libmedc-dev

apt-get actually installs slightly older versions of HDF5 and MED, 1.6.6 and 2.3.1, respectively. This is a drawback. More severely, when I 'configure' fvm and ecs, they complained about the old version.
MED >= 2.3.4 headers not found
compatible MED headers not found

Then I think I have to compile MED 2.3.6 by myself.

When trying to compile MED 2.3.6 with the apt-get installed HDF5, I passed the configure but blocked at the make stage.
libtool: compile: gcc -DHAVE_CONFIG_H -I. -I../../include -I../../include -DH5_USE_16_API -g -O2 -MT MEDchampCr.lo -MD -MP -MF .deps/MEDchampCr.Tpo -c MEDchampCr.c -fPIC -DPIC -o .libs/MEDchampCr.o
In file included from /usr/include/hdf5.h:24,
                 from ../../include/med.h:21,
                 from MEDchampCr.c:19:
/usr/include/H5public.h:54:20: error: mpi.h: No such file or directory
/usr/include/H5public.h:56:21: error: mpio.h: No such file or directory

I don't know why but I did install openmpi packages. Ok, since the old version got problems, I turned to compile them again.

2. Process to install 2.0-rc1

If compile the source code, I gladly found most part of the post "Installation of Code_Saturne 2.0.0 on Ubuntu 9.04" can also work well for 2.0-rc1, except the following points:

a. Metis got a confliction with '/usr/include/bits/mathcalls.h'. I am not familiar with this mathcalls.h, but I did a patch to avoid the confliction.
:~/saturne/metis-4.0$ make
(cd Lib ; make )
make[1]: Entering directory `~/saturne/metis-4.0/Lib'
cc -O2 -I. -c coarsen.c
In file included from ./metis.h:36,
                 from coarsen.c:13:
./proto.h:462: error: conflicting types for ‘__log2’
/usr/include/bits/mathcalls.h:145: note: previous declaration of ‘__log2’ was here
make[1]: *** [coarsen.o] Error 1
make[1]: Leaving directory `/home/salad/saturne/metis-4.0/Lib'
make: *** [default] Error 2

We can actually change the function name 'log2' to 'ilog2' in the related head files and source codes under the directory, Lib. The files include: proto.h, rename.h, kmetis.c, kvmetis.c, mkmetis.c and util.c.

You can download my patched version of Metis-4.0 from this link.

b. MEI is now compulsory to be prepared for the compilation of ncs.

It is not difficult to prepare MEI. Firstly, make sure all necessary packages are installed.
:/$ sudo apt-get install bison flex swig python-dev

Then the compilation is easy.

# ship into mei-1.0.1
:/$ ./configure --with-bft=/usr/local
:/$ make
:/$ sudo make install

Note that explicitly specifying --with-bft=/usr/local is necessary for Python to find bft.

c. Regarding ncs, remember to extract the patch file patches-portability-ncs-20rc1.tgz to the ncs directory. When 'configure' ncs, the option 'LIBS=-lm' can be ignored now. It was a bug existing in version 2.0.0-beta2.

# ship into ncs-2.0.0-rc1
:/$ ./configure --with-mpi=/usr/lib/openmpi --with-prepro=/usr/local --with-mei=/usr/local

Once again, an explicit --with-mei=/usr/local is necessary for the python modules.

d. Because there is no eps figure contained in the latex document directories any more, mentioned by David, package texlive-extra-utils is not necessary to install either. However, transfig is still necessary to provide the tool, fig2dev.

# for LaTeX documents
:/$ sudo apt-get install tetex-bin tetex-base transfig

To be honest tetex is already obsoleted from Ubuntu; texlive is much better and can be used instead. I get used to tetex, so I am still using it.

For those who don't use latex elsewhere, maybe installing these huge latex packages to compile Code_Saturne documents seems to be a waste. Don't worry. I prepare my compiled documents (pdf files) here for you to use directly. You can copy the pdf files into the directory /usr/local/share/doc/ncs to let Code_Saturne find them.

e. Before we use command 'cs config' to check the newly installed Code_Saturne status, and then in 2.0-rc1 version, the script 'cs' changes its name to 'code_saturne'.

:/$ code_saturne config

Probably one has to re-create his study and case configurations again with 2.0-rc1, because I tried to open an old xml file, which was previously produced by 2.0.0-beta2, with the SaturneGUI, and it complained that it seems to be for an old version.

3. Future work

The future work ideas are from the mentioned comments, and they include:

a. Different ATLAS packages are provided on Ubuntu for different CPU instruction sets, libatlas-base-dev, libatlas-3dnow-dev, libatlas-sse-dev and libatlas-sse2-dev etc. libatlas-base-dev is only a generic one and should work on every supported CPU architecture. Benchmark could be made to find a most optimised ATLAS package for a specific CPU.

b. MEI is expected to be a very useful feature. With help of MEI, some work, for which FORTRAN user routines have to be written in the past days, can be done by simply expressed formulae. Definitely it is interesting for me to try this.

c. CFDSTUDY is a plugin that allows Code_Saturne to be embedded in the Salome platform. Please read this. An integrated CFD environment can be imagined from this.

d. Last but not least, I tried to apt-get install code-saturne because I know Code_Saturne is already in Debian "unstable" depository. I guess making Code_Saturne available from apt-get might be an ultimate solution for people to install it easily.

salad@salad-desktop:~$ sudo apt-get install code-saturne
Reading package lists... Done
Building dependency tree
Reading state information... Done
Package code-saturne is not available, but is referred to by another package.
This may mean that the package is missing, has been obsoleted, or is only available from another source
E: Package code-saturne has no installation candidate

This actually implies we have to work harder to make an easier life.