CFD Online Logo CFD Online URL
www.cfd-online.com
[Sponsors]
Home > Forums > Software User Forums > OpenFOAM > OpenFOAM Meshing & Mesh Conversion

[snappyHexMesh] snappyHexMesh - 90° edges problem

Register Blogs Community New Posts Updated Threads Search

Like Tree16Likes

Reply
 
LinkBack Thread Tools Search this Thread Display Modes
Old   September 24, 2021, 07:43
Question snappyHexMesh - 90° edges problem
  #1
New Member
 
troth
Join Date: May 2021
Posts: 19
Rep Power: 5
troth is on a distinguished road
Hello everyone,

I am learning SHM to generate a mesh of a simple reactor. It is a cylinder, which has an inclination at the bottom, an inflow at the top and an outflow at the side. I used sketchup for the geometry. I have created stl for each surface (inflow, outflow, walls, bottom, top) and also for the whole volume (reactor).Then I proceeded:
-BlockMesh
-SurfaceFeatureExtract
-SnnapyHexMesh



SurfaceFeatureExtract
Code:
inflow.stl
{
    // How to obtain raw features (extractFromFile || extractFromSurface)
    extractionMethod    extractFromSurface;

    // Mark edges whose adjacent surface normals are at an angle less
    // than includedAngle as features
    // - 0  : selects no edges
    // - 180: selects all edges
    includedAngle       150;

    subsetFeatures
    {
        // Keep nonManifold edges (edges with >2 connected faces)
        nonManifoldEdges       no;

        // Keep open edges (edges with 1 connected face)
        openEdges       yes;
    }


    // Write options

    // Write features to obj format for postprocessing
    writeObj            yes;
}

outflow.stl
{
    // How to obtain raw features (extractFromFile || extractFromSurface)
    extractionMethod    extractFromSurface;

    // Mark edges whose adjacent surface normals are at an angle less
    // than includedAngle as features
    // - 0  : selects no edges
    // - 180: selects all edges
    includedAngle       150;

    subsetFeatures
    {
        // Keep nonManifold edges (edges with >2 connected faces)
        nonManifoldEdges       no;

        // Keep open edges (edges with 1 connected face)
        openEdges       yes;
    }


    // Write options

    // Write features to obj format for postprocessing
    writeObj            yes;
}

top.stl
{
    // How to obtain raw features (extractFromFile || extractFromSurface)
    extractionMethod    extractFromSurface;

    // Mark edges whose adjacent surface normals are at an angle less
    // than includedAngle as features
    // - 0  : selects no edges
    // - 180: selects all edges
    includedAngle       150;

    subsetFeatures
    {
        // Keep nonManifold edges (edges with >2 connected faces)
        nonManifoldEdges       no;

        // Keep open edges (edges with 1 connected face)
        openEdges       yes;
    }


    // Write options

    // Write features to obj format for postprocessing
    writeObj            yes;
}

bottom.stl
{
    // How to obtain raw features (extractFromFile || extractFromSurface)
    extractionMethod    extractFromSurface;

    // Mark edges whose adjacent surface normals are at an angle less
    // than includedAngle as features
    // - 0  : selects no edges
    // - 180: selects all edges
    includedAngle       150;

    subsetFeatures
    {
        // Keep nonManifold edges (edges with >2 connected faces)
        nonManifoldEdges       no;

        // Keep open edges (edges with 1 connected face)
        openEdges       yes;
    }


    // Write options

    // Write features to obj format for postprocessing
    writeObj            yes;
}

walls.stl
{
    // How to obtain raw features (extractFromFile || extractFromSurface)
    extractionMethod    extractFromSurface;

    // Mark edges whose adjacent surface normals are at an angle less
    // than includedAngle as features
    // - 0  : selects no edges
    // - 180: selects all edges
    includedAngle       150;

    subsetFeatures
    {
        // Keep nonManifold edges (edges with >2 connected faces)
        nonManifoldEdges       no;

        // Keep open edges (edges with 1 connected face)
        openEdges       yes;
    }


    // Write options

    // Write features to obj format for postprocessing
    writeObj            yes;
}
SnnapyHexMesh
Code:
geometry
 {
    inflow.stl
    {
        type triSurfaceMesh;
        name inflow;
    }
    
    outflow.stl
    {
        type triSurfaceMesh;
        name outflow;
    }    
    
    top.stl
    {
        type triSurfaceMesh;
        name top;
    }
    
    bottom.stl
    {
        type triSurfaceMesh;
        name bottom;
    }
    
    walls.stl
    {
        type triSurfaceMesh;
        name walls;
    }
    
    reactor.stl
    {
        type triSurfaceMesh;
        name reactor;
    }
}


//// Optional: avoid patch-face merging. Allows mesh to be used for
////           refinement/unrefinement
mergePatchFaces off; // default on



// 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 1000000; //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 10;

    // 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 2; //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 "inflow.eMesh";
    level 0;   
    }
    
    {
    file "outflow.eMesh";
    level 0;   
    }
    
    {
    file "top.eMesh";
    level 0;   
    }
    
    {
    file "bottom.eMesh";
    level 0;   
    }
    
    {
    file "walls.eMesh";
    level 0;   
    }
    
    );


    // 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
    {
        inflow
        {
            // Surface-wise min and max refinement level
            level (0 0);

            // Optional specification of patch type (default is wall). No
            // constraint types (cyclic, symmetry) etc. are allowed.

        }
    
    outflow
        {
            // Surface-wise min and max refinement level
            level (0 0);

            // Optional specification of patch type (default is wall). No
            // constraint types (cyclic, symmetry) etc. are allowed.

        }
    
    top
        {
            // Surface-wise min and max refinement level
            level (0 0);

            // Optional specification of patch type (default is wall). No
            // constraint types (cyclic, symmetry) etc. are allowed.

        }
    
    bottom
        {
            // Surface-wise min and max refinement level
            level (4 4);

            // Optional specification of patch type (default is wall). No
            // constraint types (cyclic, symmetry) etc. are allowed.

        }
    
    walls
        {
            // Surface-wise min and max refinement level
            level (0 0);

            // Optional specification of patch type (default is wall). No
            // constraint types (cyclic, symmetry) etc. are allowed.

        }
    }

    // Resolve sharp angles
    resolveFeatureAngle 0;// 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
    {
       reactor
    {
    mode distance;
    levels ((2 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 0.7);


    // 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 3;

    //- Relative distance for points to be attracted by surface feature point
    //  or edge. True distance is this factor times local
    //  maximum edge length.
    tolerance 2.0;

    //- Number of mesh displacement relaxation iterations.
    nSolveIter 30;

    //- Maximum number of snapping relaxation iterations. Should stop
    //  before upon reaching a correct mesh.
    nRelaxIter 5;

    // Feature snapping

//        //- Number of feature edge snapping iterations.
//        //  Leave out altogether to disable.
//        nFeatureSnapIter 30; //10;
//
//        //- Detect (geometric only) features by sampling the surface
//        //  (default=false).
//        implicitFeatureSnap false;
//
//        //- Use castellatedMeshControls::features (default = true)
//        explicitFeatureSnap true;
//
//        //- Detect points on multiple surfaces (only for explicitFeatureSnap)
//        multiRegionFeatureSnap false;
 }
However, the mesh that is generated does not have 90° edges (see image). In addition, the mesh at the bottom generates "steps". I have tried with a finer mesh but the problem persists, I also tried to refine the edge and the same thing.

Any idea? thank you very much!
Attached Images
File Type: jpg top edge.jpg (197.4 KB, 193 views)
File Type: jpg bottom edge.jpg (187.9 KB, 172 views)
troth is offline   Reply With Quote

Old   September 29, 2021, 10:08
Default
  #2
Member
 
Join Date: May 2017
Posts: 31
Rep Power: 9
sqek is on a distinguished road
Quote:
mesh that is generated does not have 90° edges:
This is because snappyHexMesh snaps vertices onto surfaces - if you have 2 surfaces at 90 degrees, and a vertex gets snapped to each one, the line between them will cut the corner.
You can solve this by making a second snappyHexMeshDict, and splitting the surfaces between them.
So in system/snappyHexMeshDict1, have
Code:
geometry
 {
    inflow.stl
    {
        type triSurfaceMesh;
        name inflow;
    }
    
    outflow.stl
    {
        type triSurfaceMesh;
        name outflow;
    }    
    
// removed top and bottom
    
    walls.stl
    {
        type triSurfaceMesh;
        name walls;
    }
    
    reactor.stl
    {
        type triSurfaceMesh;
        name reactor;
    }
}
And in system/snappyHexMeshDict1, have
Code:
geometry
 {
    top.stl
    {
        type triSurfaceMesh;
        name top;
    }
    
    bottom.stl
    {
        type triSurfaceMesh;
        name bottom;
    }
}
Then run
Code:
snappyHexMesh -dict system/snappyHexMeshDict1
snappyHexMesh -dict system/snappyHexMeshDict2
You'll probably need to modify walls.stl to extend past the edges of the initial mesh to get the first step to work - effectively, you want to make an endless cylinder, then cut the ends off - when doing the second step to cut the ends off, the existing boundary vertices will be snapped vertically onto the surface (probably) so you should end up with a proper right angle.

Quote:
In addition, the mesh at the bottom generates "steps":
In snapControls:

Try reducing nSmoothPatch (with nSmoothPatch greater than 0, it modifies the surface before snapping to try to make it smoother, setting it to 0 forces it to use the original surface you've provided - this might help sharpen the corners as well)

Try increasing tolerance (if tolerance is too low, it'll leave points where they are instead of snapping them onto the surface, if they're too far away)

Try increasing nSolveIter, nRelaxIter, and nFeatureSnapIter (It'll try more times to do the snapping properly before giving up - and running out of iterations often leaves the steps you're seeing, where it couldn't snap well enough by the end of the iteration limit so just leaves you with the stair-like castellated mesh)

That last one might make it take a lot longer - test it on a much lower-resolution mesh first to find settings that seem to work, then copy the settings over to your real mesh

Hope this helps!
toolpost, hogsonik, wht and 1 others like this.
sqek is offline   Reply With Quote

Old   September 29, 2021, 12:02
Default
  #3
New Member
 
troth
Join Date: May 2021
Posts: 19
Rep Power: 5
troth is on a distinguished road
no one? =(...


Could it be a problem coming from the geometry?


For example, to construct the cylinder in sketchup I first had to define a circle with a limited number of sides (the maximum sides I could give was 600, considering that the radio is 1 m approx.)


Or is it something Im missing in snappyHexMesh...?


Thanks in advance!
troth is offline   Reply With Quote

Old   September 29, 2021, 12:45
Default
  #4
Senior Member
 
Yann
Join Date: Apr 2012
Location: France
Posts: 1,236
Rep Power: 29
Yann will become famous soon enoughYann will become famous soon enough
Hi,

In your snappyHexMeshDict, the Feature snapping section is commented. This part is supposed to deal with feature lines (edges).

Code:
// Feature snapping

//        //- Number of feature edge snapping iterations.
//        //  Leave out altogether to disable.
//        nFeatureSnapIter 30; //10;
//
//        //- Detect (geometric only) features by sampling the surface
//        //  (default=false).
//        implicitFeatureSnap false;
//
//        //- Use castellatedMeshControls::features (default = true)
//        explicitFeatureSnap true;
//
//        //- Detect points on multiple surfaces (only for explicitFeatureSnap)
//        multiRegionFeatureSnap false;

The explicitFeatureSnap flag allow to use the eMesh files created with surfaceFeatureExtract to snap your mesh on the edges of your geometry.

So you should probably start by uncommenting this, run again snappyHexMesh and let us know if it solved your issue.

Cheers,
Yann
Yann is offline   Reply With Quote

Old   September 29, 2021, 13:05
Default
  #5
New Member
 
troth
Join Date: May 2021
Posts: 19
Rep Power: 5
troth is on a distinguished road
Dear Yann,

Thank you very much for replying. Unfortunately I tried uncommenting all the Feature snapping section and running everything again, but the result looks exactly the same...
means that maybe I have an issue with the e.mesh files?

Thanks in advance!
troth is offline   Reply With Quote

Old   September 29, 2021, 13:27
Default
  #6
Senior Member
 
Yann
Join Date: Apr 2012
Location: France
Posts: 1,236
Rep Power: 29
Yann will become famous soon enoughYann will become famous soon enough
You can use the surfaceFeatureConvert utility to convert your eMesh files to obj:

Code:
surfaceFeatureConvert constant/triSurface/yourFile.eMesh youOutputFile.obj
Then you can open the obj in paraview to see if your edges are correctly captured by surfaceFeatureExtract.


Yann
snak and troth like this.
Yann is offline   Reply With Quote

Old   October 1, 2021, 05:48
Default
  #7
Member
 
Join Date: May 2017
Posts: 31
Rep Power: 9
sqek is on a distinguished road
Quote:
Originally Posted by troth View Post
no one? =(...
Did you see my reply, it's showing as before your comment (it says September 29, 2021 14:08)? (My account's quite new, so I think there's a moderation delay before things show up properly)
sqek is offline   Reply With Quote

Old   October 1, 2021, 10:55
Default
  #8
New Member
 
troth
Join Date: May 2021
Posts: 19
Rep Power: 5
troth is on a distinguished road
Dear sqek,

thank so much for your detailed answer . Your answer didnt appear until today, weird!.

If I understand well, you suggest to divide the snappyHexMeshDict in 2, one with the top and bottom and the other with inflow, outflow and wells. In addition, I should "enlarge" the cylinders at the well.stl to ensure that it will then be cut at the correct angle. Should both snappyHexMeshDict files contain the reactor.stl (the whole geometry) in the geometry section?, or is it enough that its mention only in snappyHexMeshDict1 as you wrote it in your answer.

I enlarged the cylinders of the wall.stl and separated the snappyHexMeshDict (snappyHexMeshDict1 and snappyHexMeshDict2) as suggested.

I run first:
Quote:
snappyHexMesh -dict system/snappyHexMeshDict1
but the simulation got stucked (see picture).

I provide you some pictures of my geometry and also the simulation where it got stuck.


Thank you very much
Attached Images
File Type: png geometry reactor.PNG (182.5 KB, 52 views)
File Type: jpg geometry reactor2.jpg (60.2 KB, 49 views)
File Type: png snappyHexMeshDict1.PNG (29.3 KB, 36 views)
troth is offline   Reply With Quote

Old   October 1, 2021, 11:00
Default
  #9
New Member
 
troth
Join Date: May 2021
Posts: 19
Rep Power: 5
troth is on a distinguished road
Dear Yann,

I used the surfaceFeatureConvert utility and took a look at the edges. I think they are looking fine (see e.mesh in attachments)

I also provide you more pictures of my geometry.

Any idea?

Thank you!
Attached Images
File Type: png geometry reactor.PNG (182.5 KB, 29 views)
File Type: jpg geometry reactor2.jpg (60.2 KB, 24 views)
File Type: png e.mesh.PNG (87.9 KB, 55 views)
troth is offline   Reply With Quote

Old   October 1, 2021, 11:44
Default
  #10
Senior Member
 
Yann
Join Date: Apr 2012
Location: France
Posts: 1,236
Rep Power: 29
Yann will become famous soon enoughYann will become famous soon enough
Hi Troth,


Quote:
Originally Posted by troth View Post
Dear Yann,

I used the surfaceFeatureConvert utility and took a look at the edges. I think they are looking fine (see e.mesh in attachments)

I also provide you more pictures of my geometry.

Any idea?

Thank you!
Your edges look good indeed, I don't see why you don't get a better feature line snapping.

How many cells do you have in your final mesh?
Since you did not post you full snappyHexMeshDict, do you also extrude layers on your walls? If yes, can you run a test with "addLayers false;" ?
Did you modify the default mesh quality parameters?


I would also comment the mergePatchFaces flag and set the resolveFeatureAngle back to 30.

If you run another test, please post the snappyHexMesh log file so we can have a look at it.


Yann
hogsonik and troth like this.
Yann is offline   Reply With Quote

Old   October 1, 2021, 15:41
Default
  #11
Member
 
Join Date: May 2017
Posts: 31
Rep Power: 9
sqek is on a distinguished road
Quote:
If I understand well, you suggest to divide the snappyHexMeshDict in 2, one with the top and bottom and the other with inflow, outflow and wells. In addition, I should "enlarge" the cylinders at the well.stl to ensure that it will then be cut at the correct angle. Should both snappyHexMeshDict files contain the reactor.stl (the whole geometry) in the geometry section?, or is it enough that its mention only in snappyHexMeshDict1 as you wrote it in your answer.
Yes that's the idea - use snappyhexmesh to make a longer cylinder (where messy ends don't matter), then cut the ends off separately - at least for me that's worked in the past - especially because you can then use different settings for the second one and really fine-tune

It looks like you're using the reactor geometry from reactor.stl in refinementRegions - you probably want to only refine everything once, so snappyhexmeshdict1 has reactor.stl and refinementRegions, snappyhexmeshdict2 doesn't need it in the geometry and has an empty entry for refinementRegions
(including unneeded files in the geometry doesn't cause any problems though - it only does something if theres a refinementRegion/refinementSurface with the same name)

With it getting stuck: is your extended cylinder closed (as in does it have closed ends?) or does it extend outside of the mesh?
In each snappyHexMeshDict, you want the collection of surfaces you specify (in geometry and refinementSurfaces) to topologically split the mesh - so you can't go from inside to outside without crossing a surface. If there's a gap/hole somewhere, it won't know which cells to keep and which to get rid of, and if its refining and keeping the entire base mesh that could be why its stopping.

Roughly how many cells are you aiming for? The screenshot of the log you posted says 10 million points, which seems like a lot for something you're still experimenting with - maybe make a copy with a much coarser initial mesh (lower cell count by a factor of 10 in each direction perhaps, to get ~10k rather than 10 million), to test on - that way it'll take much less time to snap and you can try different things quicker
troth likes this.
sqek is offline   Reply With Quote

Old   October 4, 2021, 10:32
Default
  #12
New Member
 
troth
Join Date: May 2021
Posts: 19
Rep Power: 5
troth is on a distinguished road
Hi Yann, thanks again for your reply.

Quote:
Originally Posted by Yann View Post
How many cells do you have in your final mesh?
My mesh has 1.6 M cells.
Quote:
Since you did not post you full snappyHexMeshDict, do you also extrude layers on your walls? If yes, can you run a test with "addLayers false;" ?
I read that when you start with SnappyHexMesh, its better to leave the addLayers as false. Since Im just starting I have never turn it true.
Quote:
Did you modify the default mesh quality parameters?
I havent change any parameter there.
Quote:
If you run another test, please post the snappyHexMesh log file so we can have a look at it.
I attached the meshqualityDict SnappyHexMeshDict and the snappyHexMesh log file.


Thank you very much!
Attached Files
File Type: zip snappyHexMesh.zip (10.7 KB, 5 views)
troth is offline   Reply With Quote

Old   October 4, 2021, 12:27
Default
  #13
New Member
 
troth
Join Date: May 2021
Posts: 19
Rep Power: 5
troth is on a distinguished road
Hi sqek, thanks a lot for taking the time to answer me.
Unfortunately, Im just starting with snappyHexMesh and I have lot of questions about your comment, which are perhaps quite basic .

Quote:
Originally Posted by sqek View Post
Yes that's the idea - use snappyhexmesh to make a longer cylinder (where messy ends don't matter), then cut the ends off separately
When you suggested to modify the walls.stl, I actually did it in sketchup and enlarge the cylinder only of the wall.stl geometry. When you say "use snappyhexmesh to make a longer cylinder", how should I do that? I mean how can I modify the stl using SHM?.

Quote:
Originally Posted by sqek View Post
With it getting stuck: is your extended cylinder closed (as in does it have closed ends?)or does it extend outside of the mesh? In each snappyHexMeshDict, you want the collection of surfaces you specify (in geometry and refinementSurfaces) to topologically split the mesh - so you can't go from inside to outside without crossing a surface. If there's a gap/hole somewhere, it won't know which cells to keep and which to get rid of, and if its refining and keeping the entire base mesh that could be why its stopping.
I wanted to test your suggestion and I only enlarged the wall.stl in the +z direction in Sketchup (therefore I expected that at least the cut between top and walls should be alright). My wall.stl is composed by open cylinders, and if I consider for the snappyHexMeshDict1: walls + inflow+outflow I will have an open geometry. Same for SnappyHexMeshDict2 with the top+bottow. Therefore Im not sure if I understand well what you mean, since if I divide my whole geometry in 2 "groups" then they will form open geometries...I attached a screenshot of the collection of surfaces that will be consider for each snappyHexMeshDict.

Quote:
Originally Posted by sqek View Post
Roughly how many cells are you aiming for? The screenshot of the log you posted says 10 million points
Im still not so sure how many cells I wanna have for my mesh. I haven't done any special refinement until now since I want to solve this "edge" issue first and then improve it. Now, the mesh is composed by 1.6M cells but it takes around 3 min to run, I think it is ok for experimenting....

If my eMesh files are looking alright, do you still think that the problem should be solved by making longer the cylinder?...(in my other answer I posted screenshot of my eMesh)

Thanks again for taking the time to answer and explain
Attached Images
File Type: png SHM1 - walls+inflow+outflow.PNG (50.2 KB, 35 views)
File Type: png SHM2 - top+bottom.PNG (9.1 KB, 20 views)
troth is offline   Reply With Quote

Old   October 5, 2021, 06:56
Default
  #14
Member
 
Join Date: May 2017
Posts: 31
Rep Power: 9
sqek is on a distinguished road
Quote:
When you suggested to modify the walls.stl, I actually did it in sketchup and enlarge the cylinder only of the wall.stl geometry. When you say "use snappyhexmesh to make a longer cylinder", how should I do that? I mean how can I modify the stl using SHM?.
Sorry I probably wasn't clear enough - I meant to create a longer cylinder, with the ends extending past your initial blockMesh, using sketchup/etc, and then use that in snappyHexMesh to make a cylindrical mesh

I've put together a quick simplified demo case, and got some screenshots attached here

the green surfaces are stls

In the first one, the ends of the open cylinder extend past the original blockmesh, so the boundary of the blockmesh closes it - basically, you can't get from the inside to the outside of the cylinder by moving point-to-point along the mesh, without crossing it

In the second one, the first snappyhexmeshdict has made a cylinder and cut away the rest, and the end stls are shown

In the third one, the second snappyhexmeshdict has cut the ends off the mesh

hopefully this explains it better than another wall of text would

And if you decrease the numbers in your blockmeshdict (assuming you're using blockmesh for the initial background mesh?) by a bit, it'll take seconds to run rather than minutes, so you can adjust settings faster and get near-instant feedback on whether its worked
Attached Images
File Type: png cylinder stl and blockmesh.png (95.2 KB, 53 views)
File Type: png after first snappyhexmesh with end stls.png (116.6 KB, 60 views)
File Type: png after second snappyhexmesh.png (94.0 KB, 59 views)
troth likes this.
sqek is offline   Reply With Quote

Old   October 6, 2021, 05:19
Default
  #15
Senior Member
 
Yann
Join Date: Apr 2012
Location: France
Posts: 1,236
Rep Power: 29
Yann will become famous soon enoughYann will become famous soon enough
Hi Troth,


Would it be possible for you to share your case here, including your STL files so we can have a closer look?


Yann
Yann is offline   Reply With Quote

Old   October 11, 2021, 13:00
Default
  #16
New Member
 
troth
Join Date: May 2021
Posts: 19
Rep Power: 5
troth is on a distinguished road
Quote:
Originally Posted by sqek View Post
Sorry I probably wasn't clear enough -
Hi Sqek,

Sorry for the late response, I haven't had time to look at it before...
Thank you very much for explaining so clearly, now I do understand what you were saying. Thanks!!

I am going to run an example similar to the one you made, to test if your suggestion works for me and I'll post the results, but it comes to my mind one small question. For the first step, did you use surfaceFeatureExtract to generate the cylinder.emesh? if this cylinder edges are outside the blockMesh, isn't it problematic?...

Thanks in advance!!
troth is offline   Reply With Quote

Old   October 11, 2021, 13:19
Default
  #17
New Member
 
troth
Join Date: May 2021
Posts: 19
Rep Power: 5
troth is on a distinguished road
Quote:
Originally Posted by Yann View Post
Hi Troth,
Would it be possible for you to share your case here, including your STL files so we can have a closer look?
Yann
Hi Yann,
yes of course. Here I attach the case. Because of the size, I had to separate the geometry and upload the reactor geometry (total volume) in a separate Zip (so this reactor.stl comes inside the triSurface folder with the rest of the stl files). I also had to eliminate the polyMesh, eMesh and extendedFeatureEdgeMesh since it was too heavy but I supposed it's not a problem since the blockMeshDict, and surfaceFeatureExtractDict are incorporated.

I know that the mesh does not close in the outflow pipe, but I want to solve first the edge problem and then fix that (I guess with higher refinement should solved).

Thank you ver much for your time!
Attached Files
File Type: zip pitzDaily.zip (121.7 KB, 4 views)
File Type: zip reactor.zip (112.8 KB, 7 views)
troth is offline   Reply With Quote

Old   October 11, 2021, 14:45
Default
  #18
Senior Member
 
Yann
Join Date: Apr 2012
Location: France
Posts: 1,236
Rep Power: 29
Yann will become famous soon enoughYann will become famous soon enough
Hi Troth,

Thank you for uploading your case. I did run it and it seems the issue is related to the fact you are meshing independent surfaces in surfaceRefinement.

If you use the reactor.stl instead, the snapping works fine with your current settings. I uploaded a screenshot, and here is the snappyHexMeshDict:

Code:
geometry
{

    reactor.stl
    {
        type triSurfaceMesh;
        name reactor;
    }

}

// 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 1000000; //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 10;

    // 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 "reactor.eMesh";
        level 0;   
        }
    
    );


    // 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
    {
    reactor
        {
            // Surface-wise min and max refinement level
            level (0 0);

            // Optional specification of patch type (default is wall). No
            // constraint types (cyclic, symmetry) etc. are allowed.

        }
     }
I did not make any changes beyond this. You just have to generate the eMesh file for the reactor.stl file.

Doing so, you loose the surfaces names in your geometry and you end up with one single patch named "reactor" for your whole geometry.

You can solve this issue by naming and concatenating your surfaces into one single STL file. This way you can get a proper snapping AND get your patches right. There must be resources about that on the internet or right here on the forum but we can elaborate about this later if you need.

Cheers,
Yann
Attached Images
File Type: jpg mesh.jpg (194.9 KB, 98 views)
AtoHM and troth like this.

Last edited by Yann; October 12, 2021 at 09:19. Reason: Typo
Yann is offline   Reply With Quote

Old   October 12, 2021, 06:29
Default
  #19
New Member
 
troth
Join Date: May 2021
Posts: 19
Rep Power: 5
troth is on a distinguished road
Quote:
Originally Posted by Yann View Post
Hi Throth,
Hi Yann,

Thank you!! I just run it as you did and it finally works properly! . I did it that way, since I saw many tutorials on youtube where they separated the surfaces in different stl, I thought it was the best way to do it. Anyway, I'm going to name the surfaces in a single stl as you suggest.

Thank you very much for your big help!

Greetings,

Troth
Yann likes this.
troth is offline   Reply With Quote

Old   October 22, 2021, 06:28
Default
  #20
New Member
 
troth
Join Date: May 2021
Posts: 19
Rep Power: 5
troth is on a distinguished road
Hello again,

I think I proceed as suggested but I'm stuck again...
  • I did not find a way to name the surfaces with the software Im using for the geometry (Sketchup pro), so I manually copied each stl surface text (inflow, outflow, top etc....) into one stl file named reactor.stl using an editor. I opened it using paraview and it looks good.
  • I generated only reactor.eMesh. I took a look and it seems also fine.
  • I modified snappyHexMeshDict as follow: (I know it's very course, but it's only to test if it works.
Code:
geometry
{  
    reactor.stl
    {
        type triSurfaceMesh;
        name reactor;
    regions 
    {
        inflow
            {
                name inflow;
            }
        outflow
            {
                name outflow;
            }
        top
            {
                name top;
            }
        bottom
            {
                name bottom;
            }
        walls
            {
                name walls;
            }        
    }
    }
};

// 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 1000000; //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 10;

    // 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 "reactor.eMesh";
    level 0;   
    }
        
    );


    // 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
    {
    reactor
        {
                level (2 2);
        regions
        {
                inflow
                {
                    level   (1 1);
                    patchInfo
                    {
                        type wall;
                    }
                }
                outflow
                {
                    level   (1 1);
                    patchInfo
                    {
                        type wall;
                    }
                }        
                top
                {
                    level   (1 1);
                    patchInfo
                    {
                        type patch;
                    }
                }
                bottom
                {
                    level   (1 1);
                    patchInfo
                    {
                        type patch;
                    }
                }        
                walls
                {
                    level   (1 1);
                    patchInfo
                    {
                        type patch;
                    }
                }        
            }
    }      
    }    

    // Resolve sharp angles
    resolveFeatureAngle 30; //0;


    // 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
    {
    }
It works, but with the same issue with the edges...
I don't know how else I can try to do it since I need to have the different patches defined to set the different refinements and later define the boundary conditions...I attached the case.

any idea?

Thank you very much!
Attached Files
File Type: zip pitzDaily.zip (121.3 KB, 1 views)
troth is offline   Reply With Quote

Reply


Posting Rules
You may not post new threads
You may not post replies
You may not post attachments
You may not edit your posts

BB code is On
Smilies are On
[IMG] code is On
HTML code is Off
Trackbacks are Off
Pingbacks are On
Refbacks are On


Similar Threads
Thread Thread Starter Forum Replies Last Post
[snappyHexMesh] snappyHexMesh <-> dynamicMeshDict problem with protected cells Billy_16 OpenFOAM Meshing & Mesh Conversion 2 November 21, 2020 04:34
[snappyHexMesh] snappyHexMesh does not create any mesh except one for the reference cell Arman_N OpenFOAM Meshing & Mesh Conversion 1 May 20, 2019 18:16
[snappyHexMesh] snappyHexMesh inclinced surface snapping problem Swift OpenFOAM Meshing & Mesh Conversion 19 January 18, 2017 05:42
[snappyHexMesh] sHM layer process keeps getting killed MBttR OpenFOAM Meshing & Mesh Conversion 4 August 15, 2016 04:21
[snappyHexMesh] SnappyHexMesh in Parallel problem swifty OpenFOAM Meshing & Mesh Conversion 10 November 6, 2015 05:40


All times are GMT -4. The time now is 14:12.