View Issue Details

IDProjectCategoryView StatusLast Update
0001692OpenFOAMBugpublic2017-12-01 11:02
ReporterDanielJ Assigned Tohenry  
PrioritynormalSeverityminorReproducibilityalways
Status resolvedResolutionfixed 
PlatformGNU/LinuxOSUbuntuOS Version14.04
Fixed 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

Activities

DanielJ

2015-05-15 09:04

reporter  

blockMeshDict (971 bytes)   
FoamFile
{
	version	2.0;
	class	dictionary;
	format	ascii;
	location	"constant/polyMesh";
	object	blockMeshDict;
}
convertToMeters	1;
edges	
(
);
vertices	(
	( -0.5 -0.5 -0.5 )
	( 0.5 -0.5 -0.5 )
	( 0.5 0.5 -0.5 )
	( -0.5 0.5 -0.5 )
	( -0.5 -0.5 0.5 )
	( 0.5 -0.5 0.5 )
	( 0.5 0.5 0.5 )
	( -0.5 0.5 0.5 )
);
boundary	
(
	boundaries
	{
		type wall;
		faces
		(
			(2 6 5 1)
			(3 7 6 2)
			(0 3 2 1)
			(4 5 6 7)
		);
	}
	left
	{
		type cyclic;	
		neighbourPatch        right;
	    matchTolerance        1E-4;
	    transform             rotational;
        rotationAxis          (0 0 1);
		rotationCentre        (-0.5 -0.5 0);
		faces
		(
			(0 4 7 3)
		);
	}
	right
	{
		type cyclic;	
		neighbourPatch        left;
	    matchTolerance        1E-4;
	    transform             rotational;
        rotationAxis          (0 0 1);
		rotationCentre        (-0.5 -0.5 0);
		faces
		(
			(1 5 4 0)
		);
	}

);
blocks	
(
	hex (0 1 2 3 4 5 6 7) (10 10 10) simpleGrading (1 1 1)
);
blockMeshDict (971 bytes)   

wyldckat

2015-05-17 21:26

updater   ~0004771

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.

DanielJ

2015-05-19 14:25

reporter   ~0004776

The same problem occurres when you try to synchronize AMI patches with 'createPatch' 'pointSync' option.

wyldckat

2015-05-24 20:42

updater   ~0004793

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.

henry

2017-12-01 09:59

manager   ~0009113

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.

henry

2017-12-01 11:02

manager   ~0009114

Resolved by commit ce181e0d7119067757a335ab47296c73775fd38b

Issue History

Date Modified Username Field Change
2015-05-15 09:04 DanielJ New Issue
2015-05-15 09:04 DanielJ File Added: blockMeshDict
2015-05-17 21:26 wyldckat Note Added: 0004771
2015-05-19 14:25 DanielJ Note Added: 0004776
2015-05-24 18:21 wyldckat Tag Attached: checkMesh
2015-05-24 20:42 wyldckat Note Added: 0004793
2017-12-01 09:59 henry Note Added: 0009113
2017-12-01 11:02 henry Assigned To => henry
2017-12-01 11:02 henry Status new => resolved
2017-12-01 11:02 henry Resolution open => fixed
2017-12-01 11:02 henry Fixed in Version => dev
2017-12-01 11:02 henry Note Added: 0009114