View Issue Details

IDProjectCategoryView StatusLast Update
0003361OpenFOAMBugpublic2019-10-08 20:37
Reporterniklas.wikstromAssigned To 
Status newResolutionopen 
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.

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