View Issue Details

IDProjectCategoryView StatusLast Update
0003361OpenFOAMBugpublic2021-12-07 12:25
Reporterniklas.wikstromAssigned Tohenry 
Status resolvedResolutionfixed 
Platformx86_64OSFedoraOS Version29
Product Versiondev 
Fixed in Version 
Summary0003361: snappyHexMesh region refinement contaminates entire geometry facet
DescriptionA distance refinement region sometimes refines entire triSurface facet. This happens when a refinement region entry specifies a distance that crosses at least one of the facet's edges.

The problem occurs in parallel or serial runs and with OpenFOAM versions 5 to dev (7).

On a geometry that has this problem it is allways reproducable, but manually generating a similar geometry to reproduce the problem is difficult.
Steps To ReproduceExtract attached snappyBugReportRoom.tgz, run blockMesh and snappyHexMesh.
Additional InformationThe image file, attached, shows the overly refined facet and visualizes the distance refinement geometry object (pink), pointed at by the yellow line.
TagsNo tags attached.



2019-10-07 11:12


geomFacetRef.png (928,134 bytes)
snappyBugReportRoom.tgz (4,846 bytes)


2019-10-07 11:14

reporter   ~0010802

Forgot to add: This issue is caused by the call to surfaces.setMinLevelFields(shells); in snappyHexMesh.C. Removing the call fixes the issue, but introduces other refinement problems.


2019-10-07 16:23

updater   ~0010803

I've had this issue for years and never reported it because I wasn't aware of how much it affects others.

In a custom version we have internally, we have an option for turning off the following lines:
- Starting here:
- Ending here:

This has been a custom option for us here at our office, but I've never tested this further to see how this affects other geometries.

@niklas.wikstrom: Perhaps by only commenting out the lines I've pointed out, instead of simply commenting 'setMinLevelFields', does it reduce the occurrence of the refinement problems you've seen? Or do the same issue occur?


2019-10-08 05:18

reporter   ~0010804

Yes, It's been around, and I mostly have gotten around it through geometry refinements :-D

Thanks a lot! I'll try the modification.



2019-10-08 09:08

reporter   ~0010805

It seems to work fine, although I overloaded the setMinLevelFields() in a modified snappyHexMesh.C, thus keeping the src tree intact. (Attaching my local version of snappyHexMesh.C, this is for v5, but minor changes to dev)

Thank you again.


snappyHexMeshM.C (46,072 bytes)


2019-10-08 14:40

manager   ~0010806

This change could be put on an optional switch, what do you think would be an appropriate name for it?

A better option would be to change the refinement approach so that it isn't so sensitive to the aspect ratio of the triangles (I am assuming the issue is with long thin triangles), any thoughts?


2019-10-08 15:38

updater   ~0010808

@henry: We defined the switch as 'triSurfacesLevelsOnly' in the 'castellatedMeshControls' dict.

I have the very vague idea that the problem occurs when the triangle was large/long enough to overlap multiple refinement regions, resulting in being affected by the other refinement definitions.

From what I can remember, there was no clear fix at the time when I saw and tried to fix this issue, only turning off that particular detection would do the trick.


2019-10-08 15:54

reporter   ~0010809

Good with a switch in the dictionary. Note, however, that the facet in my example above does not have a large aspect ratio; just three or so, but the facet gets refined as soon as the distance ref reaches across its edge(s?). The switch name 'triSurfacesLevelsOnly' might need some explanation ;-)

It would be interesting to know when the feature is needed, but I guess I'll figure it out if I run without it for a while.

Thanks for helping!


2019-10-08 16:06

manager   ~0010810

@niklas.wikstrom Do you have a better name in mind?

Is this feature needed at all? Shall I simply remove it?
If I add a switch what should the default be? If it is true how will people know that they need to set it to false?


2019-10-08 16:57

reporter   ~0010814

Very vague suggestions below, since I do not know what else the thing affects.


Will show faster if it's needed or not, set the default to false and wait for bug reports...

I do not know, but I assume there was a good reason for it. Better keep it.


2019-10-08 17:25

manager   ~0010816

The problem is that if it is needed and was put in for good reason it should be on by default for backward compatibility unless we know for sure that it actually generally not needed and then we need to know for what cases it is needed so that we can inform people of the change in default behavior.


2019-10-08 20:37

reporter   ~0010818

I realise that. It is safer. I will run without the thing and if I find some inconsistency or find out what it is all about, I will report back.


2019-11-12 16:10

manager   ~0010888

Is there any progress and/or recommendations on this or should I close the report?


2019-11-13 14:34

reporter   ~0010895

I have not seen any issues with the feature turned off, but have not much statistics. However, I think it is a good idea to add the option "shellLayerToFaces" with default value "true" to snappyHexMesh. And then close the issue.


2019-11-13 14:39

manager   ~0010896

How should I document this change? Can any particular recommendations be made? When should users consider changing this switch?
If we don't say anything it will just be a hidden switch that no one knows about or knows how to use so there wouldn't be much point having it.


2019-11-13 15:17

updater   ~0010897

If I'm not mistaken, the description can be along these lines:

   This option will allow tessellated surfaces (shells?) to inherit refinement levels from other overlapping features. If you see unwanted refinement spreading onto triangles, turn off this option.

As a side note, I very vaguely remember seeing this happen when larger triangles were overlapping smaller features that I wanted to have refined and yet the large triangle centres would get caught on the overlapping heuristic.


2019-11-14 12:03

manager   ~0010901

It is not clear for what cases this refinement condition is useful and given the difficulty in choosing a suitable name for the option, how to control it, what the default should be or when to recommend it should be switched on or off it makes sense to remove it for now and reinstate under an option if cases are found and reported which benefit from this option.

commit a64d71929f0a51229ef6c5603af1d1ca21dad5f1
Author: Henry Weller <>
Date: Thu Nov 14 11:51:13 2019 +0000

    snappyHexMesh::refinementSurfaces: Removed problematic shell refinement transfer to surface
                // Find out if triangle inside shell with higher level
                // What level does shell want to refine fc to?
                // Note: it is not clear for what cases this additional requirement
                // is beneficial but for triangulated surfaces with triangles that
                // span refinement regions it introduces unnecessary refinement so
                // it has been removed.
                // This option can be reinstated under a switch if cases are
                // provided which demonstrate the benefit.
                labelList shellLevel;
                shells.findHigherLevel(ctrs, minLevelField, shellLevel);
                forAll(minLevelField, i)
                    minLevelField[i] = max(minLevelField[i], shellLevel[i]);


2021-12-07 12:25

manager   ~0012291

commit 5d93da3aed0d03b38081717e29cfd506eba294a9 (HEAD -> master, origin/master, origin/HEAD)
Author: Henry Weller <>
Date: Tue Dec 7 12:17:52 2021 +0000

    snappyHexMesh: Added castellatedMeshControls:extendedRefinementSpan option
    The code relating to extending refinement to the span of the facet/triangles
    intersected by the refinement distance referred to in report
    and temporarily removed may now be selected by the optional
    castellatedMeshControls:extendedRefinementSpan entry in snappyHexMeshDict. It
    in not clear if this control is generally beneficial and very few users have
    reported a preference and too few example cases have been provided to make a
    balanced judgement so it has been decided to reinstate the previous default
    behaviour and default extendedRefinementSpan to true.

Issue History

Date Modified Username Field Change
2019-10-07 11:12 niklas.wikstrom New Issue
2019-10-07 11:12 niklas.wikstrom File Added: geomFacetRef.png
2019-10-07 11:12 niklas.wikstrom File Added: snappyBugReportRoom.tgz
2019-10-07 11:14 niklas.wikstrom Note Added: 0010802
2019-10-07 16:23 wyldckat Note Added: 0010803
2019-10-08 05:18 niklas.wikstrom Note Added: 0010804
2019-10-08 09:08 niklas.wikstrom File Added: snappyHexMeshM.C
2019-10-08 09:08 niklas.wikstrom Note Added: 0010805
2019-10-08 14:40 henry Note Added: 0010806
2019-10-08 15:38 wyldckat Note Added: 0010808
2019-10-08 15:54 niklas.wikstrom Note Added: 0010809
2019-10-08 16:06 henry Note Added: 0010810
2019-10-08 16:57 niklas.wikstrom Note Added: 0010814
2019-10-08 17:25 henry Note Added: 0010816
2019-10-08 20:37 niklas.wikstrom Note Added: 0010818
2019-11-12 16:10 henry Note Added: 0010888
2019-11-13 14:34 niklas.wikstrom Note Added: 0010895
2019-11-13 14:39 henry Note Added: 0010896
2019-11-13 15:17 wyldckat Note Added: 0010897
2019-11-14 12:03 henry Assigned To => henry
2019-11-14 12:03 henry Status new => resolved
2019-11-14 12:03 henry Resolution open => fixed
2019-11-14 12:03 henry Note Added: 0010901
2021-12-07 12:25 henry Note Added: 0012291