[JanL]

Dear All,

I'm still looking for a way to simulate a ship with forward speed in waves. As I'd like to use waveFoam for that purpose, I was wondering if anybody could give me some advice how to realize that type of simulations. I thought about combining potential current with a regular wave theory using combinedWaves. Has anybody experience doing that, or would this actually be a solution to my problem?
Apart from that I would like to vary the incident angle of the waves (e.g. still forward speed of the ship but waves from behind or beam seas) which leads me to the problem, how the INLET and OUTLET relaxationZones could be realised in that case for each waveType.

I'd very much appreciate any advice!

Best regards
Jan

[ngj]

Hi Jan,

Maybe you should consider streamFunction waves instead. The wave-current interaction is a natural output from the estimation of the harmonic coefficients.

What do you mean with INLET/OUTLET. They are only directional flags and has nothing to do with the behaviour of the specific relaxation zone, but can help to easily change the relaxation direction. Try to use relaxationZoneLayout utility and switch between INLET/OUTLET and you will understand the difference.

They are planned to be removed in a future release, as they do cause confusion.

Have a nice weekend,

Niels

[JanL]

Dear Niels,

thank's for your quick answer and your advice. I'll have a look into the streamFunction waveType.

What I meant with INLET/OUTLET, was that if I have a regular wave coming from one direction and a potential current from the opposite (as it would be the case if I'm simulating a ship with forward speed and waves coming from behind, if I'm not wrong!?), than I'd have to apply on both ends an INLET, as well as an OUTLET condition for one respectively the other waveType, right? Or is there another way around?

Have a nice weekend,
Jan

[ngj]

No, they are only used to change the direction in which the relaxation zone works. As stated, play around with the relaxationZoneLayout utility, and you will understand.

- Niels

[dahicke]

Hi all,

I have been playing with the wave solvers for a while and am running into a problem with a dynamic mesh version using 2.1.x, though I don't think it is version related. I have a 3D wave flume that appears to work OK without floating object (a box). However, when I add the box in one case with the mass calculated to the submerged section, it slowly picks up velocity and sinks reaching over -60 m/sec. In the other case with weight less than calculated, it starts to rise until it reaches an upward velocity of over 60 m/sec. Both of these reach local high velocities that case the Courant number is over 1 and the case crashes.

I have tried turning on momentum prediction, increasing nCorrectors to 3 and nNonOrthogonalCorrectors to 2, which did not seem to change this run away z velocity.

With this new version I had to add a definition for div((muEff*dev(T(grad(U))))) which I set to Gauss linear;

Has anyone encountered this kind of velocity run away?

Dave Hickerson

[ngj]

Hi Dave,

What happens, if you have the box, but no waves?

BTW: You say it is a dynamic mesh, however, it is pure motion and no refinement, correct?

Kind regards

Niels

[dahicke]

I ran it without the waves, basically setting the inletCoeffs to long periods and zero height:
inletCoeffs
{
waveType stokesFirst;
period 100000000000;
direction ( 1 0 0 );
//Tsoft 2;
depth 2.0;
omega 1;
phi 0;
waveNumber ( 0.1047 0 0 );
height 0;
relaxationZone
{
relaxationScheme Spatial;
relaxationShape Rectangular;
beachType Empty;
relaxType INLET;
startX ( 0 -1.5 0 );
endX ( 2 1.5 0 );
orientation ( 1 0 0 );
}
}

It appears to work OK. There is a slight oscillation in the z direction as it finds buoyancy center.

Have you noticed problems using the sixDoFRigidBodyDisplacement with the wave BC?

Other than the water height changing local to the rigid body, I don't see how the these two would interact in the code. In my case, the wave has not reached the box yet, so it shouldn't be effected at the time of the crash.

I played with the mass of the body a bit, which affected how fast in the z direction it would get prior to crashing. Closer to the calculated mass the faster the speed, but longer the calculation time. The crash always came around 2.1 seconds simulation time.

Any ideas?

Dave

[ngj]

Hi Dave,

I am sorry that I cannot help you, as I have never played with the 6DOF in OF - and I was merely asking to find out, if there was a coupling between the waves and the 6DOF, which there appears to be

Good luck,

Niels

[dahicke]

Niels,

I have a thought. If I run the case on multiple cores with the inlet and outlet sections in different areas than the test section, then I could separate out this behavior.

Is there issues with the wave code on multiple cpu's?

PS: I still want to find the coupling, though.


Dave

[kev4573]

Originally Posted by ngj

Hi Kevin,

Are you sure that the files you have sent me are from a 2.1.0 distribution? The reason I am asking is that they do not compile on a freshly installed 2.1.0 distribution from the Ubuntu repository.

The compile error is:

Making dependency list for source file waveFoam.C
SOURCE=waveFoam.C ;  g++ -m64 -Dlinux64 -DWM_DP -Wall -Wextra -Wno-unused-parameter -Wold-style-cast -Wnon-virtual-dtor -O3  -DNoRepository -ftemplate-depth-100 -I/opt/openfoam210/src/transportModels -I/opt/openfoam210/src/transportModels/incompressible/lnInclude -I/opt/openfoam210/src/transportModels/interfaceProperties/lnInclude -I/opt/openfoam210/src/turbulenceModels/incompressible/turbulenceModel -I/opt/openfoam210/src/finiteVolume/lnInclude -DOFVERSION=21 -I./../../../../src/lnInclude -IlnInclude -I. -I/opt/openfoam210/src/OpenFOAM/lnInclude -I/opt/openfoam210/src/OSspecific/POSIX/lnInclude   -fPIC -c $SOURCE -o Make/linux64GccDPOpt/waveFoam.o
In file included from waveFoam.C:63:
createFields.H: In function ‘int main(int, char**)’:
createFields.H:35: error: ‘class Foam::twoPhaseMixture’ has no member named ‘alpha1’
In file included from waveFoam.C:93:
UEqn.H:5: error: ‘class Foam::incompressible::turbulenceModel’ has no member named ‘divDevRhoReff’
/opt/openfoam210/src/finiteVolume/lnInclude/readTimeControls.H:38: warning: unused variable ‘maxDeltaT’
make: *** [Make/linux64GccDPOpt/waveFoam.o] Error 1

I will have another look at the update to 2.1.0 in waves2Foam one of the following days.

Kind regards,

Niels

Hi Niels,

Like Dennis said I am compiling against 2.1.x. I agree it would cause confusion if this is not compiling properly with 2.1.0. A possible solution might be to add the minor version number to the solver directory, something like 'solvers210', and only target stable releases of openfoam (not the git repo version).

Kevin

[ngj]

Hi Kevin,

That could be a possible solution. Can I make a version of waveFoam based on my OF-2.1 and send it to you, so you can test if it compiles? If it does, then we will be going with that solution.

The installation is on another computer, so you should have it in a couple of days.

Kind regards,

Niels

[kev4573]

Niels,

Sure, I'd be happy to test it for you.

Kevin

[erncyc]

Hi Niels,

Thank you for the tremendous job you have done with waves2Foam. I have successfully installed it and am experimenting with it. I was wondering which tutorial addresses a traveling (non-reflected) 2D wave. I tried the standing wave tutorial (wave type ....1st order) but the animation appears to show (as the name suggests) a standing wave. I am a bit confused because in the wiki...I read that there's another wave type called First order standing wave. Or do I need to change the outlet boundary condition? Please help. Thanks.



Ernest

[ngj]

Good morning,

@Kevin: Please find the waveFoam for 2.1.0 here: http://www.student.dtu.dk/~ngja/waveFoam.tar

@Ernest: Well, if you merely want a propagating wave, then you should look into the "waveFlume" tutorial. The standing wave tutorial shows that you can filter the out-going wave component so well that you get a correct standing wave pattern in the computational domain.
The waveType "standingWave" can be used, if you e.g. want to initialise a standing wave in a closed domain.

Good luck,

Niels

[erncyc]

Thank you Neil for your response. I am now running waveFlume and hopefully results will be positive. I was just wondering if there is some manual I could read to help me understand some of the terms (coefficients) in the waveProperties file. Thank you.

Ernest

[ngj]

Hi Ernest,

You could either read the Wiki or look into the header files of the waveTheories. Most of them have a reference to the literature, which was used to implement the different wave theories. Essentially, the coefficients originate from potential wave theory, hence it is where you can find more information.

Kind regards,

Niels

[kev4573]

Niels,

Thanks, I'll test this out.

Is there any reason not to make a version for the latest stable release (2.1.1) as well?

Cheers,
Kevin

[ngj]

Good morning Kevin,

I can see that there are fewer pre-processor statements in the source code than I recalled and most of them related to OF15, so it would be rather easy to change it to compile differently for 2.1.0 and 2.1.1.

I will put it on my TODO, but it would be nice if the 2.1.0 version compiles on 2.1.1., so a release can be made of waves2Foam under the current structure of the source.

Thank you for your help,

Niels

[Rotto]

I have three comments about the Solitary wave maker:


Niels: Thank you for your response to my question about the reference used in writing the solution of the Solitary wave in the waves2Foam package. The reference you provided (Ib A. Svendsen and Ivar G. Jonsson (1982) Hydrodynamics of Coastal Regions), does not give any expression for vertical particle velocity for a solitary wave. And the expression given for horizontal particle velocity is different with what is used in the waves2Foam Solitary wave maker. So it is still not clear to me where are the equations coming from. Unless you (or Bjarne Jensen according to solitaryFirst.H) have derived the equations for solitary wave as a limit of Cnoidal wave theory, which in this case I guess it would be useful (at least to me ) to provide a reference in which the derivations are given.


The numerical wave tank with solitary wave maker in waves2Foam package suffers from formation of small amplitude waves traveling to the opposite direction of the main wave. In the Wiki page of waves2Foam package, a comment given by NB under section 6.5 (Periodic Solitary) is misleading, and in fact I would even say it is incorrect. First, formation of these small amplitude waves is not related to beach slope, seafloor is flat here. Thus it is misleading to refer to the paper (Grilli et al. (1994), JWPCOE, 120(6)), which only discusses deformation of solitary wave due to the beach slope, which is not the case or the reason here. Second, solitary wave is a complete nonlinear wave to begin with, so it is not correct to say formation of the small amplitude waves is because solitary wave theory does not fulfill the nonlinear wave theory, even in their first order of approximation.


I wrote a new code for the solitary wave maker in waves2Foam package, using the Green-Naghdi water-wave equations. These equations satisfy the boundary conditions exactly. Similar problem is occurring using this wave maker. Changing grid resolution, water depth, tank dimension and initial position of the wave, although affect the form of the small amplitude waves, do not fully resolve the issue. So, the problem should be somewhere else, not above options nor the wave theory used to create the solitary wave. Also, I have noticed that initially there is a sudden drop in the wave amplitude, which I could not understand the reason/solution. As the wave propagates, however, it gradually recovers to the desired wave amplitude.


Any input, comment or suggestion to resolve these issues would be highly appreciated.


Niels et al., I enjoy the wave tank very much. If it was not because of your work we would not have these discussions. So, thank you again.


Masoud

[ngj]

Hi Masoud,

1.
With respect to the implemented velocity field, I think that we used Hydrodynamics in Coastal Regions as a source - but I might be mistaken; I do not have the book at hand, so I will not be able to check the correctness of the implemented velocities.
This source, however, does indeed only give the horizontal velocities, but it is easy to derive the vertical velocity component through an integration over the vertical of the continuity equation. This is what has been done in this case.

2.
If you look in the figure in Grilli et al depicting the wave elevation on the flat part of their physical wave flume, you can identify a set of trailing waves. These must have been generated in the horizontal part of the flume, hence, experimental evidence of them being generated, when using a low-order solitary wave theory.

3.
With respect to the accuracy of the wave theory, both the cnoidal and solitary waves have been implemented using 1st order theory based on the solution to the KdV equations.
Since it is a perturbation theory of 1st order, it does not fulfil entirely the full non-linear wave equations, so I am still convinced that the spurious waves could be due to a non-exact fulfilment, just as spurious waves are generated, when 1st order Stokes waves of finite amplitude are generated in shallow water.
You could e.g. test using a stream function wave with a very large period. Here, the solution would tend toward the solitary solution, and having a sufficient number of harmonics, the solution is an exact solution to the non-linear wave problem.

Good luck, I hope you find a solution, since it could be nice to find a correct explanation. If you are interested, I would be happy to include your Green-Naghdi implemetion in waves2Foam.

Best regards,

Niels

P.S. Thanks to all, who have been using waves2Foam and shown an interest in the source package. Today, the Wiki exceeded 10,000 hits - a number reached in less than a year