Hi, I'm new to OpenFOAM and
 

Hi,

I'm new to OpenFOAM and I'm interested in
calculating the flow around ships incl. the
free surface.
Is there already something "ready to use"
for that application?
The 2nd step might be considering dynamic trim
and sinkage, so 6DOF capabilities will be needed.
Is something like that also available?

Best regards,
Tim

Hi Tim I am facing similar
 

Hi Tim

I am facing similar issues (and I'm also at the starting point...). I would like to investigate OpenFOAM's potential to deal with this. I cannot help with solid answers ATM, but here are some thoughts:

1. "...The 2nd step might be considering dynamic trim and sinkage, so 6DOF capabilities will be needed....". Are you going after the seakeeping problem/behavior, the increased resistance (i.e. "increased resistance when traveling in a seaway") or to detect differences in the wake pattern (if they are at all detectable...)?
(Since the first step is actually a "leap"*, going after the seakeeping problem in this fashion seems a bit too much...the traditional method is to employ frequency domain methods and from what I understand they yield decent results).
[*: external viscous problem on an unbounded half-space with a priori unknown boundary - the free surface - with non linear boundary conditions...]

2. I think (I am still going through the documentation...) that interFoam may be a suitable solver. A question I still have is about geometry handling and continuity attainability on mesh surfaces. Is it C2?

3. Choice of specific problem formulation? Assuming the "simplest" situation - trying to establish total resistance and form of wake behind a known hull form moving at constant velocity, different options exist:
> Treat this a priori as a steady-state case - assuming that it exists (actually the "steady-state" may be actually an observed average of a fluctuating solution of the true unsteady case as t->oo) or
> Treat the unsteady/transient problem (undisturbed, flat, free surface, hull starting to move from rest @ t=0 to target velocity) while time gets sufficiently large...

4. Proper Domain decomposition? Since this is an external problem, only a portion (containing the hull) of the half space may be examined (and meshed...). One needs to carefully choose the extent of the treated sub-domain and apply suitable matching conditions at the artificial boundaries to reach a realistic simulation.

Best Regards
GK

Hi George, at the first ste
 

Hi George,

at the first step I'm interested in predicting
the resistance of a ship. To get that value
right the ship has to have to possibility to
adjust its position depending on the flow forces
that act on the hull.
So 6dof capabilities are only needed for resistance prediction.

Best regards,
Tim

To my knowledge OpenFOAM doesn
 

To my knowledge OpenFOAM doesn't include a surface following mesher (VOF with interface reconstruction) as would be necessary for efficient solution.

Or do you plan to use a phase fraction approach similar to the breaking dam example in the OpenFOAM manual? How would you balance the high/low mesh resolution close to the free surface and to the hull on the one hand side and in the distance on the oher hand side, all this while the free surface moves?

Eddi

Ship flow simulations are defi
 

Ship flow simulations are definatey possible with rasInterFoam.

Here is a simple example for the Wigley Hull at Fr=0.316. The plot shows wave-elevation contours.

http://www.cfd-online.com/OpenFOAM_D...ges/1/6710.jpg

One more figure: gamma contou
 

One more figure: gamma contours at a cross-plane near the bow.

http://www.cfd-online.com/OpenFOAM_D...ges/1/6712.jpg

Hi Eric, could you please
 

Hi Eric,

could you please tell us which is your test-case setup? BC, mesh, etc... Is your hull fixed in the mesh? If not how can you move it?

I'm not able to do ship simulations and it would be something really interesting, please give me any hints to achieve your results

Thanks in advance

Francesco

Francesco, You can download
 

Francesco,

You can download the Wigley Hull example at http://idisk.mac.com/egpaterson-Public. Look for the file, wigley.tar.gz.

In naval architecture terminology, this problem is set up for the steady resistance problem, i.e., no motion, and no incident waves. However, I am currently working on these issues.

Eric

Hi Eric, Thank you for the
 

Hi Eric,

Thank you for the example, very interesting! I'm interested in coupling interFoam with 6DOF solver and icoDyMFoam to make the simulation more realistic and interesting, I'll try to work on it, if you have any suggestions, you are welcome

Regards

Francesco

Hi Eric, Really nice pics a
 

Hi Eric,

Really nice pics and interesting results, it is opening a lot of questions, i miss a pic with drag force time history convergence (do you have any?, or routine to get forces in every step?)
Did you try with diferents froude numbers, transom stern?

I am new in OF (i installed the past week), i would like to join to find the best parameters to free surface about bodies. Let me known what mesher are you using.

Thanks,

Pablo

hi i want to modify the cod
 

hi
i want to modify the code,how can i get the source code?　

Hi, I am currently doing a
 

Hi,

I am currently doing a simulation around a planing hull (15 meters) with an incoming flow velocity of 10 m/s.

The mesh was done using GridPro. The 'checkMesh' is OK.

I am using the rasnterFoam solver.

I have re-used the settings of E. Patterson (model scale of wigley hull) with a maximum Courant number of 0.8.

After 10-15 the run crashes (bounding k and epsilon).

So I have decieded to run the case setting off the turbulence (RASProperties and turbulenceProperties files). And the calculation runs well, but very slowly.

So, is it possible to resume how to define (formula) the turbulence parameters for such a case :
- k
- epsilon
- nuTilda
- nut

And what about the initialization of the flow domain ?

Thanks for helping me !

Stephane.

does not work
 

hello,
I have download the wigley test case and when I launch interFoam or rasinterFoam, I have the following message. Thers is someone who can help me?


/*---------------------------------------------------------------------------*\
| ========= | |
| \\ / F ield | OpenFOAM: The Open Source CFD Toolbox |
| \\ / O peration | Version: 1.4.1 |
| \\ / A nd | Web: http://www.openfoam.org |
| \\/ M anipulation | |
\*---------------------------------------------------------------------------*/
Exec : foamToFieldview9 ./ wigley
Date : Mar 25 2009
Time : 14:16:00
Host : hpxo.crihan.fr
PID : 18985
Root : /state/partition1/home/hp08003/yandri01/TEST/
Case : wigley
Nprocs : 1
Create time
Create mesh for time = 0
#0 Foam::error::printStack(Foam::Ostream&) in "/share/apps/soft/OpenFOAM/OpenFOAM-1.4.1/lib/linux64GccDPOpt/libOpenFOAM.so"
#1 Foam::sigSegv::sigSegvHandler(int) in "/share/apps/soft/OpenFOAM/OpenFOAM-1.4.1/lib/linux64GccDPOpt/libOpenFOAM.so"
#2 __restore_rt in "/lib64/tls/libc.so.6"
#3 Foam::polyMesh::initMesh() in "/share/apps/soft/OpenFOAM/OpenFOAM-1.4.1/lib/linux64GccDPOpt/libOpenFOAM.so"
#4 Foam::polyMesh::polyMesh(Foam::IOobject const&) in "/share/apps/soft/OpenFOAM/OpenFOAM-1.4.1/lib/linux64GccDPOpt/libOpenFOAM.so"
#5 Foam::fvMesh::fvMesh(Foam::IOobject const&) in "/share/apps/soft/OpenFOAM/OpenFOAM-1.4.1/lib/linux64GccDPOpt/libfiniteVolume.so"
#6 main in "/share/apps/soft/OpenFOAM/OpenFOAM-1.4.1/applications/bin/linux64GccDPOpt/foamToFieldview9"
#7 __libc_start_main in "/lib64/tls/libc.so.6"
#8 Foam::regIOobject::readIfModified() in "/share/apps/soft/OpenFOAM/OpenFOAM-1.4.1/applications/bin/linux64GccDPOpt/foamToFieldview9"

Hi OpenFOAM users,

I have problems in running free surface computations around ships using grids generated with ICEMCFD Hexa and the rasInterFoam solver . Very soon messages about bounding epsilon and bounding k appear and then the case crashes.

ICEMCFD Hexa is not able to keep orthogonality at the walls (with a kind of elliptic smoothing).

With GridPro meshes I succeed in running this kind of cases. Unfortunatly I do not have GridPro. I think that the mesh of the wigley hull of Paterson was done using GridPro. The wigley hull runs well.

Has someone experienced similar problems with ICEMCFD meshes ?

Regards,

Stephane

Hi stephane,
I am currently having the same issues you posted. I produce my meshes with ICEM (structured hexa) and altough they seems ok and runs well with CFX, they diverge very quickly with Openfoam. I tried both with interFoam and rasinterFoam and in both cases the simulations diverges (let's say that interfoam is a bit more forgiving and tend to diverge more slowly, while rasinterfoam explodes a bit faster..)

Postprocessing the results, it can clearly be observed that the critical area where the simulation diverges are the one where the mesh is not orthogonal (constant/poly/sets/nonorthoFaces... it can be plotted via paraview and VTK with setSet commands.. btw you can observe it also in icem plotting the maxortho quality criteria over a value of about 65.)

Theorically Openfoam should be able to take care of the non-orthogonality via the "nNonOrthogonalCorrectors" parameters but I have tried many value (from 0 to 6) and it doesn't seems to change at all..

I have tried with Patterson parameters and with many others, but i only manage to delay a bit the divergence at best..

Any ideas?

I don't think it is a problem related to the VOF approach since in some cases the critical area are well under the freesurface (thus completely immerged in water and thus sould be the same of a single-phase simulation in that area), but it seems very strange to me that thus this is a general problem because if so it would affect almost all cases...

Is the nonorthogonal correction for some reason not suited to hexa meshes?

Or if the checkmesh reports some non-orthogonal cells, are those over the limit of Openfoam and thus we cannot expect to recover them via the correction?

suggestions?

thansk,
Matteo

Hi Matteo, hi OpenFOAM readers,

Until now I haven't solve the problem. Cases computed with ICEMCFD Hexa grids (wigley hull, Series 60) and Eric Paterson settings always diverge !

I don't know which grid software is using E. Paterson. Maybe Gridgen, maybe GridPro !

I would be nice to have the opinion of Eric Paterson about our specific problems. Hoping Eric paterson is reading this thread.

Matteo, I know that you are mainly interested in computing simulations with this kind of geometries, but try to use a more rounded boat to begin. Let me know about an alternative geometry.

Regards,
Stephane.

Hi Stephane & Matteo,

Is it possible for you to post your case at http://idisk.mac.com/egpaterson-Public ? If so, I'll try to take a look and see if it is something obvious.

It is probably dangerous to think that the settings from a simple problem like the Wigley hull will be uniformly applicable to all problems. You may need to turn on the limiters for the laplacian and grad calculations, e.g.,

gradSchemes
{
default faceLimited leastSquares 0.5;
}
laplacianSchemes
{
default Gauss linear limited 0.33;
}
snGradSchemes
{
default limited 0.33;
}

and also set divSchemes to upwind until you establish something close the correct pressure and wave field.

Good luck, Eric

P.S. I primarily use Pointwise & Gridgen, from Pointwise Inc. Pointwise has an OpenFOAM parser which makes it particularly nice.

Hi Eric,
thank you very much for the post!

I have managed to find a way in Icem to control a bit the orthogonality and now checkmesh doesn't complain anymore.

Unfortunately with my old settings the simulation used to diverge as well.

I have then added the schemes correction suggested by Eric and now finally I manage to run it! I still have to check results and so on, but at least it is not exploding!
thank you very much Eric!


A couple more questions:
1)are the limited schemes a sort of under-relaxation and thus at some point I have to switch them off to obtain the correct result or are they just just numerical correction and thus I can leave them on? If the second case: why not leaving them like that as default? and also, I have seen on the user-guide they are some sort of orthogonal correction: what's the difference between these correction and the the non-orthogonal correction step in the fvSolution?

Thanks again,
Matteo

Wigley hull and series 60 test case
 

Hello,
I am wondering whether anyone has managed to validate rasInterfoam on any test case (i.e. wigley hull or similar) since I have tried to do it with the Series60 case but I am getting results that are not very close at all with the experimental one.

In brief:
-Openfoam predicts a value of pressure drag and viscous drag that is about twice as big as the experimental and CFX one (the CFX one run on the same grid)
-My openfoam case starts as first-order-Upwind and at a certain time switches to second order-SFCD-corrected etc etc..
-I have tried on different grid, a medium one (500 000 cells) and a more refined one (1.5 millions cell). Mesh check is fine and the meshes are produced with ICEM and are hexa-structured
-As turbulence model i am using only Kepsilon since SST was not converging.

Thus, my question is:
Has anyone obtained any good agreement on any test case with Openfoam-rasInterfoam?Prof. Patterson showed before some qualitative very interesting results, are those also quantitevely correct? how do they compare with experimental data?

Finally:
anyone can point me to some web page or similar where i can find some experimental data about the wigley hull (waterline, watersurface elevation, measurememt conditions, sink and trim)? I cannot find them anywhere.

Thanks,
best regards,
Matteo

wigley simulation with OF1.6
 

Interfoam has been updated in version 1.6 to use p instead of pd. I've been trying to update the wigley case to 1.6 without success. Did anyone tried to run it in 1.6? Any help would be greatly appreciated.

Gonzalo

Case running in 1.6
 

Hello, Redondo

i've just starded calculating the case in OF1.6. I had to change all 'pd' in 'p' and all 'gamma' in 'alpha1' (in fvSchemes change 'gamma' to 'alpha'). Don't forget to rename the files in 0 dir accordingly (p und alpha1)

That seems to work:)

Thanks mks,

I forgot to post how I did it, but the problem is already solved pretty much doing what you mentioned. The only thing I'm missing is how to separate hydrodynamic and aerodynamic forces. Any clue?

Gonzalo

Wigley Fn=0.316
 

Hi all,

I wonder how are you doing with OF1.6 for free surface flows. I was able to run robust simulations, but the forces are way off the experimental data, about twice:

Pressure Forces:
Fpx = -0.212253, Fpy = 0, Fpz = 25.228174

Viscous Forces:
Fvx = -0.427812, Fvy = 0, Fvz = 0.045150

I don't bother too much about viscous forces at this stage but what is killing me is that I cannot figure out what is going on with pressure forces.

Here I'm showing the results for a 514K mesh with at T=10 seconds. Timestep is 0.002s and turbulence model is kOmegaSST. There's a 0.7 relaxation on p. Anyway, if somebody has a clue about the issue with the forces or just want some help I can post or attach some files :)

Turbulence off does not solve pressure forces, it's all pretty much the same. I also tried other turbulence models and different yPlus. Right now it is around 100.

Attachment 1687

Attachment 1688

Two phase flow
 

Hello,

how do you calculate the forces? I've done comparison calculations using Wigley hulls and containerships which showed good agreement with experimental data. The forces were calculated using a modified functionObject 'forces' since the original one does not support two phase flow.

HTH,
Jean-Peer.

Hi Jean-Peer,

You're correct about the original force function, but I also made a filter with paraview and the pressure forces are pretty much the same (neglecting aerodynamics). Would be nice to know about your modified function though.

I think that the problem I'm facing is new in OF1.6 as Eric has shown very nice results with previous versions. The case had to be ported and doesn't seem to work so nice, although as you can see free surface is not too bad.

Gonzalo

Thanks for the quick reply, I appreciated it. It is also good to know that it's working for you.

I'm using zerogradient for the pressure on the hull. Outlet is buoyantPressure. Should it also be buoyantPressure on the hull? How did you set up the boundaries?

I will try the modification of the force function after fixing this.

Gonzalo

Hello Gonzales,

IMO zeroGradient is not the proper BC for the hull in 1.6. You should use 'buoyantPressure 0' instead. As far as I understood, buoyantPressure is a fixed gradient BC that takes the impact of the buoyancy into account. Thus, the use of 'buoyantPressure 0' and zeroGradient is equally in the case of vertical wall but is not if the wall arbitrary located (as the hull) or is a horizontal wall (as the bottom).

Some comments on my BCs: the application of zeroGradient for the outlet did not work very well for me (especially in combination with unstructured grids), so I prescribed the pressure (profile) on the outlet. The inlet was modelled as velocity inlet and remaining bounds as free slip walls.

Good luck.
Jean-Peer

Ok, got it.

I will try with buoyantPressure at the hull and I'll post the results here as soon as possible, if any :)

Gonzalo

hello,
I'm very interested in the results of buoyantPressure on the hull.
As Jean-Peer said, buoyantPressure has a "strange" impact on non vertical interface. You can see what I obtained in another topic
http://www.cfd-online.com/Forums/ope...interface.html
I didn't find an equivalent to zeroGradient in 1.5 for Pressure. If I put zeroGradient in 1.6, I don't have mass conservation.

Waiting for your opinion.

Regards

U and p
 

Hi all,

Still running, it is slightly less but not sure if enough. I will post results when (and if) it gets to 5s (this night here in Spain).

The only difference I think I have compared to Jean is that instead of having free-slip walls at the side and bottom I have it all defined as an inlet. The reason why I do this is to keep the same setup as CCM and Comet. I'm gonna try changing it by I don't think it's the problem.

I'm running a structured grid.

Here I paste my U:

dimensions [0 1 -1 0 0 0 0];

internalField uniform (-0.9897 0 0);

boundaryField
{
OUTLET
{
type zeroGradient;
}
SYMMETRY
{
type symmetryPlane;
}
ATMOSPHERE
{
type pressureInletOutletVelocity;
value uniform (-0.9897 0 0);
}
EXTRAHULL
{
type zeroGradient;
}
INLET
{
type fixedValue;
value uniform (-0.9897 0 0);
}
HULL
{
type fixedValue;
value uniform (0 0 0);
}
}


and also my p file:



dimensions [1 -1 -2 0 0 0 0];

internalField nonuniform List<scalar>
286572
(
14192.7
12528.2
11062.6
9772.02
............
............
0.193104
0.123309
0.0429817
)
;

boundaryField
{
INLET
{
type buoyantPressure;
gradient uniform 0;
rho rho;
value nonuniform List<scalar>
17080
(
14192.7
14192.7
14192.7
............
............
0.193104
0.123309
0.0429817
)
;
}
EXTRAHULL
{
type buoyantPressure;
gradient uniform 0;
rho rho;
value uniform 0;
}
ATMOSPHERE
{
type totalPressure;
rho none;
psi none;
gamma 1;
p0 uniform 0;
value uniform 0;
}
OUTLET
{
type buoyantPressure;
gradient uniform 0;
rho rho;
value uniform 0;
}
SYMMETRY
{
type symmetryPlane;
}
HULL
{
type buoyantPressure;
gradient uniform 0;
rho rho;
value uniform 0;
}
}

This might help
 

This might help
http://www.iihr.uiowa.edu/~shiphydro...S60_steady.htm
http://gfs.sourceforge.net/examples/...ip.html#htoc11

Good Luck

Wigley with buoyantPressure BC
 

Ok, thanks Ahmed.

According to Jean-Peer I run the simulation with buoyantPressure BC at the hull.

The resulting forces are the following:

Fpx = -0.162647
Fpz = 25.119922
Fvx = -0.567550
Fvz = 0.065198

So it is better in terms of pressure forces, I can't say the same about viscous though. Anyway, it looks like the way to go, but it is still far from the target of Fpx = -0.1232 and Fvx = 0.3577.

I was thinking on making a wider domain because of my sides(inlets). I will also run a simulation with free slip walls just to see the difference between both approaches.

This are the settings that I still have to investigate properly, what are you using?

- Domain Size (I think it's big enough, check it on the TOP view, but as I said I'll make it bigger just to try)

- Turbulence model (KOmegaSST, also tried KEpsilon)

- Yplus (50~100)

The mesh density didn't affect before (zeroGradient BC), so I don't that'll change with the buoyantPressure BC. Therefore I'm investigating on the coarse mesh (286K). Here I attach some pictures at 5s.

Attachment 1716

Attachment 1717

Attachment 1715

Hello everybody,

To clarify: I don't think the buoyantPressure BC has any strange impact. In fact, it takes the gravity (and thus the resulting constant pressure gradient) into account and is the right BC for non-vertical walls when using the interFoam solvers in 1.6.

@g.redondo
Some more remarks:
1. I'm sure the grid resolution has impact on the computed resistance, in particular the pressure resistance. IMO, you cannot expect to get results that match exactly the experiments with somewhat 200K cells.

2. Did you investigate the time history of your forces. There are oscillations in the (pressure) forces that take time to vanish. Have a look at that and take a time average, maybe.

HTH,
Jean-Peer.

Ok, my mistake, I didn't get what you meant. Did you have a look at my topic? How can you explain the behaviour of water in my case?

Regards,

I know, but I would expect it to be closer, as it is in CCM with the same mesh (Fpx ~ -0.013). I tried the same settings with a 286K, a 514K and a 915K mesh. All results are pretty much the same.


I did. The results I'm giving are an average of the last 500 timesteps.

In my opinion, there must be something else.

Wigley Investigation
 

Hi all,

Still struggling with this. The following is my current situation after another week of investigations on this simulation.

These are the investigations I've done so far:

- Simulation time: I concluded that the simulation stabilizes at t=5s

- Mesh size independence investigation (286K, 514K and 914K): Results show no differences between them in terms of forces and free surface.

- Domain size investigation: With two step variations I've checked the length upstream, downstream and also the width. No differences.

- Turbulence model investigation (KEpsilon, KOmega and KOmegaSST): No differences.

- Yplus investigation (~30, ~100, ~200). The smaller it is the bigger the viscous forces are. Pressure remains the same.

Right now I'm still ~20% off in pressure forces and ~80% off in viscous. What could be the reason for so high viscous forces?

I wonder if someone has validated interfoam 1.6 with this case.

Best Regards,

Gonzalo

Hi Gonzalo,

I've not used 1.6 extensively, but this is alarming given that you are taking a case from 1.5 and getting very different results.

In general, I do not like the idea of solving for total pressure. For the simplicity of initial and boundary conditions, I much prefer solving for the dynamic pressure and would be inclined to modify interFoam back to the 1.5 formulation. Also, the hydrostatic component tends to mask convergence problems due to the large amplitude in comparison to the delta between iterations. In one test with 1.6, my pressure forces looked strange, and upon subtraction of the hydrostatic component (in my post-processing tool), I could see that the dynamic component had lots of problems in regions of high grid clustering.

This of course doesn't explain the discrepancy in the viscous component. Since your mesh is a wall-function mesh, are you sure your b.c. are set correctly? 1.6 changed the wall-function implementation.

Eric

Hi Eric,

I completely agree with you about masking dynamic pressure convergence.

You can check U and p in a previous post, but I think they're correct. K, Omega and nut are the same as for 1.5.

About that case you've run in 1.6... what results do you have for the viscous forces?

Soon I'll be running out of ideas so the last option would be to go back to 1.5, but only if I know that the old formulation is going to come back.

Regards,

Gonzalo

Hello redondo,
I think that in OF-1.6 you have to set different BC for the turbulence terms.

mut for example should become (at least int the interfoam tutorials looks like this):

Wigley
{
type mutWallFunction;
value uniform 0;
}

and not zeroGradient as in 0F-1.5.

Is that what you have in your cases?

I agree with Eric about the dynamic pressure approach, in our cases it should be much better.

One question:
has anyone managed to have the 6-dof motion working in parallel with OF1.5-dev? I managed to have it running in serial, but in parallel I have same strange error like in the mesh motion solver (something I haven't touched at all): "operator T ()() temporary deallocated"..

I would just like to know if it is just my problem or if anyone has it working and thus I may have done something wrong.. (p.s: I have the blocking option)

Thanks,
Matteo