[kalle]

Dear all,

For some time I have been working on making blockMesh body fit capable. I hoped initially that algebraic placement of the block interior points would work out, but as literature also suggests; point's positions are best described by solving PDE's. I have followed the method suggested in Chapter 4 of:

Joe F. Thompson (Editor), Bharat K. Soni (Editor), Nigel P. Weatherill (Editor)
Handbook of Grid Generation, 1999

http://ebrary.free.fr/Mesh%20Generat...neration,1999/

Solving the Poisson grid equations numerically means solving a linear system of algebraic equations. This type of elliptic problems are best solved by a multigrid solver. I am using

http://www10.informatik.uni-erlangen.de/~preclik/amgpp/

for that. It turns out however that this is very slow for anything except test cases. I do not know why it is slow - maybe I am setting it up incorrectly? This I will look into as soon as I find time (may be several months from now). I would like to make use of OpenFOAM's GAMG instead. If someone knows how to do this straight off, please contact me!

Installing:

1. Clone from my repo: "git clone https://github.com/nogenmyr/blockMeshBodyFit" into your preferred directory.
2. Source OpenFOAM 2.1 or 2.2
3. "wmake libso" in the install directory.
4. Edit your /applications/utilities/mesh/generation/blockMesh/Make/options file:

EXE_INC = \ 
     -I$(LIB_SRC)/mesh/blockMesh/lnInclude \ 
     -I$(LIB_SRC)/meshTools/lnInclude \ 
     -I$(LIB_SRC)/dynamicMesh/lnInclude \ 
     -I$(LIB_SRC)/mesh/blockMesh/amgpp-0.1.2.1/include \ 
     -I$(LIB_SRC)/triSurface/lnInclude  
  
 EXE_LIBS = \ 
     -lblockMesh \ 
     -lmeshTools \ 
     -ldynamicMesh \ 
     -ltriSurface

... where LIB_SRC should point to where you put the downloaded code

5. "wmake" the blockMesh application

Usage:
The user should now specify which block faces he/she wants to project. A block's face is identified by the four vertices defining the face. (See example case attached.)

For this, blockMeshDict has some new entries:

searchLength 10;  // The search length to find a projection point on a surface

snapFaces
{
    test.stl
    {
        faces
        (
        (11 8 9 10)
        (8 12 13 9)
        (12 8 11 15)
        (9 13 14 10)
        (10 14 15 11)
        (12 15 14 13)
        );
    }
};

Note the use of curly brackets!

Forgot to add: You need to disable floating point exception tracking before running the new blockMesh. Just do "unset FOAM_SIGFPE" - else it will crash in the amgSolver.

Have fun! Kalle

[startingWithCFD]

Hello! I tried to use your tool with your example and

blockMesh > output.txt 2> error.txt

and I got a segmentation fault.

I think I followed the instructions carefully, including the "unset FOAM_SIGFPE" command. My OF version is 2.1.x. Any ideas what is wrong?

[kalle]

Hmm... can't point out exactly what is going wrong here. From the error log it looks like it is crashing while parsing the blockMeshDict. The point in the code where it crashes is somewhere in lines 45 -289 in blockMeshTopology.C.

Did both the library and blockMesh compile well?
You try this on the test case I provided?



p.s. You do not have to mess up your standard OF installation by using this. You can place the downloaded code anywhere, and you can make a copy of the blockMesh-app's directory, and compile the new blockMesh to some other name - then you can use standard blockMesh along with blockMeshBodyFit (or whichever name you prefer) Just make sure that the Make/options file gives the compiler access to the right libraries. d.s.

[onyir]

Hi kalle,

I've tried your application and it's quite impressive. Good job!!
I'm still doing some tests, but it looks promising. If you manage to use OpenFOAM GAMG and improve speed taht wolud be perfect.

[dkokron]

Kalle,

Thank you for your contribution.

Do you see an easy way to performance the reverse operation, keeping the mesh between the outer edge of the bounding box and the shape (sphere in your example)? To put it another way, would it be easy to add the locationInMesh feature of snappHexMesh.

Dan

[kalle]

Hi Dan,

Short answer is no. Block structured meshing is a fundamentally different approach to mesh creation as compared to sHM.

Kalle

[kalle]

So, I finally got some time to implement another multigrid solver. Now the code is using AMGCL which seems very powerful. I have cleaned up the installation process. Really sorry for the terrible setup from before. Now there is a lib and app directory. wmake them both and you have solver called blockMeshBodyFit in your USER_APP directory. The test case is now also provided via github (https://github.com/nogenmyr/blockMeshBodyFit)!

Regards,
Kalle

[kalle]

A screenshot of the provided test case...

[kalle]

And some info on how to specify block faces that should be projected onto a surface. Except all the entries of a regular blockMeshDict, you need this entry, using the tag "snapFaces":

snapFaces
{
test.stl
{
faces
(
(11 8 9 10)
(8 12 13 9)
(12 8 11 15)
(9 13 14 10)
(10 14 15 11)
(12 15 14 13)
);
}
};

For each surface, here test.stl, you simply specify all the block faces that should snap, or project, onto the surface. This can be both boundary faces, but also internal faces in your block structure. You can add as many surfaces as you like.

If you specify an edge, i.e. polyLine etc, that will be respected. Else, edges that are adjacent to a projected face will also be projected. This is happening in the test case. Note that the test case is a sphere, while above I took a screen shot of half the mesh to show how interior points are distributed.

Further, you need to specify how far in space a block face point should look for finding a surface to project on:

searchLength 10;

So far there is no support for this in the Blender utility SwiftBlock.

Regards,
Kalle

[kalle]

So, there were some problems with the AMG solver. This was fixed upstream. I have added that to my code now. It makes the Poisson solver much faster, and also allows me to find out when the grid has converged. I can then stop the iterations at that point. All this should make the code much faster.

Regards,
Kalle

[kalle]

Some hints on meshing:

First a block's face is calculated like in standard blockMesh. If the face should snap to a surface, then a normal is calculated for each face vertex. For each vertex blockMeshBodyFit tries to find the specified surface along that normal. It searches the distance given by "searchLength". It looks in both directions. If there is a hit, the face vertex is moved to the "hit point". Sometimes this hit point may not be where you liked it to be. To get around such problems you can divide your stl geometry in many parts. In the extreme, a separate file for each block face. Often, it may be enough to have a separate stl for each patch you have defined.

K

[GerhardHolzinger]

FYI: blockMeshBodyFit compiles with OpenFOAM-2.4.x, OpenFOAM-3.0.1 and OpenFOAM-4.0

I am looking forward to putting it to use.

Thanks for this utility.

[shaileshbg]

Hello Kalle,

I downloaded the files from github, installed boost library and ran wmake successfully in lib directory. But when I ran wmake in app directory I am getting this error log:

g++ -std=c++11 -m64 -Dlinux64 -DWM_ARCH_OPTION=64 -DWM_DP -DWM_LABEL_SIZE=32 -Wall -Wextra -Wold-style-cast -Wnon-virtual-dtor -Wno-unused-parameter -Wno-invalid-offsetof -O3  -DNoRepository -ftemplate-depth-100 -I../lib/lnInclude -I/opt/openfoam5/src/meshTools/lnInclude -I/opt/openfoam5/src/dynamicMesh/lnInclude -I/opt/openfoam5/src/triSurface/lnInclude  -IlnInclude -I. -I/opt/openfoam5/src/OpenFOAM/lnInclude -I/opt/openfoam5/src/OSspecific/POSIX/lnInclude   -fPIC -c blockMeshApp.C -o Make/linux64GccDPInt32Opt/blockMeshApp.o
blockMeshApp.C: In function ‘int main(int, char**)’:
blockMeshApp.C:135:21: error: ‘class Foam::IOobject’ has no member named ‘headerOk’
     if (!meshDictIO.headerOk())
                     ^
/opt/openfoam5/wmake/rules/General/transform:25: recipe for target 'Make/linux64GccDPInt32Opt/blockMeshApp.o' failed
make: *** [Make/linux64GccDPInt32Opt/blockMeshApp.o] Error 1

Could you please look into the issue and let me know on how to proceed.

[kalle]

Seems you are compiling using OF5. I have only been using this with OF2.3. If you have an installation of that version, you may compile and mesh there, then use the mesh with OF5. Sorry for the inconvenience.

You may also try to resolve the compilation errors, but there may be more errors than the one you've seen so far.

[shaileshbg]

Hi Kalle,

Thank you for your quick reply. I installed openFoam 4.0 and was able to run the test case.

I have one doubt though, my geometry is a hemisphere. I assume that I have to create an stl file in blender and then use swiftBlock to generate the blockMeshDict file, the problem is I know neither of the tools. Is there a simpler way to achieve this (maybe edit the sphere configuration in the test case to consider a hemisphere?)

I have worked with snappyHexMesh to create an unstructured mesh, but I require a structured mesh for my simulation.

[shaileshbg]

Hi Kalle,

I managed to get my block structure created in Blender and defined my edge too. I also defined my hemisphere in a different stl file (checked both the files in paraview)

blockMeshBodyFit is running properly but I do not know how to specify the block faces that are to snap- snapFaces

I searched for any post on forum, any tutorial or video, swiftBlock wiki for some hints on how to specify block faces, but I couldn't find any. Could you please guide me on how to define snapFaces.
This is the link to my case file:
https://www.dropbox.com/s/1i4nqssmge..._case.zip?dl=0

I would be grateful for any help and guidance from your side, looking forward to hearing back from you.

[kalle]

Hi!

SwiftBlock has no support for the extra features present in this bodyfit-blockmesh.... but the things you need to add to blockMeshDict is not that complicated. You need to specify the stl-surface to snap to, and which block-faces that should snap to that surface. Have a look at the example case for blockMeshBodyFit and you'll see what I mean!

Kalle