Contrib/olaFlow

olaFlow is a free and open source project, committed to bringing the latest advances in the simulation of wave dynamics to the OpenFOAM and FOAM-extend communities.

olaFlow is a set of solvers and boundary conditions to generate and absorb water waves actively at the boundaries and to simulate their interaction with porous coastal structures.

The main scope of these modelling tools is coastal, marine, hydraulic and offshore engineering.

1 olaFlow Overview

The olaFlow package includes:

• Individual boundary conditions for wave generation and active wave absorption for alpha1 and U fields. (libwaveGeneration.so)
  • waveAlpha
  • waveVelocity
• Boundary conditions for pure wave absorption applicable to U field. Based on 2D or 3D theories, both are applicable to 3D cases. (libwaveAbsorption.so)
  • 2DWaveAbsorptionVelocity
  • 3DWaveAbsorptionVelocity
• Boundary condition for wave generation and active wave absorption using a piston wavemaker, with any number of paddles. (libmultiPistonMovement.so)
  • multiPistonMovement
• Solvers to be used with your favourite version of OpenFOAM or FOAM-extend. See compatibility below.
  • olaFlow
  • olaDyMFlow
• Brief reference manual
• Tutorials and validation cases

1.1 About olaFlow solvers

olaFlow and olaDyMFlow solve two-phase incompressible flows within porous media by means of the VARANS (Volume-Averaged Reynolds-Averaged Navier-Stokes) equations. More information will be added, in the mean time check the references.

Both solvers are derived from interFoam and interDyMFoam. Furthermore, outside the porous media, the VARANS equations are identical to the classic RANS. Therefore, olaFlow and olaDyMFlow can be used instead of interFoam and interDyMFoam even when the case presents no porous zones.

1.2 Supported Versions

Currently all versions of OpenFOAM.org, OpenFOAM.com (+) and Foam-extend are supported.

Known issues:

   the boundary conditions compile and everything works.

• Running in parallel yields an error.
  • Solution: edit $WM_PROJECT_DIR/etc/controlDict and change commsType to nonBlocking. Reference [1].

[user:PID] *** An error occurred in MPI_Recv
[user:PID] *** on communicator MPI_COMM_WORLD
[user:PID] *** MPI_ERR_TRUNCATE: message truncated
[user:PID] *** MPI_ERRORS_ARE_FATAL: your MPI job will now abort
--------------------------------------------------------------------------

• Running in parallel may produce unexpected results due to a bug in gMin and gMax functions. See [2]
  • Fixed with commits c5a2b9d7 (master) and 02833621 (nextRelease).
  • The solution can be found here.

 the boundary conditions compile and everything works.

• Running in parallel yields an error.
  • Solution: edit your case's controlDict and add the following snippet. Reference [3].

OptimisationSwitches
{
    commsType       nonBlocking;
}

 everything works when you compile OpenFOAM from source, as there is a problem with the precompiled installable pack. Reference [4].

• Otherwise:
  • The solvers (even the regular version of interFoam) need to include "-linterfaceProperties" to compile.
  • olaFlow solvers compile and work. Despite the BCs being included, apparently they are not linked, as they are not recognized.
  • If the boundary conditions are included dynamically in controlDict and used with the olaFlow solvers, turbulence modelling does not work.

1.3 Ongoing Development

• Bug fixes will be issued on a regular basis, while the development of new features is currently ongoing.
• New versions may include major changes in the structure of the boundary conditions; however, efforts will be put in minimizing those that will affect the use.

1.4 References and Citing

olaFlow is the evolution of IHFOAM, a product developed in the frame of a Master and PhD Thesis at the Environmental Hydraulics Institute "IH Cantabria" of the University of Cantabria. The PhD thesis can be found and downloaded for free here:

Pablo Higuera PhD Thesis

If you want to reference the model in your publications it should be called olaFlow, and state that is an evolution of IHFOAM, referencing any of the following research papers, in which the IHFOAM implementation, validation and application details are published:

(2015) Three-dimensional numerical wave generation with moving boundaries.

Three-dimensional numerical wave generation with moving boundaries.
Higuera, P., Losada, I.J. and  Lara, J.L. (2015)
Coastal Engineering, Vol. 101, pp. 35–47

(2014) Three-dimensional interaction of waves and porous coastal structures using OpenFOAM. Part II: Application.

Three-dimensional interaction of waves and porous coastal structures using OpenFOAM. Part II: Application.
Higuera, P., Lara, J.L. and Losada, I.J. (2014)
Coastal Engineering, Vol. 83, pp. 259–270

(2014) Three-dimensional interaction of waves and porous coastal structures using OpenFOAM. Part I: Formulation and validation.

Three-dimensional interaction of waves and porous coastal structures using OpenFOAM. Part I: Formulation and validation.
Higuera, P., Lara, J.L. and Losada, I.J. (2014)
Coastal Engineering, Vol. 83, pp. 243-258

(2013) Simulating coastal engineering processes with OpenFOAM.

Simulating coastal engineering processes with OpenFOAM.
Higuera, P., Lara, J.L. and Losada, I.J. (2013)
Coastal Engineering, Vol. 71, pp. 119-134.

(2013) Realistic wave generation and active wave absorption for Navier-Stokes models: Application to OpenFOAM.

Realistic wave generation and active wave absorption for Navier-Stokes models: Application to OpenFOAM.
Higuera, P., Lara, J.L. and Losada, I.J. (2013)
Coastal Engineering, Vol. 71, pp. 102-118.

1.5 Get Connected

To submit your feedback, suggestions, bugs... you have many options:

• The olaFlow e-mail, found here.
• The e-mail found within the source code headers.

olaFlow at cfd-online:

• olaFlow Support Thread

2 Source Download and Compilation

olaFlow download site can be found here.

2.1 Source Code Download

You can find IHFOAM in GitHub, and it can be downloaded in zip format.

For a more convenient download of the source code, run the following command:

git clone git://github.com/phicau/olaFlow.git

If the git protocol is blocked in your network try either of the following commands:

git clone https://github.com/phicau/olaFlow.git
git clone http://github.com/phicau/olaFlow.git

Code updates can be downloaded in the future for the olaFlow folder as follows:

git checkout
git pull

Recompilation is required to apply the changes.

2.2 Source Code Structure

olaFlow source code is divided in two main folders:

• genAbs --> Generation and absorption boundary conditions
  • waveAbsorption --> (BCs)
  • waveGeneration --> (BCs)
  • common --> Scripts shared by both BCs
• solvers --> Guess what's inside...
  • olaFlowXXXXX --> One for each compatible version, including olaFlow and olaDyMFlow

2.3 Compilation

Compilation has been automatized and needs to be performed only once. Since olaFlow does not require any dependencies, the source code can be downloaded and compiled anywhere on your computer, provided that you have a working OpenFOAM installation.

Simply run the following script from the olaFlow base folder:

./allMake

You can also compile the boundary conditions or the solvers (olaFlow and olaDyMFlow) independently:

cd genAbs
./allMake

cd solvers/olaFlowXXXXX
./allMake

In this case be sure to select the correct folder for your preferred OpenFOAM/FOAM-extend (OF/FE) version. The currently supported versions have already been shown.

2.4 Dynamic Linking of the Boundary Conditions

In order to include the wave generation and active wave absorption boundary conditions without needing to re-compile a solver, write the following code in controlDict:

libs
(
    "libwaveGeneration.so"
    "libwaveAbsorption.so"
);

3 olaFlow Usage

IMPORTANT NOTES:

• olaFlow is programmed in such a way that gravity has to act in the negative Z direction.
• Currently the X and Y coordinates of each boundary face are substituted by those of the centroid of the paddle to which the face belongs (similarly to what happens in the laboratory). Therefore, to obtain accurate directionality you need several paddles (nPaddles >> 1). Next releases will change the implementation so you can choose.
• Angles such as waveDir and absDir are measured in degrees with respect to the positive X axis (0º), growing towards the positive Y axis (90º).

3.1 olaFlow and olaDyMFlow Solvers

IMPORTANT NOTE:

• olaFlow has a slightly different formulation than the one published in the third reference, due to a volume-averaging approach with an ill-posed term. The correct formulation is included in Pablo Higuera PhD thesis. The results now, however, are as good as those shown on the validation, but with different friction factors. Check out the tutorials for the dam break validation case. The wrong term slightly changed the results where gradients of porosity appeared (i.e. at the interface between the porous medium and the clear fluid, or between porous media), where not many people measure, as the flow is very dependent on the local effects (the ones that we try to filter out by volume-averaging).

Porosity is introduced by setting an initial field. It can be done using the setFields utility, in a similar way to the VOF indicator function (alpha1, alpha.water). This field is called porosityIndex and it features the index of the porous zone to which each cell belongs.

• If no porosityIndex field is found, olaFlow is identical to interFoam.
• Index 0 represents the clear region, outside any porous medium.
• Practical examples can be found in the training materials.

The porous media properties (i.e. a, b and c friction factors, mean rock size and porosity) are included in constant/porosityDict

a               n(0.0 ... );
b               n(0.0 ... );
c               n(0.0 ... );

D50             n(1.0 ... );
porosity        n(1.0 ... );

• The first values should always be as shown, as they represent the clear flow region.
• n is the number of materials.

3.2 Wave Generation BCs

To generate waves you have to set the following boundary conditions.

For alpha1/alpha.water:

    inlet
    {
        type            waveAlpha;
        waveDictName    waveDict;
        value           uniform 0;
    }

For U:

    inlet
    {
        type            waveVelocity;
        waveDictName    waveDict;
        value           uniform (0 0 0);
    }

• The other boundary condition needed is:
  • buoyantPressure or fixedFluxPressure for p_rgh

3.2.1 Wave Generation Dictionary

Wave generation dictionary options

• The wave conditions are read from a dictionary file located in the constant folder.
• By default it is named waveDict, however, you can name it differently setting waveDictName.
• This way you can even specify different wave conditions for different patches on your case.

All the options are gathered in the figure on the right. The rectangles indicate the different parameters and the rounded boxes denote the options available. A complete showcase for the different wave theories can be found in the reference/waveDict folder.

Implemented wave theories:

waveType / waveTheory	Reference	Comments
regular / StokesI	Dean and Dalrymple (1991)
regular / StokesII	Dean and Dalrymple (1991)
regular / StokesIII	Borgman and Chappelear (1958)
regular / StokesV	Skjelbreia and Hendrickson (1960)
regular / cnoidal	Svendsen (2006)
regular / streamfunction	Fenton (1988)	No solver programmed. Use Fenton's Fourier solver (old version tested only, distributed with the materials) to set all the parameters required.
solitary / Boussinesq	Lee et al. (1982)
solitary / Grimshaw	Lee et al. (1982)
wavemaker / (tx/tv/txeta/tveta)	Own development	waveTheory depending on what you provide: t (time series), x (paddle displacement), eta (free surface elevation). Note that this BC replicates the wavemaker (constant) profile, but it does not move.
irregular / ()	Dean and Dalrymple (1991)	Linear summation of StokesI components. Second order by Longuet-Higgins and Stewart (1960) completed with Baldock et al. (1996)

Active wave absorption can be connected on the wave generation boundary so that waves incident to it flow out while still generating the target waves. If no other boundary is absorbing it sould be connected, to avoid a mean water level increase due to the mass imbalance between crests and troughs.

• Controlled by genAbs bool variable: true/false
• Correction velocity applied in the absDir direction. When not set or set greater than 360, it defaults the perpendicular direction to the boundary. See the first reference for a complete explanation on when it is convenient to set absDir.
• You can select nPaddles greater than 1 to obtain a better directional absorption.

3.2.2 Wave Formulae Form

All the waves in olaFlow are generated in a similar way to the following implementation (Stokes I):

$\eta = \frac{H}{2} cos \left( k_x x + k_y y - \omega t + \psi \right)$

This means that the free surface elevation (eta) is dependent of the patch location. If you want to keep the phase meaningful I would recommend you to locate the wave generation patch at X = 0, although this is not a must.

3.3 Wave Absorption BCs

Why pure active wave absorption conditions when wave generation already includes it? Pure active wave absorption, disregarding wave generation, allows a more sofisticated treatment and better performance.

To absorb waves you have to set the following boundary condition for U. This time no data are read from a dictionary, so everything is set at the boundary condition level. The default values are shown, so the parameters that need no different value can be left out.

2D-theory version, applicable to 2D/3D:

    outlet
    {
        type            waveAbsorption2DVelocity;
        nPaddles        1;
        nEdgeMin        0;
        nEdgeMax        0;
        absorptionDir   400;
        value           uniform (0 0 0);
    }

• absorptionDir can be used to obtain Quasi-3D behaviour (see the first reference). Its default value is greater than 360, so absorption is applied to the perpendicular direction to the patch.

3D-theory version, applicable to 3D:

    outlet
    {
        type            3DWaveAbsorptionVelocity;
        nPaddles        1;
        nEdgeMin        0;
        nEdgeMax        0;
        value           uniform (0 0 0);
    }

The differences between both are explained in the first reference. If you are unsure whether to use the 2D or 3D version, use the 2D, as its range of applicability is wider.

• The rest of the boundary conditions needed are:
  • zeroGradient for alpha1
  • buoyantPressure or fixedFluxPressure for p_rgh

Similarly to wave generation, setting nPaddles > 1 will allow directional absorption, as each paddles (vertical slices of the patch) absorbs the waves independently. For stability reasons try to keep your paddles approximately 5 cells wide at least.

• The patch is splitted in nPaddles vertical transects according to its orientation
  • If it is more perpendicular to the X axis, it uses the Y coordinates to divide the patch in nPaddles between YMin and YMax. nEdgeMin starts to count from YMin. nEdgeMax starts to count from YMax.
  • If it is more perpendicular to the Y axis, it uses the X coordinates to divide the patch in nPaddles between XMin and XMax. nEdgeMin starts to count from XMin. nEdgeMax starts to count from XMax.
• nEdgeMin and nEdgeMax solve some issues that appear on the corners, selecting a number of paddles that are only capable of taking water out according to the 2D theory.

4 olaFlow Documentation and Tutorials

The olaFlow documentation and tutorials are included in the Github bundle.

4.1 Documentation

A brief reference document is included.

4.1.1 FourierFenton

Old version of Fenton's Fourier program to obtain the input parameters needed to set up streamfunction wave theory.

4.1.2 waveDict

Directory that includes a sample of waveDict file for each supported wave theory.

4.2 Tutorials

A set of tutorials, covering the use of olaFlow and the wave generation boundary conditions, is available. All the cases include a runCase and cleanCase. The first one runs all the steps needed to simulate the case and sampling/validation (when available). The second one resets the case to its initial state (i.e. with a very small size).

The practical cases are as follows.

4.2.1 baseWaveFlume

A simple wave flume (i.e. 2D channel).

• Waves are generated on the left patch (inlet).
• Waves are absorbed on the right patch (outlet), according to the 2D theory.
• Water depth is set to 0.4 m.
• The wave conditions are specified in constant/waveDict.
  • Regular waves, 0.1 m high and with 3 s of period are generated according to the cnoidal theory.
• No porosity involved.
• The case can be run very fast in serial.

4.2.2 irreg45degTank

A more advanced wave case. This is a 3D wave tank with a peculiar shape, similar to the one used in the first reference. An irregular sea state is generated at patch X = 0, and absorbed elsewhere.

• A directional, irregular sea state is generated (842 wave components).
  • Note nPaddles value for directionality
• On the rest of the patches, the waves are absorbed according to the 3D theory.
  • Note also nPaddles, nEdgeMin and nEdgeMin values.
• No porosity involved.
• Case to be better run in parallel. Some known issues exist for several OpenFOAM and FOAM-extend versions.

4.2.3 CR35_dambreak

A classic benchmark case to validate free surface flow through a porous medium. It is a 2D dam break in a tank.

• Porosity.
  • Note the porosityIndex field at the 0 folder.
  • porosityIndex is set using setFields, check setFieldsDict out.
  • The porous variables are set in constant/porosityDict.
• Validation is included.
  • Sampling is not needed as free surface is obtained with a function object (included in controlDict).
  • Requirement: matplotlib (a.k.a. pylab)
  • A python script (plotValidation.py) can be run in the end to plot a comparison between the experimental and numerical data.
• The case can be run very fast in serial.

4.2.4 breakwater

A composite breakwater within a wave flume in 2D.

• Porosity.
  • Note the porosityIndex field at the 0 folder.
  • porosityIndex is set using setFields, check setFieldsDict out for setting porosity inside STL files.
  • The porous variables are set in constant/porosityDict. This time several porous media are included.
• Waves are generated in the left patch (inlet)
• Waves are absorbed on the right patch (outlet), according to the 2D theory.
• Water depth is set to 0.8 m.
• The wave conditions are specified in constant/waveDict.
  • Regular waves, 0.25 m high and with 3 s of period are generated according to the cnoidal theory.
• Samping of free surface elevation and pressure is included.
  • Requirement: matplotlib (a.k.a. pylab)
  • Python scripts are included for postprocessing OpenFOAM results: postSens*.py
  • Python scripts are included for plotting postprocessed results: plotSens*.py
• The case can be run very fast in serial.

This case also involves turbulence modelling. In future releases it will include the volume-averaged k-epsilon model.

4.2.5 pistonFlumeABS

A simple wave flume (i.e. 2D channel) where waves are absorbed by a piston wavemaker.

• Waves are generated on the left patch (inlet), .
• Waves are absorbed on the right patch (outlet), according to the 2D theory, with a moving boundary (piston).
• The case runs with olaDyMFlow

4.2.6 currentWaveFlume

A simple wave flume where waves and a current are generated simultaneously.

• Waves and the current are generated on the left patch (inlet).
• Waves and the current are absorbed on the right patch (outlet), according to the 2D theory.
• You can check the differences with baseWaveFlume to see how to set up the currents:
  • 0.org/U
  • constant/waveDict
  • system/setFieldsDict
• The case runs with olaFlow

4.2.7 wavemakerFlume

A simple wave flume where waves are generated either by a piston or a flap wavemaker

• Waves are generated on the left patch (inlet).
• Waves are absorbed on the right patch (outlet), according to the 2D theory.
• Python scripts included in constant directory to create wavemaker displacement according to linear theory. Parameters can be modified.
  • flapWaveGen.py for flap wavemaker.
  • pistonWaveGen.py for piston wavemaker.
• The case runs with olaDyMFlow.
  • runCaseFlap script for flap wavemaker.
  • runCasePiston script for piston wavemaker.

4.2.8 wavemakerTank

A simple wave flume where oblique waves are generated either by a multi-piston or a multi-flap wavemaker (10 individual paddles).

• Waves are generated on the left patch (inlet), with 10 individual moving paddles.
• Waves are absorbed on the right patch (outlet), according to the 2D theory.
• Python scripts included in constant directory to create wavemaker displacement according to linear theory. Parameters can be modified.
  • flapWaveGen.py for flap wavemaker.
  • pistonWaveGen.py for piston wavemaker.
• The case runs with olaDyMFlow.
  • runParallelCaseFlap script for flap wavemaker (it will only run in serial in foam-extend).
  • runParallelCasePiston script for piston wavemaker (it will only run in serial in foam-extend).

5 Changelog

History of the changes in the source code. Slightly more detailed descriptions than in git:

• Feb 16, 2018: Added Stokes III order wave theory, according to Borgman and Chappelear (1958)
• Jan 2, 2018: Changes for compatibility with OpenFOAM v1712
• Dec 30, 2017: Renamed missed olaFoam.C and olaDyMFoam.C files
• Dec 19, 2017: Initial olaFlow commit - equivalent to olaFoam commit 0dd707cdee66ba658603fac9e40127a6319ea7d6