[Phicau]

Hi Philip,


yes, the turbulence modelling in olaFlow is set up as in any other OpenFOAM solver.
LES can be run under any situation, including coarse meshes and in 2D, now the question is whether the results will be physical/realistic.


Best,


Pablo

[philiplu]

Hello, Phicau,
thank u for the reply, so you mean:
logically as RANS in ola, LES can also be run in 2D (for reducing overhead in e.g. waves normal to shore)? when taking sufficient care in the mesh-buildup, especially the "sensitive" areas?

if no reply from u (I've re-edited this post, to state more clear), means, my understanding is Ok.

sorry, my OF/ola know-how is still limited, thus I must be "careful", since
1. RANS is of ensemble average, but LES, partial DNS, so(with my limited turbulence knowhow) am not sure, if fully logical to spare 1D, but
2. specifically the original linear/nonlinear wave-theories are all 2D-derived


thank you and regards

[arashghgood]

Dear Pablo
1) In the following movie as you can see, despite the genabs is true, the reflection occurs at the right boundary.

https://youtu.be/dghEx9QiEBA

how can I modify the waveDict so that wave becomes absorbed at the right wall?

2) I am interested in starting from an initial wave pattern in the whole domain at t=0. I try to use funkySetFields for fields U and alpha.water. But the olaFlow boundary types are unknown. So fatal error appears. How can I do this?

thanks for your help in advance.

[aow]

Hi Arash,

I'm not sure about what to do for your first question since I've never used the wave absorption capabilities of olaFlow; however, for your second question, is there a reason you cannot use the built-in setWaves utility (see https://github.com/OpenFOAM/OpenFOAM...m/laminar/wave)? Unless you're using a non-standard wave theory or recorded data, this utility is the easiest way to setup initial wave conditions.

Best,

Andrew

[arashghgood]

Originally Posted by aow

Hi Arash,

I'm not sure about what to do for your first question since I've never used the wave absorption capabilities of olaFlow; however, for your second question, is there a reason you cannot use the built-in setWaves utility (see https://github.com/OpenFOAM/OpenFOAM...m/laminar/wave)? Unless you're using a non-standard wave theory or recorded data, this utility is the easiest way to setup initial wave conditions.

Best,

Andrew

Dear Andrew
thanks for answering me. My issue is not related to gave generation. I am interested in following
consider that the whole domain (x-z) in two dimensions, is initially at eta=sinh(z)*cos(k*x) at t=0. So the water is not at rest at t=0.
then olaFlow will implement for t>0.

[aow]

Ah, I don't think you can implement something quite like that function using the setWaves utility. The z-direction (transverse or perpendicular to the wave propagation direction) variation in amplitude is not implemented in the default OpenFOAM wave generation utilities as far as I can tell (i.e. it's only capable of making a constant eta for the transverse direction).

However, if you didn't need the transverse variation in eta, setWaves would be able to set fields (alpha.water, U, etc...) throughout the domain according to the chosen wave theory and wave parameters (length, height, etc...) so that there are waves with non-zero velocity and amplitude at t = 0 s (see https://www.openfoam.com/documentati...modelling.html).

If you really want to get crazy, you could manually specify the field data in a very painful process similar to, but more involved than what is presented in this video, which provides details for setting a non-uniform inlet velocity profile.

Also, this may not work as I have not tried it, but it occurred to me that perhaps you could initially set the BCs to be built-in OpenFOAM options when running funkySetFields and then switch the BCs back to the olaFlow options before running your case. This could be automated in your job running script so you don't have to do it by hand. I would recommend you use sed to do it if you choose to try this.

Sorry I can't be of more help...

[arashghgood]

Originally Posted by aow

Ah, I don't think you can implement something quite like that function using the setWaves utility. The z-direction (transverse or perpendicular to the wave propagation direction) variation in amplitude is not implemented in the default OpenFOAM wave generation utilities as far as I can tell (i.e. it's only capable of making a constant eta for the transverse direction).

However, if you didn't need the transverse variation in eta, setWaves would be able to set fields (alpha.water, U, etc...) throughout the domain according to the chosen wave theory and wave parameters (length, height, etc...) so that there are waves with non-zero velocity and amplitude at t = 0 s (see https://www.openfoam.com/documentati...modelling.html).

If you really want to get crazy, you could manually specify the field data in a very painful process similar to, but more involved than what is presented in this video, which provides details for setting a non-uniform inlet velocity profile.

Also, this may not work as I have not tried it, but it occurred to me that perhaps you could initially set the BCs to be built-in OpenFOAM options when running funkySetFields and then switch the BCs back to the olaFlow options before running your case. This could be automated in your job running script so you don't have to do it by hand. I would recommend you use sed to do it if you choose to try this.

Sorry I can't be of more help...

Dear Andrew
First of all, thanks for your help. exactly, my idea of using funkySetFields is what you mentioned. However, I asked it to receive ideas because I am not an expert in OF and olaFlow. There is also an error when I set back the boundary conditions to olaFlow ones. this is another reason.
I aim to see the damping and propagation of waves starting from initial conditions throughout the domain. In other words, we know that waves will damp in time and in distance theoretically. to check the simulation results it is necessary to provide the same condition as theory.
======

one more thing for all, I believe (my experience with olaflow) in olaflow/genAbs/common/ the iteration for calculating wavelength (in waveFun.C) is not enough. I increase it to 1000000 to get better results.

[Phicau]

Hi Arash,


regarding your first question, have you set active wave absorption correctly on the right boundary? All BCs should be like those in the baseWaveFlume tutorial.
If you did, you can try using the Extended Range Active Wave Absorption, because your waves seem to be in the mid- to deep-water regime. You can find more information here: https://olaflow.github.io/blog/exten...een-published/


Regarding your second question, Andrew is right, you can set the olaFlow boundary types to, e.g., zeroGradient, use funkySetFields and then set them back to the original types. If you use zeroGradient I presume that the format will be easier to change.

Alternatively, I am not sure if this works but it is worth trying, you can link the olaFlow BCs dynamically in controlDict and see if they are then recognized by funkySetFields. More information here https://openfoamwiki.net/index.php/C...ary_Conditions


Finally, a couple of years back I programmed a setFields-like tool to set wave initial conditions, which I have been testing and sharing with some colleagues already. Most likely I will be releasing it to the public next month, so stay tuned.


Best,


Pablo

[aow]

Finally, a couple of years back I programmed a setFields-like tool to set wave initial conditions, which I have been testing and sharing with some colleagues already. Most likely I will be releasing it to the public next month, so stay tuned.

Definitely keeping tabs on this. I'll be looking forward to trying it out once you've decided it's ready for public consumption.

[arashghgood]

Dear Pablo
I am using McCowan wave theory to generate a soliton. the geometry is a simple box of the following size:
0 < x < 2, 0 < y < -0.0002 and -0.001 < z < 0.004
meshx = 5000 , mesh y =1,
meshz = 100 in this way ( (0.14 0.3 1) (0.12 0.5 1) (0.74 0.2 1) )
and finally
waveHeight 2e-4;

after running the simulation an error appears

#0  Foam::error::printStack(Foam::Ostream&) at ??:?
#1  Foam::sigFpe::sigHandler(int) at ??:?
#2  ? in "/lib/x86_64-linux-gnu/libc.so.6"
#3  Foam::PhiScheme<double, Foam::interfaceCompressionLimiter>::limiter(Foam::GeometricField<double, Foam::fvPatchField, Foam::volMesh> const&) const at ??:?
#4  Foam::limitedSurfaceInterpolationScheme<double>::weights(Foam::GeometricField<double, Foam::fvPatchField, Foam::volMesh> const&) const at ??:?
#5  Foam::surfaceInterpolationScheme<double>::interpolate(Foam::GeometricField<double, Foam::fvPatchField, Foam::volMesh> const&) const at ??:?
#6  Foam::fv::gaussConvectionScheme<double>::flux(Foam::GeometricField<double, Foam::fvsPatchField, Foam::surfaceMesh> const&, Foam::GeometricField<double, Foam::fvPatchField, Foam::volMesh> const&) const at ??:?
#7  ? at ??:?
#8  ? at ??:?
#9  __libc_start_main in "/lib/x86_64-linux-gnu/libc.so.6"
#10  ? at ??:?
./runCase: line 16:  6295 Floating point exception(core dumped) olaFlow > olaFlow.log
Simulation complete.

Does it mean that deciding by zero is in the theory? or my problem is wrong?
could you explain to me the error?
thank you in advance

[Phicau]

Hi Arash,


the information in that error seems to suggest that wave generation is not the problem. When in doubt, substitute the olaFlow boundary conditions by zeroGradient and try to solve the problem with interFoam to see if you get the same error. You may also need to change the setFieldsDict to add a small water hump to get some movement ongoing. Always use checkMesh and Paraview to check your mesh quality.


Best,


Pablo

[arashghgood]

Originally Posted by Phicau

Hi Arash,


the information in that error seems to suggest that wave generation is not the problem. When in doubt, substitute the olaFlow boundary conditions by zeroGradient and try to solve the problem with interFoam to see if you get the same error. You may also need to change the setFieldsDict to add a small water hump to get some movement ongoing. Always use checkMesh and Paraview to check your mesh quality.


Best,


Pablo

Dear Pablo
Thank you for your attention and suggestion. I will apply your suggestion.

[georgiak]

Hi Pablo,

I am relatively new to the CFD and I try to simulate a coastal area in shallow waters with olaFlow.

My parameters are: h=5.47m, Hmax=4.88m and T=13.3s. According to the Mehaute diagram, I am marginally placed at cnoidal or Stokes V theory.

However, when I run the simulation with cnoidal I always take this waveVelocity related error:

#0 Foam::error:rintStack(Foam::Ostream&) at ??:?
#1 Foam::sigFpe::sigHandler(int) at ??:?
#2 ? in "/lib/x86_64-linux-gnu/libc.so.6"
#3 cnoidalFun::calculations(double, double, double, double*, double*) at ??:?
#4 Foam::waveVelocityFvPatchVectorField::updateCoeffs () at ??:?
#5 Foam::GeometricField<Foam::Vector<double>, Foam::fvPatchField, Foam::volMesh>::Boundary::evaluate() at ??:?
#6 ? at ??:?
#7 __libc_start_main in "/lib/x86_64-linux-gnu/libc.so.6"
#8 ? at ??:?
Exception en point flottant (core dumped)

While the Stokes V model returns me convergence error (No convergence for Stokes V wave theory).

I just tried the StokesII model to see if it will work and it runs, but during the first trough generation it bugs (deltaT very small (magnitude of e-15) and clearly the model is not adapted physically).

Firstly I would like to ask you if the wave models are based on the Mehaute diagram, because it seems strange this story of StokesII, when theoritically we are clearly placed on cnoidal theory. Also, I would like to ask you what kind of error is it on cnoidal case? Should I just update my olaFlow version (updateCoeffs()...)?

Thank you in advance

Georgia

[Phicau]

Hi Georgia,


please double check your calculations because they are wrong. Your wave steepness is around 0.9, so your waves are breaking. This is why the solver fails to converge.


Mathematically you can do lots of things, but it does not mean that the results will be physical. Can you run such wave with Stokes II? Sure, Stokes II does not have any iterative solvers except for linear wavelength. Does that mean that what I am simulating makes any sense? No.



Best,


Pablo

[georgiak]

Originally Posted by Phicau

Hi Georgia,


please double check your calculations because they are wrong. Your wave steepness is around 0.9, so your waves are breaking. This is why the solver fails to converge.


Mathematically you can do lots of things, but it does not mean that the results will be physical. Can you run such wave with Stokes II? Sure, Stokes II does not have any iterative solvers except for linear wavelength. Does that mean that what I am simulating makes any sense? No.



Best,


Pablo

Yes Pablo,


You are write I checked this yesterday!



Thanks again for your quick response


Georgia

[renos]

Dear Pablo,

I am trying to simulate wave breaking in a 3d NWT with wave generation of Stokes V and k-omega SST turbulence model.
I have a question in the boundary conditions for the sides patch (front and back). Can I use the slip boundary condition or I have to use the no slip boundary condition. What is the difference beween them?
Also in k and omega files can i use slip condition for side patch or I have to use the wall functions?

Thank you very much for your time,

Kind regards,

Renos

[Phicau]

Hi Renos,


of course you can, you just need to understand it and check if it makes sense. No slip BC is fixed value equal to 0; Slip BC is no flux across the boundary and zero gradient BC in tangential directions, which is the same as having a symmetry BC.



Best,


Pablo

[renos]

Hi Pablo,

Thanks for your reply, I have another question about the meshing.

My case is breakwater simulation around a monopile. I would like to ask about the meshing near the monopile. I am using the K-omega SST model.

What the y plus value should be near the monopile? I was trying with the snappyHexMesh but the values were between 7 (min) max (60) and average 30. From a lot of articles, I have seen that the value varies between 30-200. In order to make the value 30 near the wall of the monopile, the meshing would be very coarse. What should I do?

Thank you very much,

kind regards,

Renos

[Phicau]

Hi Renos,


I would not mind much that the y+ drops slightly from 30 as long as your grid convergence analysis indicates that you have reached convergence.


Best,
Pablo

[georgiak]

Dear Pablo,


I return to you with a question on waveAbsorption2DVelocity condition on outlet boundary.



I'm trying to simulate a low-crested breakwater in an inclined beach in shallow water conditions. The depth initially is (inlet boundary) is -6.6m and near the outlet boundary is around -2.5m, the wave model is cnoidal with H=4.5m and T=12.5s. The porosity of the structure is taken by the VARANS equations as they are described to the article "Three-dimensional interaction of waves and porous coastal structures
using OpenFOAM®. Part I: Formulation and validation"



I have a problem these last days with the waveAbsorption boundary condition. As I read to olaFlow's manual, this condition practical induces velocities opposite to the wave generation in order to cancel out the evanescent modes of the wave propagation. I have imposed then to the outlet boundary the condition hereafter:

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


The value of absorptionDir should be greater than 360degrees (according to olaFlow's manual) so that the boundary condition chooses the direction perpandicular to the paddle. Unfortunately, in the first steps of the simulation (even first 0.4s) ubnormal big velocities (even Ux=-70m/s) are observed to the free surface level in an area of 50m around the breakwater and the simulation bugs. I have also tried without the direction option and I had very similar results.



Do you have an idea of why does this phenomena appears? Could it be the structure geometry or the porosity?


Thank you in advance,


Best regards,
Georgia