2017-11-24 09:10 GMT

View Issue Details Jump to Notes ]
IDProjectCategoryView StatusLast Update
0001038OpenFOAMContributionpublic2017-11-12 20:44
Reporterwyldckat 
Assigned Towyldckat 
PrioritynormalSeveritymajorReproducibilityalways
StatusclosedResolutionsuspended 
Product Version 
Target VersionFixed in Version 
Summary0001038: snappyHexMesh: problems with snapping to sharp corners of patches
DescriptionAs shown in the attached images "testSnappy*.png", there are some issues with how the mesh is snapped to the corners of the patches.

"snappyHexMesh" is able to respect those corners only when the base mesh is close enough to those points, or when the "nSmoothPatch" value is set to a high value, such as 30 or 50 (which gives us very large cells near the corners of the walls).

In white is the wire-frame of the original STL file. In colour are the patches on the surface mesh.

Attached are also the respective test cases, where these openings are on the X+ side of the test geometry.

Latest commit tested on 2.2.x: {{61014a285a75c16c982a5a3d2b2b250a062791f5}}
Steps To Reproduce1. Unpack each one of the attached tarballs.
2. Run the "Allrun" script inside each one of the "testSnappy*" folders.
3. Run "paraFoam" and choose to show the plug-in field "vtkCompositeIndex", with the representation of "surface + edges". Rotate to see X+.


The main important settings being used on "snappyHexMeshDict" are:

  nSmoothPatch 3;
  tolerance 4.0;
  nSolveIter 0;
  nRelaxIter 5;
  nFeatureSnapIter 10;
  implicitFeatureSnap false;
  explicitFeatureSnap true;
  multiRegionFeatureSnap true;
Additional InformationSorry about the broad use of the #include, but the dictionary files were partially generated by our internal development software.


I did try figuring this out myself, but all I managed to assess was that the method "Foam::autoSnapDriver::determineFeatures()" in "src/mesh/autoMesh/autoHexMesh/autoHexMeshDriver/autoSnapDriverFeature.C" could be hacked in this if-block:
  if (patchConstraints[pointI].first() == 2)
  {
    //...
  }

in such a way that the average of the initial point with the closest "multiPatchPt" point, could help in some cases, as attempted in this commit: https://github.com/wyldckat/OpenFOAM-2.2.x/commit/42c3b9696adfaca7bb6fdd4482c8534a8080d3c8

Unfortunately, such a hack only worked for the first example "testSnappy" and only when the base mesh was good enough for the average to be helpful. Otherwise, it simply makes a bigger mess.


I also tried cleaning up the eMesh file, by removing overlapping edges, but to no avail.
TagsNo tags attached.
Attached Files

-Relationships
+Relationships

-Notes

~0002579

wyldckat (updater)

Greetings,

After a couple of days of looking+debugging the source code related to this part of snappyHexMesh's algorithm, here are our findings we've made here at blueCAPE Lda:

1- In the file "src/mesh/autoMesh/autoHexMesh/autoHexMeshDriver/autoSnapDriverFeature.C" is the core code that takes care of snapping the cell vertexes in the mesh onto the STL surfaces and feature edges/points.

2- The method "Foam::autoSnapDriver::binFeatureFace" seemed to be a good place to introduce an artificial normal definition for cell faces that are from different patch IDs, so that it would trick the algorithms later on to think that it was hitting a corner... but it wasn't tested because:
  a) It would take a long while to code it.
  b) It felt that it would lead to having other snapping issues, namely to distort the mesh around the points of interest.

3- Having dropped the idea from #2, we went back to the method "void Foam::autoSnapDriver::featureAttractionUsingFeatureEdges" and found a suspicious looking code for baffles, that was commented out, namely where it says "TEMPORARILY DISABLED".
This lead us to try and enforce - in the "forAll" loop next to it - that every feature point is a baffle point. This resulted in having successful snapping made on the intersection points between the patches at the sharp edge (the 2 intersections at the bottom of the image "testSnappy.png").
But it did not snap the corner points that are in the middle of the larger patch (the two points at the top of the red patch).

4- From #3, the investigation went towards looking for where the feature points were coming from, which lead us to the constructor "Foam::refinementFeatures::refinementFeatures" in the file "src/mesh/autoMesh/autoHexMesh/refinementFeatures/refinementFeatures.C". There we found this piece of code:

    if (pointEdges[pointI].size() > 2)

which means that only points that belong to 3 edges are accepted as feature points. Changing the limit from 2 to 1, along with the previous hack, lead to a successful snapping!

In the next comment is a possible bug fix or feature request, depending on the perspective ;)

~0002580

wyldckat (updater)

Attached are the following files:
  "patch.v4" - This is the proposed patch.

  "patch.v4.modified-files.tar.gz" - This includes a full copy of the modified files (i.e., with the patch applied).

  "testSnappy3_fix.tar.gz" - This is the "testSnappy3.tar.gz" case with the small modification described below.


The changes made to the code were as follows:
1- In the method "autoSnapDriver::featureAttractionUsingFeatureEdges", more specifically in the "forAll" loop where the condition "pointStatus[pointI] == 0" is checked, was switched with the "pointStatus[pointI] == 1" check and it was added the additional check of whether the "multiRegionFeatureSnap" option was turned on. This is because without "multiRegionFeatureSnap", the patches that share the same normals, do not have a snapping on the feature edges between them.

2- To the class "Foam::refinementFeatures" a new optional dictionary entry was added, namely "includeTwoEdgePoints", which has the default setting of "false" and which enables the user to decide if the standard 3-edges per point rule is to be observed or if 2-edges is enough, by setting it to "true".

3- Still on the same class, the constructor will now observe if this new dictionary entry is true or not, in order to define the number of edges needed for defining a feature point.


As for the test case, simply added this line:
  includeTwoEdgePoints true;

to the eMesh block, resulting in this:
    features
    (
        {
            file "house4.eMesh";
            level 0;
            includeTwoEdgePoints true;
        }
    );


I don't think this is an elegant fix as per OpenFOAM standards, but it works well for us. The downside is that if some rogue feature edges are present in the eMesh files... well, that's at the responsibility of the user :)

Best regards,
Bruno Santos

~0002581

wyldckat (updater)

And I forgot to mention:
- The image "testSnappy3_fix.png" demonstrates that the snapping worked.

- The suggested fix refers to commit 010af4d26a167aa44f997c09924f56373681abea on the repository OpenFOAM-2.2.x.

~0002594

user4

Hi Bruno,

nice analysis. It looks to me that the eMesh format is too basic - it does not store information about feature points. I commented out the baffle code since it was too 'geometric'. Patch smoothing will pull the two sides apart so then we need to use some angle to detect them.

~0003108

wyldckat (updater)

Hi Mattijs,

Many thanks for the feedback!
Having a second file with a list of explicit feature points wouldn't be half bad, although the issue would be how that file would be generated...
On the other hand, corner detection on coplanar surfaces is technically what we're looking for in this specific situation, but there are some situations where this isn't the desired effect.

Either way, I've come back with some more intel on this topic.

The previously submitted "hack" has a really very big flaw: when "snappyHexMesh" is used in parallel, mesh points on one processor will be attracted to feature points that are meant to be snapped-to on other processors or are snapped onto unintended edges. In other words, something as gruesome as shown in the attached image "resolve_feature_0.png" can occur; and this case is not the worst scenario, because the "resolveFeatureAngle" keyword was set to 0. Although do keep in mind that this issue was more easily triggered because we've been using "tolerance 4.0" in the snap controls, which is considerably high.

We've managed to fix this issue, by solving the issue in three steps:
 1. Copy-paste-adapted only the code we needed from the snap-to-baffles loop. More specifically, we only need to snap to the feature points, since snapping to edges is already taken care of.

 2. Relying on a local list of attraction distances for each feature point, as well as a global copy of that list, synced to all processors.

 3. Then those processors who don't have the "winning distance", will undo their plans to snap to that feature point.


Attached is the "patch.v5" and the tarball "patch.v5.modified-files.tar.gz", both of which have the latest modifications, although it's still only referenced to the latest commit on OpenFOAM 2.2.x. The changes in the patch (and modified files) are as follows:

 1. New class "Foam::listListMin" was added to be used by "combineReduce", so that we can combine the global list of distances for each feature point.

 2. In the method "autoSnapDriver::featureAttractionUsingFeatureEdges", the baffle code is kept as it is originally and added a new code block that does the steps indicated in the 3-step description above.

 3. Same as in the previous patch, the class "Foam::refinementFeatures" has a new optional dictionary entry, namely "includeTwoEdgePoints", which has the default setting of "false" and which enables the user to decide if the standard 3-edges per point rule is to be observed or if 2-edges is enough, by setting it to "true".

 4. Also same as in the previous patch and still in the class "Foam::refinementFeatures", the constructor will now observe if this new dictionary entry is true or not, in order to define the number of edges needed for defining a feature point.


I haven't added a new test case, but it's as simple as using the attached test case "testSnappy3_fix.tar.gz", adding a "decomposeParDict", decomposing after "blockMesh" and running "snappyHexMesh" in parallel.

Best regards,
Bruno

~0009022

wyldckat (updater)

I'm closing this as suspended for now.

In order to to properly implement this into OpenFOAM, it's necessary to:
 1. First decide how the feature points should be provided;
 2. Then have a few more example cases set-up for not originally intended situations, such as wanting to only to snap to feature;
 3. Then re-adapt these changes to the latest OpenFOAM-dev;
 4. And fully test this feature.

+Notes

-Issue History
Date Modified Username Field Change
2013-10-07 18:31 wyldckat New Issue
2013-10-07 18:31 wyldckat File Added: testSnappy.png
2013-10-07 18:31 wyldckat File Added: testSnappy2.png
2013-10-07 18:31 wyldckat File Added: testSnappy3.png
2013-10-07 18:31 wyldckat File Added: testSnappy.tar.gz
2013-10-07 18:31 wyldckat File Added: testSnappy2.tar.gz
2013-10-07 18:32 wyldckat File Added: testSnappy3.tar.gz
2013-10-23 16:40 wyldckat Note Added: 0002579
2013-10-23 16:40 wyldckat Note Added: 0002580
2013-10-23 16:40 wyldckat File Added: testSnappy3_fix.png
2013-10-23 16:40 wyldckat File Added: testSnappy3_fix.tar.gz
2013-10-23 16:41 wyldckat File Added: patch.v4
2013-10-23 16:41 wyldckat File Added: patch.v4.modified-files.tar.gz
2013-10-23 16:44 wyldckat Note Added: 0002581
2013-10-29 10:18 user4 Note Added: 0002594
2014-06-05 15:40 wyldckat File Added: resolve_feature_0.png
2014-06-05 15:40 wyldckat File Added: patch.v5
2014-06-05 15:40 wyldckat File Added: patch.v5.modified-files.tar.gz
2014-06-05 15:41 wyldckat Note Added: 0003108
2017-11-12 20:43 wyldckat Category Bug => Contribution
2017-11-12 20:44 wyldckat Assigned To => wyldckat
2017-11-12 20:44 wyldckat Status new => closed
2017-11-12 20:44 wyldckat Resolution open => suspended
2017-11-12 20:44 wyldckat Note Added: 0009022
+Issue History