[aylalisa]

Hi to All!

I've created a mesh of a simple channel with snappyHexMesh (in parallel).
In principle meshing with SHM worked fine, simulation ran successfully.
Primarily the model had these boundary regions:
inlet, outlet : patch
wallLeft, wallRight, top, bottom: wall

Next I've changed the boundaries of LeftWall and RightWall to cyclic in blockMeshDict and I've adapted the 0/* files accordingly.




log-file 'log.snappyHexMesh_par' discloses this error:

nProcs : 8
Slaves : 
7
(
"linux-0ze2.14255"
"linux-0ze2.14256"
"linux-0ze2.14258"
"linux-0ze2.14259"
"linux-0ze2.14260"
"linux-0ze2.14261"
"linux-0ze2.14262"
)

Pstream initialized with:
    floatTransfer      : 0
    nProcsSimpleSum    : 0
    commsType          : nonBlocking
    polling iterations : 0
sigFpe : Enabling floating point exception trapping (FOAM_SIGFPE).
fileModificationChecking : Monitoring run-time modified files using timeStampMaster
allowSystemOperations : Disallowing user-supplied system call operations

// * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * //
Create time

Create mesh for time = 0

Read mesh in = 0.14 s

Overall mesh bounding box  : (0 0 0) (3.14 1.57 1)
Relative tolerance         : 1e-06
Absolute matching distance : 3.65027e-06

Reading refinement surfaces.
Read refinement surfaces in = 0.01 s

Reading refinement shells.
Refinement level according to distance to rod
    level 2 for all cells within 0.2 metre.
Read refinement shells in = 0 s

Setting refinement level of surface to be consistent with shells.
Checked shell refinement in = 0 s

Reading features.
Read features in = 0 s


Determining initial surface intersections
-----------------------------------------

Edge intersection testing:
    Number of edges             : 244200
    Number of edges to retest   : 244200
    Number of intersected edges : 542
Calculated surface intersections in = 0.19 s

Initial mesh : cells:80000  faces:244200  points:84240
Cells per refinement level:
    0    80000

Adding patches for surface regions
----------------------------------

Patch    Type    Region
-----    ----    ------
rod:

6    wall    rod_region0

Added patches in = 0.01 s

Selecting decompositionMethod hierarchical

Refinement phase
----------------

[4] Found point (1 0.5 0.5) in cell 203 on processor 4

Surface refinement iteration 0
------------------------------

Marked for refinement due to surface intersection          : 718 cells.
Marked for refinement due to curvature/regions             : 0 cells.
Determined cells to refine in = 0.07 s
Selected for refinement : 718 cells (out of 80000)
[0] Cannot find point in pts1 matching point 0 coord:(0.019625 0 0.02) in pts0 when using tolerance 0.0280204
[0] Searching started from:0 in pts1
.
.
.
[7]     Compared coord: (3.12038 0 0.98) at index 509 with difference to point 1.57051
[7] Cannot find point in pts1 matching point 485 coord:(3.12038 1.57 0.98) in pts0 when using tolerance 0.0280204
[7] Searching started from:509 in pts1
[7]     Compared coord: (3.12038 0 0.98) at index 509 with difference to point 1.57
[7] processorPolyPatch::order : Writing faces to OBJ file procBoundary7to5throughwallLeft_faces.obj
[3] processorPolyPatch::order : Dumping newly found match as lines between corresponding face centres to OBJ file "/home/lisa/OpenFOAM/lisa-2.2.2/run/modelle_2/Anfangsbedingungen_obstacle_rod/1_simpleFoam_cyclic/processor3/procBoundary3to1throughwallLeft_faceCentresConnections.obj"
[3] --> FOAM Serious Error : 
[3]     From function processorPolyPatch::order(const primitivePatch&, labelList&, labelList&) const
[3]     in file meshes/polyMesh/polyPatches/constraint/processor/processorPolyPatch.C at line 1014
[3]     in patch:procBoundary3to1throughwallLeft : Cannot match vectors to faces on both sides of patch
[3]     masterCtrs[0]:(1.58963 0 0.02)
[3]     ctrs[0]:(1.58963 1.57 0.02)
[3]     Check your topology changes or maybe you have multiple separated (from cyclics) processor patches
[3]     Continuing with incorrect face ordering from now on
[7] processorPolyPatch::order : Dumping newly found match as lines between corresponding face centres to OBJ file "/home/lisa/OpenFOAM/lisa-2.2.2/run/modelle_2/Anfangsbedingungen_obstacle_rod/1_simpleFoam_cyclic/processor7/procBoundary7to5throughwallLeft_faceCentresConnections.obj"
[7] --> FOAM Serious Error : 
[7]     From function processorPolyPatch::order(const primitivePatch&, labelList&, labelList&) const
[7]     in file meshes/polyMesh/polyPatches/constraint/processor/processorPolyPatch.C at line 1014
[7]     in patch:procBoundary7to5throughwallLeft : Cannot match vectors to faces on both sides of patch
[7]     masterCtrs[0]:(1.58963 0 0.54)
[7]     ctrs[0]:(1.58963 1.57 0.54)
[7]     Check your topology changes or maybe you have multiple separated (from cyclics) processor patches
[7]     Continuing with incorrect face ordering from now on

Could anybody point out the problem?

Thanks!
Ayla

[Ruli]

Dear Ayla,
I recently had the same problem. I think, snappy often has problems with cylcic BCs, especially when snappy is workin ON the cyclic patches. If you use cyclic BCs, the single faces on the cyclic patches have to be exactly the same (except mirrored postion), which is not the case, when snappy changes them.

What I recommend:
-Use snappy on the blockMesh with standard patches.
-After succesful snapping process use createPatch for subsequent redefinement of cyclicAMI patches.

Here is my createPatchDict:

FoamFile
{
    version     2.0;
    format      ascii;
    class       dictionary;
    object      createPatchDict;
}

// * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * //

pointSync false;
patches
(
    {
        // Name of new patch
        name rightWall;
        // Type of new patch
        patchInfo
        {
                type cyclicAMI;
           neighbourPatch leftWall;
           transform rotational;
           rotationAxis (1 0 0);
          rotationCentre (0 0 0);
           matchTolerance 0.01;
        }
        // How to construct: either from 'patches' or 'set'
        constructFrom patches;
        // If constructFrom = patches : names of patches. Wildcards allowed.
        patches (rightPatchWall);
    }
 
    {
        // Name of new patch
        name leftWall;
        // Type of new patch
        patchInfo
        {
                type cyclicAMI;
           neighbourPatch rightWall;
           transform rotational;
           rotationAxis (1 0 0);
           rotationCentre (0 0 0);
           matchTolerance 0.01;
        }
        // How to construct: either from 'patches' or 'set'
        constructFrom patches;
        // If constructFrom = patches : names of patches. Wildcards allowed.
        patches (leftPatchWall);
    }
);

CyclicAMI does not require the faces to be exactly the same, as it interpolates.

Best regards
Julian

[aylalisa]

Hello Julian!


did you finally (before solver starts) replace the old Patches (rightPatchWall, leftPatchWall) of the boundary files in 0/ folder after executing 'createPatch' - adapted from 'createPatchDict' dictionary - by the newly created Patches 'rightWall' and 'leftWall'?

dimensions      [0 1 -1 0 0 0 0];

internalField   uniform (0 0 0);

boundaryField
{
    inlet
    {
    type            fixedValue;
        value           uniform (0.0256 0 0);
    }

    outlet
    {
    type            zeroGradient;
    }

    leftWall
    {
        type            cyclicAMI;
    }
    
    rightWall
    {
        type            cyclicAMI;
    }
    
    top
    {
        type            fixedValue;
        value           uniform (0 0 0);
    }
    
    bottom
    {
        type            fixedValue;
        value           uniform (0 0 0);
    }
    
}

Because in your old boundary files, if I understand you correctly, you had defined:

.
.
.
   rightPatchWall
    {
        type             fixedValue;
        value           uniform (0 0 0);
    }
    
    leftPatchWall
    {
        type             fixedValue;
        value           uniform (0 0 0);
    }
.
.
.

--------------------------------------------------------------------------------------------------------------

Why is it necessary to create two new patches with createPatch utility?

...If you use cyclic BCs, the single faces on the cyclic patches have to be exactly the same (except mirrored postion), which is not the case, when snappy changes them.

Shouldn't it be enough to produce only one new patch on the basis of the other one? Then the faces in the patches would be identical (except mirrored position) too?
--------------------------------------------------------------------------------------------------------------

According to your explanation the error that occurred in my trial is due to the sensitive behavior of snappyHexMesh. This fact sort of forces the creation of cyclicAMI. But the case definition I work on (simple flow channel geometry) is actually not a typical application for cyclicAMI. Is that correct? I've found a masters thesis and OF documentation to AMI and tried to understand the typical case of application for AMI (which keeps my mind busy for quite some time):
http://www.openfoam.org/version2.1.0/ami.php
--------------------------------------------------------------------------------------------------------------

Here is a fundamental question I still have, concerning the usage of 'cyclic*' boundary conditions and 'symmetricPlane' boundary conditions and how to create periodic boundaries with help of these two available ones.

case 1: heat exchanger
Let's say I would like to simulate the behavior of an heat exchanger module. Instead of representing the whole module it would be cheaper, concerning computational cost, to restrict on a cutout of the whole geometry.

Is, in the case, the correct setting for the BCs (green edge) cyclic - to achieve that the mass flow through the pipes is constant and the geometry of the whole module - compared to the small cutout - is supposed to be infinite? What is the correct setting for the other boundaries (red edges)?



case 2: channel flow



In the channel above the middle plane (x-z) is obviously a symmetry plane.

But how to define boundaries shown in the following pic:


In case I would like to examine transition from laminar to turbulent flow (in a channel) a reasonable approach would be for example an LES computation. To save cells near walls I would like to omit leftWall and rightWall by setting proper BCs.
Is it reasonable to set cyclic boundaries for leftWall and rightWall or is it better to set symmetryPlane?
Is it correct to define type cyclic if I assume that the geometry is not a channel constrained by leftWall, rightWall, top and bottom but only by two infinite plates (top and bottom)?

Is it possible to equalize 'cyclic' with 'periodic'? Then I could define inlet, outlet, leftWall and rightWall as cyclic? According to what I've understood so far this would enable me to build a channel flow (a small cutting of the whole channel) with a comparatively small number of cells and the 'only' remaining near wall problem I still have to allow for are regions close to the walls top and bottom.

Honestly speaking I haven't understood the meaning of periodic up to a full extent, described in books and papers, so far.
Is periodic equatable with cyclic?
What is the intent of the definition of periodic? Save computational cost?

Sorry for this extensive novel but I really would like to improve my understanding and hope for your input.

Thank you!

Ayla

[sisetrun]

Hey Ayla,
It has been a while since yoru post... Do have a solution for your channel probleme since I am dealing with more or less the same setup at the moment!
Thanks for your info