[mattijs]

You either
- generate your correct cyclics in blockMesh
or
- generate a correct mesh first and then create the cyclics using createPatch.

The blockMesh you created has some partially defined cyclics it seems so cannot be loaded/morphed. Check the cyclic patch definition in the blockMeshDict.

[deepblue17]

Sorry, but I don't understand what you mean. What should be wrong in the blockMeshDict patch definition? The blockMesh utility is running correctly and the mesh is ok.
What I want to do is:
I have four surfaces with the same number of cell faces and at each equal cell face it should the same cyclic bc. For the createPatch utility I need to specify the faces with an patch and since version 1.3 multiple patches are allowed. And so I thought I could do four cyclic patches:
patch(surface_1 surface_2)
patch(surface_2 surface_3)
patch(surface_3 surface_4)
patch(surface_4 surface_1)
When the patch definition is wall, patch etc. it works but not when the patch definition is cyclic.
In this case I have merge two surfaces in one patch, so I need only one patch definition in the createPatchDict and there is only one error and not four but it is the same. And there are no multipli patches.
And because the old patches are removed with the createPatch utility it doesn't matter how the patch is defined in the blockMeshDict. Or am I wrong?

Thanks, a lot.

[deepblue17]

Servus,

has anybody a testcase for the createPatch utility with cyclic patches that is running correctly with version 1.3 ?

Thanks

[mattijs]

Take e.g. the cavity and put cyclics on frontAndBack.

I think the problem is the multiple cyclics. The automatic matching expects the cyclic halves to be non-connected or separated by a sharp angle.

So do one opposing pair first, then change the type to e.g. polyPatch by editing the boundary file, do the second opposing pair, change their type to polyPatch etc. until all your pairs are matched up.

Then change all those polyPatches back to cyclics.

[deepblue17]

I have modified the cavity case, so that it is a real cube with 5 cells at each edge. When I change the frontAndBack patch definition from empty to patch and the createPatchDict looks like this:

name cyclicFront;
type cyclic;

constructFrom patches;

patches (frontAndBack);

It comes the following warning message very often:

Reading createPatchDict

Copying patch movingWall at position 0
Copying patch fixedWalls at position 1
Copying patch frontAndBack at position 2
Adding new patch cyclicFront of type cyclic as patch 3
Moving faces from patch frontAndBack to patch 3

Removing empty patch frontAndBack
Compacted patches:
movingWall size:25 start:300
fixedWalls size:75 start:325
cyclicFront size:0 start:400
--> FOAM Warning :
From function min(const UList<type>&)
in file /home/dm2/henry/OpenFOAM/OpenFOAM-1.3/src/OpenFOAM/lnInclude/FieldFunctions.C at line 362
empty field, returning zero
--> FOAM Warning :
From function max(const UList<type>&)
in file /home/dm2/henry/OpenFOAM/OpenFOAM-1.3/src/OpenFOAM/lnInclude/FieldFunctions.C at line 341
empty field, returning zero


But when I disable the movingWall and fixedWall patches in the blockMeshDict, then it works.

And when there are more then one patch at
patches(patch_1 patch_2)
it doens't works with cyclic and the old error message comes again.

Thanks, very much.

[mattijs]

Is bug in createPatch.

- In mesh/manipulation/createPatch/createPatch.C comment out the check for whether the patch has changed on line 338. (so always do the repatcher.changePatchID)

[chris1980]

yeah this really fixes the problem

btw: why does the util create the new "stuff" in a new directory instead of overwriting it?

[deepblue17]

Well it work's sometimes. When I combine
patches( surface_1 surface_3)
patches( surface_2 surface_4)
then it is running correctly. But when I combine
patches( surface_1 surface_2)
patches( surface_3 surface_4)
then it comes the first error message. At this time there are no multiple cyclic patches! The surfaces are side by side from one to four.

It is possible to make multiple cyclic patches? With a patch or wall definition it is possible.

Thanks

[mattijs]

Can you send me a simple blockMeshDict which replicates the problem? Send to m.janssens

[mattijs]

Hi Oliver,

- your case cannot be handled by createPatches - it has to be done by the mesh generator. This is because the two patches you are trying to merge are connected and in-line. createPatches just bunches the faces to-be-merged together and then tries to split it into two equal sets using some geometric or topological feature.

- I can couple the non-neighbouring front_01 and front_03 if I start off with everything polyPatch.

- you can switch on the 'cyclic' debug switch in the controlDict if you want some more info on what it does 'under the hood'.

[maka]

some times two patches are cyclic for velocity field but are not so for scalar field. So on need to select them in different way for specifying b.c. for velocity and scalar field.

I tried to define the patches as:

patch patch1
(
...
)

patch patch2
(
...
)
cyclic patch12
(
patch1
patch2
)
since in the user guide 6.2.2 it says that
"cyclic
Enables two patches to be treated as if they are physically connected; used for repeated geometries"
In this way I call the b.c of the scalar on patch1 and patch2 while calling the cyclic b.c for velocity on patch12. But I got error that means that cyclic is not expecting a patch name in its list. I then tried to copy the contents of patch1 faces and patch2 face into cyclic patch12, I got an error that I'm using faces that are part of previously defined patch. It seems that a face can only be part of a single patch. I'm using V1.2

Can this problem be solved with createPatch?

Thanks,
Maka

[mattijs]

The polyPatch has to be cyclic since this is about additional topological information (i.e. connectivity across the patch). This is purely a mesh issue.

Then you set up boundary conditions which in your case do something special. Quite possibly your scalar b.c. (fixedValue?) cannot be defined on a cyclicPolyPatch and you'll have to define your own boundary condition. The sources for boundary conditions (for finite volume) are all in $FOAM_SRC/finiteVolume/lnInclude/

[maka]

so the library does not allow a face to be part of two different patches, does it? if so, would not it be easier if I remove such constrain? I wonder if this can have some bad effect on the way OpenFOAM works? If the constrain is removed then the problem is solved by:

apply fixed scalar value b.c. on patch1.
apply Neumann b.c. for the scalar on patch2.
apply cyclic velocity on patch12.

Thanks for you prompt reply.

regards,
Maka