[cfdengineering]

I'm dealing with a 2D mesh with traslational periodic boundary made in Gambit. I put the 2 periodic linked edge in a single patch name "cyc" and then I translated the mesh with the fluentMeshToFoam utility. I changed the "cyc" type from empty to cyclic.
I checked the mesh then I used the couplePatches utility and from the log files every ordering problem seems to be solved. But as soon as i try to view the mesh in paraview, I get the following message:
--> FOAM FATAL ERROR : face 0 and 65 areas do not match by 0.000222148% -- possible face ordering problem

From function cyclicFvPatch::makeWeights(scalarField& w) const
in file meshes/fvMesh/fvPatches/derivedFvPatches/cyclicFvPatch/cyclicFvPatch.C at line 62.

FOAM aborting

can anybody tell me what's wrong?
thanks

[gschaider]

The problem could be the following:
in the controlDict there is a writePrecision set to 6. This is sufficient for data, but not for mesh information (look at the tolerance in your error message). So before manipulating mesh data set the writePrecision to a higher value and reset it after you're finished with the mesh.

(I believe this was fixed in 1.2 - Are you using an earlier Version?)

[cfdengineering]

I'm using OpenFoam 1.2 for amd64 (I've just downloaded it a week ago)
I set the writeprecision to 12 and nothing's changed!
I made a cyclic boundary with straight edges and everything works good but unfortunately I have to work with curved blade profile most of the times.

[hani]

Does couplePatches have any requirements on a rotational cyclic patch other than that the rotation axis must go through the origin?

Does the patch have to be planar?

I try to use couplePatches on a curved rotational cyclic patch (one of the blade passages of a water turbine runner) and I get the following error message:

Testing for correct face ordering ...
--> FOAM Serious Error :
From function cyclicPolyPatch::geometricOrder
in file meshes/polyMesh/polyPatches/derivedPolyPatches/cyclicPolyPatch/cyclicPolyPatchMo rph.C at line 386
patch:PER1 : Cannot match vectors to faces on both sides of patch
half0Ctrs[0]: (5.9572663436 31.0989222406 -123.042740111)
half1Ctrs[0]: ( -7.95441396004 5.93069624374 -126.663981078)
Please use topological matching or adapt the featureCos() setting

Håkan.

[hani]

cyclicPolyPatch::order : Found 0 on patch PER1 where the cos of the angle between two connected faces was less than 0.9
cyclicPolyPatch::order : Writing zone 0 face centres to OBJ file "PER1_zone_0.obj"
cyclicPolyPatch::order : Writing zone 1 face centres to OBJ file "PER1_zone_1.obj"
cyclicPolyPatch::order : Number of faces per zone:2{2622}
cyclicPolyPatch::geometricOrder : Rotation : n0: (0.921071 -0.238244 0.308006) n1: (-0.564988 0.242068 0.788791)
cyclicPolyPatch::order : Dumping newly found cyclic match as lines between corresponding face centres to file "PER1_faceCentres.obj"
Here are some more error messages, when using the degug switch. It seems like couplePatches finds the two cyclic sides, but that there is some vector that should determine the rotation between the sides, which gets some strange results.

--> FOAM Serious Error :
From function cyclicPolyPatch::geometricOrder
in file meshes/polyMesh/polyPatches/derivedPolyPatches/cyclicPolyPatch/cyclicPolyPatchMo rph.C at line 386
patch:PER1 : Cannot match vectors to faces on both sides of patch
half0Ctrs[0]: ( 5.95727 31.0989 -123.043)
half1Ctrs[0]: (-7.95441 5.9307 -126.664)
Please use topological matching or adapt the featureCos() setting

Håkan.

[hani]

Sorry for the last message, the text got all mixed up. Here it is again:

Here are some more error messages, when using the degug switch. It seems like couplePatches finds the two cyclic sides, but that there is some vector that should determine the rotation between the sides, which gets some strange results.

cyclicPolyPatch::order : Found 0 on patch PER1 where the cos of the angle between two connected faces was less than 0.9
cyclicPolyPatch::order : Writing zone 0 face centres to OBJ file "PER1_zone_0.obj"
cyclicPolyPatch::order : Writing zone 1 face centres to OBJ file "PER1_zone_1.obj"
cyclicPolyPatch::order : Number of faces per zone:2{2622}
cyclicPolyPatch::geometricOrder : Rotation : n0: (0.921071 -0.238244 0.308006) n1: (-0.564988 0.242068 0.788791)
cyclicPolyPatch::order : Dumping newly found cyclic match as lines between corresponding face centres to file "PER1_faceCentres.obj"

--> FOAM Serious Error :
From function cyclicPolyPatch::geometricOrder
in file meshes/polyMesh/polyPatches/derivedPolyPatches/cyclicPolyPatch/cyclicPolyPatchMo rph.C at line 386
patch:PER1 : Cannot match vectors to faces on both sides of patch
half0Ctrs[0]: ( 5.95727 31.0989 -123.043)
half1Ctrs[0]: (-7.95441 5.9307 -126.664)
Please use topological matching or adapt the featureCos() setting

Håkan.

[mattijs]

Hi Håkan,

cyclics have to be planar for automatic matching (couplePatches, createPatch) to work since both transformation tensor and face-face correspondence have to be determined.

If they are non-planar you'll have to get your mesh generator to output the patch faces in the correct order.

[hani]

Thanks for your answer Mattijs, although I would perhaps have liked an answer saying that cyclic surfaces can be curved. I guess it will be up to me to implement it as soon as I have learnt how. There's a whole turbomachine industry in need of this feature.

Please tell me how a correct order of the patch faces is defined.

I'm working in ICEM, so if anyone knows how to get a cyclic grid with correct face ordering for Foam this way, I would appreciate it much. Right now I export my grid in Fluent format and convert using fluentMeshToFoam.

I'm aiming at writing an evaluation of OpenFOAM for a water turbine conference in 2006, and it is crusial that I am able to use cyclic grids where the cyclic patches are curved.

Håkan.

[hani]

It seems like OpenFOAM wants the cyclic patch to be ordered in the following way, correct me if I'm wrong:

One of the cyclic sides should be in the first half of the face list and the other should be in the second half of the face list. The faces that are cyclic should then have the same position in the first and second half of the face lists respectively.

If this is true, will OpenFoam automatically determine the rotation ange for each cyclic twin of faces, or will there be a problem at that stage also?

I am not able to test this since my grid has an incorrect cyclic face list. It would be nice to know what problems I will run into if I try to reorder my facelist.

Håkan.

[hjasak]

The ordering comment is correct. In the patch of n faces, face 0 matches face n/2, 1 to n/2 +1 etc. Incidentally, I really hate this arrangement, but that's life...

As for the rotation, in the case of cyclic patches there is only one rotation tensor for all faces, which means the matching sides must be planar. The processor patches store a rotation tensor on a per-face basis.

Enjoy,

Hrv

[hani]

Please enlighten me on why the matching sides must be planar since there is only one rotation tensor for all faces.

Maybe I don't understand what you mean by rotation tensor, but I interpret it as a tensor containing the information on how one face should be rotated in order to 'become' its cyclic twin. In that case the rotation tensor must anyway be the same for all the faces on a cyclic patch, otherwise there would be different periodicity for different parts of the cyclic patch.

If the cyclic faces must be planar, should I then interpret it as OpenFOAM is not able to handle cyclic computations of turbomachine runners (or periodic, which it is usually called, where only one blade passage is computed in order to save computational time)? I really hope not.

Håkan.

[mattijs]

The rotation tensor is indeed the transformation tensor and is constructed from the face normals of the face 0 and the face n/2. Any in-plane rotation is not supported.

The patch needs to be planar for the 'automatic' matching to work (createPatch, couplePatches) since there one also doesn't know what the n/2 face is. It does not need to be planar for the solvers.

[hani]

Thanks Mattijs, that's more like what I wanted hear. Then I just have to find a way to renumber the cyclic patch in a correct way, either through ICEM or some other way.

If couplePatches was written in a way where the transformation tensor was suggested by the user, I think that it would be much more general. I will probably dig into this in the future.

Thanks!
Håkan.

[hani]

I'm testing the cyclic capabilities of OpenFOAM with a simple testcase that I thought would be possible to use with OpenFOAM. You can see it in this picture:
.
The y-axis is the axis of rotation. There are three planar cyclic patches, and the verical cyclic patches work alright but the tilted cyclic patch (PER3) does not work. I get the following error message when running couplePatches:

--> FOAM Serious Error :
From function cyclicPolyPatch::geometricOrder
in file meshes/polyMesh/polyPatches/derivedPolyPatches/cyclicPolyPatch/cyclicPolyPatchMorph.C at line 386
patch:PER3 : Cannot match vectors to faces on both sides of patch
half0Ctrs[0]: (0.0161701 0.121289 0.0387181)
half1Ctrs[0]: (0.0177285 0.127 0.00533573)
Please use topological matching or adapt the featureCos() setting
Continuing with incorrect face ordering from now on!

From previous discussions I thought that as long as all cyclic patches are planar, OpenFOAM will be able to handle my problem. Did I mis-understand that?

Håkan.

[mattijs]

The underlying cyclics should probably be able to handle this case (though we've never tried)

couplePatches (which should only be nessecary if your mesher/mesh converter doesn't output the faces correctly) probably doesn't like the separation of the two halves of per3 not to be in the direction of the patch.

Try creating the case in blockMesh and see if it works then.

[hani]

Hi, I'm back on the cyclic issues.

I have managed to reorder my cyclic patch for my 'real' case using couplePatches. In this case it was obviously important which faces were used for the determination of the transformation tensor. I had to renumber the mesh in ICEM to get some benefitial faces in the beginning of the cyclic patch face list. The accuracy of the determination of the transformation tensor is of course improved if the faces that are used are located at as large radius as possible. Could someone comment on this? Which faces are used for the determination of the transformation tensor? I guess: faces 0 and the first face that is not in the same plane as face 0?

The obj-files now show correct coupling between the cyclic nodes and the new polyMesh is written to 1. I move polyMesh to the correct folder and try to view the grid in paraFoam. Then I get to the next problem, which has been discussed before but I am not able to find the solution in the forum: The first cyclic faces differ in area by 0.00156051%:
--> FOAM FATAL ERROR : face 0 and 6119 areas do not match by 0.00156051% -- possible face ordering problem
From function cyclicFvPatch::makeWeights(scalarField& w) const
in file meshes/fvMesh/fvPatches/derivedFvPatches/cyclicFvPatch/cyclicFvPatch.C at line 62.

Obviously, couplePatches thought that the cyclic patch was sufficiently cyclic, but paraFoam (and also simpleFoam) does not think so. I have tried increasing the write precision to 12 as recommended in the forum (although a high precision is set by default in couplePatches in 1.2, I have actually also tried increasing the default value in couplePatches.C)

Now, an area error of 0.00156051% shouldn't do too much harm to my results. Is there a way to tell OpenFOAM not to bother about this? I have searched the forum without success.

I tried the procedure both on AMD and AMD64 using RedHat9, yielding the same result.

Håkan.

[mattijs]

No easy way to do this at the moment. Change in cyclicFvPatch.C the FatalErrorIn to a warning message if like you say you can live with this continuity error.

[steja]

I generated a simple 3D mesh for a pipe using ICEM with translational periodicity in x-direction for an LES with OpenFOAM. Using the fluentToFoam application I imported the mesh correctly into OpenFOAMs polyMesh format. After using the createPatch utility to merge the two patches (say IN and OUT) together to a cyclic patch (say INOUT) I get the following error while having the debugSwitch for polyMeshMorph at 1:

cyclicPolyPatch::order : Number of faces per zone:2{4896}
cyclicPolyPatch::geometricOrder : Rotation : n0: (-0.999999999697 -5.54905331569e-07 -2.45924692739e-05) n1: (0.999999999701 5.51248917836e-07 2.44304231784e-05)
cyclicPolyPatch::order : Dumping newly found cyclic match as lines between corresponding face centres to file "INOUT_faceCentres.obj"
--> FOAM Serious Error :
From function cyclicPolyPatch::geometricOrder
in file meshes/polyMesh/polyPatches/derivedPolyPatches/cyclicPolyPatch/cyclicPolyPatchMo rph.C at line 386
patch:INOUT : Cannot match vectors to faces on both sides of patch
half0Ctrs[0]: (-0.100000001555 0.000108585979925 -0.00497710608548)
half1Ctrs[0]: (7.46057646651e-10 0.000108585614284 -0.00497712229009)
Please use topological matching or adapt the featureCos() setting
Continuing with incorrect face ordering from now on!
void Foam::polyTopoChange::clear() : clearing topological change request
End


First it uses the "Rotation" branch which is not applicable for my translational periodicity. But this seem to happen because the condition mag(n0 & n1 < 1-SMALL) is true, i.e. SMALL is too small for my case. In order to change SMALL I have to recompile lots of stuff, because cyclicPolyPatchMorph.C is not just linked.
I also changed the writePrecision to 12. Further I checked the node positions for the two boundary patches in the ascii fluent file and the axial positions are all exactly x0=-0.1 and x1=0.

Any suggestions to solve the problem would be very helpful.

Steffen

[mattijs]

Create a copy the fluentToFoam converter and copy in a local version of cyclicPolyPatch.C with that SMALL replaced by something bigger.

Add cyclicPolyPatch.C to Make/files and
wclean
wmake

[gschaider]

Just a little thought: some of the mesh-manipulation utilities (not all) honor the writePrecision variable in the controlDict. So when these utilities write out node positions they clip everything beyond the 6th digit. The problem is that 6 digits is enough for the temperature, but not for grid information.

I could make similar problems go away if I set writePrecision to a rather high value, manipulated the mesh and then reset it to the reasonable 6 before doing simulations.