View Issue Details
| ID | Project | Category | View Status | Date Submitted | Last Update |
|---|---|---|---|---|---|
| 0001692 | OpenFOAM | Bug | public | 2015-05-15 09:04 | 2017-12-01 11:02 |
| Reporter | DanielJ | Assigned To | henry | ||
| Priority | normal | Severity | minor | Reproducibility | always |
| Status | resolved | Resolution | fixed | ||
| Platform | GNU/Linux | OS | Ubuntu | OS Version | 14.04 |
| Fixed in Version | dev | ||||
| Summary | 0001692: blockMesh cannot create rotational cyclic patches | ||||
| Description | When 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. " | ||||
| Tags | checkMesh | ||||
|
|
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)
);
|
|
|
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. |
|
|
The same problem occurres when you try to synchronize AMI patches with 'createPatch' 'pointSync' option. |
|
|
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. |
|
|
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. |
|
|
Resolved by commit ce181e0d7119067757a335ab47296c73775fd38b |
| 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 |
