CFD Online Discussion Forums - [snappyHexMesh] Snappy : Multi-region meshing

CFD Online Discussion Forums (https://www.cfd-online.com/Forums/)

- OpenFOAM Meshing & Mesh Conversion (https://www.cfd-online.com/Forums/openfoam-meshing/)

- - [snappyHexMesh] Snappy : Multi-region meshing (https://www.cfd-online.com/Forums/openfoam-meshing/94413-snappy-multi-region-meshing.html)

Dear Bruno,
Thank you so much for your help!
I created one block with one cube in one case, then created another block with another cube, (both in the case of motorBike), then merge the two parts, and it seems like works!
I will find that whether this mesh will work with GGI.
Thank you so much again!

Aqua

Problem with snappy

Good year everybody,
sorry for my bad english...

I successfully meshed a multi domain with Fluent 13 mesher and then used it in OF1.7.1, but, i love open source then I am looking toward the capabilities of snappyHexMesh in multi doamin meshing.

The geometry is very simple, an heated pipe and a cold fluid through it.

I have follow this steps for case setup (reported in past post) based on
snappyMultiReginHeater tutorial (in OF-1.7.1)

1) copy the case dir in the working folder.
2) modify the blockMeshDict (whole domain)
3) replace the stl files by SOLIDO.stl and FLUIDO.stl. stl files are obtain by exporting SALOME geom.
4) modify the regionProperties.
5) modify the snappyHexMeshDict to fit the new stl files.

When I launch SHM the background mesh don't diasappear and it creates a domain0, SOLIDO and FLUIDO mesh.

I have read thousand post and i:
-modify the locationInMesh (pointed in FLUIDO, SOLIDO and domain0)
-increase background mesh quality
- etc ..
but without success!!!!

PLEASE HELP ME!!!

Do you know how to delete the domain0 mesh?

Thanks

Antonello

hi,
I had similar problem, then I solved it by correct the name in the stl file.
I think there is something wrong with the name in your stl file. so maybe you should check that...

Aqua

Thanks Aqua,
I have change the stl files in this manner ->
for FLUIDO.stl:

solid FLUIDO
...
...
endsolid FLUIDO

for SOLIDO.stl

solid SOLIDO
...
...
endsolid SOLIDO

but the problem persist

there is the same strange behaviour with OF 2.0.1

Do you have any other suggestion?

now i think your stl file is right from the name. But the only think i can suggest is:
did you perform "Allclean" before you recreat the mesh and domain?

Thanks Aqua,
yes, i perform Allclean before recreate new setup simulation....
the file Allclean is in snappy_pipe.zip that i have posted ....

I've been banging my head for this

how you generate STL files? SALOME?

I use starccm+, export stl file in "coded" format. Then edit the stl file in note book, changint the name like you did:
solid FLUIDO
...
...
endsolid FLUIDO

for SOLIDO.stl

solid SOLIDO
...
...
endsolid SOLIDO

Or, is it possible that you wrote the wrong name in other files? such as boundary or something like that?
Sorry that's all i know..

thanks Aqua,
the names are right .... i have copy/paste the snappyMultiRegionHeater case and changed all files: regionProperties, snappyHexMeshDict etc
I have read many tutorials ....

The problem is in STL files, clearly

i prove starccm+ !!!!

I'm having similar problems in using SHM for a multiregion simple test case.

In particular I'm referring to this post: http://www.cfd-online.com/Forums/ope...tml#post333256

I'm a little confused after many trials.
I'd like to have a clarification: are "big" stl triangles causing SHM to fail ?

Probably this won't be an issue in real cases but just during simple test. Not so bad.

Just in case: what to use to refine a stl geometry ? At the moment I'm using Salome to convert Pro/e geometries but none of them has the possibility to adjust the dimension of the triangles.

I also tried MeshLab but with no success...

Thanks.

I'm not sure my problem is just with large stl triangles.

I'm trying to setup a multiregion case simulating the heat transfer between liquid (two water filled holes) and solid (the outside collector).

Here is what I did:
1. Model the collector geometry and the global domain in CAD (pro/E)
2. Import .step files in Salome
3. Subracting the two geometries I obtained the fluid domain.
4. Explode the faces of the fluid domain and the collector and group them accordly to BC (inlet / outlet / walls ...).
5. Export each boundary as stl file
6. Manually create (joining the previous files) two single stl files with the proper names of the solid.
7. Use the SHM procedure, following the tutorial sample.
8. Split the regions using SplitMeshRegions -cellZones

The problems I found are:
a. Flooding of the cells into the blockmesh domain.
b. Other than fluid and collector regions, I obtain domain0,domain1,... regions. If I play with the refinement values (above all edge) in SHM dict I can obtain up to domain100 !

Probably (b) problem is caused by (a) problem...

I checked the stl files that SHM has to use and you can see them in the attached pictures.
The other pict is the parafoam display of... well I don't know I had to select the readZone flag and de-select everything in order to see this.

Looking at the pictures I think I know why the problem is there: all the triangles join in a single point. But is it not normal ?

Have the stl triangulations of the solids to be vertex-coincident at the common boundaries ?

How to solve it ?

Anyone has an idea ?

Thanks.
Daniele

Sorry to continue to update this thread alone but maybe this will help someone in future...

I "solved" my problem by using a blockmesh domain fitted onto the collector size. This way sHM cannot flood anymore.

Another thing: creating the fluid domain I used a single stl file for two separate objects. That bring to two different regions (one will be called "fluid" and the other domainX). Best thing is to create an stl file per object.

What is worried me is the "solution" of the flooding... in a real case can I use a sHM-created object to be used as starting mesh ? (Insted of the classical blockmesh-generated one ?)

Daniele

Hi Daniele,

What do you mean by "I "solved" my problem by using a blockmesh domain fitted onto the collector size. This way sHM cannot flood anymore." ?

I was confronted to this problem too and I gave up trying to mesh both fluid and solid regions in just 1 step. Now I am meshing each part and then I merge into 1 mesh (unstructured mesh).

Aurélien

In my test case the bigger part to be meshed was a 40x50x300mm parallelepiped (see the pictures I posted).
So I just executed sHM using an initial mesh (the one you create with blockmesh) with exactly those dimensions.

But I was thinking to use you way, more general (for sure) and less problematic, I think.

BTW, how to reproduce all the polymesh subdir files ? Which tool have you used ?

Thanks.

Daniele

Well, I am doing it by hands. I have several folders for each mesh and then I copy paste into one single folder.

If you can create several cellzones, you can use something like "splitMeshRegion" (I'm not sure of its name). It will do the job based on the different cellZones.

Quote:

Originally Posted by danvica (Post 351247)

With proe you can export to stl and also adjust the refinement level as you wish

Hi all,
sorry for my bad english...

SOLIDWORKS can import stl files and adjust the refinement level as you wish

No open source software unfortunately!!

My experience with SHM:

The geometry is very simple, an heated pipe and a cold fluid through it.

My opinion is that stl files which represent surface in contact i.e. fluid and tube interface in fact are not perfectly in contact....

I have follow this steps to avoid multiple domain* creation.

1) generate cylindrical background mesh with blockMesh (whole domain tube+fluid) the dimension of background mesh are equal to mesh i wish to obtain
2) in snappyHexMeshDict file i have declared ONLY the fluid stl (only fluid.stl in trisurface folder)
the locationInMesh pointed into FLUIDO region

When I launch SHM it creates only one domain region mesh and FLUIDO mesh with correct interfaces domain_to_FLUIDO and FLUIDO_to_domain

Naturally is necessary to correct boundary file etc etc

Antonello

@sail
It's a little OT but afaik with Pro/e you can define just chord height and angle control. It always minimizes the number of triangle used. i.e. a plane will be always meshed as two triangles, whichever the dimensions. But let me know if I'm wrong, please.

@antonessiu
This is more or less what I did but with two fluid regions. The main problem is that it doesn't seem a general method. What if your bigger part (fluid or solid) is not a perfect geometric shape to be defined in blockmeshdict ? Maybe I can use sHM to meshed it but I still have to test it.

At the moment I'm looking at meshing each region separately and join them all togheter. I think I have to use setset and setstoZones utility... anyone knows a better / more reliable way ?

Daniele

Ok, actually I tried again with the "canonical" way using sHM to do all the job.
The meshing seems ok but I don't have the boundary surfaces.

Here is my sHMDict:

Code:

/*--------------------------------*- C++ -*----------------------------------*\

| =========                 |                                                 |

| \\      /  F ield         | OpenFOAM: The Open Source CFD Toolbox           |

|  \\    /   O peration     | Version:  2.0.0                                 |

|   \\  /    A nd           | Web:      www.OpenFOAM.org                      |

|    \\/     M anipulation  |                                                 |

\*---------------------------------------------------------------------------*/

FoamFile

{

    version     2.0;

    format      ascii;

    class       dictionary;

    object      snappyHexMeshDict;

}

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

// Which of the steps to run

castellatedMesh true;

snap            true;

addLayers       false;

 

// Geometry. Definition of all surfaces. All surfaces are of class

// searchableSurface.

// Surfaces are used

// - to specify refinement for any mesh cell intersecting it

// - to specify refinement for any mesh cell inside/outside/near

// - to 'snap' the mesh boundary to the surface

geometry

{

    collector.stl

    {

        type triSurfaceMesh;

        name collector;

        regions 

        {

            ewalls

            {

                name ewalls;

            }

            tubb

            {

                name tubb;

            }

            tubs

            {

                name tubs;

            }

        }

    }

    fluids.stl

    {

        type triSurfaceMesh;

        name fluids;

    }

    fluidb.stl

    {

        type triSurfaceMesh;

        name fluidb;

    }

 

    //refinementBox1

    //{

    //    type searchableBox;

    //    min (-0.05 -0.05 -0.35);

    //    max ( 0.05  0.05 0.05);

    //}

};

 

// Settings for the castellatedMesh generation.

castellatedMeshControls

{

    // Refinement parameters

    // ~~~~~~~~~~~~~~~~~~~~~

    // If local number of cells is >= maxLocalCells on any processor

    // switches from from refinement followed by balancing

    // (current method) to (weighted) balancing before refinement.

    maxLocalCells 100000;

    // Overall cell limit (approximately). Refinement will stop immediately

    // upon reaching this number so a refinement level might not complete.

    // Note that this is the number of cells before removing the part which

    // is not 'visible' from the keepPoint. The final number of cells might

    // actually be a lot less.

    maxGlobalCells 2000000;

    // The surface refinement loop might spend lots of iterations refining just a

    // few cells. This setting will cause refinement to stop if <= minimumRefine

    // are selected for refinement. Note: it will at least do one iteration

    // (unless the number of cells to refine is 0)

    minRefinementCells 0;

    // Allow a certain level of imbalance during refining

    // (since balancing is quite expensive)

    // Expressed as fraction of perfect balance (= overall number of cells /

    // nProcs). 0=balance always.

    maxLoadUnbalance 0.10;

 

    // Number of buffer layers between different levels.

    // 1 means normal 2:1 refinement restriction, larger means slower

    // refinement.

    nCellsBetweenLevels 1;

 

    // Explicit feature edge refinement

    // ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~

    // Specifies a level for any cell intersected by its edges.

    // This is a featureEdgeMesh, read from constant/triSurface for now.

    features

    (       

        {

            file "collector.eMesh";

            level 1;

        }

        {

            file "fluidb.eMesh";

            level 1;

        }

        {

            file "fluids.eMesh";

            level 1;

        }

    );

 

    // Surface based refinement

    // ~~~~~~~~~~~~~~~~~~~~~~~~

    // Specifies two levels for every surface. The first is the minimum level,

    // every cell intersecting a surface gets refined up to the minimum level.

    // The second level is the maximum level. Cells that 'see' multiple

    // intersections where the intersections make an

    // angle > resolveFeatureAngle get refined up to the maximum level.

    refinementSurfaces

    {

        collector

        {

            // Surface-wise min and max refinement level

            level (0 1);

             faceZone collector;

             cellZone collector;

             cellZoneInside inside;

 

             regions

             {

                ewalls

                {

                  level (0 1);

                  faceZone ewalls;

                }

                tubb

                {

                  level (0 1);

                  faceZone tubb;

                }

                tubs

                {

                  level (0 1);

                  faceZone tubs;

                }

             }

 

        }

 

        fluids

        {

            // Surface-wise min and max refinement level

            level (0 1);

            faceZone fluids;

            cellZone fluids;

            cellZoneInside inside;

        }

        fluidb

        {

            // Surface-wise min and max refinement level

            level (0 1);

            faceZone fluidb;

            cellZone fluidb;

            cellZoneInside inside;

        }

    }

    // Resolve sharp angles

 

     resolveFeatureAngle 30;

    // Region-wise refinement

    // ~~~~~~~~~~~~~~~~~~~~~~

    // Specifies refinement level for cells in relation to a surface. One of

    // three modes

    // - distance. 'levels' specifies per distance to the surface the

    //   wanted refinement level. The distances need to be specified in

    //   descending order.

    // - inside. 'levels' is only one entry and only the level is used. All

    //   cells inside the surface get refined up to the level. The surface

    //   needs to be closed for this to be possible.

    // - outside. Same but cells outside.

    refinementRegions

    {

        //fluid

        //{

        //   mode inside;

        //   levels ((1E15 2));

        //}

    }

 

    // Mesh selection

    // ~~~~~~~~~~~~~~

    // After refinement patches get added for all refinementSurfaces and

    // all cells intersecting the surfaces get put into these patches. The

    // section reachable from the locationInMesh is kept.

    // NOTE: This point should never be on a face, always inside a cell, even

    // after refinement.

    locationInMesh (0 0.05 0);

 

    // Whether any faceZones (as specified in the refinementSurfaces)

    // are only on the boundary of corresponding cellZones or also allow

    // free-standing zone faces. Not used if there are no faceZones.

    allowFreeStandingZoneFaces true;

}

 

// Settings for the snapping.

snapControls

{

    //- Number of patch smoothing iterations before finding correspondence

    //  to surface

    nSmoothPatch 4;

    //- Relative distance for points to be attracted by surface feature point

    //  or edge. True distance is this factor times local

    //  maximum edge length.

    tolerance 20.0;

    //- Number of mesh displacement relaxation iterations.

    //nSolveIter 0;

    nSolveIter 30;

    //- Maximum number of snapping relaxation iterations. Should stop

    //  before upon reaching a correct mesh.

    nRelaxIter 5;

    //- Highly experimental and wip: number of feature edge snapping

    //  iterations. Leave out altogether to disable.

    nFeatureSnapIter 5;

}

 

// Advanced

// Flags for optional output

// 0 : only write final meshes

// 1 : write intermediate meshes

// 2 : write volScalarField with cellLevel for postprocessing

// 4 : write current intersections as .obj files

debug 0;

 

// Merge tolerance. Is fraction of overall bounding box of initial mesh.

// Note: the write tolerance needs to be higher than this.

mergeTolerance 1e-6;

 

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

Note: At the moment I'm trying different setup just for collector region but it should be the same for all the three regions.

The boundary file under constant/collector/polyMesh is:

Code:

3

(

    defaultFaces

    {

        type            empty;

        nFaces          31536;

        startFace       784724;

    }

    collector_to_fluidb

    {

        type            mappedWall;

        nFaces          32000;

        startFace       816260;

        sampleMode      nearestPatchFace;

        sampleRegion    fluidb;

        samplePatch     fluidb_to_collector;

        offsetMode      uniform;

        offset          (0 0 0);

    }

    collector_to_fluids

    {

        type            mappedWall;

        nFaces          24000;

        startFace       848260;

        sampleMode      nearestPatchFace;

        sampleRegion    fluids;

        samplePatch     fluids_to_collector;

        offsetMode      uniform;

        offset          (0 0 0);

    }

)

And under constant/polymesh the boundary file is:

Code:

10

(

    defaultFaces

    {

        type            empty;

        nFaces          33160;

        startFace       1185496;

    }

    tubb

    {

        type            wall;

        nFaces          0;

        startFace       1218656;

    }

    tubs

    {

        type            wall;

        nFaces          0;

        startFace       1218656;

    }

    ewalls

    {

        type            wall;

        nFaces          0;

        startFace       1218656;

    }

    fluids_wals

    {

        type            wall;

        nFaces          0;

        startFace       1218656;

    }

    fluids_outls

    {

        type            wall;

        nFaces          0;

        startFace       1218656;

    }

    fluids_inls

    {

        type            wall;

        nFaces          0;

        startFace       1218656;

    }

    fluidb_outlb

    {

        type            wall;

        nFaces          0;

        startFace       1218656;

    }

    fluidb_inlb

    {

        type            wall;

        nFaces          0;

        startFace       1218656;

    }

    fluidb_walb

    {

        type            wall;

        nFaces          0;

        startFace       1218656;

    }

)

I don't have any wall face ! (nFaces=0)

I tryed to remove facezones from the collector refinement region (leaving facezones for the patches only). This assigns the collector walls correctly but doesn't create the collector regions (creates lots of domainX regions, instead).

And, why so many defaultFaces ? All my surfaces are well defined by name.

Sorry for my bad explanation... if someone has a solution I appreciate.

Thanks.

Daniele

Daniele,

To perform a multi domain mesh in different steps :

1) Create a folder for each domain you'll have :
Fluid1 / Fluid2...
Solid1 / Solid2...

2) Then do the snappy for each domain. So you will have a polymesh in the constant directory of each Fluidi and Solidi folders.

3) Then create a "super-folder", let's say CHT-mesh/. In this folder you will have :
0/Fluid1 0/Fluid2... 0/Solid1 0/Solid2..
constant/Fluid1.... <- here you copy paste the polymesh folders created previously.
system/Fluid1....

4) Finally go inside each constant/Fluidi/polymesh folders and edit the boundary files. Switch the type of your internal fluid/solid interfaces from wall (or patch) to something like "mappedTemperature...". I don't have any case open, just have a look at a CHT tutorial.

5) Last but not least, create the file regionProperties in the constant folder.

This way you'll have your case ready for a run. You will have to check the surface face's size and check the heat flux between the mapped interfaces to be sure there is no glitch linked to the non structured mesh.

Hi All,
Another question:

I have a swirl pipe to mesh, hence, the refinement of background mesh in axial direction is high.
blockMesh proceed without errors but SHM log generate this error:

Marked for refinement due to refinement shells: 0 cells
new cannot satisfy memory request
This does not necessarily mean you have run out of virtual memory.
It could be due to a stack violation caused by e.g. bad use of pointers or out of date shared library.

I have think that this error is due to insufficient hardware characteristics, dual core with 2Gb RAM memory, but the same error occur in quad core 4 Gb RAM pc

It is necessary to run SHM in cluster to get some results ?

Which are the parameters to change in SHMdict to get best mesh fitted to stl?

thanks for your responses
once again, sorry for my bad english !