CFD Online Discussion Forums

CFD Online Discussion Forums (http://www.cfd-online.com/Forums/)
-   OpenFOAM Native Meshers: blockMesh (http://www.cfd-online.com/Forums/openfoam-meshing-blockmesh/)
-   -   Automated transitions in blockMesh? (http://www.cfd-online.com/Forums/openfoam-meshing-blockmesh/96033-automated-transitions-blockmesh.html)

the.drizzle January 10, 2012 17:51

Automated transitions in blockMesh? [SOLVED]
 
1 Attachment(s)
Hiya!

Owing to the limited memory on this machine, I am being forced to use more elegant meshing techniques than what I would like to do. Probably a good thing in the long run, but for now a bit of a pain.

What I'm wondering for the moment is if there is a way of automatically defining some sort of transition from a fine mesh to a coarse one that allows one to build a transition region that is then compatible with snappyHexMesh? The attached image illustrates (in a very invalid way, I know) roughly what I am trying to go from and to.

I can see how to do this manually, but I'm thinking that this must be a feature somewhere...

mturcios777 January 10, 2012 20:30

Quote:

Originally Posted by the.drizzle (Post 338715)
Hiya!

Owing to the limited memory on this machine, I am being forced to use more elegant meshing techniques than what I would like to do. Probably a good thing in the long run, but for now a bit of a pain.

What I'm wondering for the moment is if there is a way of automatically defining some sort of transition from a fine mesh to a coarse one that allows one to build a transition region that is then compatible with snappyHexMesh? The attached image illustrates (in a very invalid way, I know) roughly what I am trying to go from and to.

I can see how to do this manually, but I'm thinking that this must be a feature somewhere...

I don't know about fully automatic. Off the top of my thick skull, I would try writing a script (in your favorite scripting language) that would create a series of adjacent refinement boxes with gradually increasing (or decreasing) refinement levels, then copy and paste the result into your snappyHexMeshDict. Unless I am misreading what you want to do (which is entirely possible).

the.drizzle January 10, 2012 20:37

Nah, not misreading it at all, but that's (more or less) the process I'm trying to avoid if at all possible. In other words, what you have described is what I would call a manual refinement.

mturcios777 January 10, 2012 20:46

There might be something in pyFoam, but what is pyFoam other than a scripting language wrapped around a programming language (its the "Inception" of CFD programs [not sure if you are familiar with that film]). You could make it so that at least you can set the number of regions and extent as input parameters. Almost makes me want to do it myself. ALMOST.

That said, save any scripts you make for the future. Every now and again I find myself wishing I hadn't thrown away a snippet of code/script/utility because I thought I would "never use it again". Now I keep a sort of "junk drawer" full of that kind of stuff that at best gives me exactly what I need, and at the very least inspires my though process.

the.drizzle January 13, 2012 00:45

mergePatchPairs is the key! Except it doesn't seem to deal with corners very well...

I've attached an un-commented version of my my blockMeshDict file so you can see what I'm talking about. Basically, if I comment out some of the patch pairs in such a manner that no merging is happening on adjacent faces, it works fine. The end result is useless of course, but the fact remains that the merging works.

So, what I'm wondering at this point is if there is something I can do to get faces to merge around corners like I'm trying to do here? I'm thinking I'm probably going to have to take a different strategy altogether, but we'll see...

Thanks in advance for any help!

Code:

/*--------------------------------*- C++ -*----------------------------------*\
| =========                |                                                |
| \\      /  F ield        | OpenFOAM: The Open Source CFD Toolbox          |
|  \\    /  O peration    | Version:  2.0.0                                |
|  \\  /    A nd          | Web:      www.OpenFOAM.com                      |
|    \\/    M anipulation  |                                                |
\*---------------------------------------------------------------------------*/
FoamFile
{
    version    2.0;
    format      ascii;
    class      dictionary;
    object      blockMeshDict;
}
// * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * //

convertToMeters 1e-6;

vertices       
(
        (-250  -125    -1150)  // 0
        (-78    -125    -1150)
        (78    -125    -1150)
        (1900  -125    -1150)

        (-250  5.2875  -1150)  // 4
        (-78    5.2875  -1150)
        (78    5.2875  -1150)
        (1900  5.2875  -1150)

        (-250  1243.3425      -1150)  // 8
        (-78    1243.3425      -1150)
        (78    1243.3425      -1150)
        (1900  1243.3425      -1150)

        (-250  1375    -1150)  // 12
        (-78    1375    -1150)
        (78    1375    -1150)
        (1900  1375    -1150)

        (-250  -125    -50)    // 16
        (-78    -125    -50)
        (78    -125    -50)
        (1900  -125    -50)

        (-250  5.2875  -50)    // 20
        (-78    5.2875  -50)
        (78    5.2875  -50)
        (1900  5.2875  -50)

        (-250  1243.3425      -50)    // 24
        (-78    1243.3425      -50)
        (78    1243.3425      -50)
        (1900  1243.3425      -50)

        (-250  1375    -50)    // 28
        (-78    1375    -50)
        (78    1375    -50)
        (1900  1375    -50)

        (-250  -125    158.5)  // 32
        (-78    -125    158.5)
        (78    -125    158.5)
        (1900  -125    158.5)

        (-250  5.2875  158.5)  // 36
        (-78    5.2875  158.5)
        (78    5.2875  158.5)
        (1900  5.2875  158.5)

        (-250  1243.3425      158.5)  // 40
        (-78    1243.3425      158.5)
        (78    1243.3425      158.5)
        (1900  1243.3425      158.5)

        (-250  1375    158.5)  // 44
        (-78    1375    158.5)
        (78    1375    158.5)
        (1900  1375    158.5)

//      Need an extra set of points for the finer block

        (-78    5.2875  -50)            //48 = 21
        (78    5.2875  -50)            //49 = 22
        (-78    1243.3425      -50)    //50 = 25
        (78    1243.3425      -50)    //51 = 26

        (-78    5.2875  158.5)          //52 = 37
        (78    5.2875  158.5)          //53 = 38
        (-78    1243.3425      158.5)  //54 = 41
        (78    1243.3425      158.5)  //55 = 42

);

blocks         
(

//  Thick layer

        hex (0 1 5 4 16 17 21 20) (3 2 18) simpleGrading (1 1 1)
        hex (1 2 6 5 17 18 22 21) (3 2 18) simpleGrading (1 1 1)
        hex (2 3 7 6 18 19 23 22) (28 2 18) simpleGrading (1 1 1)

        hex (4 5 9 8 20 21 25 24) (3 20 18) simpleGrading (1 1 1)
        hex (5 6 10 9 21 22 26 25) (3 20 18) simpleGrading (1 1 1)
        hex (6 7 11 10 22 23 27 26) (28 20 18) simpleGrading (1 1 1)

        hex (8 9 13 12 24 25 29 28) (3 2 18) simpleGrading (1 1 1)
        hex (9 10 14 13 25 26 30 29) (3 2 18) simpleGrading (1 1 1)
        hex (10 11 15 14 26 27 31 30) (28 2 18) simpleGrading (1 1 1)

//  Thin layer

        hex (16 17 21 20 32 33 37 36) (3 2 3) simpleGrading (1 1 1)
        hex (17 18 22 21 33 34 38 37) (3 2 3) simpleGrading (1 1 1)
        hex (18 19 23 22 34 35 39 38) (28 2 3) simpleGrading (1 1 1)

        hex (20 21 25 24 36 37 41 40) (3 20 3) simpleGrading (1 1 1)
        hex (48 49 51 50 52 53 55 54) (10 78 13) simpleGrading (1 1 1)  // Fine block, merging required
        hex (22 23 27 26 38 39 43 42) (28 20 3) simpleGrading (1 1 1)

        hex (24 25 29 28 40 41 45 44) (3 2 3) simpleGrading (1 1 1)
        hex (25 26 30 29 41 42 46 45) (3 2 3) simpleGrading (1 1 1)
        hex (26 27 31 30 42 43 47 46) (28 2 3) simpleGrading (1 1 1)

);
edges         
(
);

boundary
(
);

patches
(
        patch top_master
        (
                (22 21 25 26)
        )

        patch top_slave
        (
                (48 49 51 50)
        )

        patch front_master
        (
                (37 41 25 21)
        )

        patch front_slave
        (
                (54 52 48 50)
        )
        patch back_master
        (
                (42 38 22 26)
        )

        patch back_slave
        (
                (53 55 51 49)
        )
        patch left_master
        (
                (38 37 21 22)
        )

        patch left_slave
        (
                (52 53 49 48)
        )
        patch right_master
        (
                (41 42 26 25)
        )

        patch right_slave
        (
                (55 54 50 51)
        )
);

mergePatchPairs
(
        (top_master top_slave)
        (front_master front_slave)
        (back_master back_slave)
        (left_master left_slave)
        (right_master right_slave)
);

// ************************************************************************* //


the.drizzle January 20, 2012 18:42

OK, I still would like to know why the above patching problem fails in general, but I saw after posting that the concept I posted above would fail for two primary reasons:

- snappyHexMesh requires hexahedron elements only, and the above merging has to break this constraint.

- snappyHexMesh (more or less) requires that all the cells in the initial mesh have an aspect ratio somewhere around unity, which again will the above merging technique will break.

For future reference, what has worked is that I have had to break up the initial parts into sub-parts in a manner that corresponds to where the mesh refinement levels are required, with the interfaces defined as patch regions. One can then use snappyHexMesh to mesh all of the "oddball" shapes one at a time, and then glue the parts back together via mergeMeshs and stitchMesh.


All times are GMT -4. The time now is 02:11.