[cStef]

Hello,

I'am trying to set up a pimpleDyMFoam case. I have seen that there are different transform Settings for cyclicAMI's.
Can someone explain to me the differences between these Settings and the case of application?

The Settings are:
noOrdering
coincidentFullMatch
rotational
translational
unknown

Thank you!

[HenningW]

Hi cStef,

I tried to figure out this one as well. My best source so far was:

http://de.slideshare.net/fumiyanozak...cacmi-34456484 Maybe you are lucky enough to find someone that speaks Japanese. I just know that the slide 17 mentions he does not know what unknown and coincidentFullMatch mean. Maybe it would be best to inspect the source code for that.

However, here is what I think the other three are used for:

rotational: for peridic cyclic boundary condition. So if you have 5 blades on a fan it might be wise to just simulate 1/5 of 360° and use the results on one side as a input on the other one (and vice versa)

translational: for periodic translational boundary conditions. Imagine the rows in a plane or train. As a first approach you just might want to simulate one row and assume it repeats to infinity. So you just connect the front and the back plane with this setting. Or even simpler: Instead of simulating a very long pipe you just might want to repeat a short part again and again by connecting the outlet to the inlet.

noOrdering: This one is for adjacent boundaries. This one I am not so sure about because I just started sliding meshes. But basically you seem to use this one for connecting meshes with each other where the interaction of the meshes is changing or not the same all the time.

As I said, I just started to look into it, so it would be nice if someone else could confirm my thoughts or correct them.
But be careful: I recently set my boundary "transform" to "rotational" for a rotational sliding mesh and somehow it ran. However, the results where not convincing me (not saying they are wrong, but there is no symmetry where one would exspect one, no smooth transition in velocity between the meshes). When I tried to refine the mesh my simulation crashed before the first timestep (problems with souce and target faces). So it seems to me that other settings for "transform" might work under certain circumstances, depending on your mesh, but are not neccessarly correct. I just found this error and switched to "noOrdering" and now it seems to be fine. Hopefully this solves at least my problem. Just wanted to let you guys know what can happen and maybe where to look if someone else as a similar problem.

Good luck,

Henning

[HannesGS]

Hi HenningW,

thanks for you interesting explanations. I looked at the presentation and, with the help of Google translate and a colleague, I got the same idea as you. Do I correctly understand that these keywords are available for both the cyclic and the cyclicAMI boundary condition type?

Originally Posted by HenningW

noOrdering: This one is for adjacent boundaries. This one I am not so sure about because I just started sliding meshes. But basically you seem to use this one for connecting meshes with each other where the interaction of the meshes is changing or not the same all the time.

I'm not sure what an adjacent cyclic patch connection would look like - could you show an example?

Hannes

[HenningW]

Hi Hannes,

Do I correctly understand that these keywords are available for both the cyclic and the cyclicAMI boundary condition type?

I cannot tell you for sure, since I have not used "cyclic", yet. However, I was possible to use the keyword "rotational" in combination with "cyclicAMI" (I did that by mistake) although I cannot think of any combination it would make sense. So I assume any combination is possible, but not all of them make sense from a physical point of view and you most likely will get strange/wrong results.

I'm not sure what an adjacent cyclic patch connection would look like - could you show an example?

In my case I had oscillating airfoils. I put a cylinder (stl-file) around each of them, cut out the domain and repatched it via sHM. The code below should give you an idea of what I did in sHM. I did the cylinder in a CAD program so it was positioned right where I wanted it. I am sure there are other possible solutions but this one worked quite well for me.

   

//..

geometry
    {

//..

        cylinder_left.stl
        {
            type triSurfaceMesh;
            name slidingCellZoneLeft;
            appendRegionName false;
        }
        cylinder_right.stl
        {
            type triSurfaceMesh;
            name slidingCellZoneRight;
            appendRegionName false;
        }
    }

//..

    castellatedMeshControls
    {
        features
        (
        );
        refinementSurfaces
        {

//..

            slidingCellZoneLeft
            {
                cellZoneInside inside;
                cellZone movingZoneLeft;
                faceType boundary;
                faceZone movingZoneLeft;
                level ( 2 2 );
            }

            slidingCellZoneRight
            {
                cellZoneInside inside;
                cellZone movingZoneRight;
                faceType boundary;
                faceZone movingZoneRight;
                level ( 2 2 );
            }

        }
    }

// ...

    repatchRegions
    {
        movingPatchLeft
        {
            location ( 0.0 0.1 -0.04 );
            excludePatches ( slidingCellZoneLeft slidingCellZoneLeft_slave );
            zone movingZoneLeft;
        }

        movingPatchRight
        {
            location ( 0.0 0.1 0.04 );
            excludePatches ( slidingCellZoneRight slidingCellZoneRight_slave );
            zone movingZoneRight;
        }
    }

In the attached image you can see the circular cuts in this slice of the domain around the airfoils. Of couse the rotation was set right in the center via dynamicMeshDict and the b.c. were set in 0 and constant/polyMesh/boundary for the patched.

On more advice from experience: Don't let the cylinder directly end with your geometry unless the wall on the inner geometry moves along a solid wall. For example my airfoil was rotation along a non-slip wall on one side and was moving the the domain on the other side. OF did not like the movement of the airfoil's sidewall in the domain. I always got errors regarding the connection/weighting of the cells. Either increase the size of the cylinder slightly so some inner domain is moved with the geometry and no change between wall and fluid cells occurs (inner cells & inner cells work just fine) or try ACMI, which might also solve the problem (i have not checked that, though).

Hope that helps,

Henning

[HannesGS]

Again thank you for your explanations.

Originally Posted by HenningW

I cannot tell you for sure, since I have not used "cyclic", yet. However, I was possible to use the keyword "rotational" in combination with "cyclicAMI" (I did that by mistake) although I cannot think of any combination it would make sense. So I assume any combination is possible, but not all of them make sense from a physical point of view and you most likely will get strange/wrong results.

Following the presentation you linked before, I thought that a boundary of type rotational cyclicAMI describes two patches the boundaries of which match after rotation, but the grid lines don't (e.g., due to different number of points/faces).

[HenningW]

As far as I know you either use "rotational" transformation with the type "cyclic" (e.g. a wedge that repeats x-times during a revolution) OR "noOrdering" transformation with "cyclicAMI" for sliding meshes. To my knowledge the first one needs an identical mesh on both patches, while the second one does not. It is weighted based on the area of the overlapping cells between the master and the slave. Even with the same mesh it would change due to the shift of the meshes towards each other.

Edit: The combination of "rotational" and "cyclicAMI" lead to strange results in my case. That is why assume it does not make sense from a physical point of view (at least for my case).

Edit: Sorry, I think I misread you comment. I am not sure if the combination "rotational" and "cyclicAMI" (in case they make sense) with need patches with a surface mesh that is somewhat identical. But I am quite confident that the surface geometry itself has to be identical within some tolerance.

[tripodtwostep]

Originally Posted by HenningW

Hi cStef,

I tried to figure out this one as well. My best source so far was:

http://de.slideshare.net/fumiyanozak...cacmi-34456484 Maybe you are lucky enough to find someone that speaks Japanese. I just know that the slide 17 mentions he does not know what unknown and coincidentFullMatch mean. Maybe it would be best to inspect the source code for that.

However, here is what I think the other three are used for:

rotational: for peridic cyclic boundary condition. So if you have 5 blades on a fan it might be wise to just simulate 1/5 of 360° and use the results on one side as a input on the other one (and vice versa)

translational: for periodic translational boundary conditions. Imagine the rows in a plane or train. As a first approach you just might want to simulate one row and assume it repeats to infinity. So you just connect the front and the back plane with this setting. Or even simpler: Instead of simulating a very long pipe you just might want to repeat a short part again and again by connecting the outlet to the inlet.

noOrdering: This one is for adjacent boundaries. This one I am not so sure about because I just started sliding meshes. But basically you seem to use this one for connecting meshes with each other where the interaction of the meshes is changing or not the same all the time.

As I said, I just started to look into it, so it would be nice if someone else could confirm my thoughts or correct them.
But be careful: I recently set my boundary "transform" to "rotational" for a rotational sliding mesh and somehow it ran. However, the results where not convincing me (not saying they are wrong, but there is no symmetry where one would exspect one, no smooth transition in velocity between the meshes). When I tried to refine the mesh my simulation crashed before the first timestep (problems with souce and target faces). So it seems to me that other settings for "transform" might work under certain circumstances, depending on your mesh, but are not neccessarly correct. I just found this error and switched to "noOrdering" and now it seems to be fine. Hopefully this solves at least my problem. Just wanted to let you guys know what can happen and maybe where to look if someone else as a similar problem.

Good luck,

Henning

That's a good file. And if you can not find a Japanese around, someone who speaks Chinese may half understand the Japanese slide.