OpenFOAM 2.1.x - AMI (Arbitrary Mesh Interface)
 

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

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

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.

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

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 your work published (paper or presentation)?

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

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.

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.

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.


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.

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

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

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.

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?

try a smaller courant number?

Also problems setting up AMI
 

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

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.

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.

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

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?

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.

thank you.I figured out the subject.a little thing i should correct is that sides are constant and i want to move channels in the middle altogether between ports that are stationary.

yeah, it is not important what moves and not ;) only that you have partial overlapping in your geometry.

In GGI one can do that, but I know there is some kind of a sliding interface method to do that in OF. Some people who do combustion work with that a lot. I think you can find some help in checking some 1.6-ext tutorials.

yeah, it is not important what moves and not ;) only that you have partial overlapping in your geometry.

In GGI one can do that, but I know there is some kind of a sliding interface method to do that in OF. Some people who do combustion work with that a lot. I think you can find some help in checking some 1.6-ext tutorials.

should i install OpenFOAM extended version to use GGI or it can be compiled on ordinary version?

if you want to use GGI you have to install the 1.6-ext version. Did you find any thing concerning sliding interfaces? I think there was a talk about it in the last OpenFoam workshop, but I am not sure. Here is the link:
http://www.openfoamworkshop.org/2012/OFW7.html
Good luck with your simulation.

Hello everyone,

I don't know if it is a bug, but I figured out following problem:
in a case with stationary-rotating-stationary part with rotating mesh (pimpleDyMFoam) and coupled with cyclicAMI in the first time step the interpolation weights are wrong.
This leads to a complete wrong pressure field in the first time step.

You can download a simple test case with a rotating pipe between stationary parts.

http://www.file-upload.net/download-...peBug.tgz.html

Best regards,
Timo

Bug is fixed:
http://www.openfoam.org/mantisbt/view.php?id=740

hi
I downloaded and executed but this error occurs:
why?

Hi everybody,

As this thread has among other things also been about overlapping and not overlapping AMI's I hope not to be hijacking it by asking the following:

I would like to construct an AMI interpolation where on one side (say source patch) I have one patch, which is coupled to two other patches (say target patches), which together cover the source patch completely, and viceversa. The interface between the two patches will be sliding across the one patch.
Finally, this shall develop into a multi region coupling where a boundary between regions can slide along the boundary of a third region, probably by inheriting from AMI coupled patch and something like the temperatureCoupledBase patch field.

Currently I think I should perhaps join the two target patches, and use one of these constructors:

template<class SourcePatch, class TargetPatch>Foam::AMIInterpolation<SourcePatch, TargetPatch>::AMIInterpolation ( const SourcePatch& srcPatch,
const TargetPatch& tgtPatch,...

--- or ----:

AMIInterpolation (const SourcePatch &srcPatch, const TargetPatch &tgtPatch, const autoPtr< searchableSurface > &surf, ...

However, I have not yet been able to figure out which types are allowable as SourcePatch/targetPatch - could that just be a list of faces? If so, I could just construct a faceList from my two target patches and use that for interpolation?

Or what about the second constructor: Could I construct a searchableSurface from the two target patches and use that for interpolation?

I could probably figure this out myself - but have to admit I am secretly hoping someone has already made some experience with this and would share the best way how to do this, or like to discuss it.
And, b.t.w., I would like to stick with the OpenCFD version, so GGI seems not to be an alternative. (Nothing against the ext version, but feels like a lot of trouble to live in both worlds :))

Partial Overlap GGI
 

Hello everybody,

I am working on GGI for a project. I am unable to follow the concept of partial overlap GGI. Can somebody explain this ?

AMI in pointwise mesh for airfoil
 

Hi
I want to use the AMI interpolation to interface between external and internal domain in airfoil mesh. Internal domain is O-type and external is rectangular shap (CinHmesh).I want to apply a non-conformal sliding interface in my work to take into account the pitching motion of the solid body.The central circular portion of the mesh is free to rotate around the z-axis.I use pimpleDyMFoam solver for flapping motion of airfoil.I have created grid using the pointwise software.
How do I define interface in pointwise?
How do I use AMI?

what is AMI ?
 

hi every body
I'm trying to solve my case with rhoPimpleDymFoam
When I write rhoPimpleDymFoam in terminal , my case solves correctly but when I want to solve by parallel situation,it give me this error in log.rhoPimpleDymFoam :
mpirun noticed that process rank 2 with PID 3543 on node jvd-K53SV exited on signal 8 (Floating point exception).

I don't understand any thing of this error.Can every body help me to solve this error?
a person said me that i must use the AMI approach.i don't know any thing about that and how i can use that.i ask from that person to say me that how i can use that but hi didn't answer me.can anybody help me pls ?
Thanks before
JVD

Hi javad

You can use the following :

1. start with your mesh ... you have one wall for AMI_stator and one wall for AMI_rotor

1. checkMesh -->

1. use splitMeshRegions -makeCellZones -overwrite if the two regions are not connected (so the don't share any node)

post # 185
http://www.cfd-online.com/Forums/ope...ng-ami-10.html
1. checkMesh --> your mesh should now have 2 Regions

1. change your walls AMI_stator and AMI_rotor to

AMI_stator
{
type cyclicAMI;
inGroups 1(cyclicAMI); //comes from snappy...not important
nFaces number of faces (stands here automatically);
startFace 1; (stands here automatically)
matchTolerance 0.0001; // do not know if it is important ...never changed that
transform noOrdering;
neighbourPatch AMI_rotor;
}
AMI_rotor
{
type cyclicAMI;
inGroups 1(cyclicAMI);
nFaces number of faces (stands here automatically);
startFace 10; (stands here automatically)
matchTolerance 0.0001;
transform noOrdering;
neighbourPatch AMI_stator;
}

have also a look in the propeller tutorial in OpenFOAM ... .../tutorials/incompressible/pimpleDyMFoam/propeller

There are much more commands ... some you don't need if your mesh has two regions ...

if you are ready try the "solver" moveDynamicMesh --> only rotates the mesh and show you how good your AMI is ... the AMI weights should be around 1 ...if there is a problem and the min weights goes down to 0 ... you must start with a new mesh ...

have fun ;-)

do you have any idea to do this now? i need the similar problem as you.

Problem set up
 

Dear Arash,

Could you send me your case of pitching airfoil? I have been struggling to set up my problem correctly but no success has been yielded!

Thanks

Dear syavash,

Unfortunately, The file size is 1.87 MB and exceeds the forum's limit of 195.3 KB. It can be sent via email.

Arash,

Thanks for your kind reply,

My e-mail address is: s.airyaman@gmail.com

I really appreciate your help and kindness,

Syavash

Dear All,

I know its been a long time since this was posted. But Im trying to simulate flow around a pitching (only) NACA0012 airfoil in OpenFOAM. I use blockMesh and then snappyHexMesh to generate mesh around the airfoil. I then use topoSet to assign a cylinder (two circular patches in front and back of the mesh). I run simpleFoam for the AOA 11deg (took 6000 iterations to converge) and then use mapField command to map the flow field for initializing the transient simulation. Couple of questions,

I am using the oscillatingRotatingMotion in the dynamicMesh, but when I increase the amplitude anything higher than (0 0 2.0) which should be 2 rad/s correct? It fails due to floating point error. I also defined omega to be 1 rad/sec (hoping it would be ~ 60deg /sec ) but it was way slow so I ended up bumping it up to ~ 50rad/sec. but regardless, I want to increase amplitude so I can see vortex shedding but I dont know how the amplitude works. Will appreciate if anyone can explain.
Thanks


Sent from my iPhone using CFD Online Forum mobile app

Hi Mehdi,
From the top of my head, it seems that you may have a mesh problem or an issue with the definition of the center of rotation. Have you looked at what happens to the mesh when it actually does work? Do the AMI zones move as expected? Feel free to share your case if you want me to look at it...
Regards,
-Louis

OpenFOAM 2.1.x - AMI (Arbitrary Mesh Interface)
 

Dear Luis,

Thanks for your reply. I think I figured it out. It was a mesh interference issue. I should use AMI to prevent this in future.

Thanks anyways