snappyHexMesh: problem meshing baffle (surface with zero thickness)
 

Hi,

I am trying to use snappyHexMesh to mesh a thin wall/baffle. The aim is to model a sail on a small sailing boat (i.e I want the sail to be zero thickness). I have some problem at the edge of the mesh generated by snappyHexMesh - it does not snap to the edges.

I have replicated the problem with a simple 1x1 square STL surface. It is titled to be not aligned with the mesh in order to reproduce the problem (see attached picture).

I have a nagging feeling that the issue is with the eMesh file (generated by surfaceFeatureExtract). When surfaceFeatureExtract is used without specifying an includedAngle, it reports the following error message (my concern is highlighted in bold as the surface is definitively not a closed manifold). It works as soon as includedAngle is specified:

Feature line extraction is only valid on closed manifold surfaces.
Surface : "constant\triSurface\Volume_0.stl"
Output feature set : "test"

Statistics:
Triangles : 2
Vertices : 4
Bounding Box : (-0.696364 -0.603069 -0.348182) (0.696364 0.603069 0.348182)

--> FOAM FATAL ERROR:
No initial feature set. Provide either one of -set (to read existing set)
or -includedAngle (to new set construct from angle)

From function surfaceFeatureExtract
in file surfaceFeatureExtract.C at line 253.

FOAM exiting

Also attached are:
- snappyHexMeshDict;
- blockMeshDict (in case it is relevant).

I use blueCFD (Windows port of openFoam). I tried v2.0 and v2.1 without success.

Also I am trying to use "surfaceFeatureConvert" but get the following problem (emesh file attached):

--> FOAM FATAL IO ERROR:
Expected a '(' while reading VectorSpace<Form, Cmpt, nCmpt>, found on line 25 an
error

file: constant\triSurface\Volume_0.eMesh at line 25.

From function Istream::readBegin(const char*)
in file db/IOstreams/IOstreams/Istream.C at line 94.

FOAM exiting

Any help/tips will be very appreciated.

Kind regards,
Julien

Hi Julien,

About the conversion: apparently it's a bug in OpenFOAM, because I just tested this on Linux and it gave me the same error when converting eMesh to obj. The problem is that the converter isn't handling properly the eMesh file in binary format.

Attached are the two scenarios ascii vs binary, but both give badly formed meshes, so it's not a strict eMesh. This conversion bug should be reported in the bug tracker: http://www.openfoam.org/mantisbt/my_view_page.php - if you want, I can report this.


The reason for the bad mesh around the shape seems to be a visibility issue provided by the base mesh.
Sometime ago I had a very similar problem, but it was with meshing inside very thin walls. A solution was to do the meshing process in two steps, so that certain cells would not be discarded: http://www.openfoam.org/mantisbt/view.php?id=295
I haven't tested the two stage mesh generation... I can test this later today.

Another bug report that might be useful: http://www.openfoam.org/mantisbt/view.php?id=518

Best regards,
Bruno

OK, after looking a bit further into this, here's what I can figure out:

• Two stages for mesh generation didn't help. The trick should be to have a better base mesh.
• Another trick might be to have an extruded shape first for snappy to adjust the mesh and then on another stage do the real mesh.
• modifyMesh could help, since it has some features for mesh manipulation, but I haven't had time to experiment with it. For example, it might be possible to insert by force the edges of the eMesh feature lines onto the base mesh.
• Modeling sails with OpenFOAM has already been done in the past: http://www.cfd-online.com/Forums/ope...tml#post282649
  But it didn't look like they used snappy...

Hi Bruno,

Thanks for looking into it for me. I had a long hard look at the problem today and I am still stuck... I tried to do a 3 step snappyHexMesh process:

- SHM step 1: Refine the mesh at the edges (eMesh file);
- SHM step 2: Casttelate;
- SHM step 3: Snap.

Did not really improve the problem (the jaggering was a little less as edges were refined at level 2). I noted a few strange things in step 1:

1) The initial eMesh has an entry:

// edges:
4((0 1) (1 2) (2 3) (3 0))

With this entry, there was no refinement at step 1. I had to manually edit it and change to:

// edges:
3((0 1) (1 2) (2 3))
1((3 0))

This seems very similar to the issue notified in http://www.cfd-online.com/Forums/ope...ain-edges.html

2) The final mesh is refined on three out of four edges.

I also tried refining the initial block mesh (x 3 in all direction) - did not improve. My problem looks awfully similar to http://www.cfd-online.com/Forums/ope...t-surface.html.

Let me know if you get any idea.

Hi Julien,

Well, I've got several ideas, but haven't managed to implement any of them. My head isn't agreeing with the idea of wanting to work today...

I did manage to do a little test if the old snapEdge utility would help, but it didn't do anything at first try, so I gave up on it. You should be able to build it directly with blueCFD in an MSys terminal.

The ideas are:

1. The simplest one - but it might not work with curved sails:
   1. Generate a bigger boundary box with blockMesh.
   2. Rotate the mesh to align with the surface to be meshed.
   3. Create an STL file with the real bounding box.
   4. Now use snappyHexMesh to mesh around the desired surface, along with the real STL bounding box.
2. Generate a displacement field - the idea here is to use deformedGeom or a modified version of it, to adjust the cells that can see the surface edges and snap them directly. This would be done either directly in blockMesh or after a first pass of refinement on the desired area.
3. Generate a multi-zone mesh and merge the zones back into a single mesh. This uses the meshing process used for chtMultiRegion*Foam solvers, such as described here: http://www.cfd-online.com/Forums/ope...omain-cht.html
   The idea would be:
   1. Generate and use an extruded box of the surface in question, and generate a mesh (block+snappy) that includes both the inside and outside of the box.
   2. Then merge the two zones back into a single mesh.
   3. Then use that mesh as a base for the real mesh generation around the desired surface.
4. Last but not least, modify snappyHexMesh to allow dummy snap-able geometries that only affected the mesh, but did not result in patches/walls.

I started to do #3, but my head went "ITS SUNDAY" and went home...

By the way, I've already reported the bug about converting the binary eMesh to obj: http://www.openfoam.org/mantisbt/view.php?id=541

Best regards,
Bruno

Hi Bruno,

Thanks a lot for the inputs. I hoped for a quick fix. I will move on to other problems for the moment. If you find a solution, I would love to hear but do not get out of your way for it.

Thanks again.
Julien

Hi Julien,

FYI: http://www.cfd-online.com/Forums/ope...tml#post366242
It looks like I'll have to check if your model is working with the latest 2.1.x :) I'll try looking at it this weekend.

Best regards,
Bruno

Hi Julien,

Well, after compiling the latest 2.1.x, ran both the ASCII and binary cases and:

• Conversion now does work with the binary eMesh.
• But snappy still can't handle the surface the way we want it to, at least with the dictionary attached on these cases.

I haven't tested yet that idea of disabling all quality controls and then turn on one by one...


Best regards,
Bruno