[michele]

I'm just starting to use the OpenFOAM. I'm interested in VOF methods for ship hydrodynamics simulations. I had previously used other CFD tools when I worked at University.
The first test I'm making is a very simple undisturbed free surface 2D case. An uniform velocity field enters from the left and, after having crossed the domain, leaves the domain through an outlet boundary condition. I'm using the rasInterFoam, as I'm interested in getting a model more and more sophisticated (the complete simulation will require a 3D full rigid body dynamics for a boat... I would like to make roll damping calculations and performance analyses).

But I must confess I hadn't obtained good results even for this simple problem. The problem is well initialised and starts well. But after about 2.6 seconds the free surface is distorted (I was expecting a trivial solution of steady undisturbed free surface). The link to a picture of gamma is the following:
http://www.lem3.it/tests/gamma_2.57102.png

The process becomes unstable some time after, as can be seen in the following picture:
http://www.lem3.it/tests/gamma_3.15095.png

The time step is limited by a Courant number of 0.2, the fields are initialised accordingly with the boundary conditions...

I was considering what I was missing... Thanks in advance.
Michele.

[hjasak]

The second picture looks like a problem of a wave trying to reflect back from an inlet boundary...

Hrv

[eugene]

What are your left and right boundary conditions on gamma? They should be fixed value on the left and zeroGradient on the outlet.

I assume in terms of numerics you used all the default settings from the rasInterFoam test case? Try running it with both
div(phi,U) Gauss upwind;
div(rho*phi,U) Gauss upwind;
in your fvSchemes dictionary. If this doesn't solve your problem (and even if it does), it is more than likely an issue with the step change between the air and liquid at the inlet.

Could you please pack up the case and post it to this forum? I would like to take a look at it some time.

[michele]

Thanks for your kind replies. I think I imposed correctly the boundary conditions. The numerical scheme used for the momentum equation is upwind (at the first trials I realised that the gamma schemes where more unstable).
Herebelow, as Eugene requested to me, I attach the whole case.

By he way, its name, "waves", is misleading... it is a simple steady case (when the current issues will be solved, I will implement a time/space varying inlet boundary condition accordingly with potential wave theory).
I'm however still having problems with the case attached... any suggestions?

Thanks,
Michele.

[michele]

Thanks for your kind replies. I think I imposed correctly the boundary conditions. The numerical scheme used for the momentum equation is upwind (at the first trials I realised that the gamma schemes where more unstable).
Herebelow, as Eugene requested to me, is a link to the case (it's too big to be posted to this forum):
www.lem3.it/tests/waves.tar.gz

By he way, its name, "waves", is misleading... it is a simple steady case (when the current issues will be solved, I will implement a time/space varying inlet boundary condition accordingly with potential wave theory).
I'm however still having problems with the case attached... any suggestions?

Thanks,
Michele.

[chris]

It might be worth running with interFoam (rather than rasInterFoam) with upwind on the momentum equation. See if you hit the same problem.

[michele]

I tried running the case even with interFoam (with upwind discretisation for the momentum equations), but I experienced the same issues, i.e.
1. during the first part of the simulation the free surface continues going down (instead of keeping the original height)
2. after this starting phase, instabilities near the inlet boundary are observable

Michele.

[henry]

The conservation problem you have sounds like your mesh is incorrect, have you tried running checkMesh on it? Have you tried simpler meshes?

[hjasak]

Hello Michele,

I've got an idea for you, but before I can think of a fix, I need you to try something out for me. Could you please repeat the same run but set the gravity vector to zero:

constant/environmentalProperties

g g [0 1 -2 0 0 0 0] (0 0 0);

Now you should get a perfect undisturbed surface, right? If not, something else is badly wrong, but if you do, the problem will be easier to solve.

Please let me know,

Hrv

[henry]

Check the number of faces of the front and back "empty" patches, these should be equal to the number of cells otherwise the case is not 2D. Are you sure the mesh is 1-cell thick everywhere and is properly connected? How did you generate the mesh?

[henry]

> The checkMesh tool suggests using zipUpMesh, but nothing happens

Are you sure nothing happens? Doesn't it write out the corrected mesh? If you run it a second time what does it tell you? If you run checkMesh after running zipUpMesh do you still get errors/warnings?

> Another strange issue: the mesh non-orthogonality should be zero

Does your mesh contain refined regions? If so the mesh will not be perfectly orthogonal.

[michele]

Thank you, Henry.
Yes, indeed the mesh contains refined regions.
So I assume that the non-orthogonality and skewness parameters are non zero due to the refined faces. That's OK.

Indeed, if I run the zipUpMesh tool twice, it always outputs the following message:

-------------------------------------------------------------------------------
/*---------------------------------------------------------------------------*\
| ========= | |
| \ / F ield | OpenFOAM: The Open Source CFD Toolbox |
| \ / O peration | Version: 1.1 |
| \ / A nd | Web: http://www.openfoam.org |
| \/ M anipulation | |
\*---------------------------------------------------------------------------*/

Exec : zipUpMesh . waves
Date : May 30 2005
Time : 14:34:03
Host : binah
PID : 6479
Root : /home/michele/OpenFOAM/michele-1.1/run/simulations/rasInterFoam
Case : waves
Nprocs : 1
Create time

Reading polyMesh
Cycle 1 changed 3600 faces.
Cycle 2 changed 0 faces.
-------------------------------------------------------------------------------

No one of the files into the polyMesh directory is modified (I verified to have write access to these files). There is the
polyMesh/sets/zipUpCells
file, generated during the checkMesh execution.
I don't understand what is going wrong with this mesh.

Michele

[henry]

I am not sure why zipUpMesh doesn't write a new mesh, we will investigate. However the test checkMesh fails on and requests running zipUpMesh is only important is you want to run finite-elements on the mesh, i.e. mesh-motion, because it relates to edge connectivity which is only used for that purpose.

[eugene]

I haven't had a chance to look at this case yet. Has anything changed since last week?

[michele]

Dear Henry, thanks for the support.
I've just uploaded on my webspace the whole test case (www.lem3.it/tests/waves_050601/waves.tar.gz). Note that in the constant/polyMesh/star_mesh directory reside the exported star mesh (the simple mesh is "star" and the mesh containing embedded regions is "star2").

I however assume that for this simulation the mesh "star2" (the one that fails the checkMesh tests) is correct.
Regarding the rasInterfoam simulation made with this mesh, the following observations came out:

1. The visualiser shows skewed elements in the refinement interface region (as it can be seen two refinements were applied)
(see fig: http://www.lem3.it/tests/waves_05060...30s/1_mesh.png)
The mesh instead is made of hexaedra with split faces on refinement. (Is it due to this the fact that checkMesh reveals skewed elements?)
Is it a problem of starToFoam conversion or only of visualisation? I think the latter, as I manually verified the vertex positions (into the imported vertices files) and they seemed to be correct.

2. One small issue: the runFoamX applications, when saving the simulation files, forgets adding the
div((nuEff*dev(grad(U).T()))) divScheme in the fvSchemes dictionary... only a little bug.


Regarting the simulations results, at time 30s, I have to make the following observations:

a. Gamma shows a wavy pattern (see fig: http://www.lem3.it/tests/waves_05060...0s/2_gamma.png).
I think that this type of instability has no hydrodynamic sense. What's happening?

b. Turbulence grows when the wavy instability starts as a coupled effect (see fig: http://www.lem3.it/tests/waves_050601/res_30s/3_k.png and http://www.lem3.it/tests/waves_05060.../4_epsilon.png).

c. pressure shows some spikes (of large magnitude, up to pd= 426Pa/density, i.e. the pressure goes up to 4.26 bar see fig: http://www.lem3.it/tests/waves_050601/res_30s/5_pd.png)

d. The graphs of velocity also show these kind of instabilities. (see Ux in fig: http://www.lem3.it/tests/waves_050601/res_30s/6_Ux.png and Uy in fig: http://www.lem3.it/tests/waves_050601/res_30s/7_Uy.png).

The fvSchemes employed in this simulation are of high order. No numerical instability problems arose.

I will appreciate any comment.
Yours sincerely,
Michele.

[mattijs]

Hi Michele,

we found a bug in the writing of zipUpMesh. It does do its work but doesn't write the new mesh!

Attached a version of zipUpMesh which does. I have however no files to test it with so let me know if it actually helps.

Compile as usual:
- unpack
- wclean
- wmake

zipUpMesh.tgz

[henry]

1) The split-hex cells are decomposed into pyramids for ParaView because it cannot directly handle cells "higher" than hex.

2) Yes this is an omission in the FoamX configuration files which is easy to fix.

Have you tried:

making the walls slip?
lower-order schemes?
or any other schemes?
compression coefficient of 1?

[henry]

I also notice you have a relative tolerance set for pd, I think this is unwise although it what is set for the tutorial case. For the next release I will reset and test all the settings for tutorial cases of all the interFoam-based codes. I suggest you try:

Setting relative tolerance on pd to 0

cGamma to 1

the coefficient on the Gamma201 to 1 on both terms

nNonOrthogonalCorrectors to 0

[eugene]

I had a quick look at this case.

Neither upwind, setting cGamma=0, changing surface tension to zero nor any combination of these factors changes the occurrance of the initial perturbation near the inlet (lower order schemes do of course damp out the larger perturbations further downstream).

However, switching off gravity makes the problem disappear very rapidly.

I'm not quite sure why this happens, but it is noteworthy that a fixedValue outlet as used in this case is not valid. Pressure should increase with depth, not remain constant.

It is not clear whether this erronous BC influences the deccelelation of the interfacial gas phase near the inlet. I think it somewhat unlikely, but I dont have the time to pinpoint the origin at the moment.

[henry]

> but it is noteworthy that a fixedValue outlet as used in this case is not valid. Pressure should increase with depth, not remain constant.

Why do you think there is a problem with the oulet pressure BC? Remember we are solving for pd which is p - rho*g*h, i.e. is constant with depth at the outlet.