Hi Foamers I have made a bo
 

Hi Foamers

I have made a boundary condition to be used within the multiphase solvers. At present I have only used it with InterFoam, but I cannot see any problem in applying it with rasInterFoam or lesInterFoam.

The BC generates Stokes 1st order waves on a vertical boundary - though easily extended to any higher order wave theories. The key difference from those BCs previously posted is that the faces at the boundary patch is evaluated each and every one. If a face intersects the interface at the boundary, then the wet and dry areas are determined, and a weighting of the boundary condition above and below the surface is given to that specific face. The reason for this extension is that the other procedure gave me problems with noise generated at the boundary if WET/DRY was only evaluated based on whether the center of the face was above or below the surface. This smoother approach seems to eliminate that.

I am in the middle of making a small technical note, which will be posted her, as soon it is done, but I thought I would like to share with all of you. The technical note will include a small verification and documentation of the chosen procedure together with verification of the BC against available experimental data.

The boundary conditions can be found by following this link:

http://www.student.dtu.dk/~s001581/f...BasedBC.tar.gz

and an example of the use can be found here:

http://www.student.dtu.dk/~s001581/testExample.tar.gz

Any comments will be appreciatedhttp://www.cfd-online.com/OpenFOAM_D...part/happy.gif Have fun,

Niels

Niels- Thanks for sharing y
 

Niels-

Thanks for sharing your new boundary conditions. I am trying to use them on your test case, but I am having some difficulties.

I unpacked your files and ran the Allwmake script. It executes smoothly, and the *so files are placed in my $FOAM_LIBBIN.

When I execute interFoam, I get the following response:

--> FOAM FATAL ERROR :
gradientInternalCoeffs cannot be called for a defaultFvPatchField (actual type surfaceWaveVelocity)
on patch inlet of field U in file "/k/kjmaki/OpenFOAM/kjmaki-1.4.1-dev/run/testExample/0/U"
You are probably trying to solve for a field with a default boundary condition.

From function defaultFvPatchField<type>::gradientInternalCoeffs( ) const
in file fields/fvPatchFields/basic/default/defaultFvPatchField.C at line 694.

FOAM exiting

If I switch disallowDefaultFvPatchField to 1 in my ~/.OpenFOAM-1.4.1-dev/controlDict, it informs me that surfaceWavePressure is an unknown patchField type.

I have searched the Message Board, and I have found numerous posts that deal with related problems. Unfortunately, none of them were descriptive enough for me to understand exactly how to ensure interFoam will recognize the new conditions.

Thanks for the help!

Kevin

Hi Kevin Good to hear that
 

Hi Kevin

Good to hear that you can use it.
You have to recompile InterFoam, so it links to the new libraries. Look in the file
OpenFOAM/OpenFOAM-1.4.1/applications/solvers/multiphase/interFoam/Make/options

and add the libraries in the same fashion as "-lfiniteVolume".
The libsurfaceWaveGammaFvPatchField.so does not need to be linked to interFoam as it is not used .. I never managed to get a robust method, where gamma was given as a Dirichlet, thus it is just set to zeroGradient in /0/gamma. The files are just left in the directory for completeness, if any of you come of with a clever ideahttp://www.cfd-online.com/OpenFOAM_D...part/happy.gif

I forgot to write, that my test example is rather large - 4 hours run in parallel on 3 cpus - so you might consider to look at the number of cells. I just gave a test, which I used for my verification - details on that to follow.

Further it could be difficult to use the BC on anything but rectangular faces on the boundary patch, where the faces is aligned with the y-z axes. This is due to a minor part of the method, which hasn't been implemented yet - when that is done arbitrary polygons can be used. This addition will come together with the technical note.

Have fun,

Niels

Hi Niels, Thank you for pos
 

Hi Niels,

Thank you for posting your BCs.
I have one comment and and one question.

It seems that OpenFoam recommends that new boundary conditions be compiled as new user dynamic library (for example as "libmyBCs.so") by using the following compilation line in the Make/files file: LIB = $(FOAM_LIBBIN)/libmyBCs. The library can then be accessed simply by including the following line at the end of the case/system/controDict:

libs ("libmyBCs.so")

In this way the OpenFoam source code is not modified.

My question concerns the contructor of your boundary condition. You are using the environmentalProperties dictionary. It seems that this dictionary is not loaded when the setFields and decomposePart utilities are run. So when I try to initialise the fields using setFields I get the following errors:

Exec : setFields . testExample
Date : Mar 10 2008
Time : 09:44:50
Host : CARNOT6
PID : 10012
Root : /home/delaurey/OpenFOAM/delaurey-1.4.1/run/tutorials/interFoam/VOF_Apps
Case : testExample
Nprocs : 1
Create time

Create mesh for time = 0

Reading setFieldsDict

Setting field default values
Setting volScalarField gamma
Setting volVectorField U


--> FOAM FATAL ERROR :
request for dictionary environmentalProperties from objectRegistry region0 failed
available objects of type dictionary are

3
(
fvSolution
fvSchemes
setFieldsDict
)


Reading the gamma field does not generate any error since I use like you a zeroGradient boundary condition. But executation terminates with the initialisation of U. Did you experience similar difficulties?
Thanks
Yann

Hi Yann I tried to remove m
 

Hi Yann

I tried to remove my BCs from the compilation of interFoam. When I did that I got the same error as yours. Though compiling with the libraries does not seems to give any problems.

I am very new to both OpenFOAM and C++ thus if there is a need to change things in my BCs, I believe we need to get some advise from a more experienced user. The present BCs is actually based on some other FvPatch<type>Field I found in the source.

Best regards,

Niels

Niels, Thanks for your resp
 

Niels,

Thanks for your response. I am also just starting using OpenFoam. I also had a look at the BCs class you used to derive your own. One way of avoiding the problem is to remove the BC variable from the environmentalPropeties dictionary and placing them in the 0/U and other initial field definition. For example:

boundaryName
{
type surfaceWaveVelocity;
inletValue uniform (0 0 0);
value uniform (0 0 0);
depth 1;
seaLevel 1;
...
}

and in the contructor:

...
depth_(readScalar(dict.lookup("depth"))),
...

instead of reading the environmentalProperties dictionary. Just to check have you had any problem running your case in parallel? I have implemented a similar BC which runs well on a single processor but fails in parallel. Has anyone else experienced similar problems when using dynamic libraries by using the dlopen methd recommended in the last distribution of OpenFoam (by adding libs ("libfoamUser.so" in controlDict)
Regards
Yann

Hi While implementing a sec
 

Hi

While implementing a second order stokes, I found that I have made a bug in the pressure gradient.

Corrected version will be uploaded as soon as possible.

Hope you haven't trusted your life on ithttp://www.cfd-online.com/OpenFOAM_D...part/happy.gif

- Niels

Niels, I was reading throug
 

Niels,

I was reading through your codes and I have a quick question about a line in interfaceWeight.H:

points[fProp[fI]].component(1)

Does this return the value of the first component of the point vector. In your test case, the x axis is aligned with the wave tank and the gravity vector is in the y direction. Doesn't this mean that your test to check that the point is above the elevation of the free surface should be made with regard to component(2).
Have I misunderstood the meaning of the component() function?
Thanks
Yann

Hi Yann The componet() coun
 

Hi Yann

The componet() counts from 0, thus 0->x, 1->y and 2->z

Hope ypu have been getting it to work.

- Niels

Niels, Of course, sorry about
 

Niels,
Of course, sorry about that.
Yann

Hi The bug has now been cor
 

Hi

The bug has now been corrected and the boundary condition can be found following the link at the top of this thread.
A second order stokes wave has been implemented, which resulted in an additional keyword in the environmental-dictionary, namely waveType. It has to be either StokesFirst or StokesSecond. At second order wavenumber, etc is the same as for first order.

Have fun,

Niels

Hi Niels, I am very keen to
 

Hi Niels,

I am very keen to look at the boundary conditions you have created but I cant access the link supplied:

http://www.student.dtu.dk/~s001581/f...BasedBC.tar.gz

Are you able to email it to me?

Cheers
Charlotte

Hi Charlotte My initials ha
 

Hi Charlotte

My initials have been changed, so please replace "s001581" with "ngja" and you should be able to access the files.

Best regards,

Niels

Hi Charlotte I have ended u
 

Hi Charlotte

I have ended up with setting the velocity in the air to zero in each time step, as discussed in [1] p. 11.

The reason for this is that I never got around to control the air velocities at the inlet. Large and unphysical velocities appear if such means are not taken.

Best regards,

Niels

[1]. http://vtchl.uiuc.edu/~liu19/publications/scour.pdf

Hi I'm new to OpenFoam and
 

Hi

I'm new to OpenFoam and i'm having difficulty applying these boundary conditions. Eventually I'd like to place an aerofoil into a wave tank, but initially I'm trying to use a wave tank with a cylinder inside it. I've built the mesh and the tank is producing waves, however the waves are generating from the centre creating 2 sets of waves. Does anyone know why this is happening and how I would go about generating the waves from the left hand side of my tank.

Thanks
Ben

Hi Waves are generated at x
 

Hi

Waves are generated at x=0 at default (a.k.a. hard-coded).

- Niels

Sorry, that does not make sens
 

Sorry, that does not make sense, as internal generation of waves sound pretty weird. You need to elaborate on the problem, otherwise we will not be able to help you.
A screen-dump or similar would be helpful.

- Niels

The screen shot shows how the
 

The screen shot shows how the waves are mirrored about x = 0. The mesh I built starts at x = -2. If I rebuild the mesh to start at x = 0, should the waves generate from the far left of my mesh?

file:///home/ben/OpenFOAM/ben-1.5/run/tutorials/interFoam/wavecylinder/wavecylin der/wave.0002.jpg

Thanks

Ben

Sorry, here is the screen h
 

Sorry, here is the screen

http://pichostonline.com/][img]http://pichostonline.com/u/081003/c1f756d531.jpg[/img][/url]

Hi Are you sure, that you h
 

Hi

Are you sure, that you haven't applied the waveBC to a patch internally, as the boundary conditions are applied to a patch and not in the internal part of the domain.

/ Niels