[katakgoreng]

Originally Posted by Phicau

Hi Dmitrijs, katakgoreng,

@Dmitrijs
I don't see anything wrong, setFields does not magically set water at your desired level, it just fills up full cells whose centre is inside the box you define. If the top of the filled cells is not exactly at 1 m, then you are definitely not obtaining that water level.

I would also not expect great results from your resolution, as the wave height is discretized by 2 cells only, which may not be enough.

@katakgoreng
I copied your IHWavesDict over to the default baseWaveFlume tutorial and it runs perfectly well for me:

It seems that you are facing problems with your C++ compilation. I programmed the wave generation functions to be independent (written in regular C++ and the library loads <math.h>).

The problem seem the same you were facing with the cnoidal function. Which OS and version are you using? 32/64 bits?

Best,

Pablo

Hi Pablo,

I'm currently using OpenFOAM 2.2.1 on Xubuntu 13.10 64-bit.
I managed to run regular waves (cnoidal, StokesI, StokesII, StokesV) & irregular (first order) without any problem.

Last night, I managed to get the second order irregular waves running but with only 2 wave components. If I use more than 2 wave components, I get the previous error.
Is there an extra library that I should install?

Kind regards,
katakgoreng

[Phicau]

Hi katakgoreng,

In principle you don't need any additional packages or libraries to run IHFOAM.

I've just downloaded Xubuntu 13.10 64-bit, created a Live USB, installed OpenFOAM and tested the case. Again, as in my computer, copying the IHWavesDict provided by you over to baseWaveFlume tutorial worked with no problems.

Since I cannot reproduce the error I can only suggest you to recompile the BCs and solvers.

Best,

Pablo

[katakgoreng]

Hi Pablo,

I think I might have pin-pointed the problem (might be bug or problem with my computer). Previously I generated my mesh using gmsh. However, trying to run the case using baseWaveFlume, I spotted the following problem.

# BUG 1 ?

For my case, I need the still water level to be at z=0. Instead of using blockMeshDict as follows (where the bottom sits at z=0)

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

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

convertToMeters 1;

vertices        
(
   (0.0     -0.02   0.0)
   (10.0    -0.02   0.0)
   (10.0    -0.02   0.7)
   (0.0     -0.02   0.7)
   (0.0     0.0     0.0)
   (10.0    0.0     0.0)
   (10.0    0.0     0.7)
   (0.0     0.0     0.7)
);

blocks          
(
    hex (0 1 5 4 3 2 6 7)   (500 1 70) simpleGrading (1 1 1)
);

edges           
(
);

patches         
(
    patch inlet 
    (
        (0 4 7 3)
    )
    patch outlet 
    (
        (1 5 6 2)
    )
    wall bottom 
    (
        (0 1 5 4)
    )
    patch atmosphere 
    (
        (3 2 6 7)
    )
    empty frontAndBack
    (
        (0 1 2 3)
        (4 5 6 7)
    )
);

mergePatchPairs
(
);

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

I have the following blockMeshDict (where the bottom is at z=-1)

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

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

convertToMeters 1;

vertices        
(
   (0.0     -0.02  -1.0)
   (10.0    -0.02  -1.0)
   (10.0    -0.02   0.7)
   (0.0     -0.02   0.7)
   (0.0     0.0    -1.0)
   (10.0    0.0    -1.0)
   (10.0    0.0     0.7)
   (0.0     0.0     0.7)
);

blocks          
(
    hex (0 1 5 4 3 2 6 7)   (500 1 70) simpleGrading (1 1 1)
);

edges           
(
);

patches         
(
    patch inlet 
    (
        (0 4 7 3)
    )
    patch outlet 
    (
        (1 5 6 2)
    )
    wall bottom 
    (
        (0 1 5 4)
    )
    patch atmosphere 
    (
        (3 2 6 7)
    )
    empty frontAndBack
    (
        (0 1 2 3)
        (4 5 6 7)
    )
);

mergePatchPairs
(
);

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

Running second order irregular waves for the domain yield an error.
However, it ran without any problem for first order irregular waves.

I think you could reproduce the error if you copy the new blockMeshDict into baseWaveFlume and try to rerun the second order irregular waves.

Kind regards,
katakgoreng

[katakgoreng]

# BUG 2 ?

I think I might have find another bug (or problem with my computer) regarding the second order irregular waves.
I have blockMeshDict as follows, where the bottom is at z=0 with domain height of 1.2m.

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

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

convertToMeters 1;

vertices        
(
   (0.0     -0.02  0.0)
   (10.0    -0.02  0.0)
   (10.0    -0.02  1.2)
   (0.0     -0.02  1.2)
   (0.0     0.0    0.0)
   (10.0    0.0    0.0)
   (10.0    0.0    1.2)
   (0.0     0.0    1.2)
);

blocks          
(
    hex (0 1 5 4 3 2 6 7)   (500 1 70) simpleGrading (1 1 1)
);

edges           
(
);

patches         
(
    patch inlet 
    (
        (0 4 7 3)
    )
    patch outlet 
    (
        (1 5 6 2)
    )
    wall bottom 
    (
        (0 1 5 4)
    )
    patch atmosphere 
    (
        (3 2 6 7)
    )
    empty frontAndBack
    (
        (0 1 2 3)
        (4 5 6 7)
    )
);

mergePatchPairs
(
);

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

Running second order irregular waves with the following setFieldDict does not yield any error (water depth, d=0.5m)

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

defaultFieldValues
(
    volScalarFieldValue alpha1 0
);

regions
(
    boxToCell
    {
        box (-10 -1 -1) (30 1 0.5);

        fieldValues
        (
            volScalarFieldValue alpha1 1
        );
    }
);

However, running the second order irregular waves with the following setFieldDict yield an error (water depth, d=1.0m)

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

defaultFieldValues
(
    volScalarFieldValue alpha1 0
);

regions
(
    boxToCell
    {
        box (-10 -1 -1) (30 1 1.0);

        fieldValues
        (
            volScalarFieldValue alpha1 1
        );
    }
);

As with previous case, both setFieldDict work without any problem for first order irregular waves.
Would you mind trying these cases as I'm not sure whether this problem is related to my computer or bug in the code.

Kind regards,
katakgoreng

[Phicau]

Thanks for your feedback, I can now reproduce both. Next time if you could upload the cases it would be great to test things straightaway.

I will keep you all up to date.

Best,

Pablo

[Dmitrjs]

Hi Pablo and everyone,
Thank you very much for your reply (post #20), it makes sense now how setFields work.
I ran the simulation with refined mesh around the interface area to get 13.2 cells per wave height (cell size in z 0.0025) and 1939 cells per wave length (cell size in x 0.0056). The solution did not really change compared to a coarser mesh with only 2 cells per wave height.
Maybe if someone had experience simulating a simple 2D wave flume in a wave tank, what number of cells per wave height/length gave reasonable results? I have quite limited resources and just want to know is it worth continuing refining the mesh further, or I have a mistake somewhere which give these results.
I really appreciate your help and thank you again!
Dmitrijs

[Phicau]

Hi all,

@katakgoreng
I can confirm that the errors you are experiencing are not bugs. They are caused by your ill-posed wave conditions, namely between these two components:

H_1 = 5.1284e-06
T_1 = 0.455676

H_2 = 4.9612e-06
T_2 = 0.452603

This is the first pair of components that trigger a division by 0 at the secondOrderFun::C function, but they may be more. The reason is simple, both components are in very deep waters:

k_1 = 19.3811 -> 1.0/tanh(kh) = 1
k_2 = 19.6451 -> 1.0/tanh(kh) = 1

Moreover, I don't see the point of having two different components separated barely 0.003 s in wave period...

I will update the github version later to correct this behaviour, just disregarding that kind of components. Please follow the instructions in the wiki to update, and recompile the BCs.

@Dmitrijs
That discretization seems ok now, even if you don't notice any changes near the generation boundary you will if you propagate the wave further away.

I see that your wave conditions are close to the limit of applicability, you may have to fine tune the wave height to obtain better results.


Best,

Pablo

[katakgoreng]

Hi Pablo,

Many thanks for your help. I'm trying to simulate random waves in deep water. All the waves component came from a JONSWAP spectrum that I need to use.
I converted the spectrum into discrete wave component (amplitude and frequency) using equidistant frequency.
However, converting frequency to period makes the wave period clustered together for lower frequency part.
I'll fetch the latest update, recheck my waves components and report back if I have any problem.

Kind regards,
katakgoreng

[katakgoreng]

Hi Dmitrijs,

I have stokes case that I think you could refer to.
The waves has the following properties:

Water depth, h = 0.5 m
Wave height, H = 0.025 m
Wave period, T = 1.5964 s
Wave length, L = 3.06913 m

This correspond to:

h/gT^2 = 0.02
H/gT^2 = 0.001
Wave applicability = Stokes II (Refer to IHFOAM Fig 2.1)

The domain info:

Length = 15 m (600 cells in x)
Height = 0.6 m (240 cells in z)
Width = 0.02 m (1 cells in y)

This correspond to:

122 cells per wave length (might be too excessive)
10 cells per wave height

The following is plot of wave amplitude vs time as x=3m for this case against analytical linear waves.



The result could be improved if you :

1. increase mesh density
2. decrease the time step @ using lower courant number

The wave case is as attached.

Kind regards,
katakgoreng

[surfer]

Dear Pablo,

after having solved the problem about evaluating the wave-induced forces on a cylinder, I am facing another problem concerning the same simulation: it blows up suddenly after 5.75 seconds and without any previous bad behaviour.
I am using IHFoam with the OpenFOAM 2.2.2 version.
In the following I describe my case:

WAVE: StokesV
waveTheory StokesV;
genAbs 1;
absDir 0.0;
nPaddles 1;
waveHeight 0.1;
wavePeriod 0.959692898;
waveDir 0.0;
wavePhase 4.712388979;
tSmooth 2;

DOMAIN: 2D rectangular
length = twice the wavelength (2 x 1.5 m);
height = twice the water depth (2 x 0.9 m);
cylinder: diameter = 0.1 m;
axis in the middle of the domain

MESH: it is made by means of blockMeshDict
~ 360 elements per wavelength,
~ 50 elements for the wave height
finer mesh around the cylinder

SIMULATION SETUP: adjustableRunTime with maxCo 0.25;
fvSolution and fvSchemes equal to those in
baseWaveFlume tutorial case.

What happens is that after 5.75 seconds of run time the simulation blows up when solving the alpha equation with MULES algorithm. I tried to change set up by reducing maxCo till 0.1, but nothing changed; I tried changing fvSchemes setup by reducing the order of accuracy for both gradient (till Gauss linear) and divergence (till Gauss upwind) schemes, but nothing changed in terms of stability: the simulation blows up again after 5.75 seconds.

In my opinion something unstable happens at the wave generation patch, but I am not sure.

If information I provided are not sufficient, I will send you the entire case by mail.

I thank you a lot for your help and attention

Gabriele

[Phicau]

Hi Gabriele,

I cannot assess why the case blows up from that information. Maybe it is due to a large Courant number, caused by the BCs, by a bad mesh, non-orthogonal cells, all at the same time...

If you send me the case I will check it and if the failure is caused by my BCs I will try to correct it.

Best,

Pablo

[surfer]

Dear Pablo,

thanks a lot for your quick answer.

Here you can find attached the case which blows up suddenly.
You can find as comments almost all the entries I tried with fvSolution setups: with all of them I obtained the blow up at the same instant.

I thank you a lot in advance for your help.

Bye,

Gabriele

[Dmitrjs]

Hi Pablo and Katakgoreng,

Thank you so much for your answers!

@Pablo. You mentioned that my wave conditions are close to the limit of applicability. Could you please clarify what limit you meant? I read in one paper that openFoam has difficulties in simulating waves with a steepness a*k over 0.05 because of the high air velocity, but in my case the steepness is well below that: 0.0165*0.578=0.0095.

@katakgoreng many thanks for your case, I was able to reproduce the same results and will use it for reference.

Regards,
Dmitrijs

[Phicau]

Hi Dmitrijs,

I forgot a couple of words there: your wave conditions (post #18) are in the limit of applicability for the Stokes I (linear) wave theory.

Best,

Pablo

[Phicau]

Hi Gabriele,

I've been able to run your case up to 7.5 seconds, but no more. A water droplet gets attached to the boundary and everything blows up. This is caused by a combination of the waves and the mesh. Unfortunately I cannot do anything at this point, but future releases may overcome this issue.

I may suggest you to change your mesh, as this one has cells with an aspect ratio of 1:17, and plenty of non-orthogonality. Try snappyHexMesh instead of blockMesh.

Best,

Pablo

[Denao]

Hi,

I was wondering if IHFoam is able to simulate waves in a moving body of water, i.e. to simulate a floating body with forward motion travelling through a wave profile?

Kind regards,

Denao

[Phicau]

Hi Denao,

sorry for the delay, I'm just back in the office. Unfortunately the combination of a current plus waves is just pre-programmed at this moment, so it has not been tested or validated yet. There are plans to do so and the work is ongoing.

Best,

Pablo

[Denao]

OK. Thanks for letting me know. It would certainly be a useful feature for me.

-Denao

[dneves]

Greatings Pablo,

I am a new user of the IHFOAM 2.0.

I am very impressed and pleased with the way the model behaves, I'm exploring it intensively

I would like to present some results in a small conference but I am a little puzzled by how am I going to refer the model in the bibliography.

How would you like me to refer your model in the conference preceedings?

Thank you very much for your attention,

I will wait for an answer

Best regards

Diogo Neves

[Phicau]

Hi Diogo,

thank you very much for your kind words, I am pleased that you are finding it useful.

The model should be called IHFOAM, either if you are only using the wave generation and absorption capabilities (that was IHFOAM 1.0) or the new porous media capabilities (that's IHFOAM 2.0).

You can find all the reference papers in the following link:

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

I suggest that if you want to reference the wave generation and absorption procedures you can cite the first paper.
For general validation and application to coastal processes you may cite the second paper.
For the porous media implementation you can reference the third paper.
Finally, for application of porous media flow to a "real" case you can cite the fourth paper.

I'm updating the wiki with this info, which maybe was not very clear.

Best regards,

Pablo