[vinz]

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:

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.

[philippose]

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

[vinz]

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?

[philippose]

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

[vinz]

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?

[philippose]

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

[vinz]

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]

sorry I forgot the attachment.

[philippose]

Hi,

The mesh actually looks quite decent :-)!

Have you tried using a single processor rather than directly trying a decomposed case?

[vinz]

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]

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?

[philippose]

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

[vinz]

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.

[openfoam_user]

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.

[vinz]

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.

[openfoam_user]

Hi,
for me the run crashes after 0.008 sec.
How did you improve your mesh (which area, which criteria) ?
Regards,
Stephane.

[vinz]

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.

[openfoam_user]

Vincent,

What value of maxCo (controlDict) do you use ?

Regards,

Stephane.

[vinz]

I used maxCo=2.

I also tried to start with something smaller, but it didn't really help to avoid the previous discussed problem.

[moritzhoefert]

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