[nope]

Hello everyone

I'm using cartesianMesh and having mixed feelings about it. I do like the simplicity and performance very much. However there are some show stoppers to efficiently use and rely on it. First i would like to mention, with complex geometries, the mesh on the boundary has to be very (emphasis on very) fine. This results in rather large meshes compared to snappyhexmesh or other (also commercial) tools. Otherwise there are bad faces/cells.


More importantly with certain mesh settings (refinement values) i get the error mentioned in the title. The output looks as following (attached picture).

cfmesh_neg_size.PNG

The mesh is with around 100Mio cells rather large. It is kind of annoying to find settings where the error doesn't occure. I'm not using distributed memory and i'm having 60 cores and 200GB RAM. Sometimes it does work without error.

Has anyone experienced something simmilar and what could be the reason? I would like to get rid of this behaviour so I can focus on the mesh itself.

Thank you, regards
nope


Edit:
For the interested people, i changed a few things and the above mentioned error hasn't occured again yet. Unfortunately I can't tell what was the reason because the following changes were made alltogether... I know.
- Repaired geometry, there was a not so nice surface
- Updated to OF v1906
- Compiled OF with 64bit label size

Creating a good mesh with a reasonable cell size at the boundary is still a challenge. The workflow is basically starting with a "large" cellsize (around 0.0005m) and make it smaller until the meshing is successfully. Any best practice hints are welcome.

[Krao]

Hi nope,

I was looking at de-featuring the geometry as we have discussed on the other thread genetation of mesh for very thin airfoil propellers, and found this pdf http://www.arek.pajak.info.pl/wp-con...flow_cadOF.pdf. I hope the procedure mentioned here is useful for everyone regardless of the geometry and the meshing tools they are using.

Krao

[nope]

Hi Krao

Thank you for sharing.

The particular error mentioned in my first post got away with 64bit labels. Even though 32bit labels are enough for the finished mesh, it seems some intermediate state results in a overflow.

Cheers, nope

[user007]

Originally Posted by nope

Hi Krao

Thank you for sharing.

The particular error mentioned in my first post got away with 64bit labels. Even though 32bit labels are enough for the finished mesh, it seems some intermediate state results in a overflow.

Cheers, nope

I'm facing the same problem but with pMesh and tetMesh under Windows 10. When I use the cartesianMesh everithing is fine.
What does it means compile with 64 label instead of 32? I suppose you are referign to the Unix enviroment...

[nope]

Hi user007... i guess

I'm using OpenFOAM v1812/v1906 which has cfMesh included. In the etc/bashrc file in the OpenFOAM directory you can set the size of the labels in bits, either 32 or 64. This influences the max. integer number OpenFOAM can use. If your mesh is too big, it can happen that a integer number which exceeds this max. number occurs. Then you can switch to 64 and recompile OpenFOAM.

If your Mesh is not particularly big (>>100Mio. cells), then i guess something else is wrong and this is not the solution for your problem. Your geometry (stl or whatever) could be bad and not closed or in the wrong units.

Cheers, nope

[user007]

Originally Posted by nope

Hi user007... i guess

I'm using OpenFOAM v1812/v1906 which has cfMesh included. In the etc/bashrc file in the OpenFOAM directory you can set the size of the labels in bits, either 32 or 64. This influences the max. integer number OpenFOAM can use. If your mesh is too big, it can happen that a integer number which exceeds this max. number occurs. Then you can switch to 64 and recompile OpenFOAM.

If your Mesh is not particularly big (>>100Mio. cells), then i guess something else is wrong and this is not the solution for your problem. Your geometry (stl or whatever) could be bad and not closed or in the wrong units.

Cheers, nope

recompiled with 64 bit labels solved the problem, however now either the mesh fails for too low quality, or I end up running out of ram during meshing if I try to reduce the elements size...
There is no way to assign max and min size to surfaces in order to get refinement just where quality is too low insted of a fixed target size/refinement level only?