OpenFOAM Issue Tracking - OpenFOAM
View Issue Details
0001692OpenFOAM[All Projects] Bugpublic2015-05-15 09:042017-12-01 11:02
ReporterDanielJ 
Assigned Tohenry 
PrioritynormalSeverityminorReproducibilityalways
StatusresolvedResolutionfixed 
PlatformGNU/LinuxOSUbuntuOS Version14.04
Product Version 
Target VersionFixed in Versiondev 
Summary0001692: blockMesh cannot create rotational cyclic patches
DescriptionWhen cyclic patches with rotation are defined for blockMesh the resulting mesh is incorrect.

"
Checking geometry...
    Overall domain bounding box (-0.5 -0.5 -0.5) (0.5 0.5 0.5)
    Mesh (non-empty, non-wedge) directions (1 1 1)
    Mesh (non-empty) directions (1 1 1)
    Boundary openness (-1.156482e-017 6.360653e-018 5.782412e-018) OK.
    Max cell openness = 2.255141e-016 OK.
    Max aspect ratio = 1 OK.
    Minimum face area = 0.01. Maximum face area = 0.01. Face area magnitudes OK.
    Min volume = 0.001. Max volume = 0.001. Total volume = 1. Cell volumes OK.
    Mesh non-orthogonality Max: 85.50765 average: 12.41976
   *Number of severely non-orthogonal (> 70 degrees) faces: 144.
    Non-orthogonality check OK.
  <<Writing 144 non-orthogonal faces to set nonOrthoFaces
    Face pyramids OK.
    Max skewness = 2.492319 OK.
  **Error in coupled point location: 90 faces have their 0th or consecutive vertex not opposite their coupled equivalent. Average mismatch 3.386219e-017.
  <<Writing 90 faces with incorrectly matched 0th (or consecutive) vertex to set coupledFaces

Failed 1 mesh checks.
"
TagscheckMesh
Attached Files? blockMeshDict (971) 2015-05-15 09:04
https://bugs.openfoam.org/file_download.php?file_id=1168&type=bug

Notes
(0004771)
wyldckat   
2015-05-17 21:26   
I've only managed to do some very preliminary diagnosis on this and my suspicion is on the algorithm that automatically calculates the angle between the cyclic patch pair, which might not handle exact 90 degree transformations, or at least in this direction.

I vaguely remember that there is a more explicit way of defining the transformation for rotation, but I will still have to look into this better.
(0004776)
DanielJ   
2015-05-19 14:25   
The same problem occurres when you try to synchronize AMI patches with 'createPatch' 'pointSync' option.
(0004793)
wyldckat   
2015-05-24 20:42   
OK, I've looked at the source code and tried to debug it as best as I can... and I still can't figure out why this was implemented like this in the first place and how exactly to fix it :(

Here's what I can figure out:

1- "Foam::cyclicPolyPatch::calcTransforms" was a strong suspect to be the source of the bug. As far as I can figure out, the transformations are being done correctly, therefore this does not seem to be the origin of the problem.

2- In the file "applications/utilities/mesh/manipulation/checkMesh/checkGeometry.C", the method "Foam::checkCoupledPoints" seems to be the origin of the problem.

And here's where I get lost on why this was implemented this way. Because in the loop that has the comment:

   // Exchange zero point

it clearly generates the list of points for each patch that has a couple-match. For that, it uses this face ID:

   label bFaceI = cpp.start() + i - mesh.nInternalFaces();


Now, once the list of points is generated, it's transformed with this:

    syncTools::syncBoundaryFaceList
    (
        mesh,
        nbrPoints,
        eqOp<pointField>(),
        transformPositionList()
    );

via the class-operator "transformPositionList()", which should convert the list of points for a patch to the respective coupled patch. So far, so good, I couldn't find a flaw here.


Problem is when we come to the loop that starts with the comment:

   // Compare to local ones. Use same tolerance as for matching

It checks only the owner coupled patches, which seems OK, but the problem is that it then uses the same exact face ID short-list it used in the original list:

   label bFaceI = cpp.start() + i - mesh.nInternalFaces();

Instead of using the ones for the neighbour patch.
The problem here is that I can't figure why this works in some cases (tutorial "incompressible/simpleFoam/pipeCyclic"), but not in this case, since from what I can figure out, this should only work well if the patches always overlapped.
(0009113)
henry   
2017-12-01 09:59   
The issue is that blockMesh does not reorder boundary faces so adjacent patches do not face orders consistent for cyclic. The simplest solution is to run the createPatch utility to correct the cyclic patches.

Simply create a createPatchDict file in system with dummy entries:

patches
(
);

pointSync false;

and run

createPatch -overwrite

and the mesh will be fixed.
(0009114)
henry   
2017-12-01 11:02   
Resolved by commit ce181e0d7119067757a335ab47296c73775fd38b

Issue History
2015-05-15 09:04DanielJNew Issue
2015-05-15 09:04DanielJFile Added: blockMeshDict
2015-05-17 21:26wyldckatNote Added: 0004771
2015-05-19 14:25DanielJNote Added: 0004776
2015-05-24 18:21wyldckatTag Attached: checkMesh
2015-05-24 20:42wyldckatNote Added: 0004793
2017-12-01 09:59henryNote Added: 0009113
2017-12-01 11:02henryAssigned To => henry
2017-12-01 11:02henryStatusnew => resolved
2017-12-01 11:02henryResolutionopen => fixed
2017-12-01 11:02henryFixed in Version => dev
2017-12-01 11:02henryNote Added: 0009114