[ngj]

Good morning,

I have put a new version of waves2Foam here:

www.student.dtu.dk/~ngja/waves2Foam.tar.gz

The only difference with respect to previous versions is an additional tutorial, which follows the experiment by Beji and Battjes. Thanks to Jorge Gadelho for providing the basis for this tutorial. The tutorial is distributed along with experimental data in order to use the case for validation.

Kind regards

Niels

[ngj]

Dear all,

It is a great pleasure and relief to be able to say that the SVN for waves2Foam is now again fully operational. The checkout installations are changed, so if you what to relocate the SVN-repository please follow the instructions given here:

http://openfoamwiki.net/index.php/Of...e_Repositories

Otherwise, if you just want the most recent checkout of the svn, do a fresh checkout following the instructions on the wiki for waves2Foam:

http://openfoamwiki.net/index.php/Co...on_SourceForge

In order to celebrate the reinstatement of the SVN, I will probably recast the compilation procedure a bit in the coming days (inspired by Dennis Kingsley) and perhaps an additional tutorial case is also on its way.

Have a nice weekend,

Niels

[ngj]

Dear all,

I have had a chance to update the compilation system, so it is now committed as revision 1996.

All environmental variables are now set in the file

$WAVES_DIR/bin/bashrc

which is created and made as an executable during the first run of

$WAVES_DIR/Allwmake

Please note that this file will not be affected/reset by any svn-updates, since the communication with svn is through the file

bin/bashrc.org

which you should just leave as is.

If you know that the settings in bashrc.org are wrong before even beginning on the compilation, then perform the first compilation as follows from the waves2Foam directory:

(cd bin; cp bashrc.org bashrc; chmod a+x bashrc)
<Edit bin/bashrc>
./Allwmake

Then the Allwmake skips the creation of bin/bashrc.

Also note that I have chosen to make a small change in the part, where the compilation of the solver(s) take place. In order to prepare for e.g. waveDyMFoam the compilation is like this:

solvers=`ls -d $WAVES_SOL/*`

# Loop over the solver names
for s in $solvers
do
    solverName=`basename $s`

    <Some different cross-version compatibility>

    # Compile the solver
    ( cd $WAVES_SOL/$solverName; wmake )
done

This also means that for correct execution, e.g. waveDyMFoam should be placed alongside to and not inside of the waveFoam directory. This only requires a bit of tweaking in the waveDyMFoam/Make/options file for correct targeting of the files from the waveFoam directory.

I sincerely hope that the new structure will make life easier for those running with settings, which deviate from the previous standard choices/paths/etc.

Kind regards

Niels

P.S. Here is posted the setting, which are distributed in the bashrc.org file, so you can orient yourself before checking out:

#!/bin/bash

### SETTING A FLAG
if [ -z "$WAVES_DIR" ]
then
    printVariables=1
fi

### USER DEFINED ENVIRONMENTAL VARIABLES
export WAVES_DIR=$WM_PROJECT_USER_DIR/applications/utilities/waves2Foam
export WAVES_APPBIN=$FOAM_USER_APPBIN
export WAVES_LIBBIN=$FOAM_USER_LIBBIN

export WAVES_GSL_INCLUDE=/usr/include
export WAVES_GSL_LIB=/usr/lib64

### OTHER STATIC ENVIRONMENTAL VARIABLES
## Version number
# The "-0" is for zero-padding the version number, to accept differences between e.g. 2.1 and 2.1.1
if [ `uname` = "Darwin" ]
then
    version=`echo $WM_PROJECT_VERSION"-0" | sed -e 's/\.x/-0/' -e 's/\./\'$'\n/g' -e 's/-/\'$'\n/g' | grep "[0-9]" | head -3 | tr -d '\n'`
else
    version=`echo $WM_PROJECT_VERSION"-0" | sed -e 's/\.x/-0/' -e 's/\./\n/g' -e 's/-/\n/g' | grep "[0-9]" | head -3 | tr -d '\n'`
fi

export WM_PROJECT_VERSION_NUMBER=$version

## Easy navigation
export WAVES_SRC=$WAVES_DIR/src
export WAVES_TUT=$WAVES_DIR/tutorials
export WAVES_SOL=$WAVES_DIR/applications/solvers/solvers$WM_PROJECT_VERSION_NUMBER
export WAVES_UTIL=$WAVES_DIR/applications/utilities
export WAVES_PRE=$WAVES_UTIL/preProcessing
export WAVES_POST=$WAVES_UTIL/postProcessing

## Extend branch or not
EXTBRANCH=`echo $WM_PROJECT_VERSION | grep 'dev\|ext'`

if [ -z $EXTBRANCH ]
then
    EXTBRANCH=0
else
    EXTBRANCH=1
fi

export EXTBRANCH

### PRINT INFORMATION
if [ "$printVariables" ]
then
    echo ""
    echo "====================================="
    echo "    ENVIRONMENTAL VARIABLES"
    echo "====================================="
    env | grep "WAVES\|EXTBRANCH\|WM_PROJECT_VERSION_NUMBER"
    echo ""
fi

[ngj]

Dear all,

Today a large change has occured to the waves2Foam distribution.

1. I have restructured the src-directory (revision 2004-2006, which will not compile).

2. The restructuring is such that now three libraries are compiled instead of one. These libraries are libwaves2Foam.so, libwaves2FoamProcessing.so and libwaves2FoamSampling.so.

3. Especially the processing library comes with a considerable increase in source code, since a lot of pre- and post-processing utilities are now directly implemented into the OF-source.

The additional utilities are:

- faceSetToSTL (a simple utility to create an STL surface, see bejiBattjes tutorial).
- waveGaugesNProbes (utility to create wave gauges and probes (the latter prepared but not implemented). The location of the wave gauges are exported to VTK-format for easy visualisation in paraFoam, see waveFlume tutorial)
- runTime sampling of overtopping (no tutorial yet)
- postProcessingWaves (utility to analyse the sampled data sets; special emphasis on free surface wave dynamics, but it can be used on other type of applications, as e.g. FFT on forces are supported. See waveFlume tutorial).

The Wiki has not been updated yet, but I will try to make it happen as soon as possible, however, I hope that you will enjoy the extension until then.

Practical information:
- The bashrc file in waves2Foam/bin has not been affected. Users can continue to use their local settings as is.
- The release is revision number 2007.
- Compilation of the sampling utilities on 2.2.x. will still crash, since I have not had the time to look into it. This will also affect the compilation of the application "waveFoam" and the utility "surfaceElevation".

Kind regards

Niels

[ngj]

Good morning,

Now, waves2Foam also compiles under the most recent release: OF2.2.1.

Kind regards

Niels

Edit: On the Wiki, I have added a long (yet not complete) description of the postProcessWaves2Foam utility. Please see here for details on its use: http://openfoamwiki.net/index.php/Co...cessWaves2Foam

[ngj]

Dear all,

You might have noticed the releases on the Wiki, which states updating to standard OpenFoam coding style. I am updating the coding style, such that it at least on the broad perspective is compatible with:

http://www.openfoam.org/contrib/code-style.php

Please bear with me for a couple more commits, as I prefer committing secure code style update a little by little, as I estimate to have corrected some 4000 lines at the end of the style adjustment.

Kind regards and enjoy your summer,

Niels

[ngj]

Dear all,

It is my pleasure to announce an expansion of the waves2Foam framework. It has now been added the functionality of porous media, such that practical coastal engineering problems can be considered.

The following additions have been made to solvers/libraries:

1. Corrected the lack of mass conservation for porous media flows with a free surface. This has simply been corrected by using a different call to MULES (this has been visualised in Figure 7 in the reference below).
2. Added a small resistance calculator, such that the user can provide information on grain size, porosity and resistance coefficients in stead of the native format in OpenFoam. The native format is still supported in this implementation. Currently, the resistance formulations by Engelund (1954) and van Gent (1995) implemented.
3. Altered the momentum equation such that the effect of porosity and added mass in transient flows are taken into account.

The porosity implementation is based on the original formulation in OpenFoam, however, the code has been stripped to only offer the Darcy-Forcheimer resistance formulation.

A solver (porousWaveFoam) has been delivered along with the svn-commit for versions 1.6, 2.1.0, 2.1.1, 2.2.0 and 2.2.1.

Furthermore, a single tutorial has been released (more to come in 2014) in the folder tutorials/porousWaveFoam/porousDamBreak. As the name indicates, this is the classical dambreak example with a porous block in the middle. This tutorial will be extended to an actual validation case in 2014 as soon as I have the experimental data.

The mathematical formulation and the calibration of the resistance coefficients have been described in the work lead authored by Bjarne Jensen (TU Denmark):

@article{Jensen2014,
    Author = {Jensen, Bjarne and Jacobsen, Niels Gj\o{}l and Christensen, Erik Damgaard},
    Journal = {Coastal Engineering},
    Pages = {56--72},
    Publisher = {Elsevier B.V.},
    Title = {{Investigations on the porous media equations and resistance coefficients for coastal structures}},
    Volume = {84},
    Year = {2014},
}

which can be accessed here: http://www.sciencedirect.com/science...78383913001816

Compilation of the additional pieces of code has been verified on the OpenFoam versions mentioned above. Any questions one the compilation/use of waves2Foam should be placed in this thread:

http://www.cfd-online.com/Forums/ope...ed-topics.html

Please note that the porous zones are based on a static cellZone, i.e. moving the computational mesh will result in a reshaping of the porous zone. Therefore, it is not recommended to extend porousWaveFoam to a dynamic version without considerable alteration to the source code.

Also note that the Wiki has not been updated following this commit, however, the tutorial(s) will give the needed information on the coupling with the porous zones.

Kind regards,

Niels


References:

Engelund, F. (1954). On the laminar and turbulent flows of ground water through homogeneous sand. Technical report. Danish Academy of Technical Sciences.

van Gent, M.R.A. (1995). Wave interaction with permeable coastal structures. Ph.D. thesis, Delft University.

[ngj]

Dear all,

A small note with respect to the compatibility of waves2Foam with the new foam-extend-3.0. I have today painlessly installed foam-extend-3.0, however, it will take some time before the repository is updated with a compatible version of waves2Foam; mainly (solely?) due to cross-version compatibility issues.

Kind regards,

Niels

[ngj]

Dear all,

The waves2Foam libraries and utilities are now also compatible with foam-extend-3.0.

There is, however, not any solver in the release, because the way the pimple-loop is constructed deviates from previous versions, so I will have to do some experimentation on how and where to enforce the relaxation.

But since the libraries are compilable, feel free to toy around.

Kind regards

Niels

[ngj]

Hallo again,

For all of you, who are trying to compile waves2Foam revision 2026 (or newer), please note that you must delete bin/bashrc, such that the compile script can substitute with an updated bin/bashrc.org.

I was forced to include some new compile flags in order to get things running for both foam-extend-3.0 and the older versions of OpenFoam, standard and ext versions alike.

Kind regards,

Niels

[ngj]

Dear all,

I have now managed to get waves2Foam compiled under 2.3. Several naming changes has been introduced with OF2.3, which means that none of the tutorials are currently running. I will try to resolve this issue as soon as possible.

The following other changes have also been added to the most recent revision:

1. It is no longer necessary to give the name of the pressure field in waveProperties.

2. The experimental data has been added to the tutorial porousDamBreak along with a matlab script, which makes a comparison between measured and computed surface elevation.

I would like to thank Kevin Maki, whose help made the adjustments to OF2.3 easier.

Kind regards,

Niels

[ngj]

Good evening,

The tutorials are now updated to run under 2.3.

As you will experience, I have completely altered the structure, such that cross-version compatibility files are being hidden away.

Because of the introduction of the files src/waves2Foam/include/crossVersionCompatibility.[C,H], the name of the pressure field is no longer needed in waveProperties. This means that all the various versions of waveProperties.*, which cluttered the constant-folders, have been removed.

Because of the change in alpha-name and structure of the transportProperties, a new folder has been introduced, which is called tutorials/commenFiles. This contains the two relevant versions of transportProperties, and these are used in all tutorials.

In every single <case>/system the folder fvFiles has been created. This contains fvSchemes-files and fvSolution-files fitted to the various versions.

Finally, bin/prepareCase.sh has been given an update and old/redundant *.org fields has been cleared out of the tutorial cases.

Kind regards,

Niels

[ngj]

Good evening,

It turned out that I had forgotten one element in the transformation in the tutorials. Please update your svn repositories, if you are running under revision 2037 or 2038.

Kind regards,

Niels

[ngj]

Hallo,

This is merely a small service announcement that the svn-repository has been updated (revision 2041). There is, however, at this point no functional change in executing waves2Foam, and it does not carry any bug-fixes. The log in the svn-repository states this:

Release to facilitate planned future open-source contribution(s) [No functional change in execution].

This release is only intended to make life a bit easier in the course of incorporating a coming open-source contribution from a user of waves2Foam.

I hope to be able to tell more about this coming and quite exciting extension of waves2Foam within not too long.

Kind regards,

Niels

[ngj]

Good evening all,

I have just committed a new revision of waves2Foam (revision 2044).

Besides a couple of cross-version related bug-fixes, there are also the following additions:

1. waveFoam is now created for foam-extend 3.0. I have cut away all of the PIMPLE-procedure parts, as I have not had the time to proper test, which approach was the best for PIMPLE with the (explicit) relaxation zone technique.
2. A new relaxationZoneShape has been added. It is called "Frozen" and it is merely a wrapper around the remaining shapes (except itself), and it freezes the relaxation parameters in time. This is needed for some special types of moving meshes. Note that it does support restarting for t > 0 s with coefficients computed for t = 0 (serial and parallel), but the method does not support mesh refinement.

Following the extension to foam-extend 3.0, all tutorials for waveFoam have been updated with fvSchemes and fvSolution files. Note that porousWaveFoam still awaits to be created for OF2.3 and foam-extend 3.0.

With respect to the previous announced additional contribution, we are currently having some issues with non-GPL software used in the contribution, and we are trying to figure out, how this can either be (i) omitted or (ii) incorporated in a future release.

Kind regards,

Niels

[ngj]

Good morning,

There is now a bug-reporting section on

https://sourceforge.net/apps/mantisbt/openfoam-extend

for waves2Foam related issues. Please do use this in the future for the reporting of bugs, as it will make the handling of these more smooth than today.

This bug-reporting system is not intended to be used for compilation issues of unsupported versions of OF. Supported versions are found here:

http://openfoamwiki.net/index.php/Co...Versions_of_OF

Note, that *.x versions are only supported, if it is explicitly stated in the above list.

Kind regards,

Niels

[ngj]

Good afternoon,

waves2Foam does now compile on foam-extend-3.1, and I have for convenience also copied the solvers compatible with OF2.2.1 to OF2.2.2. (no modifications needed), but it will ease the installation for those of you, who runs of that particular OF-platform.

Kind regards,

Niels

[ngj]

Good morning,

This morning I have made a commit to the waves2Foam repository. This commit contains a modification of the porous part of the source code and derived modifications to the solvers.

The modification is that the definition of the porous structure is now runTime selectable. This is chosen to ease testing of various approaches for the porosity module. Currently, only one porous method is available and it is unchanged in functionality compared to previous commits. In order to use a porous module the user now needs to specify the following in waveProperties.input (setWaveParameters takes care of writing the keyword to waveProperties):

porosityModel       jensenJacobsenChristensen2014;

where the model jensenJacobsenChristensen2014 is the implementation made available along with the paper Jensen et al. (2014); see the wiki for details on this reference.

Unfortunately, it is not possible to define this keyword in porosityZones - which would have been the logical choice - because of the way the porosity properties are being read.

Kind regards,

Niels

[ngj]

Good morning,

I have now committed a bug-fix for the surfaceElevation-tool. This resolves the malfunctioning of this tool, when it is used in runTime on moving meshes.

See revision 2064 on the Wiki-page:

http://openfoamwiki.net/index.php/Co..._.28History.29

Kind regards,

Niels

[ngj]

Dear all,

I have now streamlined the code in setWaveProperties related to irregular waves (as of revision 2066). This means that I have removed code duplication, but also that the interface for irregular waves is slightly changed.

Instead of the old interface, it is now necessary to add the following subDict to the waveProperties dictionary, e.g. immediately prior to the definition of the relaxation zone:

    frequencyAxis
    {
        writeSpectrum true; // false = default value

        discretisation cosineStretchedFrequencyAxis; // equidistantFrequencyAxis;

        //lowerFrequencyCutoff 0.1;
        //upperFrequencyCutoff 2;
    }

There is no functional change in the execution of the program, i.e. the frequency discretisation is unchanged and the default values of the lower and upper bounds are still 0.3fp and 3.0fp, where fp is the peak frequency.

The flag

discretisation equidistantFrequencyAxis;

is identical to

equidistantFrequencyAxis on;

and the flag

discretisation cosineStretchedFrequencyAxis;

is identical to

equidistantFrequencyAxis off;

I am sorry for the inconvenience, but these changes will eventually become clear.

Kind regards,

Niels