CFD Online Discussion Forums

CFD Online Discussion Forums (https://www.cfd-online.com/Forums/)
-   OpenFOAM Meshing & Mesh Conversion (https://www.cfd-online.com/Forums/openfoam-meshing/)
-   -   [snappyHexMesh] Mesh around ship with appropriate free surface refinement (https://www.cfd-online.com/Forums/openfoam-meshing/102860-mesh-around-ship-appropriate-free-surface-refinement.html)

Hannes_Kiel May 30, 2013 03:23

Remove the 0 directory (save all relevant field data (U, p, ...) in 0.org before)

For getting the best cell sizes for resolution of a typical wave train several refine passes in normal direction are usually required, but, if you want to limit the normal refinement to specific refinement levels (e.g. up to one below the hull refinement level) you run into challenges after the first pass due to loss of information (cellLevel).

Hannes

Quote:

Originally Posted by pepe.aero (Post 430783)
Hi Vieri,

thanks for your reply.
I've tried the procedure you suggested, but still troubles remain. Using the following procedure:

1. blockMesh
2. SHM (setting castellated as true, snap false, layers false)
3. topoSet
4. refineMesh
( till now checkMesh is very good !! )
5. SHM (setting castellated as false, snap true, layers true)

I was hoping this would work fine, but the following error was reported:

--> FOAM FATAL ERROR:
Number of cells in mesh:1948200 does not equal size of cellLevel:918205
This might be because of a restart with inconsistent cellLevel.

It seems that the 0/cellLevel file has not be updated after the refineMesh phase.
How did you manage this problem, if it happened to you in the past?

Thanks in advance, best regards.

Andrea


colinB May 30, 2013 04:52

Hi Andrea,

to avoid the mentioned error message and to
prevent you from copying folders and so on you could also
use the -overwrite flag for some of the commands.
That works for me.

So the workflow looks like:

1. blockMesh
2. snappyHexMesh -overwrite
3. topoSet
4. refineMesh -dict -overwrite
( till now checkMesh is very good !! )
5. snappyHexMesh -overwrite


This however makes it impossible to see earlier results of your mesh.


A question that came up to me:
How much does the mesh quality improve if you do the snappy in two
steps instead of one.

my current procedure looks like:

blockMesh
surfaceFeatureExtract -includedAngle 150 (...)
decomposePar
snappyHexMesh -overwrite (of course with mpirun etc)
reconstructParMesh
topoSet
refineMesh -dict -overwrite

then changing the set in the refineMeshDict

topoSet
refineMesh -dict -overwrite

with this procedure I get some good results.

Do you think with my approach and yours combined the results could be
even more improved?

pepe.aero May 31, 2013 07:09

1 Attachment(s)
Dear all,

thanks for all your replies. They have been very useful to me, and now my procedure works fine.

About your issue Colin: as you know the problem is related to mesh quality.
Refining the mesh in the free surface region after having completed all the three SHM phases (castellated, snap, layer) could be critical for skewness and non-orthogonality of cells.
So a good solution can be move up the refineMesh phase, just after the castellated meshing.
As Vieri suggested, this works quite fine for me.

But some issues regarding the layers insertion remain: the boundary layer appears not complete in many areas.
I think you have managed similar problem, very frequently, using SHM in the past. Which parameters in my SHMD (please see attached file) can improve my boundary layer, in your opinion?

Thanks again, regards.

Andrea

colinB June 4, 2013 04:44

1 Attachment(s)
Dear Andrea,

I have also troubles with the layer settings and I
overcome it with a more or less suitable workaround:

scaling down the ship to model scale and then simply just add
only one layer, for adding more layers doesn't work.

see attached my sHMD for comparison. I hope you find the information
you need.

regards

vince_44 October 10, 2013 11:43

2 Attachment(s)
Dear all,

I try to mesh with refinement in z direction. I use the procedure blockMesh/SHM/topoSet/refineMesh but when I run topoSet, I have the following message:

Create polyMesh for time = 0

Reading topoSetDict

Time = 0
mesh not changed.
Created cellSet refineCells
Applying source boxToCell
Adding cells with center within box (-30 0 -2) (66 -24 2)
cellSet refineCells now size 0

End

It's normal to have size 0? Where is my mistake?

I attache my blockMesh and topoSetdict.

best regards

vince_44 October 11, 2013 03:56

Hi all

I found the solution. It seem I must create an box in SHM around the free surface to have a size different than 0 whit topoSetDict.

But now, when I use refineMeshDict, even if in direction part in refineMeshDict, I choose only "normal", always It refine all cells in all directions like if he don't take account of topoSetDict and refineMeshDict.

Any Idea?

Best Regard

Vince

vince_44 October 11, 2013 04:55

Ok I resolve my problem with refineMesh. I just forget to indicate the file where is the refineMeshDict.

Now it's ok.

Vince

Rafael_Coelho October 12, 2013 05:33

Hi Vince,

Thanks for your contribution. Do you mind post your case? I never used refine mesh before and it will be good to compare my results?


Regards,
Rafael

vince_44 October 13, 2013 05:43

Hi Rafael

Sadly, I can't post this case because the CAD geometry is confidential. But I'm going to test the KCS hull and I will be happy to post this case. I hope I will have some good result to show.

Regards
Vince

Rafael_Coelho October 14, 2013 04:11

It will be good to see your KCS hull results. Do you have any experimental data to compare it?

vince_44 October 14, 2013 05:08

Hi Rafael

I have some experimental data from the Gothenburg 2010 workshop but if you have more data base, I'm interesting to see that.

Regards
Vince

vince_44 October 22, 2013 10:58

1 Attachment(s)
Hi Rafael

I test the KCS with this meshing method. I join the folder, but sadly for the moment, I have a Ct=3.21.10-3 where it's expected Ct=3.711.10-3, so an error up to 13%.

I use a simple K-epsilon model for turbulence and for numerical scheme, you can see in the folder.

If anybody have an idea to increase the precision.

I must delete the CAD file to upload my case but if some people would like the CAD, I can send by mail.

Regards

Vince

colinB November 5, 2013 03:22

Hey Vince,

have you tried the k-omega-SST turbulence model instead of the
k-epsilon model?

For me the k-omega model gives somewhat better results than
the k-epsilon.

It would be interesting to see whether you could confirm that or not.

kind regards
Colin

vince_44 November 6, 2013 02:31

3 Attachment(s)
Hey Colin

I test yesterday the same calcul with kOmega SST model. If it's little better, I haven't a result closed to experience yet.

An another problem that if I see the forces evolutions, it's not stabillize after 100s (I work with the full scale model). I attached the Fpx, Fvx et Fpz evolution.

In your opinion, what's wrong? My mesh, maybe too coarse? Or my schemes (I modify the div(rho*phi,U), div(phi,k) and div(phi,omega) ?

You can note, I use for k, omega and nut parameter, the formula found on this page:

http://www.cfd-online.com/Wiki/Turbu...ary_conditions

Kind regards

Vince

colinB November 6, 2013 05:18

Hi Vince

I noticed one major difference:
You use interFoam while I use LTSInterFoam.

Apart from that:
  • What is your value for I in the formula for k? I use 0.005
  • Your value for Cmu is probably 0.09 as suggested?
  • What is your turbulent length scale? I use here 5% of Lpp
Concerning the convergence:
  • It is recommended that the water passes the domain 3x times for a transient calculation! Was this the case after 100s?
  • with LTSInterFoam I need approx. 10.000 Iterations, and then I'm using the average over the last 2000 Iterations
fvSchemes (for comparison only, keep in mind that I use LTSInterFoam):


Code:

ddtSchemes                                           
 {                                               
    default      localEuler rDeltaT;                               
 }                                               
                                                 
 gradSchemes                                           
 {                                               
                                                 
      default        Gauss linear;                               
 }                                               
                                                 
 divSchemes                                           
 {                                               
    div(rho*phi,U)  Gauss linearUpwind grad(U);                         
    div(phi,alpha)  Gauss vanLeer;                               
    div(phirb,alpha) Gauss interfaceCompression;                       
    div(phi,k)      Gauss upwind;                               
    div(phi,omega) Gauss upwind;                                                     
 }                                               
                                                 
 laplacianSchemes                                       
 {                                               
    default      Gauss linear corrected;                           
 }                                               
                                                 
 interpolationSchemes                                       
 {                                               
    default      linear;                                   
 }                                               
                                                 
 snGradSchemes                                           
 {                                               
    default      corrected;                                   
 }                                               
                                                 
 fluxRequired                                           
 {                                               
    default      no;                                       
    p_rgh;                                           
    pcorr;                                           
    alpha;                                           
 }

I can't tell what the influence of your mesh is, but a coarse mesh can also

lead to a more stable calculation for waves are dampened.


Does that help you?



regards
Colin

vince_44 November 7, 2013 05:36

Hi Colin

Thanks for yours indications.

I use 0.001 for I (I'm going to test with 0.005)

Mu turbulent lenght scale is 1 Lpp (I assume it's too hight)

My Cmu is 0.09

For my fvscheme, I use a limitedLinear scheme for dive(rho*phi,U), like for div(phi,k) and div(phi,omega). With those schemes, I have better results than with basic scheme. But with those scheme, when I have 2.6M cells, with LTSInterFoam, my calcul crash, that's why I use interFoam.

Finally, if the water must passes the domain 3xtimes, 100s is not enought (U=12.34m/s and the lenght of domain is 883m).

I'm going change the turbulent lenght and I and run the calcul during 215s to see if I have a better result.

regards
Vince

vince_44 November 13, 2013 05:39

2 Attachment(s)
Hi Collin

So I change some values (turbulente intensity, turbulente length scale...) and I use a KomegaSST like turbulente model.

I modifie my mesh, now I have 2.6M of cells.

I run the calcul on 3 froude number and compare with experience. The total force is always under estimate (between 21.9% and 11.5%). But If I decompose the forces from the experience between viscous force (I use the ITTC57 formula) and wave resistance and I compare with pressure and viscous forces from OF, I note the pressure forces are very close (1.68% for Fr=0.28). However, viscous forces are really under estimate (67.45% for Fr=0.28!).

I assume I must add a layer (for the moment I don't arrive to have a correct layer for KCS) and may be increase the number of cells.

have you any idea to improve the results?

Last question, when the calcul run during a long time, it appear some wave (I join a picture) and the forces begin to split. What's wrong? My boundary conditions (wall on side and bottom, symmetry on the other side and classical inlet/outlet on enter face/exit face).

Regards
Vince

colinB November 14, 2013 03:15

Hi Vince,

indeed the layers are important when it comes to viscous effects.
Did you run yPlusRAS on your mesh, and if so what are the results?

Concerning the incoming waves:
If the mesh is too small this leads to non-physical waves in the domain.
So I use a rather coarse mesh at the inlet to dampen out some
irregularities
Then as approaching the ship hull I gradually make the mesh more dense
and after that when the wake field gets uninteresting again I'm using again
a coarser mesh to dampen the waves and avoid reflection.

Another question that I have is, is the distance from your bow to the inlet
really that short? If so you might want to increase this distance , for
otherwise the ship might impair the inlet.

For the rest it is difficult to give you more hints, for i dont know the rest
of the settings you have.

Another hint I have is what I found just yesterday:
http://www.openfoamworkshop2013.org/...p?Main=2&sub=1

on this page you will find a paper:
Practical Application of OpenFOAM to Prediction of Hull Resistance
of some guys from Hyundai where they also describe some settings in OF
I'm about to compare my settings with theirs and see how it effects the
results.

regards
Colin

Hannes_Kiel November 14, 2013 03:33

Hi Vince,

I've good experience with 1 length ahead of the ship, 3 astern, 2 aside, 1 below, 1/2 above. Further, integrate waves2foam into your solver and use the potentialCurrent condition to stabilise in- and outlet.
Good Luck
Hannes

vince_44 November 22, 2013 10:10

Hi Colin and Hannes

Thanks for yours replies. I meshing with new dimension for blockMesh with different mesh density and the problem of incoming wave was solved. Now I try to add a layer but for the moment, I don't arrive on the KCS (if you have some suggestion...).

I read with lot of interest the paper "Pratical Application of OpenFOAM to predict hull resistance" present in the link gives by Colin. I have some question about this:

-he use for alpha divscheme a mHRIC, it's the first time I meet this scheme, and you?

-with LTSInterFoam, I believe it was impossible to have degree of freedom but he use DFBI (Dynamic fluid body interaction) module, it's an in-house modul developpe by HHI or it's present with the basic version of OF?

Regards
Vince


All times are GMT -4. The time now is 02:05.