View Issue Details
|ID||Project||Category||View Status||Date Submitted||Last Update|
|0003361||OpenFOAM||Bug||public||2019-10-07 11:12||2021-12-07 12:25|
|Fixed in Version|
|Summary||0003361: snappyHexMesh region refinement contaminates entire geometry facet|
|Description||A 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 Reproduce||Extract attached snappyBugReportRoom.tgz, run blockMesh and snappyHexMesh.|
|Additional Information||The image file, attached, shows the overly refined facet and visualizes the distance refinement geometry object (pink), pointed at by the yellow line.|
|Tags||No tags attached.|
geomFacetRef.png (928,134 bytes)
snappyBugReportRoom.tgz (4,846 bytes)
||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.|
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: https://github.com/OpenFOAM/OpenFOAM-7/blob/master/src/mesh/snappyHexMesh/refinementSurfaces/refinementSurfaces.C#L440
- Ending here: https://github.com/OpenFOAM/OpenFOAM-7/blob/master/src/mesh/snappyHexMesh/refinementSurfaces/refinementSurfaces.C#L448
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?
Yes, It's been around, and I mostly have gotten around it through geometry refinements :-D
Thanks a lot! I'll try the modification.
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)
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?
@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.
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!
@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?
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.
||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.|
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.
||Is there any progress and/or recommendations on this or should I close the report?|
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.
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.
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.
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.
Author: Henry Weller <http://openfoam.org>
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.
shells.findHigherLevel(ctrs, minLevelField, shellLevel);
minLevelField[i] = max(minLevelField[i], shellLevel[i]);
commit 5d93da3aed0d03b38081717e29cfd506eba294a9 (HEAD -> master, origin/master, origin/HEAD)
Author: Henry Weller <http://cfd.direct>
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.
|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|