View Issue Details

Jump to NotesJump to History
IDProjectCategoryView StatusDate SubmittedLast Update
0000138OpenFOAMBugpublic2011-02-15 13:322011-02-23 16:45
Reporteruser134Assigned Touser4 
PrioritynormalSeverityminorReproducibilityalways
Status resolvedResolutionfixed 
PlatformLinuxOSUbuntuOS Version10.04
Summary0000138: incorrect implementation of cyclic b.c. with 180 degree rotation
DescriptionCyclic 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 ReproduceThe 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 InformationI 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.
TagsNo tags attached.

Activities

user134

2011-02-15 13:32

 

doubleSquare.tar.gz (12,749 bytes)

user4

2011-02-16 08:51

  ~0000250

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

user134

2011-02-16 09:11

  ~0000251

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

user4

2011-02-23 16:45

  ~0000259

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

Issue History

Date Modified Username Field Change
2011-02-15 13:32 user134 New Issue
2011-02-15 13:32 user134 File Added: doubleSquare.tar.gz
2011-02-16 08:51 user4 Note Added: 0000250
2011-02-16 09:11 user134 Note Added: 0000251
2011-02-23 16:45 user4 Note Added: 0000259
2011-02-23 16:45 user4 Status new => resolved
2011-02-23 16:45 user4 Fixed in Version => 1.7.x
2011-02-23 16:45 user4 Resolution open => fixed
2011-02-23 16:45 user4 Assigned To => user4