[bastil]

Hello all,

I have a background mesh for sHM created in blockMesh. It is structured and consists of three blocks.
To use this in sHM I have to merge the "interfaces" between the blocks to form one continuous input background-mesh. This is an issue, simply due to the size of the patches to merge (approx. 450000 nodes each of the two pairs). Both stitchMesh and mergePatchPairs in blockMesh are running for hours and I am not sure about the result yet.

I thought about defining three "locationsInMesh" in sHM, one inside each block. I guess this will work, the questions is if the resulting mesh after sHM-run is merged or not? (means will the resulting mesh consist of one part as required or will it still consist of three parts). I think still three.

Is there any other option to think about? Thanks.

[otaolafr]

hello,
why are you using three blocks in blockmesh?

-to have better refiment in part of the final mesh?
if thats so, it might be better to define a block that is the size of the three and use a region with a box defined in gemoetry inside snappy to refine the region you want to be refined.

-to have a "L-like" backgound mesh?
if that is the case, i recomend to simple use a big block as snappy will erase the rest of the mesh and sincerely (i dont know the size of your blockmesh) but is usually super fast, it wouldnt matter for the complete case to do the L-like or a bigger block (at least in my experience)

I can not imagine another case, hope it helps

[lebc]

Hi Bastil,

Can you send a picture of you blockMesh mesh? I have been working with multiple blocks in blockMesh without any issue (attached figure).

One thing you have to make sure is that the vertices and faces are well defined, if the interface of the blocks is well defined, then you don't have to manually merge them (the face of one block has to have the same vertices from the face in the other block, in the correct order).

Best Regards,
Luis

[bastil]

Hello,


thanks for the hints. For clarification:

- I have a "U" shaped geometry I want to mesh. As I am completely at the limit with RAM I can't put the geometry inside one big box without reducing block mesh cell count by approx. two which will end in a too coarse mesh.
- From all my experience refinement in blockMesh is much less memory expensive than doing refinement in sHM (factor of two approx.). Therefore. no refinement is done in sHM, only snapping and layers. I start with an initial fine mesh.
- As my blockMesh is somehow U-shaped to fit the geometry my blocks do not completely match (I have conformal nodes due to same refinement but can not share all the four face vertices)


One other option I am thinking of is creating one large block in blockMesh (I have the RAM for this) and remove the unrequired parts before starting sHM.



Hope my explanation helps. I can post an image next week.

[lebc]

Hi Bastil,

A U-shaped geometry can definitely be generated in blockMesh, maybe a figure of your geometry and the mesh you got would help, it may be something specific from your problem that I'm not quite understanding.

How much RAM do you have? What is the number of elements you are getting your mesh?

[bastil]

Originally Posted by lebc

A U-shaped geometry can definitely be generated in blockMesh, maybe a figure of your geometry and the mesh you got would help, it may be something specific from your problem that I'm not quite understanding.

Agree. I will post a picture next week. I get the U-shaped geometry without merged patches. As soon as turning on "mergePatchPairs" blockMesh (and also stitchMesh as the alterantive) run for hours so far without result. Note that the patches between block 1 and block 2 and block 2 and block 3 have arround 450000 nodes to be merged each. Seems to be to much for mergePatchPairs and stichMesh.

Originally Posted by lebc

How much RAM do you have? What is the number of elements you are getting your mesh?

128 GB. I can create a blockMesh of up to 100 Million elements. However, from what I figured out, sHM requires about 2.2 times the memory. Therefore, the maximum number of hex elements as a background mesh that I can have in snappy is approx. 45 million cells.
To encapsulate my geomety with a sufficant resolution in ONE block I need about 95 million cells in blockMesh, to much to handle in sHM afterwards. Doing it in THREE blocks will reduce the amount of required background cells to approx. 40 million cells. I tried I can chandle it in sHM but so far I have unconnected blocks there ....

[lebc]

Hi Bastil,
Did you manage to make it work? Could you also share you blockMeshDict file?
I don't have the amount of RAM that you have, but I can try a simplified mesh...

[otaolafr]

Originally Posted by bastil

Hello,


thanks for the hints. For clarification:

- I have a "U" shaped geometry I want to mesh. As I am completely at the limit with RAM I can't put the geometry inside one big box without reducing block mesh cell count by approx. two which will end in a too coarse mesh.
- From all my experience refinement in blockMesh is much less memory expensive than doing refinement in sHM (factor of two approx.). Therefore. no refinement is done in sHM, only snapping and layers. I start with an initial fine mesh.
- As my blockMesh is somehow U-shaped to fit the geometry my blocks do not completely match (I have conformal nodes due to same refinement but can not share all the four face vertices)


One other option I am thinking of is creating one large block in blockMesh (I have the RAM for this) and remove the unrequired parts before starting sHM.



Hope my explanation helps. I can post an image next week.

hello bastil!

a way easier way to do it (at least IMO...) is to do the background mesh in salome and then you export it to univ mesh and transform it to openfoam

[bastil]

Hello all,

here is the blockMeshDict:

convertToMeters 1;

vertices
(
    (-124.9875 -63.4875 -0.05) // 0
    ( 124.9875 -63.4875 -0.05) // 1
    ( 124.9875  63.4875 -0.05) // 2
    (-124.9875  63.4875 -0.05) // 3
    (-124.9875 -63.4875  0.45) // 4
    ( 124.9875 -63.4875  0.45) // 5
    ( 124.9875  63.4875  0.45) // 6
    (-124.9875  63.4875  0.45) // 7
    ( -76.9875 -63.4875  0.45) // 8
    ( -76.9875 -15.4875  0.45) // 9
    (-124.9875 -15.4875  0.45) // 10
    (-124.9875 -63.4875  0.95) // 11
    ( -76.9875 -63.4875  0.95) // 12
    ( -76.9875 -15.4875  0.95) // 13
    (-124.9875 -15.4875  0.95) // 14
    (  76.9875  63.4875  0.45) // 15
    (  76.9875  15.4875  0.45) // 16
    ( 124.9875  15.4875  0.45) // 17
    ( 124.9875  63.4875  0.95) // 18
    (  76.9875  63.4875  0.95) // 19
    (  76.9875  15.4875  0.95) // 20
    ( 124.9875  15.4875  0.95) // 21

);

blocks
(
    hex (0 1 2 3 4 5 6 7) block1 (3333 1693 8) simpleGrading (1 1 1)
    hex (4 8 9 10 11 12 13 14) block2 (640 640 8) simpleGrading (1 1 1)
    hex (6 15 16 17 18 19 20 21) block3 (640 640 8) simpleGrading (1 1 1)
);

edges
(
);

boundary
(
    topPatch
    {
        type patch;
        faces
        (
            (4 5 6 7)
        );
    }

    inletPatch
    {
        type patch;
        faces
        (
            (4 8 9 10)
        );
    }

    outletPatch
    {
        type patch;
        faces
        (
            (6 17 16 15)
        );
    }

    walls 
    { 
        type wall; 
        faces 
        ( 
            (0 1 5 4)
            (1 2 6 5)
            (0 1 2 3)
            (2 3 7 6)
            (0 3 7 4)
            (4 8 12 11)
            (8 9 13 12)
            (9 10 14 13)
            (10 4 11 14)
            (11 12 13 14)
            (16 17 21 20)
            (17 6 18 21)
            (6 15 19 18)
            (15 16 20 19)
            (18 19 20 21)
        ); 
    }
);

mergePatchPairs
(
//    (topPatch inletPatch)
//    (topPatch outletPatch)
);

That's how it works. Uncommenting the two "mergePatchPairs"-lines make it run forever. Note: Each of the merge pairs have more than 400000 verticies to merge.

[bastil]

Originally Posted by otaolafr

hello bastil!

a way easier way to do it (at least IMO...) is to do the background mesh in salome and then you export it to univ mesh and transform it to openfoam

I don't think for meshes of that size ....

[bastil]

Ok workaround that seems to run:

1. Create one uniform large block in blockMesh (Memory for this is available, but not enough RAM for using this as a background mesh)
2. Use "setSet" and "subsetMesh" to cut out the U-Shape out of the large mesh block (will reduce the mesh size and remove not required cells in the background mesh before starting sHM). Now we have the desired U-shaped background mesh (without the need to merge any patches)
3. Use this as background mesh for sHM.

[lebc]

Hi Bastil,

And how does your geometry looks inside this blockMesh? I'm insisting on this because it may be possible to create this geometry in your blockMeshDict (if it is not a complex geometry...) and generate the mesh only inside that region, this way you would save millions of cells.

Your blockMeshDict also worked for me.

Best Regards,
Luis

[bastil]

Originally Posted by lebc

Hi Bastil,

And how does your geometry looks inside this blockMesh? I'm insisting on this because it may be possible to create this geometry in your blockMeshDict (if it is not a complex geometry...) and generate the mesh only inside that region, this way you would save millions of cells.

No way. The geometry is highly complex.



Did blockMesh also run with the two "mergePatchPair" lines uncommented? This is were the trouble starts for me. However I need a connected Background Mesh as far as I know.

[lebc]

Actually, it runs Ok for a simplified mesh, but the checkMesh points 2 fails:

Mesh stats
    points:           7204107
    faces:            18414756
    internal faces:   15806152
    cells:            5520000
    faces per cell:   6.19944
    boundary patches: 2
    point zones:      0
    face zones:       0
    cell zones:       3

Overall number of cells of each type:
    hexahedra:     5167781
    prisms:        0
    wedges:        0
    pyramids:      0
    tet wedges:    0
    tetrahedra:    0
    polyhedra:     352219
    Breakdown of polyhedra by number of faces:
        faces   number of cells
            5   435
            6   75
            7   36739
            8   26634
            9   142008
           10   146328

Checking topology...
    Boundary definition OK.
    Cell to face addressing OK.
    Point usage OK.
    Upper triangular ordering OK.
    Face vertices OK.
    Number of regions: 1 (OK).

Checking patch topology for multiply connected surfaces...
                   Patch    Faces   Points                  Surface topology
                topPatch  1200604  1363736  multiply connected (shared edge)
                   walls  1408000  1412449  ok (non-closed singly connected)
  <<Writing 2220 conflicting points to set nonManifoldPoints

Checking geometry...
    Overall domain bounding box (-124.988 -63.4875 -0.05) (124.988 63.4875 0.95)
    Mesh has 3 geometric (non-empty/wedge) directions (1 1 1)
    Mesh has 3 solution (non-empty) directions (1 1 1)
 ***Boundary openness (2.19193e-18 -8.85885e-18 0.0672382) possible hole in boundary description.
 ***Open cells found, max cell openness: 0.984424, number of open cells 174556
  <<Writing 174556 non closed cells to set nonClosedCells
    Minimum face area = 6.6e-05. Maximum face area = 0.0264505.  Face area magnitudes OK.
    Min volume = 0.00259327. Max volume = 0.00377864.  Total volume = 18233.8.  Cell volumes OK.
    Mesh non-orthogonality Max: 61.1557 average: 8.61417
    Non-orthogonality check OK.
    Face pyramids OK.
    Max skewness = 0.732837 OK.
    Coupled point location match (average 0) OK.

Failed 2 mesh checks.

As you said that it's a highly complex geometry, then go to an external mesh generator, SHM will give you a hard time for the mesh size you want to generate... I thought it was a U-shaped geometry.


If you are dealing with pipes, you can still make it work in blockMesh. It's not an easy task, but it can be done.


Good luck!

[lebc]

I just saw this other post, maybe it can help you!

Creating blockMeshDict from python