cyclicAMI: what is each transform type for?
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! |
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 |
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:
Hannes |
1 Attachment(s)
Hi Hannes,
Quote:
Quote:
Code:
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 |
Again thank you for your explanations.
Quote:
|
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. |
Quote:
|
All times are GMT -4. The time now is 02:51. |