CFD Online Discussion Forums

CFD Online Discussion Forums (http://www.cfd-online.com/Forums/)
-   OpenFOAM Announcements from Other Sources (http://www.cfd-online.com/Forums/openfoam-news-announcements-other/)
-   -   Body-fit capable blockMesh (http://www.cfd-online.com/Forums/openfoam-news-announcements-other/119767-body-fit-capable-blockmesh.html)

kalle June 24, 2013 15:39

Body-fit capable blockMesh
 
1 Attachment(s)
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:
Code:

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:

Code:

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 June 25, 2013 04:42

2 Attachment(s)
Hello! I tried to use your tool with your example and
Code:

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 June 25, 2013 15:59

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 June 26, 2013 03:50

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 November 16, 2013 23:24

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 November 18, 2013 03:26

Hi Dan,

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

Kalle

kalle December 11, 2014 08:10

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 December 11, 2014 08:26

1 Attachment(s)
A screenshot of the provided test case...

kalle December 12, 2014 03:31

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 December 14, 2014 04:30

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 December 15, 2014 06:30

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 July 27, 2016 05:18

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.


All times are GMT -4. The time now is 05:46.