CFD Online Logo CFD Online URL
www.cfd-online.com
[Sponsors]
Home > Forums > Software User Forums > OpenFOAM > OpenFOAM Meshing & Mesh Conversion

[snappyHexMesh] bad snap phase with high cell count

Register Blogs Members List Search Today's Posts Mark Forums Read

Like Tree3Likes
  • 1 Post By Artur
  • 1 Post By Artur
  • 1 Post By CRI_CFD

Reply
 
LinkBack Thread Tools Search this Thread Display Modes
Old   April 25, 2014, 06:19
Talking bad snap phase with high cell count
  #1
Senior Member
 
James
Join Date: May 2013
Posts: 116
Rep Power: 12
Tensian is on a distinguished road
Hi Foamers,

I am having some troubles with snappyHexMesh and blockMesh.

First thing I want to argue is the bad behaviour of snap phase when the number of cells is high. Which parameters are need to be increased to obtain a smooth appearecne of the geometry meshed? I have used surfaceFeatureExtract but without success...

On the other hand, when I introduce less cell count, sometimes the mesh is surface but it introduces some holes that didnīt belong to the geometry.

Also I have used different blockMesh sizes, and even when I use very hard constraints in meshQuality controls the resulting mesh is smooth in appearence (Great!) but the resulting mesh fails all checkMesh tests.

I am using OF 2.2 for meshing a complicated pipe with two inlets and one outlet. Sorry but I canīt attach geometry due to company banning.

It would be great if somebody have meshed somke complicated geometries with snappy and can share knwoledge, mainly in how to make a good snap with high mesh density.

Thank you for all our help forum, you are great!

Best.
Tensian is offline   Reply With Quote

Old   May 7, 2014, 17:44
Default
  #2
Senior Member
 
Artur's Avatar
 
Artur
Join Date: May 2013
Location: Southampton, UK
Posts: 372
Rep Power: 19
Artur will become famous soon enough
Hi James,

To achieve better snapping of complex geometries it is worth increasing the number of solver iterations and the total number of snap iterations (nSolverIter and nFeatureSnapIter). You may also want to reduce the mesh quality in order to represent the surface better but be careful not to push it too far or you'll have problems with getting your solution to converge.

For a generic pipe problem I'd recommend reading this:

https://sites.google.com/site/snappy.../cylinder-case

In terms of high cell counts... Increasing the refinement on the surface should generally lead to better representation being achieved and should not affect the snapping adversely, not in my experience at least. Can you elaborate a bit on why you think the cell count is causing problems for you?

Peace,

A
Artur is offline   Reply With Quote

Old   May 13, 2014, 06:37
Smile
  #3
Member
 
Richardpluff
Join Date: May 2014
Posts: 95
Rep Power: 11
CRI_CFD is on a distinguished road
Hi James,

I am having the same problem I think. Have you solved the problem?

When I increase mesh density the shape of the mesh becomes more "castellated" than when I use smaller meshes. At about 3-4 million cells becomes very difficult to have a good snapped grid.

I am using surfaceFeatureExtract and with low cell count surface is represented almost perfect, but when I increase level of refinment (let say, for example, wall.emesh to level 9 and refinmentSurfaces to (8 9), the wall looks very close to the castellated one).

Artur, do you think that only relaxing the quality parameters and giving higher values to nFeatureSnapIter and nSolverIter it's possible to obtain a well snapped mesh? In my case I set the meshqualityControls by default (max_non_orth=65,max_sk=20...), but looking for checkMesh report, the quality criterion is widely satisfied (for example, non_orth_max=45) and the surface snap itīs far from what I expected. Why snappy stops until reaching the limits of quality?

Thanks to all. Snappy is sometimes very difficult to understand...
CRI_CFD is offline   Reply With Quote

Old   May 13, 2014, 06:50
Default
  #4
Senior Member
 
Artur's Avatar
 
Artur
Join Date: May 2013
Location: Southampton, UK
Posts: 372
Rep Power: 19
Artur will become famous soon enough
Quote:
Originally Posted by CRI_CFD View Post
Snappy is sometimes very difficult to understand...
I could not agree more

Anyway, I am not sure why it stops before reaching the criteria, i.e. why it's not "pushing" the snapped mesh to the maximum allowed deformation. Perhaps try changing it to something like 80 and see if the actual value will be different from what you're getting now?

As for nFeatureSnapIter parameter I have had some very good experiences when changing it and hence I often recommend it - I was meshing a cylinder for a sliding AMI interface and with this parameter low it wouldn't work because of insufficiently well deformed mesh.

Peace,

A
CRI_CFD likes this.
Artur is offline   Reply With Quote

Old   May 13, 2014, 08:11
Smile
  #5
Member
 
Richardpluff
Join Date: May 2014
Posts: 95
Rep Power: 11
CRI_CFD is on a distinguished road
Hi again,

I attach my snappyHexMeshDict, the log file and a snapshot os some zones of the (supposedly) snaped mesh. I can't find where the mistake is (maybe blockMesh issues or featureAngle?). Perharps somebody could give me the key (Artur, supermoderators... I need your knoweldge!!). Unfortunately I cannot share the geometry .

Thanks in advance.
Attached Images
File Type: jpg bad_sanp.jpg (18.9 KB, 82 views)
File Type: jpg bad_snap2.jpg (9.7 KB, 75 views)
Attached Files
File Type: gz dict_&_logs.tar.gz (16.4 KB, 5 views)
CRI_CFD is offline   Reply With Quote

Old   May 13, 2014, 08:16
Default
  #6
Senior Member
 
Artur's Avatar
 
Artur
Join Date: May 2013
Location: Southampton, UK
Posts: 372
Rep Power: 19
Artur will become famous soon enough
Can you give it a quick go with changing

Code:
tolerance 5.0;
to something smaller, like 1.0 or 2.0?

This could explain why your mesh becomes worse as you refine it more; this parameter defines the distance at which the edge/surface attracts the points relative to the refined cell size; if mesh is fine and this parameter is big it might attract too many points and give this weird effect.

I've had the a very similar problem some time ago, sorry I didn't recognise this sooner; the images you posted reminded me straight away.

Hopefully this will work,

A
CRI_CFD likes this.
Artur is offline   Reply With Quote

Old   May 13, 2014, 08:25
Smile
  #7
Member
 
Richardpluff
Join Date: May 2014
Posts: 95
Rep Power: 11
CRI_CFD is on a distinguished road
OK, I'll try!

Thanks for your fast reply!

Maybe I can make the nFeatureSnap higher. This was only a trial and error stage.
Artur likes this.
CRI_CFD is offline   Reply With Quote

Old   May 13, 2014, 10:28
Smile
  #8
Member
 
Richardpluff
Join Date: May 2014
Posts: 95
Rep Power: 11
CRI_CFD is on a distinguished road
Artur,

With tol=1.0 the checkMesh reports very little difference, just only in max non orth (from 46 to 48). I guess this means that snap to surface is a little bit improved, but this is not enough.

Do you think it could be a good idea to set this value below 1?
CRI_CFD is offline   Reply With Quote

Old   May 13, 2014, 10:31
Default
  #9
Senior Member
 
Artur's Avatar
 
Artur
Join Date: May 2013
Location: Southampton, UK
Posts: 372
Rep Power: 19
Artur will become famous soon enough
Can you post the last log from snappy, checkMesh and a screenshot as in the previous post? I've never used it below 1.0. It doesn't make much sense since you want the points to be attracted to the surface and with <1.0 you may not always get it to work... Doesn't mean you can't try
Artur is offline   Reply With Quote

Old   May 13, 2014, 11:10
Smile
  #10
Member
 
Richardpluff
Join Date: May 2014
Posts: 95
Rep Power: 11
CRI_CFD is on a distinguished road
I made a mistake. Just execute another case in the same directory and killed the log. Sorry.

I remember in most iterations appeared a warning (not new for my cases).It was something like:

Morph iteration 0
-----------------
Calculating patchDisplacement as distance to nearest surface point ...
--> FOAM Warning :
From function autoSnapDriver::calcNearestSurface(..)
in file autoHexMesh/autoHexMeshDriver/autoSnapDriver.C at line 916
For point:1 coordinate0.062 0.008125 0.031) did not find any surface within:6.25e-05 meter.

CheckMesh and snapshots are attached. at a first sight, it looks the same like the previous mesh, only a little change in max_non_orth (higher now). From my experience, the higher this value is the better the snap is done...
Maybe I can try to rise all quality parameters...but this leads to very bad quality meshes.

I am stuck on this...
Attached Images
File Type: jpg bad_snap_tol1.jpg (23.6 KB, 49 views)
Attached Files
File Type: gz checkLog.tar.gz (1.5 KB, 1 views)
CRI_CFD is offline   Reply With Quote

Old   May 13, 2014, 11:37
Default
  #11
Senior Member
 
Artur's Avatar
 
Artur
Join Date: May 2013
Location: Southampton, UK
Posts: 372
Rep Power: 19
Artur will become famous soon enough
This is the type of error you get when this parameter is too small - the snapper can't reach any points within the specified distance and so you end up with completely unsnapped mesh. I'd suggest giving it a go with something intermediate this time and see if it gets any better...
Artur is offline   Reply With Quote

Reply

Thread Tools Search this Thread
Search this Thread:

Advanced Search
Display Modes

Posting Rules
You may not post new threads
You may not post replies
You may not post attachments
You may not edit your posts

BB code is On
Smilies are On
[IMG] code is On
HTML code is Off
Trackbacks are Off
Pingbacks are On
Refbacks are On


Similar Threads
Thread Thread Starter Forum Replies Last Post
[General] Extracting ParaView Data into Python Arrays Jeffzda ParaView 30 November 6, 2023 22:00
Fluent UDF wrong number of cells in parallel - correct in serial dralexpe Fluent UDF and Scheme Programming 7 May 17, 2018 09:26
Neighboring cells in tetrahedral mesh vishwesh OpenFOAM Programming & Development 9 November 10, 2017 08:06
How to use "translation" in solidBodyMotionFunction in OpenFOAM rupesh_w OpenFOAM Running, Solving & CFD 5 August 16, 2016 05:27
Problems of Duns Codes! Martin J Main CFD Forum 8 August 15, 2003 00:19


All times are GMT -4. The time now is 12:11.