getting rid of some non-orthogonal cells
 

I'm currently trying to create a mesh for a complicated geometry. snappyHexMesh didn't work for me so far, because I couldn't manage to create a watertight geometry from CAD while still preserving single surfaces. This results in it not being able to determine the inside of the geometry.

cfMesh works much better here, and captures the geometry of the STL file, however I'm getting some low-quality cells close to the surfaces of the STL.

Here's the relevant checkMesh output:
Are there any options I might not know about in cfMesh that control the relaxation of such cells?

Is it possible to use the mesh from cfMesh as input for snappyHexMesh, and have it perform only the snapping stage (since it fails in the first stage for my STL file)?
I tried to enable only snapping in snappyHexMeshDict, but the resulting mesh was the same as the input mesh.

Also, what schemes are best when most of the cells are very much orthogonal, but some are highly non-orthogonal, like in this case?

Currently, there are are not any options to specify mesh quality criteria; they are hard-coded. In meshOptimizer.C you can find functions findBadFaces and findLowQualityFaces where you can play with the tolerances, and add/remove mesh checks. I am curious to find out whether you will get better results by playing with the quality tolerances. If so, it is not a problem to enable those settings in meshDict.

I have never tried to use the mesh from cfMesh as a starting mesh for snappy. The snapping stage shall not change the mesh because it is already constrained to the input geometry. What is the difference after the smoothing stage?

Non-orthogonality and skewness do not cause problems in regions where the solution is fairly uniform. You can also use the limited scheme, which ensures that the contribution from the non-orthogonal part does not exceed the contribution from the orthogonal part. Skewness could cause any you convergence problems if you use skew corrected schemes. The best way to resolve your dilemma is to try various schemes, and check which one works best for your particular problem.

I haven't done any further tests yet, as I'm currently running a fairly coarse mesh for my problem with ~500k cells, which already takes long enough on a single machine...I hope I can get access to better machines in the near future :D

Unfortunately my problems contain very large gradients in temperature and in pressure which can/will be present in most of the mesh, so mesh errors can result in a rather large error for me.

First of all thank you Franjo for this amazing tool. It seems it is going to replace snappyHexMesh in my daily job...

Your tool preserves the shape of the stl geometry in an amazing manner, I have not seen something similar in GNU software using hexaedral dominant meshes so congratulations for this.

I have some questions I would like to ask:

1. As Chriss85 said, I obtain some non orthogonal faces, but I guess they are needed in order to preserve the features. I am meshing very complex geometries and at some point you have to choose: preserve geometry features or obtain a very orthogonal mesh. Both things at the same time looks quite difficult. This is only a guess. What do you thing based on your experience? In this sense, I thing that nonOrthogonalCorrectors could help with the accuraccy of that kind of meshes (but simulation will become slow)

2. When cell size is bigger than it should be, I have found some undesired holes in the geometry. How can I prevent this? It seems to happen in places where thickness between parts is very small (for example an strecthed cylinder with an elongation in the middle)

3. I started using cfMesh because I cannot create a full wall layer coverage near walls. snappy always collapse it in some place, no matter the featureAngle you use (at less in my trials). I tried to get it using cfMesh and results are going better, but sometimes layers collapse or first layer height varies with consequent variation of yplus values for turbulent simulations. I attach a couple of images and my dictionary for one of my geometries. How can I avoid this problem? Is t possible to get full layer coverage in complex geometries using cfMesh?

In summary, I can mesh my geometry preserving all the features (when cell count is enough), but I'll continue fighting with layers for turbulent simulations. Any help will be really much aprecciated.

Thanks everyone and congratulations again for contributing with such an amazing tool like cfmesh to the open source community.

Regards,

Tensi

Hi Tensi,

Thank you for kind review. There are a few things you can try to solve your problems, and you can find them below.

Well, there are three conflicting constraints here: 1. Mesh quality, 2. preserving of geometry and 3. is the number of cells in the mesh. The problems with mesh quality decrease as the number of cells increases, and it is also much easier to preserve the details of the geometry. Sometimes a small change in maxCellSize has have a hugely beneficial effect on mesh quality because it help the mesher capture the geometry better. The current methodology does not guarantee the best possible selection of patches for boundary cells, and you therefore have to play with the cell size and template alignment to get the mesh you want. I surely want to improve this in the future.

There are options available to solve this problem:
1. Use keepCellsIntersectingBoundary - by default, the mesher uses only the cells that are completely inside the boundary. By using this option, it also uses the cells intersected by the geometry, and this helps in thin regions. This is global option applied everywhere in the mesh. By looking at the geometry posted here, it seems to me that this options could solve your problems.
2. keepCellsIntersectingPatches - you can specify the patches/subsets where you want to use the intersected cells, too.

There is more on how to use these options in the manual.

The layers are NEVER collapsed in cfMesh, they extend as long as they need to exit out at the boundary. There are a few rules here: 1. Layers can only exit the domain at convex feature edges. 4. Corners with valence greater than 3 enforce creation of a single layer over all patches connected via the corner. What I see in the figure is a layer near the artificial holes generated due to insufficient resolution, and the layer is available at every boundary face. Therefore, the layer will improve once the problem with the holes is resolved.
Regarding the boundary layer thickness, please avoid doing local refinement where you want the layer thickness to be as constant as possible. We plan to release new features improving the boundary layer quality with the next release.

I hope this helps you get further with your meshing.

Regards,

Franjo

Hi Franjo,

I still have some problems regarding layer addition and mesh quality. I have a quite complex geometry, but I am sure with the right setting cfMesh could do a good job here...

Could you please have a look at my geometry and my meshDict settings?
This is for my Phd thesis and I should not redistribute it,but it is clear I need some help...

If you agree I can send it to you via email...

Regards,

Tensian

Holes in the mesh
 

Hi Tensian,

I cannot see anything wrong the in meshDict. The holes in the figures are a consequence of insufficient mesh resolution, and the mesher cannot put a single cell there.
Yes, feel free to send me an e-mail or PM.

Regards,

Franjo

Hello together,

in general I think that cfMesh can become a very good meshing tool. But until now I am facing some mesh quality issues in my complex geometries with a lot of steps, curvatures and interior mixing elements. I always find the bad quality near by those steps where the fine mesh from the wall is starting to pass over to the coarser mesh in the bulk flow.

Especially the face tet errors are an issue for me, because I would like to use lagrangian models.

A compressible gas flow worked also the mesh quality was bad see checkMesh -allGeometry output below:

Are there any tricks to increase the mesh quality especially to get rid of the face tet errors?

Kind regards
Chrisi

Hi,

What happens if you use refinementThickness or boundaryCellSizeRefinementThickness options to refine the mesh away from the boundary, too? These options move the transition region away from the boundary, and could make life simpler for the optimization procedure.

What is the number of bad faces in the log of cartesianMesh? You could play with the checks you need to get what you want by implementing a check for face tets in polyMeshGenChecks::findBadFaces function. I am interested if that can solve your problem.

Regards,

Franjo

Hello Franjo,

thanks for your hints!

I tried to increase the refinement thickness, but it did not improve the quality significantly.

During cartesian Meshing I am facing a lot of warnings like that:

Can you please give me an instruction how to implement a check for face tets in polyMeshGenChecks::findBadFaces function?

Thanks in advance for your support!

Kind regards
Chrisi

Hi,

These warning means that there exist some bad quality faces during the meshing process, and it usually reduces with every iteration. The warning is there to show the user that there may be some problems if the number does not drop down to zero.

The code in the findBadFaces function looks like this:

label findBadFaces( constpolyMeshGen&mesh, labelHashSet&badFaces, constboolreport, constboolList*activeFacePtr )
{
badFaces.clear();
polyMeshGenChecks::checkFacePyramids ( mesh, report, VSMALL, &badFaces, activeFacePtr );
polyMeshGenChecks::checkFaceFlatness ( mesh, report, 0.8, &badFaces, activeFacePtr );
polyMeshGenChecks::checkCellPartTetrahedra ( mesh, report, VSMALL, &badFaces, activeFacePtr );
polyMeshGenChecks::checkFaceAreas ( mesh, report, VSMALL, &badFaces, activeFacePtr );
const label nBadFaces = returnReduce(badFaces.size(),sumOp<label>());
return nBadFaces;
}

The check for face tets does not exist yet, and you have to implement it in polyMeshGenChecks and use in the findBadFaces function.

Regards,

Franjo

Hello Franjo,

thanks for your hint.

In the meanwhile I checked your code. And I think the code snipet
in findBadFaces already dose the job to check fo faceTet errors. Because the faceTet error occurs if tetQuality<1-15. And the tetQuality is checked with the function checkCellPartTetrahedra. Am I right?

Kind regards
Chrisi

Hi,

Yes, it is true. The mesher reports bad faces as long as it can find any tetrahedra with negative volumes. However, the problem may come back if the mesh is saved on disk in ascii format, unless you set the precision to 15 or more. I always use binary because it guarantees that the point coordinates are the same as they were when the checks were performed. The loss of precision causes poor quality mesh for very thin boundary layers and in cases when the volumes of cells are close to the precision tolerance.
I hope this helps a bit.

Regards,

Franjo

Hello Franjo,

I tried your tip and created the mesh in binary format. But it did not change anything.

Kind regards
Chrisi

Hello Crissi,

I guess that we are have focused on the wrong check. I am interested in trying out the following:
1. Finding out locations that initiate convergence problems. What types of cells are present there?
2. Checkout task-qualityControls from the repository and try to play with quality controls to find out the necessary quality criteria for your simulations. An example of the dictionary for quality controls is:
meshQualitySettings
{
maxNonOrthogonality 65.0;

maxSkewness 2.0;

fcUniform 0.1;

volUniform 0.1;

maxAngle 10;

minTetQuality 0.001;

minFaceTwist 0.1;

minCellDeterminant 1e-15;

minVolRatio 0.1;

minFaceTriangleTwist 0.1;

minPyramidVolume 1e-15;

minimumFaceArea 1e-15;

faceFlatness 0.001;

minCellPartTetrahedra 1e-15;
}

Let me know if you can find quality criteria that solve your problem.
I wish you a happy 2016.

Regards,

Franjo

Hi Franjo,

thanks for your answer!

I am using the following easy test case:
https://www.dropbox.com/s/1rvsatwi7b...ng.tar.gz?dl=0

The simulation with simpleFoam is going fine with the mesh resulting with cfMeshing.

Anyhow due to the "FaceTet" errors it is not possible to do lagrangian particle tracking with the mesh. As long as one parcel reaches a broken face tet the simulation crashs.

So my goal is to generate a mesh without "FaceTet" error to enable the option for reliable partickle tracking (without significant increase in number of cells).

Currently the "FaceTet" errors are at the corners of the buildings inside the boundary layer cells.
The cells there are doing some kind of zigzag there. (see pictures)

Maybe you have a good idea how to overcome that problem with cfMesh.

Kind regards and thanks in advance
Chrisi

Small Determinant Issue!!
 

Hi all. I am new to Openfoam. I have a question regarding mesh conversion. Few cells are shown as underdeterminedcells, oneinternalfacecells and twointernalfacescells. Does these affect the convergence? If so, what steps to be taken to avoid?

What are the important factors should be considered inorder to prepare the mesh for solving?
----------------------------------------------------------------------------------------------------------------
Create time

--> FOAM Warning :
From function checkMesh
in file db/Time/timeSelector.C at line 262
No time specified or available, selecting 'constant'
Create polyMesh for time = constant

Enabling all (cell, face, edge, point) topology checks.

Enabling all geometry checks.

Time = constant

Mesh stats
points: 359617
faces: 3779338
internal faces: 3595206
cells: 1843636
faces per cell: 4
boundary patches: 7
point zones: 0
face zones: 1
cell zones: 1

Overall number of cells of each type:
hexahedra: 0
prisms: 0
wedges: 0
pyramids: 0
tet wedges: 0
tetrahedra: 1843636
polyhedra: 0

Checking topology...
Boundary definition OK.
Cell to face addressing OK.
Point usage OK.
Upper triangular ordering OK.
Face vertices OK.
Topological cell zip-up check OK.
Face-face connectivity OK.
<<Writing 1 cells with zero or one non-boundary face to set oneInternalFaceCells
<<Writing 1516 cells with two non-boundary faces to set twoInternalFacesCells
Number of regions: 1 (OK).

Checking patch topology for multiply connected surfaces...
Patch Faces Points Surface topology Bounding box
CP 159518 81869 ok (non-closed singly connected) (-2.30979 -3.022 -0.132) (1.8 1.87533 0.603)
OUTFLOW 2121 1163 ok (non-closed singly connected) (1.8 -3.022 -0.132) (1.8 -1.022 0.603)
SP_INFLOW 5637 3180 ok (non-closed singly connected) (-1.135 -1.13497 0) (1.135 1.135 0.203)
CP_ROTWALL 7219 3917 ok (non-closed singly connected) (-1.135 -1.13481 0.203) (1.135 1.13491 0.3685)
BP_ROTWALL 5819 3084 ok (non-closed singly connected) (-1.135 -1.13494 -0.132) (1.135 1.13488 0)
CP_1 852 852 ok (non-closed singly connected) (-0.807087 -0.806937 0.49) (0.807087 0.806998 0.494288)
CP_2 2966 2946 ok (non-closed singly connected) (-0.7095 -0.709496 0.423) (0.7095 0.709474 0.423)

Checking geometry...
Overall domain bounding box (-2.30979 -3.022 -0.132) (1.8 1.87533 0.603)
Mesh (non-empty, non-wedge) directions (1 1 1)
Mesh (non-empty) directions (1 1 1)
Boundary openness (4.52524e-16 1.40479e-17 -2.41232e-16) OK.
Max cell openness = 3.00648e-16 OK.
Max aspect ratio = 4.44302 OK.
Minimum face area = 1.04445e-06. Maximum face area = 0.00714492. Face area magnitudes OK.
Min volume = 5.13633e-10. Max volume = 0.000224605. Total volume = 9.51851. Cell volumes OK.
Mesh non-orthogonality Max: 51.9268 average: 15.4992
Non-orthogonality check OK.
Face pyramids OK.
Max skewness = 0.580947 OK.
Coupled point location match (average 0) OK.
Face tets OK.
Min/max edge length = 0.00130362 0.15313 OK.
All angles in faces OK.
All face flatness OK.
Cell determinant (wellposedness) : minimum: 0 average: 1.54426
***Cells with small determinant (< 0.001) found, number of cells: 1517
<<Writing 1517 under-determined cells to set underdeterminedCells
Concave cell check OK.
Face interpolation weight : minimum: 0.182167 average: 0.440596
Face interpolation weight check OK.
Face volume ratio : minimum: 0.222744 average: 0.800779
Face volume ratio check OK.

Failed 1 mesh checks.
-----