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

OpenFOAM 2.1.x - AMI (Arbitrary Mesh Interface)

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

Like Tree8Likes

Reply
 
LinkBack Thread Tools Display Modes
Old   December 19, 2011, 15:48
Default OpenFOAM 2.1.x - AMI (Arbitrary Mesh Interface)
  #1
Senior Member
 
Philippose Rajan
Join Date: Mar 2009
Location: Germany
Posts: 530
Rep Power: 16
philippose will become famous soon enough
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 OpenFOAM-ext stream).

There also does not seem to be any special treatment of uncovered faces at all.... unlike the OpenFOAM-ext 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
philippose is online now   Reply With Quote

Old   December 19, 2011, 16:40
Default
  #2
Senior Member
 
Sandeep Menon
Join Date: Mar 2009
Location: Amherst, MA
Posts: 386
Rep Power: 15
deepsterblue will become famous soon enough
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... :-)
__________________
Sandeep Menon
University of Massachusetts Amherst
https://github.com/smenon
deepsterblue is offline   Reply With Quote

Old   December 20, 2011, 05:23
Default
  #3
Senior Member
 
Arjun
Join Date: Mar 2009
Location: Nurenberg, Germany
Posts: 368
Rep Power: 10
arjun is on a distinguished road
Quote:
Originally Posted by deepsterblue View Post
It doesn't look like partial overlap is handled. I assume that you're expecting uncovered faces to be converted into walls?

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.
arjun is offline   Reply With Quote

Old   December 21, 2011, 01:10
Default
  #4
Senior Member
 
Philippose Rajan
Join Date: Mar 2009
Location: Germany
Posts: 530
Rep Power: 16
philippose will become famous soon enough
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 wall-type.

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
philippose is online now   Reply With Quote

Old   December 21, 2011, 02:08
Default
  #5
Senior Member
 
Arjun
Join Date: Mar 2009
Location: Nurenberg, Germany
Posts: 368
Rep Power: 10
arjun is on a distinguished road
Quote:
Originally Posted by philippose View Post
Hello Sandeep and Arjun,
@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
While I can not share my code. I can tell you that it is one of easiest problem I have ever worked on. It took me 3 days after my office hours to implement it. (total time less than 10-15 hours).

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.
arjun is offline   Reply With Quote

Old   December 21, 2011, 04:25
Default
  #6
Senior Member
 
Alberto Passalacqua
Join Date: Mar 2009
Location: Ames, Iowa, United States
Posts: 1,894
Rep Power: 26
alberto will become famous soon enoughalberto will become famous soon enough
@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 live DVD/USB, hard drive image and virtual image.
OpenQBMM - An open-source implementation of quadrature-based moment methods
alberto is offline   Reply With Quote

Old   December 21, 2011, 18:02
Default
  #7
Senior Member
 
Philippose Rajan
Join Date: Mar 2009
Location: Germany
Posts: 530
Rep Power: 16
philippose will become famous soon enough
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 kd-trees, etc., I have a couple of questions....:

1. As far as I know, the 1.6-ext 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 Phase-2 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
philippose is online now   Reply With Quote

Old   December 21, 2011, 20:59
Default
  #8
Senior Member
 
Arjun
Join Date: Mar 2009
Location: Nurenberg, Germany
Posts: 368
Rep Power: 10
arjun is on a distinguished road
Quote:
Originally Posted by alberto View Post
@Arjun: is your work published (paper or presentation)?
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.
arjun is offline   Reply With Quote

Old   December 21, 2011, 21:01
Default
  #9
Senior Member
 
Arjun
Join Date: Mar 2009
Location: Nurenberg, Germany
Posts: 368
Rep Power: 10
arjun is on a distinguished road
Quote:
Originally Posted by philippose View Post
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 kd-trees, etc., I have a couple of questions....:

1. As far as I know, the 1.6-ext 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?
Based on what i have read in this forums -ext version of GGI is very similar to what i described. But here are the major difference:
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 Sutherland-Hodgman 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 Sutherland-Hodgman fastest algorithm. If I ever get time I might write this algo too and compare the speed.

Quote:
Originally Posted by philippose View Post
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 Phase-2 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
Sometimes the solution to very difficult problem is ridiculously simple. If I were to tell you the solution you will laugh at it, as this is so simple to do.


Quote:
Originally Posted by philippose View Post

Now... the Phase-2 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.....
The solution to this problem is that apply no solution to it. You do not need to solve this problem as it is already solved.
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.
arjun is offline   Reply With Quote

Old   March 10, 2012, 09:16
Default
  #10
New Member
 
Join Date: Jun 2011
Posts: 6
Rep Power: 6
ChristianE46 is on a distinguished road
Hello guys,

you are talking about AMI specifics. My problem is setting up an AMI-case 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
ChristianE46 is offline   Reply With Quote

Old   March 27, 2012, 14:38
Default
  #11
Senior Member
 
louisgag's Avatar
 
Louis Gagnon
Join Date: Mar 2009
Location: Québec, QC, Canada
Posts: 200
Rep Power: 9
louisgag is on a distinguished road
Send a message via ICQ to louisgag
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
louisgag is offline   Reply With Quote

Old   March 28, 2012, 11:28
Default
  #12
Senior Member
 
linnemann's Avatar
 
Niels Nielsen
Join Date: Mar 2009
Location: NJ - Denmark
Posts: 445
Rep Power: 14
linnemann will become famous soon enough
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.
louisgag, wiedangel and Alhasan like this.
__________________
Linnemann

PS. I do not do personal support, so please post in the forums.
linnemann is offline   Reply With Quote

Old   April 17, 2012, 09:45
Default
  #13
Member
 
wided
Join Date: Jul 2010
Posts: 54
Rep Power: 6
wiedangel is on a distinguished road
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.6-ext 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?
Attached Images
File Type: jpg AMI1.jpg (7.6 KB, 243 views)
wiedangel is offline   Reply With Quote

Old   April 17, 2012, 12:58
Default
  #14
Senior Member
 
louisgag's Avatar
 
Louis Gagnon
Join Date: Mar 2009
Location: Québec, QC, Canada
Posts: 200
Rep Power: 9
louisgag is on a distinguished road
Send a message via ICQ to louisgag
try a smaller courant number?
louisgag is offline   Reply With Quote

Old   May 16, 2012, 08:08
Default Also problems setting up AMI
  #15
New Member
 
Martin Söder
Join Date: Jun 2011
Posts: 8
Rep Power: 6
Soder is on a distinguished road
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
Attached Files
File Type: txt blockMeshDict.txt (2.5 KB, 102 views)
File Type: txt topoSetDict.txt (1.1 KB, 119 views)
Soder is offline   Reply With Quote

Old   May 16, 2012, 10:37
Default
  #16
Member
 
wided
Join Date: Jul 2010
Posts: 54
Rep Power: 6
wiedangel is on a distinguished road
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.
wiedangel is offline   Reply With Quote

Old   February 5, 2013, 15:59
Default
  #17
Senior Member
 
immortality's Avatar
 
Ehsan
Join Date: Oct 2012
Location: Iran
Posts: 2,186
Rep Power: 16
immortality is on a distinguished road
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.
Attached Images
File Type: jpg wr2.jpg (20.3 KB, 116 views)
File Type: jpg wr.jpg (23.3 KB, 99 views)
immortality is offline   Reply With Quote

Old   February 6, 2013, 04:22
Default
  #18
Member
 
wided
Join Date: Jul 2010
Posts: 54
Rep Power: 6
wiedangel is on a distinguished road
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
immortality likes this.
wiedangel is offline   Reply With Quote

Old   February 6, 2013, 06:21
Default
  #19
Senior Member
 
immortality's Avatar
 
Ehsan
Join Date: Oct 2012
Location: Iran
Posts: 2,186
Rep Power: 16
immortality is on a distinguished road
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?
immortality is offline   Reply With Quote

Old   February 6, 2013, 06:44
Default
  #20
Member
 
wided
Join Date: Jul 2010
Posts: 54
Rep Power: 6
wiedangel is on a distinguished road
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 non-moving parts overlap completely (a little rotating cylinder imbedded in a big non-rotating cylinder, but not a wedge rotating in a cylinder).
I hope I made myself clear.
immortality likes this.
wiedangel is offline   Reply With Quote

Reply

Tags
arbitrary mesh interface, ggi, openfoam 2.1.x

Thread Tools
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 On
Pingbacks are On
Refbacks are On


Similar Threads
Thread Thread Starter Forum Replies Last Post
SnappyHexMesh for internal Flow vishwa OpenFOAM Native Meshers: snappyHexMesh and Others 23 August 6, 2014 03:50
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 STAR-CCM+ 3 February 16, 2011 05:59
external flow with snappyHexMesh chelvistero OpenFOAM 11 January 15, 2010 20:43


All times are GMT -4. The time now is 14:31.