[allenfieldin]

hi, foamers

I am a new foamer, recently trying to combine cyclic boundaries in channelFoam with FaMesh free surface (which uses movingmesh method), cyclic boudaries were set on both the horizontal directions of the rectangular channel.
it seems that cyclic boundary in extend 3.0 needs to define a pair of faces. so I make the blockMeshDict as required and set the faMeshDefinition file as below:

polyMeshPatches  1( freeSurface );

boundary
{
    sides2
    {
        type                cyclic;
        ownerPolyPatch      freeSurface;
        neighbourPolyPatch  sides2;
    }

    inout2
    {
        type                cyclic;
        ownerPolyPatch      freeSurface;
        neighbourPolyPatch  inout2;
    }

}

where I get the error alert:

Unknown faceTetPolyPatch type cyclic.  Valid faceTetPolyPatch types are :

9
(
wall
processor
wedge
patch
empty
mixingPlane
cyclicGgi
ggi
symmetryPlane
)

another problem is, when I tried to try cyclicGgi as it prompted, cyclicGgi need to define master and shadow patch pair that are separated faces, which is definitely different from that for cyclic boundary pair. Some information told me to set directly in boundary file for cyclicGgi, but it seems not working.

can someone tell me what is going on here. I just use Foam for one or two months, and desperately need help. Any hint for this problem would be of great help for me

[allenfieldin]

fresh foamers need help.....

Does anybody know the determination of separationOffset, an coefficient used in cyclicGgi.
I have two planar patches separated with a 2m distance in Z_direction from master (z=0) to shadow(z=2). those two patches are supposed to be a pair of peroidic boundaries without rotations. Should I set separationOffset in each definition og the patch in polyMesh/boundary with (0 0 2).
Or, set to (0 0 -2) for the master patch and (0 0 2) for the shadow?

and the Brodgeovelap off ?
Thanks in advance.

[allenfieldin]

why can't I get a reply, so few people use cyclicGgi?

[allenfieldin]

Hi,

I have not used the separationOffset myself, but I would guess that you should specify the distance in meters that patch should be moved to get to the other patch. I.e. + for one and - for the other.

Always use bridgeOverlap false to start with. If that works you are fine. If it doesn't, you should check why. If there are just a couple of faces that are uncovered, you may be fine, but it may also be because you have set up things incorrectly.

There should also be some degugSwitch that gives more information.
__________________________________________________ _______________


hi, ****************,
I am student in singapore, I recently read about you presentation on the turbines where you used cyclicGgi, and you are obviously an expert on this.

I have two planar patches separated with a 2m distance in Z_direction, from master (z=0) to shadow(z=2). those two patches are supposed to be a pair of peroidic boundaries without rotations. Should I set separationOffset in each definition of the patch in polyMesh/boundary with (0 0 2).
Or, set to (0 0 -2) for the master patch and (0 0 2) for the shadow?
like this ?
__________________________________________________ ___
sides1_2
{
type cyclicGgi;
nFaces 1000;
startFace 178700;
shadowPatch sides1_1;
zone sides1_2_zone;
bridgeOverlap true;
rotationAxis (0 0 1);
rotationAngle 0;
separationOffset (0 02);
}
sides2_1
{
type cyclicGgi;
nFaces 1000;
startFace 179700;
shadowPatch sides2_2;
zone sides2_1_zone;
bridgeOverlap true;
rotationAxis (0 0 1);
rotationAngle 0;
separationOffset (0 0 -2);
__________________________________________________ ___

and with the Brodgeovelap off ?

I tried to serach papers or similar examples for this, but unfortunately I still have nothing.

hope you can read this mail, and get me out of this confusion

[allenfieldin]

Hello,guys,
I defined a pair of cyclic inlet/outlet boundries of a rectangular tank in foam-extend ,it is an interTrackFoam case, which employs FaMesh method.
the patch definition and faMesh goes as below:

    cyclic inout
    (
        (2 8 10 4)
        (3 5 11 9)
    )

polyMeshPatches  1( freeSurface );

boundary
{
    inout
    {
        type                cyclic;
        ownerPolyPatch      freeSurface;
        neighbourPolyPatch  inout;
    }

}

now I want to know the edge numbering of each edge connecting the boundary with the freeSurface ('in' with free surface ,'out 'with freeSurface)

Is there some method for this?

thanks.

[wyldckat]

Greetings Allen,

After reading a bit of the private message you sent me, I came looking for any threads you had written. Seeing that you had a few threads roughly on the same topic, I merged them all into this single thread.

In addition, here's a quote from part of the message you sent me, since it gives more insight onto the questions you have:

Originally Posted by allenfieldin

Recently I have been trying to combine the two solvers together: interTrackFoam and channelFoam in extend-3.0, where the former employs the finite area method for the free surface and also the moving mesh mothod, and the latter uses the cyclic boundaries on both pair of the horizontal patches. The above special functionalities are preserved in my new application.

The first try:
I have been trying to apply the cyclic boundaries to the horizontal patches (4 pairs), blockMesh and makeFaMesh, it gives the following Error:

start createDynamic mesh

Create dynamic mesh for time = 0

Selecting dynamicFvMesh dynamicMotionSolverFvMesh
Selecting motion solver: laplace


--> FOAM FATAL ERROR: 
Unknown faceTetPolyPatch type cyclic.  Valid faceTetPolyPatch types are :

9
(
wall
processor
wedge
patch
empty
mixingPlane
cyclicGgi
ggi
symmetryPlane
)


    From function faceTetPolyPatch::New(const polyPatch&, const tetPolyBoundaryMesh&)
    in file tetPolyMesh/tetPolyPatches/faceTetPolyPatch/newFaceTetPolyPatch.C at line 58.

It seems the faceTetPolyPatch does not support the cyclic boundary, and later on we checked and found that the mesh motion solver with laplace for the dynamicMesh method uses the tet information, which does not support cyclic conditions. and cyclic conditions in extend-3.0 requires a pair-definition, not like that in OpenFOAM 2.3.0 where it is defined separately.

So I shifted to cyclicGgi and applied it to the the 8 separated patches (corresponding to the 4 pair of cyclic boundaries in last try). After faceSet and setZone I modified the boundary file, in the faMeshDifinition 4 cyclic patchs intersecting the freeSurface was set, hoping that it will work.
and this time makeFaMesh can pass, but not the combined solver.

After a long time debugging, we finally found the following problem:

lPN internalField of edge0is 0.666667
lPN internalField of edge1is 1.33333
lPN internalField of edge2is 0.666667
lPN internalField of edge3is 1.33333
lPN internalField of edge4is 1.33333
lPN internalField of edge5is 0.666667
lPN internalField of edge6is 1.33333
lPN internalField of edge7is 0.666667
lPN internalField of edge8is 1.33333
lPN internalField of edge9is 1.33333
lPN internalField of edge10is 0.666667
lPN internalField of edge11is 0.666667
lPN internalField of Patch0is type            cyclic;
value           nonuniform List<scalar> 3(1.5 1.5 1.02272e-321);

The error was resulted in the which shows there existed a infinitesmall value of the lPN value for the boundary edge, it happened when "edgeInterpolation::makeDeltaCoeffs" in the edgeInterpolation.C file. We reckon that this is because when setting the famMeshDifinition file as below, as the cyclic boundary requires the setting of side2_1 and side2_2 as a whole part, and the the edgelabels in faBoundary file are also required to be in pairs. So that is not right to separate the pairs, which is actually what we were trying and using cyclicGgi.

     sides2_1
    {
        type                cyclic;
        ownerPolyPatch      freeSurface;
        neighbourPolyPatch  sides2_1;
    }

    sides2_2
    {
        type                cyclic;
        ownerPolyPatch      freeSurface;
        neighbourPolyPatch  sides2_2;
    }

So the options for my application might lie in one of these:
1. How to make FaMesh or finite area method accommodate the cycliGgi boundary condition? as it does not in exten-3.0 now.
2. modified the cyclicFaPatch.C code and make it accept the separated patches in one pair just like that in OpenFOAM 2.3.0.
3. find a motion solver that can deals with cyclic boundary pairs definition. Another interesting thing isi cyclicFaPatch is inherited from faPatch, however ggi and cyclicGgi are from coupledFaPatch. That is why tet based solver doesn't support cyclic boundary?

Unfortunately, I don't have yet enough experience with dealing with the FA implementation that is available in foam-extend and I'm still building my experience with dynamic meshes and cyclic boundary conditions. Therefore, the details you provided only seem vaguely familiar to me, but I have no idea where to start looking at to try and figure things out.

My best advice is that you share some simple test cases and examples you are using for testing these features, as well as sharing some test solvers/utilities you're using, as explained here: http://www.cfd-online.com/Forums/ope...-get-help.html
This way anyone can try and accompany the evolution of your project and it makes it a lot easier to try and pinpoint where the problems might be. In other words: always divide and conquer each problem you're trying to solve

In addition, I strongly suggest that you upgrade to foam-extend 3.1. I have no idea if this issue has already been solved there, but there is somewhat good chance that it has. If not, upgrade to 3.2 when it's released: http://www.cfd-online.com/Forums/ope...er-2014-a.html

Best regards,
Bruno