[Tensian]

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.

[Artur]

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

[CRI_CFD]

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...

[Artur]

Originally Posted by CRI_CFD

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]

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.

[Artur]

Can you give it a quick go with changing

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]

OK, I'll try!

Thanks for your fast reply!

Maybe I can make the nFeatureSnap higher. This was only a trial and error stage.

[CRI_CFD]

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?

[Artur]

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

[CRI_CFD]

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...

[Artur]

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...