View Issue Details
| ID | Project | Category | View Status | Date Submitted | Last Update |
|---|---|---|---|---|---|
| 0000138 | OpenFOAM | Bug | public | 2011-02-15 13:32 | 2011-02-23 16:45 |
| Reporter | Assigned To | ||||
| Priority | normal | Severity | minor | Reproducibility | always |
| Status | resolved | Resolution | fixed | ||
| Platform | Linux | OS | Ubuntu | OS Version | 10.04 |
| Summary | 0000138: incorrect implementation of cyclic b.c. with 180 degree rotation | ||||
| Description | Cyclic patches can not be used with a rotation of 180 degrees, neither automatically nor when explicitly specifying using "transform rotational" keyword in constant/polyMesh/boundary. Solver incorrectly assumes a translational cyclic patch due to the code in functions Foam::cyclicPolyPatch::calcTransforms() Foam::coupledPolyPatch::calcTransformTensors() | ||||
| Steps To Reproduce | The attached icoFoam test case consists of two cubes, one with a fixed velocity inlet boundary, the other with a fixed pressure outlet boundary. The cubes are connected via a cyclic patch. The outlet cube is defined as a 180 degree rotated version of the inlet cube in "blockMeshDict". I have modified the test file "boundary" to force "transform rotational" behavior. This setting is necessary! Execute "Allrun" in attached test case with and without the patched library file OpenFOAM/meshes/polyMesh/polyPatches/constraint/cyclic/cyclicPolyPatch.C Original library version crashes with floating point exception, patched version runs correctly. | ||||
| Additional Information | I expect that both functions Foam::cyclicPolyPatch::calcTransforms() Foam::coupledPolyPatch::calcTransformTensors() ought to be cleaned up a little - although the concept of 180 degree rotational cyclic b.c. is rather esoteric to be honest. | ||||
| Tags | No tags attached. | ||||
|
2011-02-15 13:32
|
|
|
|
Interesting one. Ideally there should indeed be a flag passed into calcTransformTensors if we know what kind of transform needs to be calculated. However in 17x when a case with cyclics gets decomposed any cyclics on different processors get added onto the processor patch so this will now have a mix of transformed and untransformed faces. 2) In your code why do you call getConsistentRotationFace for the second half as well? The faces coming out of blockMesh are ordered whichever way you specified so it seems as if the ordering in the blockMeshDict is incorrect. Thanks, Mattijs |
|
|
Dear Mattijs, well, I called getConsistentRotationFace for the second half, because this returned a face1 that was at maximal distance from the centre of rotation - just as for face0. I expected this was a sensible thing to do when calculating a rotation tensor. I did not want to rely on choosing "just any face" on the second patch half. Incidently, I chose the block vertex ordering in the blockMeshDict to be consistent with a rotation of 180 degrees. But please don't expect me to understand the whole code yet involving patches, transformations, etc., I did not have that much time. :-) Feel free to keep me up to date with your thoughts on this. Regards, Daniel |
|
|
fixed in cab4dca7bbae374ba2eaf6a99f801aac1f36d23e. - in your testcase I changed the cyclic block face so they start at the same point but go in opposite orientation: cyclic connection ( (2 6 5 1) (11 8 12 15) ) - Added the transformType as an extra argument to calcTransformTensors and made cyclicPolyPatch pass in the transformtype. Seems to work. Please let me know if there are any problems with it. Thanks, Mattijs |
| Date Modified | Username | Field | Change |
|---|---|---|---|
| 2011-02-15 13:32 |
|
New Issue | |
| 2011-02-15 13:32 |
|
File Added: doubleSquare.tar.gz | |
| 2011-02-16 08:51 |
|
Note Added: 0000250 | |
| 2011-02-16 09:11 |
|
Note Added: 0000251 | |
| 2011-02-23 16:45 |
|
Note Added: 0000259 | |
| 2011-02-23 16:45 |
|
Status | new => resolved |
| 2011-02-23 16:45 |
|
Fixed in Version | => 1.7.x |
| 2011-02-23 16:45 |
|
Resolution | open => fixed |
| 2011-02-23 16:45 |
|
Assigned To | => user4 |
