2.3 Breaking of a dam

Back to OpenFOAM Home

OpenCFD®

Company profile

OpenFOAM support

OpenFOAM development

OpenFOAM training

Solutions

Contact OpenCFD

Recruitment

2.3 Breaking of a dam

In this tutorial we shall solve a problem of simplified dam break in 2 dimensions using the interFoam.The feature of the problem is a transient flow of two fluids separated by a sharp interface, or free surface. The two-phase algorithm in interFoam is based on the volume of fluid (VOF) method in which a specie transport equation is used to determine the relative volume fraction of the two phases, or phase fraction $g \special {t4ht=$ , in each computational cell. Physical properties are calculated as weighted averages based on this fraction. The nature of the VOF method means that an interface between the species is not explicitly computed, but rather emerges as a property of the phase fraction field. Since the phase fraction can have any value between 0 and 1, the interface is never sharply defined, but occupies a volume around the region where a sharp interface should exist.

The test setup consists of a column of water at rest located behind a membrane on the left side of a tank. At time $t = 0 s \special {t4ht=$ , the membrane is removed and the column of water collapses. During the collapse, the water impacts an obstacle at the bottom of the tank and creates a complicated flow structure, including several captured pockets of air. The geometry and the initial setup is shown in 2.20.

$0.584 m water column 0.584 m 0.292 m 0.048 m 0.024 m 0.1461 m 0.1459 m \special {t4ht=$

Figure 2.20:

Geometry of the dam break.

2.3.1 Mesh generation

The user should go to the damBreak case in their $FOAM_RUN/tutorials/interFoam directory. Generate the mesh running blockMesh as described previously. The damBreak mesh consist of 5 blocks; the blockMeshDict entries are given below.

17  convertToMeters 0.146;
18
19  vertices
20  (
21      (0 0 0)
22      (2 0 0)
23      (2.16438 0 0)
24      (4 0 0)
25      (0 0.32876 0)
26      (2 0.32876 0)
27      (2.16438 0.32876 0)
28      (4 0.32876 0)
29      (0 4 0)
30      (2 4 0)
31      (2.16438 4 0)
32      (4 4 0)
33      (0 0 0.1)
34      (2 0 0.1)
35      (2.16438 0 0.1)
36      (4 0 0.1)
37      (0 0.32876 0.1)
38      (2 0.32876 0.1)
39      (2.16438 0.32876 0.1)
40      (4 0.32876 0.1)
41      (0 4 0.1)
42      (2 4 0.1)
43      (2.16438 4 0.1)
44      (4 4 0.1)
45  );
46
47  blocks
48  (
49      hex (0 1 5 4 12 13 17 16) (23 8 1) simpleGrading (1 1 1)
50      hex (2 3 7 6 14 15 19 18) (19 8 1) simpleGrading (1 1 1)
51      hex (4 5 9 8 16 17 21 20) (23 42 1) simpleGrading (1 1 1)
52      hex (5 6 10 9 17 18 22 21) (4 42 1) simpleGrading (1 1 1)
53      hex (6 7 11 10 18 19 23 22) (19 42 1) simpleGrading (1 1 1)
54  );
55
56  edges
57  (
58  );
59
60  patches
61  (
62      wall leftWall
63      (
64          (0 12 16 4)
65          (4 16 20 8)
66      )
67      wall rightWall
68      (
69          (7 19 15 3)
70          (11 23 19 7)
71      )
72      wall lowerWall
73      (
74          (0 1 13 12)
75          (1 5 17 13)
76          (5 6 18 17)
77          (2 14 18 6)
78          (2 3 15 14)
79      )
80      patch atmosphere
81      (
82          (8 20 21 9)
83          (9 21 22 10)
84          (10 22 23 11)
85      )
86  );
87
88  mergePatchPairs
89  (
90  );
91
92  // ************************************************************************* //

2.3.2 Boundary conditions

The user can examine the boundary geometry generated by blockMesh by viewing the boundary file in the constant/polyMesh directory. The file contains a list of 5 boundary patches: leftWall, rightWall, lowerWall, atmosphere and defaultFaces. The user should notice the type of the patches. The atmosphere is a standard patch, i.e. has no special attributes, merely an entity on which boundary conditions can be specified. The defaultFaces patch is empty since the patch normal is in the direction we will not solve in this 2D case. The leftWall, rightWall and lowerWall patches are each a wall. Like the plain patch, the wall type contains no geometric or topological information about the mesh and only differs from the plain patch in that it identifies the patch as a wall, should an application need to know, e.g. to apply special wall surface modelling.

A good example is that the interFoam solver includes modelling of surface tension at the contact point between the interface and wall surface. The models are applied by specifying the gammaContactAngle boundary condition on the gamma ( $g \special {t4ht=$ ) field. With it, the user must specify the following: a static contact angle, theta0 $h0 \special {t4ht=$ ; leading and trailing edge dynamic contact angles, thetaA $hA \special {t4ht=$ and thetaR $hR \special {t4ht=$ respectively; and a velocity scaling function for dynamic contact angle, uTheta.

In this tutorial we would like to ignore surface tension effects between the wall and interface. We can do this by setting the static contact angle, $h = 90o 0 \special {t4ht=$ and the velocity scaling function to 0. However, the simpler option which we shall choose here is to specify a zeroGradient type on gamma, rather than use the gammaContactAngle boundary condition.

The top boundary is free to the atmosphere and so is given an atmosphere boundary type; the defaultFaces representing the front and back planes of the 2D problem, is, as usual, an empty type.

2.3.3 Setting initial field

Unlike the previous cases, we shall now specify a non-uniform initial condition for the phase fraction $g \special {t4ht=$ where

{ 1 for the liquid phase g = 0 for the gas phase \special {t4ht=

(2.15)

This will be done by running the setFields utility. It requires a setFieldsDict dictionary, located in the system directory, whose entries for this case are shown below.

17  defaultFieldValues
18  (
19      volScalarFieldValue gamma 0
20      volVectorFieldValue U (0 0 0)
21  );
22
23  regions
24  (
25      boxToCell
26      {
27          box (0 0 -1) (0.1461 0.292 1);
28
29          fieldValues
30          (
31              volScalarFieldValue gamma 1
32          );
33      }
34  );
35
36  // ************************************************************************* //

The defaultFieldValues sets the default value of the fields, i.e. the value the field takes unless specified otherwise in the regions sub-dictionary. That sub-dictionary contains a list of subdictionaries containing fieldValues that override the defaults in a specified region. The region is expressed in terms of a topoSetSource that creates a set of points, cells or faces based on some topological constraint. Here, boxToCell creates a bounding box within a vector minimum and maximum to define the set of cells of the liquid region. The phase fraction $g \special {t4ht=$ is defined as 1 in this region.

The user should execute setFields as any other utility is executed. Using paraFoam, check that the initial gamma field corresponds to the desired distribution as in 2.21.

$Phase fraction, g 1.0 0.9 0.8 0.7 0.6 0.5 0.4 0.3 0.2 0.1 0.0 \special {t4ht=$

Figure 2.21:

Initial conditions for phase fraction gamma.

2.3.4 Fluid properties

Let us examine the transportProperties file in the constant directory. It dictionary contains the material properties for each fluid, separated into two subdictionaries phase1 and phase2. The transport model for each phase is selected by the transportModel keyword. The user should select Newtonian in which case the kinematic viscosity is single valued and specified under the keyword nu. The viscosity parameters for the other models, e.g.CrossPowerLaw , are specified within subdictionaries with the generic name <model>Coeffs, i.e.CrossPowerLawCoeffs in this example. The density is specified under the keyword rho.

The surface tension between the two phases is specified under the keyword sigma. The values used in this tutorial are listed in 2.3.

phase1 properties

Kinematic viscosity	$m2 s-1 \special {t4ht=$	nu	$1.0× 10-6 \special {t4ht=$
Density	$kg m -3 \special {t4ht=$	rho	$1.0 × 103 \special {t4ht=$

phase2 properties

Kinematic viscosity	$2 -1 m s \special {t4ht=$	nu	$- 5 1.48 × 10 \special {t4ht=$
Density	$kg m -3 \special {t4ht=$	rho	1.0

Properties of both phases

Surface tension	$-1 N m \special {t4ht=$	sigma	0.07

Table 2.3:

Fluid properties for the damBreak tutorial

The environmentalProperties dictionary specifies the gravity acceleration vector which should be set to $(0,9.81,0) m s-2 \special {t4ht=$ for this tutorial.

2.3.5 Time step control

Time step control is an important issue in free surface tracking since the surface-tracking algorithm is considerably more sensitive to the Courant number $Co \special {t4ht=$ than in standard fluid flow calculations. Ideally, we should not exceed an upper limit $Co ~~ 0.2 \special {t4ht=$ in the region of the interface. In some cases, where the propagation velocity is easy to predict, the user should specify a fixed time-step to satisfy the $Co \special {t4ht=$ criterion. For more complex cases, this is considerably more difficult. interFoam therefore offers automatic adjustment of the time step as standard in the controlDict. The user should specify adjustTimeStep to be on and the the maximum $Co \special {t4ht=$ , maxCo to be 0.5. The upper limit on time step maxDeltaT can be set to a value that will not be exceeded in this simulation, e.g. 1.0.

By using automatic time step control, the steps themselves are never rounded to a convenient value. Consequently if we request that OpenFOAM saves results at a fixed number of time step intervals, the times at which results are saved are somewhat arbitrary. However even with automatic time step adjustment, OpenFOAM allows the user to specify that results are written at fixed times; in this case OpenFOAM forces the automatic time stepping procedure to adjust time steps so that it ‘hits’ on the exact times specified for write output. The user selects this with the adjustableRunTime option for writeControl in the controlDict dictionary. The controlDict dictionary entries should be:

17  application interFoam;
18
19  startFrom       startTime;
20
21  startTime       0;
22
23  stopAt          endTime;
24
25  endTime         1;
26
27  deltaT          0.001;
28
29  writeControl    adjustableRunTime;
30
31  writeInterval   0.05;
32
33  purgeWrite      0;
34
35  writeFormat     ascii;
36
37  writePrecision  6;
38
39  writeCompression uncompressed;
40
41  timeFormat      general;
42
43  timePrecision   6;
44
45  runTimeModifiable yes;
46
47  adjustTimeStep  yes;
48
49  maxCo           0.5;
50
51  maxDeltaT       1;
52
53  // ************************************************************************* //

2.3.6 Discretisation schemes

The free surface treatment in OpenFOAM does not account for the effects of turbulence. This is a consequence of the fact that the Reynolds averaged approach to turbulence modelling does not match the notion of an infinitesimally thin interface between air and water. As a consequence, all free surface simulations can be viewed as a direct numerical simulation (DNS) of fluid flow. DNS is associated with certain requirements on the mesh size, far beyond the mesh resolution of our test case.

This solver uses the multidimensional universal limiter for explicit solution (MULES) method, created by OpenCFD, to maintain boundedness of the phase fraction independent of underlying numerical scheme, mesh structure, etc.. The choice of schemes for convection are therfore not restricted to those that are strongly stable or bounded, e.g. upwind differencing.

The convection schemes settings are made in the divSchemes sub-dictionary of the fvSchemes dictionary. In this example, the convection term in the momentum equation ( $\~/ •(rfU) \special {t4ht=$ ), denoted by the div(rho*phi,U) keyword, uses Gauss limitedLinearV 1.0 to produce good accuracy. The limited linear schemes require a coefficient $f \special {t4ht=$ as described in 4.4.1. Here, we have opted for best stability with $f = 1.0 \special {t4ht=$ . The $\~/ •(fg) \special {t4ht=$ term, represented by the div(phi,gamma) keyword uses the vanLeer scheme. The $\~/ •(frbg) \special {t4ht=$ term, represented by the div(phirb,gamma) keyword, can similarly use the vanLeer scheme, but generally produces smoother interfaces using the specialised interfaceCompression scheme.

The other discretised terms use commonly employed schemes so that the fvSchemes dictionary entries should therefore be:

17  ddtSchemes
18  {
19      default Euler;
20  }
21
22  gradSchemes
23  {
24      default         Gauss linear;
25      grad(U)         Gauss linear;
26      grad(gamma)     Gauss linear;
27  }
28
29  divSchemes
30  {
31      div(rho*phi,U)  Gauss limitedLinearV 1;
32      div(phi,gamma)  Gauss vanLeer;
33      div(phirb,gamma) Gauss interfaceCompression;
34  }
35
36  laplacianSchemes
37  {
38      default         Gauss linear corrected;
39  }
40
41  interpolationSchemes
42  {
43      default         linear;
44  }
45
46  snGradSchemes
47  {
48      default         corrected;
49  }
50
51  fluxRequired
52  {
53      default         no;
54      pd;
55      pcorr;
56      gamma;
57  }
58
59  // ************************************************************************* //

2.3.7 Linear-solver control

In the fvSolution, the PISO sub-dictionary contains elements that are specific to interFoam. There are the usual correctors to the momentum equation but also correctors to a PISO loop around the $g \special {t4ht=$ phase equation. Of particular interest are the nGammaSubCycles and cGamma keywords. nGammaSubCycles represents the number of sub-cycles within the $g \special {t4ht=$ equation; sub-cycles are additional solutions to an equation within a given time step. It is used to enable the solution to be stable without reducing the time step and vastly increasing the solution time. Here we specify 4 sub-cycles, which means that the $g \special {t4ht=$ equation is solved in $4× \special {t4ht=$ quarter length time steps within each actual time step.

The cGamma keyword is a factor that controls the compression of the interface where: 0 corresponds to no compression; 1 corresponds to conservative compression; and, anything larger than 1, relates to enhanced compression of the interface. We generally recommend a value of 1.0 which is employed in this example.

2.3.8 Running the code

Running of the code has been described in detail in previous tutorials. Try the following, that uses tee, a command that enables output to be written to both standard output and files:

cd $FOAM_RUN/tutorials/interFoam
interFoam | tee log

The code will now be run interactively, with a copy of output stored in the log file.

2.3.9 Post-processing

Post-processing of the results can now be done in the usual way. The user can monitor the development of the phase fraction gamma in time; 2.22.

$Phase fraction, g 1.0 0.9 0.8 0.7 0.6 0.5 0.4 0.3 0.2 0.1 0.0 \special {t4ht=$

(a) At $t = 0.25 s \special {t4ht=$ .

$Phase fraction, g 1.0 0.9 0.8 0.7 0.6 0.5 0.4 0.3 0.2 0.1 0.0 \special {t4ht=$

(b) At $t = 0.50 s \special {t4ht=$ .

Figure 2.22:

Snapshots of phase $g \special {t4ht=$ .

2.3.10 Running in parallel

The results from the previous example are generated using a fairly coarse mesh. We now wish to increase the mesh resolution and re-run the case. The new case will typically take a few hours to run with a single processor so, should the user have access to multiple processors, we can demonstrate the parallel processing capability of OpenFOAM.

The user should first make a copy of the damBreak case, e.g. by

    cd $FOAM_RUN/tutorials/interFoam
    mkdir damBreakFine
    cp -r damBreak/0 damBreakFine
    cp -r damBreak/system damBreakFine
    cp -r damBreak/constant damBreakFine

Enter the new case directory and change the blocks description in the blockMeshDict dictionary to

    blocks
    (
        hex (0 1 5 4 12 13 17 16) (46 10 1) simpleGrading (1 1 1)
        hex (2 3 7 6 14 15 19 18) (40 10 1) simpleGrading (1 1 1)
        hex (4 5 9 8 16 17 21 20) (46 76 1) simpleGrading (1 2 1)
        hex (5 6 10 9 17 18 22 21) (4 76 1) simpleGrading (1 2 1)
        hex (6 7 11 10 18 19 23 22) (40 76 1) simpleGrading (1 2 1)
    );

Here, the entry is presented as printed from the blockMeshDict file; in short the user must change the mesh densities, e.g. the 46 10 1 entry, and some of the mesh grading entries to 1 2 1. Once the dictionary is correct, generate the mesh.

As the mesh has now changed from the damBreak example, the user must re-initialise the phase field gamma in the 0 time directory since it contains a number of elements that is inconsistent with the new mesh. Note that there is no need to change the U and p fields since they are specified as uniform which is independent of the number of elements in the field. We wish to initialise the field with a sharp interface, i.e. it elements would have $g = 1 \special {t4ht=$ or $g = 0 \special {t4ht=$ . Updating the field with mapFields may produce interpolated values $0 < g < 1 \special {t4ht=$ at the interface, so it is better to rerun the setFields utility. There is a backup copy of the initial uniform $g \special {t4ht=$ field named 0/gamma.org that the user should copy to 0/gamma before running setFields:

    cd $FOAM_RUN/tutorials/interFoam/damBreakFine
    cp -r 0/gamma.org 0/gamma
    setFields

The method of parallel computing used by OpenFOAM is known as domain decomposition, in which the geometry and associated fields are broken into pieces and allocated to separate processors for solution. The first step required to run a parallel case is therefore to decompose the domain using the decomposePar utility. There is a dictionary associated with decomposePar named decomposeParDict which is located in the system directory of the tutorial case; also, like with many utilities, a default dictionary can be found in the directory of the source code of the specific utility, i.e. in $FOAM_UTILITIES/parallelProcessing/decomposePar for this case.

The first entry is numberOfSubdomains which specifies the number of subdomains into which the case will be decomposed, usually corresponding to the number of processors available for the case.

In this tutorial, the method of decomposition should be simple and the corresponding simpleCoeffs should be edited according to the following criteria. The domain is split into pieces, or subdomains, in the $x \special {t4ht=$ , $y \special {t4ht=$ and $z \special {t4ht=$ directions, the number of subdomains in each direction being given by the vector $n \special {t4ht=$ . As this geometry is 2 dimensional, the 3rd direction, $z \special {t4ht=$ , cannot be split, hence $n z \special {t4ht=$ must equal 1. The $n x \special {t4ht=$ and $n y \special {t4ht=$ components of $n \special {t4ht=$ split the domain in the $x \special {t4ht=$ and $y \special {t4ht=$ directions and must be specified so that the number of subdomains specified by $nx \special {t4ht=$ and $ny \special {t4ht=$ equals the specified numberOfSubdomains, i.e. $nxny = \special {t4ht=$ numberOfSubdomains. It is beneficial to keep the number of cell faces adjoining the subdomains to a minimum so, for a square geometry, it is best to keep the split between the $x \special {t4ht=$ and $y \special {t4ht=$ directions should be fairly even. The delta keyword should be set to 0.001.

For example, let us assume we wish to run on 4 processors. We would set numberOfSubdomains to 4 and $n = (2,2, 1) \special {t4ht=$ . When running decomposePar, we can see from the screen messages that the decomposition is distributed fairly even between the processors.

The user should consult 3.4 for details of how to run a case in parallel; in this tutorial we merely present an example of running in parallel. We use the openMPI implementation of the standard message-passing interface (MPI). As a test here, the user can run in parallel on a single node, the local host only, by typing:

mpirun -np 4 interFoam -parallel > log &

The user may run on more nodes over a network by creating a file that lists the host names of the machines on which the case is to be run as described in 3.4.2. The case should run in the background and the user can follow its progress by monitoring the log file as usual.

$\special {t4ht=$

Figure 2.23:

Mesh of processor 2 in parallel processed case.

$Phase fraction, g 1.0 0.9 0.8 0.7 0.6 0.5 0.4 0.3 0.2 0.1 0.0 \special {t4ht=$

(a) At $t = 0.25 s \special {t4ht=$ .

$Phase fraction, g 1.0 0.9 0.8 0.7 0.6 0.5 0.4 0.3 0.2 0.1 0.0 \special {t4ht=$

(b) At $t = 0.50 s \special {t4ht=$ .

Figure 2.24:

Snapshots of phase $g \special {t4ht=$ with refined mesh.

2.3.11 Post-processing a case run in parallel

Once the case has completed running, the decomposed fields and mesh must be reassembled for post-processing using the reconstructPar utility. Simply execute it from the command line. The results from the fine mesh are shown in 2.24. The user can see that the resolution of interface has improved significantly compared to the coarse mesh.

The user may also post-process a segment of the decomposed domain individually by simply treating the individual processor directory as a case in its own right. For example if the user starts paraFoam by

paraFoam -case processor1

then processor1 will appear as a case module in ParaView. 2.23 shows the mesh from processor 1 following the decomposition of the domain using the simple method.

[next] [prev] [prev-tail] [front] [up]