Affichage des articles dont le libellé est CFD. Afficher tous les articles
Affichage des articles dont le libellé est CFD. Afficher tous les articles

lundi 10 novembre 2014

Darcy-Weisbach & simpleFoam

The post is a result of this thread at cfd-online.com.

There's Darcy-Weisbach equation for estimation of a pressure drop inside a tube from its geometry and flow conditions. For circular tube in laminar regime pressure drop is equal to:

$$ \Delta{P} = f_D\frac{L}{d}\rho\frac{V^2}{2} $$
where

\(f_D\) is Darcy friction factor

\(L\) is a length of the tube

\(d\) is a diameter of the tube

\(\rho\) is fluid density

\(V\) is average fluid flow velocity

In the post person was complaining about large difference between pressure drop estimated from Darcy-Weisbach equation and simulation results. As the simulation was rather obvious, and I had tube mesh nearby, so I've executed 3D case and got pressure drop value 12% off the estimation, attributed it to overall mesh quality. Cause its improvement would eventually lead to parallel simulation I've decided to run 2D simulations to check if I can get exact value of pressure drop.

Tube geometry and flow parameters are as follows:


\(L = 5~m\)

\(d = 0.02~m\)

\(\rho = 1000~\dfrac{kg}{m^3}\)

\(\nu = 10^{-6}~\dfrac{m^2}{s}\)

\(V = 0.001~\dfrac{m}{s}\,\,(Re = 20), 0.005~\dfrac{m}{s}\,\,(Re = 100)\)

According to Darcy-Weisbach pressure drop for these cases should be \(dp = 0.4~Pa\) and \(dp = 2~Pa\) correspondingly.

If in 3D there are certain inconvenient things during mesh construction, in axisymmetric 2D it's just a rectangle (though one needs to obey rules of wedge boundaries construction). Cases can be downloaded from GitHub. They are obvious simpleFoam cases with the following SIMPLE dictionary:

SIMPLE
{
    nNonOrthogonalCorrectors 0;

    residualControl
    {
        "(p|k|epsilon)" 1e-6;
        Ux 1e-6;
        Uz 1e-6;
    }
}

Well, k and epsilon residuals are not necessary for low Reynolds numbers. On figure below overall solution process is displayed. Around 1300 iteration convergence criterion was satisfied and simulation stopped.

So there were two stages of the solution: initial rapid pressure and residuals drop and further slow convergence to the pressure drop estimated with D-W equation. As the value of the pressure drop seems to be flat after 600 s, below are two zoomed versions of the plot: the first just changes range on y-axis, while the second also changes range on x-axis:

So on zoomed plots one can see that in fact pressure goes slightly below estimated value (guess, due to the way I estimated pressure drop in simulation). Also one can choose desired value of convergence criterion residuals and estimate the error. It would be quite interesting to check this thing in transient simulations as usually people select fixed number of outer iterations instead of residual control for convergence criterion.

The same figures for the case Re = 100 are shown below:
The pressure drop evolution looks almost like in the previous case, though it took longer to converge (due to higher Reynolds number?).
Zoomed versions of the plot again show that pressure drop went below estimated value and flatlining of the pressure is not actually flatlining.

Look out for your residuals.

mardi 18 mars 2014

OpenFOAM, residuals, and vortex street

This post appeared due to the question on cfd-online.com OpenFOAM forum. It has been started as yet another post on Kármán vortex street but then (around message #60) original poster revealed an article he was trying to compare with, so I've decided to check influence of different discretisation schemes and convergence criterions on final results.

Geometry and flow conditions

The first version of geometry and boundary conditions can be found in post #11, though they slightly differ from the geometry provided in the article (and as a result, from geometry used in simulations).



So we've got a cylinder with diameter D placed in the channel with a length 16D and a width 8D. At the inlet we have velocity 1 m/s, at the outlet zero pressure and zero gradient in velocity. Initially velocity inside the domain set to 1 m/s. With D = 1 m and fluid kinematic viscosity 100 m2/s, Reynolds number is equal to 100.

First attempt

Well, the first variant of the simulation was just a simulation for its own sake (even Re was 200). Just to produce neat pictures. And these videos:




Flow develops, vortices go.

Second attempt

After reading the original article I've decided to check different meshes, discretisation schemes, and convergence criteria to learn if there's any difference. In the article authors were developing new method in FEM framework, so theirs original mesh was triangular with increased density near a centerline of the channel. Now I think there's a need for another set of simulations: with and without increase of mesh density near the center-line of the channel.

Meshes

I've fallen in love with Gmsh for generating meshes, so these two meshed are produced with it. As Gmsh now has transfinite algorithm, it is more or less like blockMesh with GUI, variables and functions in a mesh file, more convenient way of grading description. Much like in blockMesh one needs to define vertices and then can use GUI to describe lines, surfaces and volumes. Then again switch to text editor for definition of transfinite lines, progressions (in the sense of Gmsh), etc. I will omit iterations during the mesh creation process and just provide GEO files with screenshots of the mesh:

"Coarse" mesh

image
Coarse cylinder-2D.geo

"Fine" mesh

image
Fine cylinder-2D.geo

The only difference between coarse and fine mesh is twice increased density in case of "Fine" mesh. So a number of cells in the fine mesh is 4 times higher than in coarse mesh.

fvSchemes

Typical fvSchemes file is provided below. The only line that is changed from simulation to simulation is div(phi,U) Gauss vanLeerV;, I've chosen to compare three different second order discretisation schemes with limiters: van Leer, QUICK, and Gamma.

/*--------------------------------*- C++ -*----------------------------------*\
| =========                 |                                                 |
| \\      /  F ield         | OpenFOAM: The Open Source CFD Toolbox           |
|  \\    /   O peration     | Version:  1.6                                   |
|   \\  /    A nd           | Web:      www.OpenFOAM.org                      |
|    \\/     M anipulation  |                                                 |
\*---------------------------------------------------------------------------*/
FoamFile
{
   version     2.0;
   format      ascii;
   class       dictionary;
   location    "system";
   object      fvSchemes;
}
// * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * //

ddtSchemes
{
   default         CrankNicolson 1.0;
}

gradSchemes
{
   default         Gauss linear;
}

divSchemes
{
   default         none;
   div(phi,U)      Gauss vanLeerV;
   div((nuEff*dev(T(grad(U))))) Gauss linear;
}

laplacianSchemes
{
   default         none;
   laplacian(nuEff,U) Gauss linear corrected;
   laplacian((1|A(U)),p) Gauss linear corrected;
}

interpolationSchemes
{
   default         linear;
}

snGradSchemes
{
   default         corrected;
}

fluxRequired
{
   default         no;
   p               ;
}


// ************************************************************************* //

fvSolution

In case of fvSolution file I changed PIMPLE dictionary:
PIMPLE
{
    momentumPredictor yes;
    nCorrectors       2;
    nOuterCorrectors  20;
    nNonOrthogonalCorrectors 1;

    residualControl
    {
        "(U|p)"
        {
            tolerance 1e-2;
            relTol 0;
        }
    }
}

Keeping everything else the same, I changed tolerance in residualControl dictionary to see if it influence results. I've checked values 1e-2, 1e-4, and 1e-6. This value defines the moment when PIMPLE loop will exit from outer corrector cycle. And usually in the beginning of a simulation number of outer correctors is around 4 (for the case of residual 1e-6 - 8), during the time this number falls to 2 (or 4 for the case of 1e-6). I don't know why all tutorial cases use fixed number of outer corrector iterations, sometimes it can lead to completely incorrect results. Maybe OpenFOAM decided that residualControl is "advanced" technique.

Also there're lots of scary posts on relaxation, so I've decided also to check the influence of relaxation factors on results of a simulation. So instead of standard

relaxationFactors
{
    fields
    {
    }
    equations
    {
       "U.*" 1.0;
       "p.*" 1.0;
    }
}

I used

relaxationFactors
{
    fields
    {
    }
    equations
    {
       "U.*" 0.7;
       "p.*" 0.3;
    }
}

Results

Color contours usually provide only schematic view of the flow, so further (surely after these pictures) I will be comparing oscillations of force coefficients. Sometimes it is possible to plot isolines of pressure and velocity on the same picture (when the phases of the oscillating flow do not differ much). But now, the color contours (time is 150 s):

Pressure
van Leer
image

QUICK
image

Gamma
image

Though values seem to be more or less the same, vortices are shifted in time. The same thing is for velocity components:

Ux
van Leer
image

QUICK
image

Gamma
image

Uy
van Leer
image

QUICK
image

Gamma
image

Discretisation schemes comparison

I've fixed final residual in fvSolution at 1e-6 and just changed discretisation scheme. On the graphs X-axis is time, Y-axis is value. All simulations were done on the 'fine' mesh.



There is phase shift between graphs, I've moved them to compare oscillation amplitude. There is difference but it's not so big.



And as there is phase shift between different scheme I will omit comparison of the pressure and velocity contours. While there is difference between Cdrag oscillation amplitudes, Clift oscillations go rather synchronously:





Final residuals comparison

After that I've decided to check sensitivity of a discretisation scheme on final residual. I've fixed the scheme and run simulations for different final residuals: 1e-2, 1e-4, and 1e-6.
While van Leer and Gamma showed almost no dependence (though there is slight shift when going from 1e-2 to 1e-4 for Gamma):

















For QUICK switch from 1e-2 to 1e-4 leads to quite large time shift between oscillations:









But even if the time shift in oscillations seems to be not so big, positions of the vortices are strongly depend on this shift. Below is overlays of Ux isolines for van Leer and Gamma schemes at 150 s:




If for van Leer scheme contours are almost the same, for Gamma results with residual 1e-2 are sufficiently shifted.

Mesh density comparison

Also compared results acquired using meshes with different densities. Number of cells in the meshes differ 4 times as I've reduced densities twice in X and Y directions.
Gamma showed just decrease of Cdrag and Clift values on fine mesh, while with QUICK and van Leer schemes there's also phase shift between results on different meshes.

Cdrag





Clift





To relax or not

Finally I've decided to check if a relaxation is really crucial to results. I've fixed the discretisation scheme (van Leer, though now I think maybe it was better to choose Gamma), the final residual in PIMPLE dictionary and just modified relaxation part as shown in the beginning of the post. Surely due to the relaxation solution converges slowly, i.e. instead of 4-5 outer corrector iterations 9-11 iterations was necessary. Also there is a time shift between results.









Conclusion

So it goes.

As usual case files (if you'd like to reproduce results) are on bitbucket.org.

dimanche 22 décembre 2013

Building OpenFOAM 2.2.2 on OS X with clang

NB! Updated version of the guide can be found in the post Building OpenFOAM on OS X

There are several instructions for building OpenFOAM on OS X (1, 2). They assume that you are using Macports which was not a case with me. So I've decided to build OpenFOAM with clang as it comes with developer tools. My patches are based upon ones by Bernhard Gschaider, basically I've applied his patches, removed Macports stuff and added clang stuff. Patches and build process was tested on OS X 10.9 with clang --version:

Apple LLVM version 5.0 (clang-500.2.79) (based on LLVM 3.3svn)
Target: x86_64-apple-darwin13.0.0
Thread model: posix

So, to build OpenFOAM you need:
  1. Download OpenFOAM and Third-Party source packs here.
  2. Create a disk image with Disk Utility. One needs this image to create case sensitive file system (see 1 or 2 for instructions with pictures).
  3. Download patches for OpenFOAM and Third-Party source packs. They assume you are building 64-bit version of the code as there're no wmake rules for 32-bit compilation.
  4. Mount created disk image to $HOME/OpenFOAM
  5. Unpack source packs to $HOME/OpenFOAM
  6. Copy patch files to source folders (OpenFOAM-2.2.2-1387556919.patch to OpenFOAM-2.2.2, ThirdParty-2.2.2-1387556964.patch to ThirdParty-2.2.2).
  7. Apply patches with git apply [patch file name] command. In addition to changing contents of the files git sets modes so you won't need to do chmod 0755 [file] on executable files created by the patches.
  8. Edit $HOME/OpenFOAM/OpenFOAM-2.2.2/ets/bashrc file to correspond to your system. I've tested build with OPENMPI (1.6.3, in ThirdParty source pack), and with SYSTEMOPENMPI (1.7.3, installed with Homebrew, I guess if you're using Macports you'll need to modify wmake rules).
  9. Source bashrc with source etc/bashrc
  10. Now you can execute Allwmake script to build OpenFOAM.
To mount disk image and source OpenFOAM's bashrc file automatically each time you launch Terminal one can add following lines to $HOME/.profile file:
# OpenFOAM
if [ -f $HOME/.OpenFOAM ]; then
    OF_VER=$(cat $HOME/.OpenFOAM)
    if [ ! -f $HOME/OpenFOAM/OpenFOAM-$OF_VER/etc/bashrc ]; then
        hdiutil attach -quiet -mountpoint $HOME/OpenFOAM OpenFOAM-$OF_VER.dmg &&
            . $HOME/OpenFOAM/OpenFOAM-$OF_VER/etc/bashrc
    else
        . $HOME/OpenFOAM/OpenFOAM-$OF_VER/etc/bashrc
    fi
fi
And create $HOME/.OpenFOAM file with OpenFOAM version in it with:
echo '2.2.2' > $HOME/.OpenFOAM
Now you can test installation with standard icoFoam run:
$ mkdir -p $FOAM_RUN
$ run
$ cp -r $FOAM_TUTOTALS/incompressible/icoFoam/cavity .
$ cd cavity
$ blockMesh
$ icoFoam
Also maybe it's worth to move $FOAM_RUN folder somewhere outside of disk image and create symlink.

That's it.