[philippose]

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

[deepsterblue]

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

[arjun]

Originally Posted by deepsterblue

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.

[philippose]

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

[arjun]

Originally Posted by philippose

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.

[alberto]

@Arjun: is your work published (paper or presentation)?

[philippose]

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

[arjun]

Originally Posted by alberto

@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]

Originally Posted by philippose

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.

Originally Posted by philippose

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.

Originally Posted by philippose

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.

[ChristianE46]

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

[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

[linnemann]

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.

[wiedangel]

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?

[louisgag]

try a smaller courant number?

[Soder]

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

[wiedangel]

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.

[immortality]

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.

[wiedangel]

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]

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?

[wiedangel]

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.