CFD Online Discussion Forums - [snappyHexMesh] Can't couple front & back faces in cyclic BC after snapping in SHM

CFD Online Discussion Forums (https://www.cfd-online.com/Forums/)

- OpenFOAM Meshing & Mesh Conversion (https://www.cfd-online.com/Forums/openfoam-meshing/)

- - [snappyHexMesh] Can't couple front & back faces in cyclic BC after snapping in SHM (https://www.cfd-online.com/Forums/openfoam-meshing/116818-cant-couple-front-back-faces-cyclic-bc-after-snapping-shm.html)

Can't couple front & back faces in cyclic BC after snapping in SHM

Hi everyone!

I have a problem involving the createPatch utility and snappyHexMesh. I'm setting up a 3D simulation across a wing section, and I want to couple the front and back faces of the mesh with a "cyclic" boundary condition.

In order to bring down the cell count, I have to do some work on the mesh after generating it in SHM. For this reason, I initially define the front and back faces of my mesh as "empty", and only convert them to "cyclic" later using the createPatch utility.

My problem is that if I allow SHM to go through with the snapping stage, it reorders the face list in such a way that the faces on the front and back patches can no longer find their twin on the opposite patch. This makes it impossible to convert these faces from "empty" to "cyclic".

I've tried the renumberMesh utility, but that didn't solve the problem. Do any of you know how to go about converting patches generated in snappyHexMesh to the cyclic type?

regards,
Håkon

Dear Håkon

I recommend that you specify the cyclic patches as type "cyclic" in a blockMeshDict. Then when SHM runs, it will preserve these patches as cyclic and you should require not further mesh processing. This worked for me.

See the openfoam website for details of how ti assign patch types in blockMesh.

Regards,
Tom

Quote:

Originally Posted by Thomas_Lloyd (Post 431854)

I just did this as you have said. My blockMeshDict is as follows:

Code:

convertToMeters 1;



vertices

(

    (0 -0.1145 0.3)

    (0.3 -0.1145 0.3)

    (0.3 -0.1145 0)

    (0 -0.1145 0)

    (0 1 0.3)

    (0.3 1 0.3)

    (0.3 1 0)

    (0 1 0)

 

    

);



blocks

(

    hex (0 3 7 4 1 2 6 5 ) (20 60 20) simpleGrading (1 1 1)//28 39 28

);



edges

(

);



boundary

(

    cyc_half0

{



type cyclic;

neighbourPatch cyc_half1;

transform rotational;

            rotationAxis (0 1 0);

            rotationCentre (0 0 0);

faces 

(

(3 7 6 2 ) 

);

}



cyc_half1

{



type cyclic;

neighbourPatch cyc_half0;

transform rotational;

            rotationAxis (0 1 0);

            rotationCentre (0 0 0);

faces 

(

(0 3 7 4 ) 

);

}

);



mergePatchPairs

(

);

It generates a block mesh with no problems. but when I run shm it says:

Code:

-> FOAM FATAL ERROR: 

More than one patch accessing the same transform but not of the same sign.

patch:cyc_half1 transform:0 sign:-1  current transforms:(-1 0 0)



    From function Foam::label Foam::globalIndexAndTransform::addToTransformIndex

(

const label,

const label,

const bool

) const



    in file lnInclude/globalIndexAndTransformI.H at line 268.



FOAM exiting

Do you know why?

Hi,
you can also define your patches as wall (default for sHM) etc. in snappy and after snappy running through you can modify your 0/* files and boundary file with the "changeDictionaryDict" command.
For this you need a changeDictionaryDict file in your system folder. You can find example files either by yourself or have a look at this one located in:

/tutorials/heatTransfer/chtMultiRegionSimpleFoam/multiRegionHeater/system/

In case you run in parallel you have to modify the command.
1. First move to the processor* folder
2. Then enter "changeDictionaryDict -dict /path/to/the/dict/file"
3. Repeat step 1 and 2 for all processor folders.

Greetings

Hi all and thanks for the advice,

My question was regarding a masters project that I handed in in June, and I seem to have misplaced the case files, so I can't go back and check it. However, the work that I intended to do on the mesh included cutting out a subset of the mesh, including some of the front and back faces, and extruding it to a lower spanwise resolution before putting it back in. It was therefore not possible to define the front and back boundaries as cyclic from the get-go, as that would mess up the subset and extrusion processes.
I also tried what you suggest, banana, but this process of cutting and extrusion changed the cell count of the mesh, which threw off the face numbering. Now, this shouldn't have been a problem when generating a cyclic boundary, as any face on one of the planes should have been able to find its twin on the other, based on its position and area. For some reason, though, this automatic face matching didn't work, and I just decided to drop the problem after a while, as it wasn't essential.

@sharon: I think the problem may be that the rotationAxis on one of your cyclic patches is defined the wrong way. Try changing one or the other to (0 -1 0). However, i also think you might be using syntax from an old version of OF, as you don't have to define the coupling of your cyclic boundaries that explicitly anymore. Check out the tutorials with cyclic boundaries. I think some of them are defined in a simpler way.

best regards,
Håkon