[gian93]

hi guys !

some days ago i'm wondering if there was any effective difference/improvement in the quality of the mesh generation between of-v1806 and older (such as of v1612) ..
I make some test and i noticed that in the v1806 the aspect ratio parameter is definitely higher than the older versions.. why? i' ve fixed my snappy dict and my geometry and I only changed the of version for the snappyHexMesh utility.
It sounds quite stange and maybe it is related to some additional features in the new version that i do not take into account..
anyone have an idea?

[dybuk]

Hi
I think you should look into relase notes of v1806
https://openfoam.com/releases/openfo...-bug-fixes.php
Behavior of featureAngle parameter for layer generation stage was changed.

[gian93]

hi! tanks for reply !
i' ve alrady see that page. My original featureAngle was set to 350, so it should not be affected by that bug. is it correct?

However , i'm playing with layer thikness and featureAngle settings..

[gian93]

neither of 6 seems to be different... anybody can help me?

[wyldckat]

Quick questions:

Originally Posted by gian93

My original featureAngle was set to 350, so it should not be affected by that bug. is it correct?

Do you mean 350 or 35.0? Because 350 is likely not a valid value (e.g. may have acted as 180) and may have been corrected to no longer support that value (e.g. now it might ignore the value)...

Originally Posted by gian93

neither of 6 seems to be different...

I didn't understand what you wrote here... Were you indicating that even with OpenFOAM 6 have gotten the same result?




Beyond this, what was the previous version of snappyHexMesh that worked correctly for your case?

[gian93]

Hi wyldcat!
I'm not the author of the original snappyHexMeshDict (made originally on a case built for the version of1612) , but i have only to make a comparison test between different version of OpenFOAM using the same snappyhexMeshDict.
i'm going to compare the behaviour (and quality output) of snappyHexMesh of the version of1806 and OpenFOAM 6 whit the older version of1612.

With of1612 version all works properly and the aspect ratio results seems to have a good quality output . I confirm to ypu that the original featureAngle is set to 350 deg . What does such a high value of featureAngle means in the specific version of of1612?

I didn't understand what you wrote here... Were you indicating that even with OpenFOAM 6 have gotten the same result?

i'm indicating that even with OpenFOAM 6 i have gotten the same result

i've made some test using in of1806 a featureAngle of 180 deg but no improvement appears effective

[wyldckat]

Greetings gian93,


Here is what I can find by investigating the Git history of the OpenFOAM-plus development repository that is available at http://develop.openfoam.com

• From commit 6e0a54d0a9642c63cb4a2c0853e08b4211d47809:

  canonical parameter name changed from "minMedianAxisAngle" to "minMedialAxisAngle" (DEC-2013), but was never previously reported as having changed.

  But it should still work as intended with any version.
• From commit 3b8c644b90cf1ecf17ecf4026a060157ef92eee7:
  

  ENH: snappyHexMesh: Remove cells inside any limitRegion with level -1. Fixes #852.

• From commit cebec5cfb0b6a1a3f0cb0155557e499aae28d528:
  

  ENH: change findCell mode in meshRefinement (issue #805)
  
  - in 2.4.x the general default for polyMesh::findCell was FACE_DIAG_TRIS,
  but this was changed to CELL_TETS for better handling of concave
  cells.
  
  - in snappyHexMesh meshRefinement, findCell is used to define
  locations in mesh and cells for closer refinement. Using CELL_TETS
  causes an octree rebuild when the mesh has changed and this adds
  considerable overhead. For this operation, the faster FACE_DIAG_TRIS
  mode can be used instead.

• From commit 10f259ccf0cf83954bb765410fb7d6d254d8dac5:
  

  ENH: snappyHexMesh: exclude feature angle analysis. See #699.
  

  -    if (minCos < 1-SMALL)
  +    if (minCos < 1-SMALL && minCos > -1+SMALL)

  This is currently my main suspect.
• 4de0779c5abfdc72003ac0268161a8b2f7cc60c7:
  

  ENH: shm: Parallel consistent extrusion. Fixes #759.

• 2e4d503cd26b8afef27960cb615be9925b5dc374:
  

  BUG: snappyHexMesh: make corner-point detection compatible with cutting

• 7ad649a44837f190f30697c028ee663eedc7ac2f:
  

  BUG: snappyHexMesh: incorrect feature angle. Fixes #699.
  

  -------- src/mesh/snappyHexMesh/snappyHexMeshDriver/snappyLayerDriver.C --------
  index fd33ec7..7b4db14 100644
  @@ -668,7 +668,7 @@ void Foam::snappyLayerDriver::handleFeatureAngle
   (
       const indirectPrimitivePatch& pp,
       const labelList& meshEdges,
  -    const scalar minCos,
  +    const scalar minAngle,
       pointField& patchDisp,
       labelList& patchNLayers,
       List<extrudeMode>& extrudeStatus
  @@ -676,7 +676,10 @@ void Foam::snappyLayerDriver::handleFeatureAngle
   {
       const fvMesh& mesh = meshRefiner_.mesh();
   
  -    Info<< nl << "Handling feature edges ..." << endl;
  +    const scalar minCos = Foam::cos(degToRad(minAngle));
  +
  +    Info<< nl << "Handling feature edges (angle < " << minAngle
  +        << ") ..." << endl;
   
       if (minCos < 1-SMALL)
       {
  @@ -3647,7 +3650,7 @@ void Foam::snappyLayerDriver::addLayers
           (
               pp,
               meshEdges,
  -            degToRad(layerParams.featureAngle()),
  +            layerParams.featureAngle(),
   
               patchDisp,
               patchNLayers,

  This is a major suspect as well.
• 85b7fb582a55c164ba6ca5674702180f3cf506d9:
  

  BUG: snappyHexMesh: calculate surface normals if face splitting. Fixes #522.

Given that 350 degrees gives around 6.1 radians, which was assigned to "minCos"; but in the new calculation this value is always bounded between 1 and -1, and with "minCos = cos(6.1) = 0.9943..." this means that this:

 if (minCos < 1-SMALL && minCos > -1+SMALL)

now always happens, while in the past it never happened for 350 degrees.


Therefore, you will have to either set it to 180 degrees to get a similar result to the past one... uh, but you already tested that and it didn't work.


OK, a few more questions/suggestions:

1. Are you running snappyHexMesh in parallel or always in serial mode?
2. Don't use the "-overwrite" argument when running snappyHexMesh with both OpenFOAM versions. Then inspect the mesh differences for the first time step, which will either be 0.0 or 1.0 or whichever the time step defined in "controlDict". Because this should show the mesh before snapping and if new cells are left in the mesh or removed from the mesh, it would explain the problem you are seeing.
   • Related to this, there are a few options in the "castellatedMeshControls" block which may be useful for you:
     

         // Optional: do not remove cells likely to give snapping problems
         // handleSnapProblems false;
     
         // Optional: switch off topological test for cells to-be-squashed
         //           and use geometric test instead
         //useTopologicalSnapDetection false;
     
         // Optional: do not refine surface cells with opposite faces of
         //           differing refinement levels
         //interfaceRefine false;
     
         // Optional: use an erosion instead of region assignment to allocate
         //           left-over cells to the background region (i.e. make cellZones
         //           consistent with the intersections of the surface).
         //           Erosion is specified as a number of erosion iterations.
         //           Erosion has less chance of bleeding and changing the zone
         //           for a complete region.
         //nCellZoneErodeIter 2;

3. Beyond this, try to use Meld or any other text comparison software, to compare your "snappyHexMeshDict" file and the file "$FOAM_UTILITIES/mesh/generation/snappyHexMesh/snappyHexMeshDict", which has a complete feature list that snappyHexMesh supports.

Best regards,
Bruno

[gian93]

Hy wyldcat ! thanks for your reply , sorry if i text you only now but in this weeks i'm involved in others stuff ...
in the next days i' ll try to follow your advice!
i'm running in parallel (anyway test mesh dimension is quite small 1,5*10^6 cells)
thanks !