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

[snappyHexMesh] How to force cells to snap and adapt to a line contained in the domain?

Register Blogs Community New Posts Updated Threads Search

Like Tree9Likes
  • 3 Post By Yann
  • 2 Post By finn_amann
  • 3 Post By Yann
  • 1 Post By finn_amann

Reply
 
LinkBack Thread Tools Search this Thread Display Modes
Old   September 16, 2022, 13:22
Default How to force cells to snap and adapt to a line contained in the domain?
  #1
New Member
 
Join Date: Dec 2021
Posts: 27
Rep Power: 4
finn_amann is on a distinguished road
Hello friends,

I am trying to create a rectangular mesh consisting of mostly rectangular cells. A wavy line is placed inside the mesh and I want the cells to mesh and refine along that.

To give you a better understanding, I attached two screenshots.

The first one simply shows us the rectangular mesh. It has a certain resolution in the xy-plane and only one cell in the z-direction resulting in a 3D box shape (do people call this 2.5D?).

The second screenshot shows us the box but in wireframe representation. The mentionend "line" is also visible, but since we operate in 3D, the line is actually a surface (not a solid, not a volume, just a surface), which is stored in an STL-file created with gmsh.

My idea was to use snappyHexMesh to force the line into the mesh and make the cells snap to it and refine the area around the line a bit (think about the xy-plane, then this sentence makes more sense). Keep in mind, I don't want any internal faces, boundaries or baffles, I simply want the line inside the mesh and the surrounding cells to adapt to it.

Now, I have briefly worked with snappyHexMesh before, however, I only worked with volumes that I cut out of other volumes, resulting in new boundaries and faces and all that.

This time, although snappyHexMesh doesn't give me an error, the mesh stays unchanged after execution.

Now, before I post any dicts, full cases or terminal outputs, I want to hear your opinion on this approach. Am I am trying to do something that one simply shouldn't do with snappyHex? At first, this seemed like an easy task, but now I'm not so sure anymore. Do I need to use some kind of other feature from OpenFOAM? I read something about surfaceFeatureExtract, createBaffle and topoSet but I couldn't really find any information that sounded useful to my case.


I know, I can simply achieve my goal by using gmsh, but I've had really bad experiences with gmsh and OpenFOAM when it comes to the performance of the solver that I'll be using. I think it's also possible to already incorporate these wavy splines in blockMesh, but I don't think blockMesh offers any of the snapping and refining of snappyHex, which is why I want to do this with snappyHex in the first place.

Let me know what you think!

Best regards
Finn
Attached Images
File Type: jpg box_only.jpg (157.7 KB, 32 views)
File Type: jpg wireframe_with_sheet.jpg (162.4 KB, 43 views)
finn_amann is offline   Reply With Quote

Old   September 19, 2022, 03:34
Default
  #2
Senior Member
 
Yann
Join Date: Apr 2012
Location: France
Posts: 1,068
Rep Power: 26
Yann will become famous soon enough
Hi Finn,

Try something like this:

Code:
refinementSurfaces
{
	yourSurface
	{
		level (1 1); // whatever refinement you want to apply on the surface
		faceZone	yourName;
	}
}
This should do what you are looking for. And you can use the same surface in refinementRegions in distance mode in order to control the refinement in the vicinity of the surface.

Cheers,
Yann
AtoHM, hogsonik and finn_amann like this.
Yann is offline   Reply With Quote

Old   September 23, 2022, 02:43
Default
  #3
New Member
 
Join Date: Dec 2021
Posts: 27
Rep Power: 4
finn_amann is on a distinguished road
Hey Yann,

thanks for the tip. I've learned a lot over the last couple of days. The level parameter you mentioned in the refinementSurfaces sub-dictionary was definitely one of the things that were important and worked instantly for me. Btw, I read your name in many of the posts, so thanks for helping people

To achieve "real snapping" I also had to extract the feature edge and include the resulting eMesh file as feature castellatedMeshControls sub-dictionary. If I didn't do this, the edges were just approximately fitted. This way, the exact shape of my stl was considered.

One thing, that didn't do anthing good for me was the nCellsBetweenLevels parameter, which only worked for a value of 2, anything higher than that resulted in the same mesh as for a value of 1. After trying to manipulate it, I eventually just set it to 1 and refined my mesh via the refinementRegions and its mode distance. This also allowed to just set the level parameter in the refinementSurfaces to 0.

Furthermore, I had to somehow keep SHM from creating a new boundary from my stl-file since it was just a thin slice that I wanted to consider in the meshing process. I was able to achieve this by not creating regions when defining the geometry in the geometry sub-dictionary. Additionally, I created a faceZone for my geometry in the refinementSurfaces sub-dictionary. Without the declaration of a faceZone, SHM created a boundary and even created some holes at the location of my geometry.

Lastly, I had to use the extrudeMesh utility to create a 2D mesh out of my results.

I attached my snappyhexMeshDict just in case anyone is interested in this.

Feel free to correct me if you noticed that I misunderstood anything.

Best regards
Finn

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

castellatedMesh true;
snap            true;
addLayers       false;

geometry
{
    duneSurface.stl // STL filename
    {
        type triSurfaceMesh;
        name dunes;  // User-defined patch name
    }
};

castellatedMeshControls
{
    maxLocalCells       1000000;
    maxGlobalCells      2000000;
    maxLoadUnbalance    0.1;
    minRefinementCells  0;
    nCellsBetweenLevels 1;
    resolveFeatureAngle 10;

    features
    (
        {
            file "duneSurface.eMesh";
            level 1;
        }
    );

    refinementSurfaces
    {
        dunes
        {
            level (0 0);
            faceZone dunes;
        }
    }
    refinementRegions
    {
        dunes
        {
            mode distance;
            levels
            (
                (0.01 3) // refinement level 3 between 0 mm and 5 mm.
                (0.05 2) // refinement level 2 between 5 mm and 15 mm.
                (0.1 1)  // refinement level 1 between 5 mm and 50 mm.
            );
        }
    }

    locationInMesh (1.701234 0.0101234 0.004);

    allowFreeStandingZoneFaces true;
}

snapControls
{

    nSmoothPatch    3;
    // nSmoothInternal 3;
    tolerance       2.0;
    nSolveIter      100;
    nRelaxIter      5;

    nFeatureSnapIter 10;

    explicitFeatureSnap    true;
    multiRegionFeatureSnap false;
    implicitFeatureSnap    false;
}

addLayersControls
{

    relativeSizes true;

    layers
    {
    }

    expansionRatio 1.0;

    finalLayerThickness 0.3;

    minThickness 0.25;

    nGrow 0;

    featureAngle 60;

    nRelaxIter 5;

    nSmoothSurfaceNormals 1;

    nSmoothNormals 3;

    nSmoothThickness 10;

    maxFaceThicknessRatio 0.5;

    maxThicknessToMedialRatio 0.3;

    minMedianAxisAngle 90;

    nBufferCellsNoExtrude 0;

    nLayerIter 50;

    nRelaxedIter 20;
}

meshQualityControls
{

    maxNonOrtho 65;

    maxBoundarySkewness 20;

    maxInternalSkewness 4;

    maxConcave 80;

    minVol 1e-13;

    minTetQuality 1e-15;

    minArea          -1;

    minTwist          0.02;

    minDeterminant    0.001;

    minFaceWeight     0.05;

    minVolRatio       0.01;

    minTriangleTwist -1;

    nSmoothScale   4;

    errorReduction 0.75;

    relaxed
    {
        maxNonOrtho   75;
    }
}

mergeTolerance 1e-6;
Yann and hogsonik like this.
finn_amann is offline   Reply With Quote

Old   September 23, 2022, 06:54
Default
  #4
Senior Member
 
Yann
Join Date: Apr 2012
Location: France
Posts: 1,068
Rep Power: 26
Yann will become famous soon enough
Hi Finn,

I am glad I could help!

Quote:
Originally Posted by finn_amann View Post
One thing, that didn't do anthing good for me was the nCellsBetweenLevels parameter, which only worked for a value of 2, anything higher than that resulted in the same mesh as for a value of 1. After trying to manipulate it, I eventually just set it to 1 and refined my mesh via the refinementRegions and its mode distance. This also allowed to just set the level parameter in the refinementSurfaces to 0.
This is not the expected behavior for nCellsBetweenLevels. You can have a look at this thread which discuss similar issues: SnappyHexMesh Refinement nCellsBetweenLevels

In your case, this is either a bug or a problem related to you setup.
How many cells do you have in your final mesh?

The parameters below limit your mesh to a maximum of 2 millions cells and 1 million cells/core.

Code:
    maxLocalCells       1000000;
    maxGlobalCells      2000000;
If you reach this limit, snappy will stop refining the mesh and will move on to the next steps. Your mesh might not respect some parameters defined in your snappyHexMeshDict. There should be messages in your log file noticing you reached the limit defined by maxLocalCells or maxGlobalCells.

Quote:
Originally Posted by finn_amann View Post
Furthermore, I had to somehow keep SHM from creating a new boundary from my stl-file since it was just a thin slice that I wanted to consider in the meshing process. I was able to achieve this by not creating regions when defining the geometry in the geometry sub-dictionary.
I am not sure what you meant, would you mind to elaborate?

Quote:
Originally Posted by finn_amann View Post
Code:
refinementRegions
    {
        dunes
        {
            mode distance;
            levels
            (
                (0.01 3) // refinement level 3 between 0 mm and 5 mm.
                (0.05 2) // refinement level 2 between 5 mm and 15 mm.
                (0.1 1)  // refinement level 1 between 5 mm and 50 mm.
            );
        }
    }
It seems there is a misunderstanding here. Your setup means you refine to:
  • level 3 at a distance of 0.01m from your surface
  • level 2 at a distance of 0.05m from your surface
  • level 1 at a distance of 0.1m from your surface

If this is not the result your get, then it means there is something going on with your setup. It could also be related to the issue I was mentioning before with maxGlobalCells/maxLocalCells.

Everything else sounds good to me: feature edges to get proper snapping, faceZones to snap on a face without creating a patch, using extrudeMesh to get a 2 mesh... All good!

Cheers,
Yann
AtoHM, hogsonik and finn_amann like this.
Yann is offline   Reply With Quote

Old   September 23, 2022, 08:53
Default
  #5
New Member
 
Join Date: Dec 2021
Posts: 27
Rep Power: 4
finn_amann is on a distinguished road
Hey Yann,

Quote:
This is not the expected behavior for nCellsBetweenLevels. You can have a look at this thread which discuss similar issues: https://www.cfd-online.com/Forums/op...eenlevels.html

In your case, this is either a bug or a problem related to you setup.
How many cells do you have in your final mesh?

The parameters below limit your mesh to a maximum of 2 millions cells and 1 million cells/core.
Code:
maxLocalCells       1000000;
maxGlobalCells      2000000;
If you reach this limit, snappy will stop refining the mesh and will move on to the next steps. Your mesh might not respect some parameters defined in your snappyHexMeshDict. There should be messages in your log file noticing you reached the limit defined by maxLocalCells or maxGlobalCells.
Yes, I also read that thread and found it quite useful. The thread mentions the Wiki-post in which there is a section about "what to do when it doesn't look like SHM is not respecting the value you've defined". It says:

Quote:
And what about when it doesn't look like it's respecting at all the value you've defined?

1. Well, keep in mind the layer indicated earlier in this subsection: what matters is that the cells are all at the same distance from a particular wall... and if the algorithm has got a hard time figuring out to which wall it was meant to be measuring the distance, then it makes it a lot harder to figure out where the layers should change resolution.
2. The other possibility is that the algorithm is trying to be conservative and/or is respecting the parameter minRefinementCells.
3. Or perhaps the parameters maxLocalCells and/or maxGlobalCells are the constraint that limits the how many refinement layers can in fact be used, without going over the requested limit.
In my case, it's probably the first point, as I have no warnings concerning the maxLocalCells and/or maxGlobalCells in my log.
The parameter minRefinementCells did not seem to have any influence whatsoever in my case.
It's probably setup related, as I have used nCellsBetweenLevels in a prior example successfully. However, the thread you linked also mentions the workaround I already employed which is mode distance and I'm happy with that.

Quote:
Quote:
Furthermore, I had to somehow keep SHM from creating a new boundary from my stl-file since it was just a thin slice that I wanted to consider in the meshing process. I was able to achieve this by not creating regions when defining the geometry in the geometry sub-dictionary.
I am not sure what you meant, would you mind to elaborate?
I made a mistake here. I was talking about the regions that you can define for your stl-file in the geometry sub-dictionary. Example:

Code:
duneSurface.stl // STL filename
    {
        type triSurfaceMesh;
        name dunes;  // User-defined patch name
        regions
        {
            dunesurfaces { name dunesurfaces; }
        }
    }
I thought, I had to omit the regions part, but I just tested it again and it does not matter. Only the definition of a faceZone is needed to omit the creation of a patch and an entry in the polyMesh/boundary file. I probably thought this was the way to go because I forgot to delete some old polyMesh data and only saw older entries.

Quote:
It seems there is a misunderstanding here. Your setup means you refine to:
  • level 3 at a distance of 0.01m from your surface
  • level 2 at a distance of 0.05m from your surface
  • level 1 at a distance of 0.1m from your surface
Another small mistake on my part, sorry. Those comments were referring to older values, but thanks for pointing it out again.

Stuff seems to be working right now, thank you Yann

Best regards,
Finn
Yann likes this.
finn_amann is offline   Reply With Quote

Old   September 23, 2022, 09:47
Default
  #6
Senior Member
 
Yann
Join Date: Apr 2012
Location: France
Posts: 1,068
Rep Power: 26
Yann will become famous soon enough
Hi Finn,

Thanks for your feedback, it seems we are all good then!

minRefinementCells will have no effect on your refinement levels but it is useful when snappy get stuck trying to refine few cells during refinement iterations.
https://www.openfoam.com/documentati...efinementCells

Regards,
Yann
Yann 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] Snappy creates strange cells far away from boundary vainilreb OpenFOAM Meshing & Mesh Conversion 3 December 16, 2020 05:11


All times are GMT -4. The time now is 18:23.