[s_braendli]

Hi Niels

Finally some results regarding your suggestions - including good news

1. I hope I understood it correctly -> I tried the relaxationZoneLayouts as shown below. Anyway both still result in negative alphas in the corner between outlet and the lateral boundary.

2. I did not exactly do what you suggested, but somehow a step in this direction: I divided the lateral boundaries in a part which is still a wave-boundary and a part (close to the outlet) which now has zeroGradient boundary conditions. The modification to the blockMeshDict is the following:

patches        
(
...
    patch inlet1
    (
        (3 0 12 15)
        (0 1 13 12)
    )
    patch inlet2
    (
        (7 10 22 19)
        (10 11 23 22)
    )
    patch zerograd
    (
        (1 4 16 13)
        (11 8 20 23)
    )
...
);

in the 0 directory each boundary field needs an additional entry of

zerograd
{
    type            zeroGradient;
}

of course.

With this modification it is possible to increase the wave height (I tried up to 1m with stokesSecond so far) and also to set seaLevel to 0.0. The total Liquid phase volume fraction is slightly increasing during the simulation, but still, I am quite happy with this solution and will try to use it on more complicated cases.

A third issue came up when I tried to apply waves to the squarePile: I end up in an infinite loop in combineEdgeList. It fails on the edgeList

5((8 9) (10 11) (8 12) (12 9) (13 11))

after constructing fInter

5(8 9 12 8 -1)

Is this due to changes in cell size, which you mention as a danger in the wiki or do you see an other reason?

btw. my wave looks as follows:

    waveType    stokesFirst;
    Tsoft       0.5;
    depth       10.000000;
    phi         0.000000;
    period      2.0;
    direction  (1.0 0.0 0.0);
    height      0.25;

Best regards
Silvan

[ngj]

Hi Silvan

Great that you got it working! With respect to the changes in the setup, could you please send me a patch of the changes and I will incorporate them into the release.

With respect to the other problem you are showing, I am really happy that you came across it (I know it bothers you, but I really tried to trigger that error but couldn't manage to), thus please send me the test case and I will do my best to solve the problem.

I think I know what is causing the error, as I have seen it before in older releases. It is a bit strange, but I might be able to find a work-around. The issue arises in the evaluation of the intersection between the edges and the water surface and the error is related to some machine precision problems.

Best regards,

Niels

[dahicke]

Hi Jordi,
For the waveDyMFoam instructions, I found that: relaxationZone relaxing(mesh, U, alpha1); needs to be added to the createFields.H file or right after it, otherwise: relaxing is undefined at relaxing.correct();
However, I am not getting waves to be generated in my 2.0.1 version, yet so my placement may not be right.

Dave Hickerson

[s_braendli]

Hi Dave

The idea is to first create waveFoam and after that, in a subdirectory, waveDyMFoam. waveDyMFoam is supposed to use the createFields (and some other includes) from waveFoam. This way it should work.

Niels:

I put some stuff to my webspace ( http://www.tu-harburg.de/~skfsb/ ):
- 3Dwaves_zero_grad.tar.gz -> the mentioned solution with zeroGradient boundaries
- 3Dwaves_ext_grid.tar.gz -> alternative solution, extending the mesh. Looks nice, but has more cells.
- 3Dwaves_comparison.mp4 -> comparison of the two above mentioned
- squarePile_in_waves -> the case with the problem in combineEdgeList

When you mentioned the machine precision I first guessed, it might only happen in a parallel run. Anyway, the problem also appears in a serial run.

Best regards
Silvan

[ngj]

Thanks, Silvan.

I believe I will have some time during the weekend to look at the problems. Until further notice you can make the following change in relaxationScheme.C:

At present on line 64:

convexPolyhedral(mesh, true),

and into the hot-fix:

convexPolyhedral(mesh, false),

All the best

Niels

[s_braendli]

Hi Niels

The convexPolyhedral(mesh, false) does not change the behaviour of the squarePile_in_waves. But no hurry, I'm working on the modified 3Dwaves case anyway.

Thanks for your efforts
Silvan

[ngj]

Thanks for reporting that - it will save me some time in the bug-hunting process.

/ Niels

[tfuwa]

Hi Niels,

Thanks again for providing this wonderful tool and for your effort on answering questions.

I am trying to simulate the propagation of a solitary wave in a wave tank. However, my simulated wave heights H' are consistently smaller than target wave heights H, as seen in the attached picture.

I looked at the "periodicSolitary" tutorial case coming with waveFoam. The wave heights are actually changing with time, ranging from 1.60m to 2.00m (target wave height is 2.00m). The wave height decreases to 1.60m after 1s of simulation, before increasing to around 1.82m, also smaller than target value.

Do you know the reason for this problem by any chance?

[ngj]

Hi Albert

We investigated the behaviour in the periodic domain, since I was uncomfortable with the results.

I you look careful at the simulation you will experience that the solitary wave has a tail of several smaller waves, which are propagating in the opposite direction. I recall reading somewhere in the literature that this is related to the choice of 1st order solitary theory, hence in order to get better results you should consider implementing 3rd order solitary theory. You could e.g. obtain it from this reference:

@article{ fenton1972,
Author = {Fenton, J},
Title = {{Ninth-Order Solution for Solitary Wave}},
Journal = {{Journal of Fluid Mechanics}},
Year = {{1972}},
Volume = {{53}},
Number = {{MAY23}},
Pages = {{257-\&}},
Publisher = {{CAMBRIDGE UNIV PRESS}},
Address = {{40 WEST 20TH STREET, NEW YORK, NY 10011-4211}},
Type = {{Article}},
Language = {{English}},
DOI = {{10.1017/S002211207200014X}},
ISSN = {{0022-1120}},
Subject-Category = {{Mechanics; Physics}},
Number-of-Cited-References = {{23}},
Times-Cited = {{71}},
}

Small guideline. (i) Copy the folder solitaryFirst to solitaryThird, (ii) rename the files, (iii) make the necessary modifications to all occurrences of the string solitaryFirst in solitaryThird, (iv) implement the third order theory into eta, U, p and ddxPd, (v) and optional send the code to me when proper tested and it will be added to the framework.

Best regards,

Niels

[Betsy]

HI Niels - What wave theory do you use to generate the cnoidal wave? Is it KdV?

[ngj]

Yes, I mean that I implemented the lowest order solution to the KdV equations.

/ Niels

[PLö]

Hi all, Niels,

is it possible to take the cylindrical relaxationZone (the one from square-pile tutorial) and limit it to a semi-circle?

Best regards
Philipp

[ngj]

Hi Philipp

That would require either (i) that your domain is only semicircular or (ii) you implemented another shape object, where you define, which cells lies inside a semi-circle in the angle interval [phi1, phi2].

Best regards,

Niels

[ngj]

Hi all

@Silvan: I have correct the bug. The problem was that the convexPolyhedral assumes that the cell is cut into two parts, however, under specific conditions it can end up in 3 parts, hence the breakdown.

When this happens, the position of the cell centre relative to the surface defines, whether the entire cell is wet or dry. This is okay, as the problem arises when the trough/crest of water surface is extremely close to some horizontal face.

@Others: I have added a semi-circular relaxation zone.

All the changes have been added to the repository.

Best regards,

Niels

[JanL]

Hi Niels,


I'm very interested in your tool and have been testing it recently. I'd like to use it for seakeeping-analysis and hence I'm interested in Stokes-theories at first. I calculated different cases, compared them with the analytical solutions and unfortunately got some strange results. I specifically analysed the results at x=2.5 (middle of inlet-relaxation-zone), x=5 (end of inlet-relaxation-zone) and x=9 (middle of free computational domain). Here is what I have done:

1. I have been solving the standard tutorial of waveFlume for StokesFirst. The standardised amplitude changes by the distance from the inlet-relaxation-zone quite dramatically (see figure 1).
2. Since that case is designed for shallow water, I modified the domain to a depth of 2m (which I also changed in waveProperties.org) to have a deepwater case. Now the amplitude generally decreases by the distance from the inlet-relaxation-zone and the wave-length increases, so that the waves get out-of-phase from the analytical solution (see figure 2).
3. Afterwards I tried StokesSecond in the standard waveFlume case which gives almost perfect results (see figure 3)!
4. Running the same case for deepwater (2m) again produces results with lower amplitudes and longer wave-lengths (see figure 4).

Have you, or anybody else experienced similar results? I already tested different settings like refining the mesh or the time-step or calculating under turbulent conditions which had different minor effects on the solution.
Have you any ideas what could have gone wrong?


Regards


Jan

[ngj]

Hi Jan

What you are experiencing with Stokes First is most probably due to the incorrectness of linear wave theory in shallow water. Using second order stokes considerably improves on that. It is all described in our article (see the wiki).

With respect to the dissipation in deep water, I might suspect that you have too few points over the vertical. How many points to you have over the wave height?

Kind regards,

Niels

[JanL]

Hi Niels,

first of all thanks for the quick reply! I already guessed that the strange behaviour of StokesFirst was due to shallow water, which was why I set up the case for deep water.
I generally ran all calculations with 10 cells per wave height but I also doubled that number which again only had minor effects.
Right now I'm running a case with a reduced wave-height in deepwater which definitely should be within the limits of the wave-theory. I hope that will solve the issues.

Regards

Jan

[winden]

Hi Niels.

Many, many thanks for an excellent tool.

Could you please tell me if this is a known/unknown issue or if I'm just being stupid .

I have been using waves2Foam so simulate objects with forward speed in waves. I modified it to give a non-zero velocity in the air phase and I use combinedWaves with a stokesFirst and a potentialCurrent. However, I find that it does not recognize the current in the relaxation zone but tries to recreate the stokes wave instead. At the end of the relaxation zone, the current "kicks in" and the wave gets elongated. If I put the expected period of encounter as the wave period of the stokes wave, I get (within 99%) the correct period of encounter at the object downstream (i.e a much longer wave period.) (see image, the red line shows where the relaxation zone ends)

The problem is that sometimes when the wave speeds up, I get some instability issues at the edge of the relaxation zone with some non-physical turbulence and ventilation (see image, the red line shows where the relaxation zone ends).

Is there a way to put in the desired wave period in combinedWaves and make it cooperate with the potentialCurrent to create the desired encounter period instead?

//Björn

[JanL]

Hi,

my calculation for StokesFirst within the limits of the wave-theory just finished (wave-height=0.02. The rest of the parameters in waveProperties.org are left as in the standard-case). The results are unfortunately similar to the previous ones (see figure 5). There is still a considerable dissipation of the wave. I used 12 cells per wave-height.

Any clues? Am I missing something?

Regards

Jan

[ngj]

Hi both of you

@Jan: Could you please upload the deep-water test case. It is impossible to say anything without it.

@Björn: A non-zero speed in the air phase is available in the "official" release; see previous discussion in this thread. Furthermore, could you attach your waveProperties file?

Kind regards,

Niels