
[Sponsors] 
December 19, 2011, 15:48 
OpenFOAM 2.1.x  AMI (Arbitrary Mesh Interface)

#1 
Senior Member
Philippose Rajan
Join Date: Mar 2009
Location: Germany
Posts: 531
Rep Power: 17 
Hello,
A Good Evening to you all :)! I must say, it feels nice to be typing out another message on the forum. It has been a fairly long time since I have actively posted anything here. It doesn't mean that I have not been using OpenFOAM though :)! I had a quick question..... Had a very quick and cursory glance at the source code for the Arbitrary Mesh Interface (AMI) in the new OpenFOAM 2.1.x release from OpenCFD/SGI.... to me, it looks like as of now, the AMI does not (yet) support linear sliding interfaces which contain large scale uncovered surfaces (the same issue with the GGI option in the OpenFOAMext stream). There also does not seem to be any special treatment of uncovered faces at all.... unlike the OpenFOAMext stream which contains limited support via the overlapGGI boundary conditions. Can anyone confirm whether these observations are right, and whether there are any plans in the pipeline of introducing support for truly generic sliding interfaces with proper treatment of uncovered / overlapping patches via the GGI / AMI technique? A Great evening ahead :)! Philippose 

December 19, 2011, 16:40 

#2 
Senior Member
Sandeep Menon
Join Date: Mar 2009
Location: Amherst, MA
Posts: 387
Rep Power: 16 
It doesn't look like partial overlap is handled. I assume that you're expecting uncovered faces to be converted into walls?
Either way  I'd like to know what Hrv and Martin think about this... :) 

December 20, 2011, 05:23 

#3  
Senior Member
Arjun
Join Date: Mar 2009
Location: Nurenberg, Germany
Posts: 487
Rep Power: 13 
Quote:
Most probably you are correct. I read the paper openCFD refers to about this implementation. In year 2007 2008 I implemented the sliding interface algorithm exactly the way mentioned in that paper. This algorithm is very easy to implement and that is its biggest advantage. But I found it was difficult to do partial overlap. Further this algorithm in some extreme cases could fail and give wrong results. For this reason, recently i dropped this algorithm and developed another one that could handle partial overlaps. 

December 21, 2011, 01:10 

#4 
Senior Member
Philippose Rajan
Join Date: Mar 2009
Location: Germany
Posts: 531
Rep Power: 17 
Hello Sandeep and Arjun,
Good Morning :)! @Sandeep: Yes.... as you know, I have been after this quest for "GGI with large overlaps" for a long time now :)! With the uncovered parts being retained as walltype. I am quite sure now (after looking a little deeper into the code), that this feature is not present in the AMI interface. @Arjun: Cool :)! Are you saying that you already have an implementation of GGI which properly handles large overlaps? If so, would it be possible for you to give me (us) more information regarding your implementation? And is your implementation available in the public domain? Philippose 

December 21, 2011, 02:08 

#5  
Senior Member
Arjun
Join Date: Mar 2009
Location: Nurenberg, Germany
Posts: 487
Rep Power: 13 
Quote:
I can give the outline to what I did, if someone wants to follow: Take two sets of polygons. Set A and Set B. Imagine they overlap, this overlap could be partial or in any fashion possible. Step 1 : Create kd tree structure for Set A. Note: I create hyper kd tree structure, here hyper kd tree is new algorithm i designed which is much faster than normal kd tree algo. Step 2: During the Step 1, find out the average size of polygons in Set A. This will be used to create search box. Step 3: Loop through polygons in Set B one by one. Step 3 (a) : Take center of polygon and length of search area, find all the polygons of set A whose center lie in this search box. Step 3 (b) : Find out whether these polygons of set A intersect with polygon in question. NOTE: My algo returns , center of this intersect and a polygon that is over lap between these two. Step 3 (c): Store it into dynamic graph structure. Setp 4: All the polygons that do not intersect with any polygons are walls. Descretization is same as of wall. Setp 5: There are some polygons , that partially overlap, so they are half wall half flow. Apply the descretization for wall and flow for them based on their overlap. My results: I take less than 0.02 millisecond per polygon. (for 100K polygons roughtly 1.5 seconds by 1 processor). This time involves construction of hyper kd tree structure + range search + polygon polygon intersection + dynamic graph for results. 

December 21, 2011, 04:25 

#6 
Senior Member
Alberto Passalacqua
Join Date: Mar 2009
Location: Ames, Iowa, United States
Posts: 1,907
Rep Power: 27 
@Arjun: is your work published (paper or presentation)?
__________________
Alberto Passalacqua GeekoCFD  A free distribution based on openSUSE 64 bit with CFD tools, including OpenFOAM. Available as in both physical and virtual formats. OpenQBMM  An opensource implementation of quadraturebased moment methods. To obtain more accurate answers, please specify the version of OpenFOAM you are using. 

December 21, 2011, 18:02 

#7 
Senior Member
Philippose Rajan
Join Date: Mar 2009
Location: Germany
Posts: 531
Rep Power: 17 
Hello again Arjun,
Thanks a lot for the information regarding your implementation of a version of GGI. After having read through your post and looking around a little regarding kdtrees, etc., I have a couple of questions....: 1. As far as I know, the 1.6ext stream of OpenFOAM already has (has had for a while now) an implementation of GGI, however, also not yet capable of handling large uncovered areas of type wall. This implementation also has algorithms for finding overlapping faces between the master and slave patches, calculating the weights, and creating lists of uncovered faces. How is your algorithm for finding overlaps and uncovered faces different? Is it a more efficient approach? 2. I think a GGI feature can basically be split up into two phases... one is the finding of the overlapping faces and calculation of the weights, and the second phase is the part where the actual interpolation / mapping of the fields between the two sets of patch faces (master and slave) are performed. Now... the Phase2 of the current implementation of GGI needs to be modified, such that uncovered faces are treated as walls. My question is, how can each field (eg. U, p, k, epsilon, omega, etc.) be informed, that a specific part of a patch is a wall, while another part is not? The boundary conditions for a wall for each of the physical variables are different than in the case when the faces are part of the set of faces which are overlapping..... This is the part where I am stuck.... should the uncovered parts be shifted into a separate zone for example? Or can the GGI face weights be somehow used to switch between different boundary conditions? etc...etc... Hope I didnt come off as sounding too confused.... Have a nice day ahead! Philippose 

December 21, 2011, 20:59 

#8 
Senior Member
Arjun
Join Date: Mar 2009
Location: Nurenberg, Germany
Posts: 487
Rep Power: 13 
alberto, there is nothing published because i can not publish anything without persmission from my company and they have zero interest in it.
I also did it just because i wanted to see whether the problem is really that difficult. There was a thread in openfoam forum about problems of GGI and after reading that thread i decided to spend two three days with it. Further, most probably this whole thing with IBM will be available in next versions of iNavier. People will be able to use them all. 

December 21, 2011, 21:01 

#9  
Senior Member
Arjun
Join Date: Mar 2009
Location: Nurenberg, Germany
Posts: 487
Rep Power: 13 
Quote:
1. they use kd tree algorithm and I use hyper kd tree algorithm. This new algorithm is very fast for large data sets. The idea is that instead of dividing each bucket into two parts, divide them into N parts. Now because of this we have a tree structure that does not go deep. So any range search is matter of very few comparisons. In normal kd tree larger the data larger the dept of tree and thus more comparison to search something. 2. They use SutherlandHodgman algorithm for polygonal clipping. Which is supposed to be the fastest algorithm for this http://en.wikipedia.org/wiki/Sutherl...gman_algorithm I do not use it. I read the algorithm and I did not understand it enough to implement myself. So i developed my own polygon polygon intersection algorithm. My algorithm takes two polygons and return a polygon that represent the intersection region of them. About efficiency , people say that SutherlandHodgman fastest algorithm. If I ever get time I might write this algo too and compare the speed. Quote:
Quote:
What you are supposed to do is to treat them as walls or any other BC you want it to be. Now after the BC is decretizised , you get source terms that has to be added to the various transport equation you are solving. For example if it was wall you get the source corresponding to wall descretization. Before you add this to source term of transport equation multiply it with another weight factor that varies between 0 and 1 . So 1 is full wall and 0 is no BC applied. in between is values representing partial overlap. The weight is = area non covered face / Total face area of wall face of control volume. It will be 0 for fully covered or live cell. On the covered faces apply the dicretization as normally as if they are continuous flow faces. It is simple, very simple. 

March 10, 2012, 09:16 

#10 
New Member
Join Date: Jun 2011
Posts: 6
Rep Power: 7 
Hello guys,
you are talking about AMI specifics. My problem is setting up an AMIcase on my own. I used 1.6 extend before. Now I try to make my testcase run on OpenFOAM 2.1.0 with AMI. I analyse the "tutorials" of AMI, but there is no description how to set up a case from the very beginning. There are too many confusing commands and files. Is there any proper and useful tutorial, which explains the use of AMI for a student? With best regards, Chris 

March 27, 2012, 14:38 

#11 
Senior Member

Hello Christian,
if you have succeeded at using AMI, would you be able to give a sort of feedback of AMI vs GGI? I have used GGI in the past and now that Martin Beaudoin et al have worked for years on it.. I'd like to try the AMI, but I doubt it can be nearly as mature so shortly after having been released... Any comments? Thanks, Louis 

March 28, 2012, 11:28 

#12 
Senior Member
Niels Nielsen
Join Date: Mar 2009
Location: NJ  Denmark
Posts: 472
Rep Power: 16 
AMI and OF21 scales much better for parallel runs.
up to 4 processors you see little difference but after that AMI scales disturbingly better than GGI. When that is said you have to be a lot more careful when constructing the mesh at the AMI's. Also the GGI implementation has a lot more features like partial overlap and other. So it really depends on your needs.
__________________
Linnemann PS. I do not do personal support, so please post in the forums. 

April 17, 2012, 09:45 

#13 
Member
wided
Join Date: Jul 2010
Posts: 54
Rep Power: 8 
Hi All, I am also trying to use AMI. I am not interested in partial overlap right now and I can´t get the 1.6ext to compile on my PC. That´s why I am trying to see if AMI does the work for now. My case is a simple one. I have an airfoil which I want to oscillate in a sinusoidal fashion.
I use pimpleDymFoam in its laminar version. I create two meshes, one for the airfoil than one for the external stator part (which basically a ring). Then I merge these two meshes using mergeMeshes. My simulations are crashing for the moment. I am not sure why is that. I nevertheless noticed that my AMI1 and AMI2, the shared surfaces between my two meshes are not really overlapping (see fig attached). Any suggestions concerning that problem? 

April 17, 2012, 12:58 

#14 
Senior Member

try a smaller courant number?


May 16, 2012, 08:08 
Also problems setting up AMI

#15 
New Member
Martin Söder
Join Date: Jun 2011
Posts: 8
Rep Power: 7 
I have been trying to set up AMI but I'm not successful
I get the following error message > FOAM FATAL ERROR: Size mismatch. Source patch size:35 Source agglomeration size:20 Target patch size:35 Target agglomeration size:20 From function AMIInterpolation<SourcePatch, TargetPatch>::AMIInterpolation ( const AMIInterpolation<SourcePatch, TargetPatch>&, const label, const labelList& ) in file lnInclude/AMIInterpolation.C at line 1619. I have so far only tried to patch two rectangular pipes. I attach blockMeshDict and topoSetDict Does anyone know what I do wrong? Best regards Martin 

May 16, 2012, 10:37 

#16 
Member
wided
Join Date: Jul 2010
Posts: 54
Rep Power: 8 
Hi Soder,
I think in your blockMeshDict an indication of the block (or blocks) which should be moving is missing. If you for example want to rotate a cylinder inside your domain, you should do something like this: // top block hex (17 5 7 6 19 13 15 14) rotor (10 100 7) simpleGrading (1 3 1) let´s say that this block represent your cylinder. When you do that and you run blockMesh you should find the name of your moving block in the file /constant/polyMesh/cellZones. Good luck with this. 

February 5, 2013, 15:59 

#17 
Senior Member
Ehsan
Join Date: Oct 2012
Location: Iran
Posts: 2,209
Rep Power: 18 
hi all
I need to simulate wave rotor.it is some channels that move with constant velocity from bottom to top as is obvious in attached picture. at the middle there are channels that move altogether between two stators at the two sides that involve ports that fluid flows through them into the channels when they face the ports.then should be two sliding interface between rotor(channels in the middle)and stators at sides. Im new in dynamic mesh.I've heard about AMI and MRF in OpenCFD version and also GGI in extended version. which is more suitable for my work?(although I prefer to work with OpenCFD version if possible)does have anyone a tutorial that help to start and modifying? Im in an urgent situation.I'll be very thankful for helps. 

February 6, 2013, 04:22 

#18 
Member
wided
Join Date: Jul 2010
Posts: 54
Rep Power: 8 
Hi, I don´t think you need to use AMI but sliding interfaces. I can send you my tutorial for AMI with a motion which is not just rotation (give me a day for that, need to dig for them ), like sliding, but I think it is not suitable for you, as you have parts which do not move in your geometry, I guess GGI will be ok cause you have partial overlapping there.
Someone correct me please if I am wrong. Good luck 

February 6, 2013, 06:21 

#19 
Senior Member
Ehsan
Join Date: Oct 2012
Location: Iran
Posts: 2,209
Rep Power: 18 
thank you.why there is not need to use AMI?though there is moving parts?im new in moving mesh subjects.could you briefly explain me whats purpose and differences between AMI and GGI?
When you speak about partial overlapping is it because there are fluid mesh at sides of interface.am i correct?thus when one side is wall there is not partial overlap? 

February 6, 2013, 06:44 

#20 
Member
wided
Join Date: Jul 2010
Posts: 54
Rep Power: 8 
Hi, I said you may not be able to get partial overlap using AMI. In your case you have moving parts at the side of your geometry, and there will be partial overlap, meaning that your moving parts are going to partially overlap the non moving parts. At least that´s what one sees from the sketch of your geometry. GGI is able to model such an overlap. AMI is only when the moving and nonmoving parts overlap completely (a little rotating cylinder imbedded in a big nonrotating cylinder, but not a wedge rotating in a cylinder).
I hope I made myself clear. 

Tags 
arbitrary mesh interface, ggi, openfoam 2.1.x 
Thread Tools  
Display Modes  


Similar Threads  
Thread  Thread Starter  Forum  Replies  Last Post 
SnappyHexMesh for internal Flow  vishwa  OpenFOAM Native Meshers: snappyHexMesh and Others  24  June 27, 2016 08:54 
Moving mesh  Niklas Wikstrom (Wikstrom)  OpenFOAM Running, Solving & CFD  122  June 15, 2014 06:20 
creating interface in openfoam  vinnithepooh  OpenFOAM  16  February 12, 2013 04:39 
Complex Interface Mesh  Jonny6001  STARCCM+  3  February 16, 2011 05:59 
external flow with snappyHexMesh  chelvistero  OpenFOAM  11  January 15, 2010 20:43 