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

Problem using AMI

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

Like Tree69Likes

Reply
 
LinkBack Thread Tools Search this Thread Display Modes
Old   December 29, 2011, 05:32
Default Problem using AMI
  #1
Senior Member
 
Vincent RIVOLA
Join Date: Mar 2009
Location: France
Posts: 283
Rep Power: 18
vinz is on a distinguished road
Dear all,

It's been a while since I did not post on the forum, but I am still following with attention the new developments.
I tried to use the AMI feature with pimpleDymFoam on the tutorial propeller. It works perfectly and look very promising.
So I decided I would try it on one of my own model, and see what I get. Unfortunately, it always break up at some point whatever I use for the max courant number, or the relaxation factors, or many different things I tried.

I just notice that the last time step writes the following lines:

Code:
solidBodyMotionFunctions::rotatingMotion::transformation(): Time = 0.00123617 transformation: ((0 0 0) (0.981207 (0 0 0.192959)))
AMI: Creating addressing and weights between 23366 source faces and 23366 target faces
AMI: Patch source weights min/max/average = 0.000261522, 1.75988, 1.00123
AMI: Patch target weights min/max/average = 0, 1.3569, 1.00084
PIMPLE: iteration 1
I guess now the problem is coming from the "0" we can see just above. Am I right? What does it exactly means? and how can I solve this problem?

Thanks in advance for your advice.
chun likes this.
vinz is offline   Reply With Quote

Old   December 29, 2011, 05:38
Default
  #2
Senior Member
 
Philippose Rajan
Join Date: Mar 2009
Location: Germany
Posts: 552
Rep Power: 25
philippose will become famous soon enough
Hi and a good morning :-)!

Just a quick thought from my side..... could it be that your GGI (AMI) Interface patches are not completely covering each other at all points?

In other words.... does your simulation have uncovered faces at the AMI interface? If so, that could be the source of the problem.

As far as I can see, the AMI in OF-2.1.0 does not support such cases.

Have a nice day ahead!

Philippose
philippose is offline   Reply With Quote

Old   December 29, 2011, 05:56
Default
  #3
Senior Member
 
Vincent RIVOLA
Join Date: Mar 2009
Location: France
Posts: 283
Rep Power: 18
vinz is on a distinguished road
Hi Philipose,

And thank you for your reply.

That is exactly what I think. And you can see on the picture bellow that the rotation of the center part of the mesh is creating some kind of hole in the mesh. At least this can be seen in a slice through the mesh.

Since I saw the same thing running the tutorial case, I thought it was not the reason of the failure. However thnking about it twice, now I understand that in the tutorial it might happen only for a slice while in my case a complete part of the mesh might be unceovered. Which would end up in a null weight factor I guess.

How would you solve this? Refining the mesh at the rotor/stator interface? or using another way?
Attached Images
File Type: jpg hole.jpg (26.6 KB, 845 views)
vinz is offline   Reply With Quote

Old   December 29, 2011, 07:35
Default
  #4
Senior Member
 
Philippose Rajan
Join Date: Mar 2009
Location: Germany
Posts: 552
Rep Power: 25
philippose will become famous soon enough
Hello again Vincent,

Hmmm.... the kind of uncovered faces which you have in the screenshot should technically be handled by some kind of "separation tolerance" in the algorithm.

I am guessing that the gap is purely due to discretization issues, and not really a separation between the two interface sides? Does your rotor and stator have slightly different radii? Have you tried using the same radius for the rotor and the stator geometry?

There was a post some time ago on the OpenFOAM forum, about someone who had solved this kind of separation caused by the mesh generation (Case where the geometry of the rotor and stator had the same radius, but gaps were formed during the mesh generation process). Basically, you need to run through all the mesh points on the two patches, and move the points so that they lie on the same radius from the centre.

What do you think?

Philippose
philippose is offline   Reply With Quote

Old   December 29, 2011, 09:22
Default
  #5
Senior Member
 
Vincent RIVOLA
Join Date: Mar 2009
Location: France
Posts: 283
Rep Power: 18
vinz is on a distinguished road
Actually, I use the exact same strategy than in the tutorial. So I have a cylinder defining my rotating region. The whole mesh is done in SnappyHexMesh.

As you will see in the pictures I attach, at the beginning everything is fine. The two pictures are a global view (my cylinder interface being colored in red) and a closer view where we can see the discretisation done by SHM. Do you think there is something wrong at this point? Should I refine the grid at this interface?

Because I have the feeling that the hole is being created by the displacement of the mesh on which I do not have any control. Or at least I don't know which parameter to change to improve it. Do you?
Attached Images
File Type: jpg mesh1.jpg (93.7 KB, 819 views)
File Type: jpg mesh2.jpg (24.4 KB, 493 views)
vinz is offline   Reply With Quote

Old   December 29, 2011, 10:37
Default
  #6
Senior Member
 
Philippose Rajan
Join Date: Mar 2009
Location: Germany
Posts: 552
Rep Power: 25
philippose will become famous soon enough
Hi Vincent,

Ahha... so basically your case is also one in which there are no "uncovered" faces caused by mesh motion. It is a typical rotor-stator case.

In that case, I think it has to do with some kind of tolerances which determine how much "error" there can be in the separation between the two patches.

I guess an initial trial would definitely be to improve the mesh. However, I am not sure if just refining it would be a solution. If you look at the mesh shown on the OpenFOAM webpage: http://www.openfoam.org/version2.1.0/ami.php

The mesh in the image is not specifically finer at the interface.

Have you tried meshing the sample AMI propeller case with your mesh settings and snappyHexMesh? Your mesh looks very different from the mesh on the OpenFOAM website image....

Philippose
philippose is offline   Reply With Quote

Old   December 29, 2011, 10:57
Default
  #7
Senior Member
 
Vincent RIVOLA
Join Date: Mar 2009
Location: France
Posts: 283
Rep Power: 18
vinz is on a distinguished road
I took almost the same settings in snappy. I just adapted the refinement level with respect to the refinement of my base mesh.
The mesh looks fine (see attached). The differences with the link you pointed out are due to the way the plot is done. I use Paraview, and the VTK conversion gives this kind of thinks when you create a slice.

I would be interested to know if they used Paraview for that plot. And if it is the case, what tool did they use.

Anyway, doesn't look like the problem is comming from this. I am currently playing with the decomposition dictionnary to check if it could have some influence.
vinz is offline   Reply With Quote

Old   December 29, 2011, 10:58
Default
  #8
Senior Member
 
Vincent RIVOLA
Join Date: Mar 2009
Location: France
Posts: 283
Rep Power: 18
vinz is on a distinguished road
sorry I forgot the attachment.
Attached Images
File Type: jpg mesh3.jpg (97.7 KB, 576 views)
vinz is offline   Reply With Quote

Old   December 29, 2011, 11:01
Default
  #9
Senior Member
 
Philippose Rajan
Join Date: Mar 2009
Location: Germany
Posts: 552
Rep Power: 25
philippose will become famous soon enough
Hi,

The mesh actually looks quite decent :-)!

Have you tried using a single processor rather than directly trying a decomposed case?
philippose is offline   Reply With Quote

Old   December 30, 2011, 04:08
Default
  #10
Senior Member
 
Vincent RIVOLA
Join Date: Mar 2009
Location: France
Posts: 283
Rep Power: 18
vinz is on a distinguished road
Hi,

I tried running it serial and with different decomposition method, the result is the same, it fails at some point.

I also tried to change the "matchTolerance" value for the AMIs in the boundary file, but didn't see any improvement.

I also tried changing the relaxation factor, even if it does not look related, and of course it didn't help...

So now, I really don't know how to solve this problem. Does somebody already used pimpleDyMFoam with AMI feature for something else than running the tutorial?
vinz is offline   Reply With Quote

Old   January 2, 2012, 04:00
Default
  #11
Senior Member
 
Vincent RIVOLA
Join Date: Mar 2009
Location: France
Posts: 283
Rep Power: 18
vinz is on a distinguished road
So,

I decided to try to create a new mesh. It looks better, the computation is running until time 0.124s. However it is diverging at some point.
I do not think the problem is comming from AMI this time, it is just k and epsilon which are diverging. So I will have to try different initial condition.

My test case is consisting in a blade rotating inside a closed tank full of water. What should be the initial conditions for k and epsilon in such a case? As a first try I used "slip" condition everywhere but on the blade where I use epsilonWallFunction for epsilon and kqRWallFunction for k. Do you think it is correct. What should I use as initial condition?
vinz is offline   Reply With Quote

Old   January 2, 2012, 05:52
Default
  #12
Senior Member
 
Philippose Rajan
Join Date: Mar 2009
Location: Germany
Posts: 552
Rep Power: 25
philippose will become famous soon enough
Hi Vincent,

Good Morning and a very Happy New Year to you :-)!

Great to see that the primary issue was to do with the mesh and not to do with the implementation of the code itself (or atleast, so it seems....)

As for your question regarding boundary conditions for k and epsilon....

A closed tank with water would imply that all the walls of the closed tank and the blade surfaces would act as normal "walls", and should be given the usual boundary condition for walls right?

In this case, shouldnt all the boundaries have "kqRWallFunction" for "k" and "epsilonWallFunction" for "epsilon" with the initial value for these boundaries being the same as the internalField?

I would also suggest, that you try to increase the rotational velocity of the blade using a ramp, so that the closed system you are trying to simulate will not have to deal with a step function at time t = 0 with velocity = N rpm, but rather, a ramped one starting with either 0 rpm or a very low value.

If you are starting with a ramp, you cold try with a small value of say... 1 or so for your "k", and say around 2000 or so for your "epsilon".

Hope this helps.

Have a nice day!

Philippose
philippose is offline   Reply With Quote

Old   January 3, 2012, 03:18
Default
  #13
Senior Member
 
Vincent RIVOLA
Join Date: Mar 2009
Location: France
Posts: 283
Rep Power: 18
vinz is on a distinguished road
Hello Philippose,

And a Happy new year to you and all other foamers.

I would say that the previous issue was partly due to the mesh. I don't find very robust since you can have a chekMesh giving you zero problem and still end up with a break up at some point.

Regarding boundary conditions, indeed, they should all be walls with "kqRWallFunction" for "k" and "epsilonWallFunction" for "epsilon". But I wanted to start easy and even like this I didn't get great results

About the ramp possibility. Is there a way to prescribe this kind of thing in the OpenFOAM dictionaries or should I do it manually (or with some script)?

I ran a laminar computation. It is almost working. Sometimes it breaks up, I just have to restart it and it goes beyond the previous breaking point...again I find it quite strange, and not very robust.
vinz is offline   Reply With Quote

Old   January 19, 2012, 03:10
Default
  #14
Senior Member
 
stephane sanchi
Join Date: Mar 2009
Posts: 314
Rep Power: 18
openfoam_user is on a distinguished road
Hi Vincent,

I encounter the same kind of problem:
AMI: Patch source weights min/max/average = 5.55057e-08, 1.62582, 1.00003
AMI: Patch target weights min/max/average = 0, 1.3053, 0.999857

Have you solved the problem ?
Is it due only to the mesh ?

Regards,
Stephane.
openfoam_user is offline   Reply With Quote

Old   January 19, 2012, 03:16
Default
  #15
Senior Member
 
Vincent RIVOLA
Join Date: Mar 2009
Location: France
Posts: 283
Rep Power: 18
vinz is on a distinguished road
Hi Stephane,

Yes, it was due to the mesh in my case. Even if blockMesh was reporting that my mesh was correct.
The problem is since it does not stop at the first iteration, you may have to wait quite a while before encountering the same problem. And it is a bit of trial and error which I don't like that much. It would be nice to find a way to make it more robust.
vinz is offline   Reply With Quote

Old   January 19, 2012, 03:20
Default
  #16
Senior Member
 
stephane sanchi
Join Date: Mar 2009
Posts: 314
Rep Power: 18
openfoam_user is on a distinguished road
Hi,
for me the run crashes after 0.008 sec.
How did you improve your mesh (which area, which criteria) ?
Regards,
Stephane.
openfoam_user is offline   Reply With Quote

Old   January 19, 2012, 03:37
Default
  #17
Senior Member
 
Vincent RIVOLA
Join Date: Mar 2009
Location: France
Posts: 283
Rep Power: 18
vinz is on a distinguished road
I actually made it coarser. In order to try, I didn't want to make it thinner and wait for hours before ending on the same problem. I was quite lucky to not encounter the problem anymore. But it is definitely not satisfying.

I also observed some relations between the time step choosen and this problem. Since basically, depending on the time step you choose, you might just jump over the precise time where you encounter this problem of source and target.

But if anyone as real guidelines to avoid this problem, I would be very interested to try them on my case.
fisichel and hogsonik like this.
vinz is offline   Reply With Quote

Old   January 19, 2012, 05:50
Default
  #18
Senior Member
 
stephane sanchi
Join Date: Mar 2009
Posts: 314
Rep Power: 18
openfoam_user is on a distinguished road
Vincent,

What value of maxCo (controlDict) do you use ?

Regards,

Stephane.
openfoam_user is offline   Reply With Quote

Old   January 19, 2012, 05:53
Default
  #19
Senior Member
 
Vincent RIVOLA
Join Date: Mar 2009
Location: France
Posts: 283
Rep Power: 18
vinz is on a distinguished road
I used maxCo=2.

I also tried to start with something smaller, but it didn't really help to avoid the previous discussed problem.
vinz is offline   Reply With Quote

Old   January 22, 2012, 07:19
Default
  #20
New Member
 
Join Date: Oct 2010
Posts: 13
Rep Power: 16
moritzhoefert is on a distinguished road
Hi all,

I was amazed by the propeller example of OF 2.1.0 and tried right away to apply it to a rotor-stator mixer. The first tests look very promising.

I used maximum Courant number 0.5. Also I made sure that two cells at opposite sides of the AMI stay in contact for at least 3 time steps. And the simulations were stable.

Did anyone of you use the sliding mesh capabilities shown in the propeller example in conjunction with the cyclic boundary condition as shown in the pipeCyclic example? Thanks a lot for your comments!

Cheers,
Moritz
moritzhoefert is offline   Reply With Quote

Reply

Thread Tools Search this Thread
Search this Thread:

Advanced Search
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 Off
Pingbacks are On
Refbacks are On


Similar Threads
Thread Thread Starter Forum Replies Last Post
UDF compiling problem Wouter Fluent UDF and Scheme Programming 6 June 6, 2012 05:43
Gambit - meshing over airfoil wrapping (?) problem JFDC FLUENT 1 July 11, 2011 06:59
natural convection problem for a CHT problem Se-Hee CFX 2 June 10, 2007 07:29
Adiabatic and Rotating wall (Convection problem) ParodDav CFX 5 April 29, 2007 20:13
Is this problem well posed? Thomas P. Abraham Main CFD Forum 5 September 8, 1999 15:52


All times are GMT -4. The time now is 18:10.