CFD Online Logo CFD Online URL
www.cfd-online.com
[Sponsors]
Home > Forums > Software User Forums > OpenFOAM > OpenFOAM Running, Solving & CFD

cyclicAMI: what is each transform type for?

Register Blogs Members List Search Today's Posts Mark Forums Read

Like Tree16Likes
  • 15 Post By HenningW
  • 1 Post By HenningW

Reply
 
LinkBack Thread Tools Search this Thread Display Modes
Old   April 23, 2015, 05:20
Default cyclicAMI: what is each transform type for?
  #1
New Member
 
Join Date: Mar 2015
Posts: 6
Rep Power: 11
cStef is on a distinguished road
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!
cStef is offline   Reply With Quote

Old   June 16, 2015, 05:26
Default
  #2
Member
 
Join Date: Feb 2015
Posts: 39
Rep Power: 11
HenningW is on a distinguished road
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
wyldckat, kaifu, fumiya and 12 others like this.
HenningW is offline   Reply With Quote

Old   October 8, 2015, 08:56
Default
  #3
New Member
 
Hannes Grimm-Strele
Join Date: Sep 2015
Posts: 7
Rep Power: 10
HannesGS is on a distinguished road
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?

Quote:
Originally Posted by HenningW View Post
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
HannesGS is offline   Reply With Quote

Old   October 8, 2015, 11:55
Default
  #4
Member
 
Join Date: Feb 2015
Posts: 39
Rep Power: 11
HenningW is on a distinguished road
Hi Hannes,

Quote:
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.

Quote:
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.

Code:
   

//..

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
Attached Images
File Type: png Screenshot-1.png (34.4 KB, 228 views)
mo_na likes this.

Last edited by HenningW; October 9, 2015 at 05:27.
HenningW is offline   Reply With Quote

Old   October 9, 2015, 04:09
Default
  #5
New Member
 
Hannes Grimm-Strele
Join Date: Sep 2015
Posts: 7
Rep Power: 10
HannesGS is on a distinguished road
Again thank you for your explanations.

Quote:
Originally Posted by HenningW View Post
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).
HannesGS is offline   Reply With Quote

Old   October 9, 2015, 04:30
Default
  #6
Member
 
Join Date: Feb 2015
Posts: 39
Rep Power: 11
HenningW is on a distinguished road
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.

Last edited by HenningW; October 9, 2015 at 05:32.
HenningW is offline   Reply With Quote

Old   July 19, 2016, 08:52
Default
  #7
New Member
 
Pin Lyu
Join Date: Mar 2016
Location: Harbin
Posts: 6
Rep Power: 10
tripodtwostep is on a distinguished road
Quote:
Originally Posted by HenningW View Post
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.
tripodtwostep is offline   Reply With Quote

Reply

Thread Tools Search this Thread
Search this Thread:

Advanced Search
Display Modes

Posting Rules
You may not post new threads
You may not post replies
You may not post attachments
You may not edit your posts

BB code is On
Smilies are On
[IMG] code is On
HTML code is Off
Trackbacks are Off
Pingbacks are On
Refbacks are On


Similar Threads
Thread Thread Starter Forum Replies Last Post
[OpenFOAM.org] compile error in dynamicMesh and thermophysicalModels libraries NickG OpenFOAM Installation 3 December 30, 2019 01:21
boundary conditions for simpleFoam calculation foam_noob OpenFOAM Running, Solving & CFD 8 July 1, 2015 09:07
interFoam/kOmegaSST tank filling with printStackError/Mules simpomann OpenFOAM Running, Solving & CFD 3 February 17, 2014 18:06
Temperature Issue in OpenFOAM-2.2.0 prasant OpenFOAM 0 March 12, 2013 08:17
pipe flow with heat transfer Fabian OpenFOAM 2 December 12, 2009 05:53


All times are GMT -4. The time now is 19:07.