Problem using AMI
 

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:

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.

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

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?

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

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?

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

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.

sorry I forgot the attachment.

Hi,

The mesh actually looks quite decent :-)!

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

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?

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?

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

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

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.

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.

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

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.

Vincent,

What value of maxCo (controlDict) do you use ?

Regards,

Stephane.

I used maxCo=2.

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

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

Hi,

I still get the following error message when running the pimpleDyMFoam solver of OF-2.1.x.

I attach the residuals and forces curves. Force curve is doing towards the experimental value. And the computation crashes suddently.

Modifying the maxCo (=2 in propeller example) doesn't help.

I need help to solve it ! Thanks.

Courant Number mean: 0.00403827 max: 1.98918
deltaT = 2.7027e-05
Time = 0.00810811

solidBodyMotionFunctions::rotatingMotion::transfor mation(): Time = 0.00810811 transformation: ((0 0 0) (0.927889 (-0.372856 0 0)))
AMI: Creating addressing and weights between 23788 source faces and 23788 target faces
AMI: Patch source weights min/max/average = 4.97804e-08, 1.62573, 1.00003
AMI: Patch target weights min/max/average = 0, 1.30524, 0.999857
PIMPLE: iteration 1
[3] #0 Foam::error::printStack(Foam::Ostream&) in "/shared/OpenFOAM/OpenFOAM-2.1.x/platforms/linux64GccDPOpt/lib/libOpenFOAM.so"
[3] #1 Foam::sigFpe::sigHandler(int) in "/shared/OpenFOAM/OpenFOAM-2.1.x/platforms/linux64GccDPOpt/lib/libOpenFOAM.so"
[3] #2 in "/lib64/libc.so.6"
[3] #3 Foam::divide(Foam::Field<double>&, double const&, Foam::UList<double> const&) in "/shared/OpenFOAM/OpenFOAM-2.1.x/platforms/linux64GccDPOpt/lib/libOpenFOAM.so"
[3] #4 Foam::tmp<Foam::GeometricField<double, Foam::fvPatchField, Foam::volMesh> > Foam::operator/<Foam::fvPatchField, Foam::volMesh>(Foam::dimensioned<double> const&, Foam::tmp<Foam::GeometricField<double, Foam::fvPatchField, Foam::volMesh> > const&) in "/shared/OpenFOAM/OpenFOAM-2.1.x/platforms/linux64GccDPOpt/bin/pimpleDyMFoam"
[3] #5
[3] in "/shared/OpenFOAM/OpenFOAM-2.1.x/platforms/linux64GccDPOpt/bin/pimpleDyMFoam"
[3] #6 __libc_start_main in "/lib64/libc.so.6"
[3] #7
[3] at /home/abuild/rpmbuild/BUILD/glibc-2.14.1/csu/../sysdeps/x86_64/elf/start.S:116
[cfs10:04034] *** Process received signal ***
[cfs10:04034] Signal: Floating point exception (8)
[cfs10:04034] Signal code: (-6)
[cfs10:04034] Failing at address: 0x45f00000fc2
[cfs10:04034] [ 0] /lib64/libc.so.6(+0x34e10) [0x2af5d1ef4e10]
[cfs10:04034] [ 1] /lib64/libc.so.6(gsignal+0x35) [0x2af5d1ef4d95]
[cfs10:04034] [ 2] /lib64/libc.so.6(+0x34e10) [0x2af5d1ef4e10]
[cfs10:04034] [ 3] /shared/OpenFOAM/OpenFOAM-2.1.x/platforms/linux64GccDPOpt/lib/libOpenFOAM.so(_ZN4Foam6divideERNS_5FieldIdEERKdRK NS_5UListIdEE+0x24) [0x2af5d117fe44]
[cfs10:04034] [ 4] pimpleDyMFoam(_ZN4FoamdvINS_12fvPatchFieldENS_7vol MeshEEENS_3tmpINS_14GeometricFieldIdT_T0_EEEERKNS_ 11dimensionedIdEERKS8_+0x2a0) [0x43f120]
[cfs10:04034] [ 5] pimpleDyMFoam() [0x419cdb]
[cfs10:04034] [ 6] /lib64/libc.so.6(__libc_start_main+0xed) [0x2af5d1ee123d]
[cfs10:04034] [ 7] pimpleDyMFoam() [0x41d9dd]
[cfs10:04034] *** End of error message ***
--------------------------------------------------------------------------
mpirun noticed that process rank 3 with PID 4034 on node cfs10 exited on signal 8 (Floating point exception)

Regards,

Stephane.

Hi,

I don't know why at a certain point the computation crashes despite good convergence (residuals and forces).

Any idea ?

Stephane.

Unfortunately, I guess it is the same problem I encountered.
Your mesh is rotating and at some point a part of the domain is not covered by any cell, or something like that which results in a crash.

I only did a new mesh with small changes in the generation process and the problem disappeared. But I did not manage to find guidelines to avoid the problem. :(

Hi Vincent,

what kind of modifications in the mesh generation process have you done ?

Did you do something special ?

Regards,

Stephane.

Vincent,

I have used the same process as the propeller tutorial (blockMesh and sHM).

I have tried to have a finer mesh between the rotating part and the stationary part, but the case crashes a bit sooner !

Do you use GridPro for the base grid instead of blockMesh ?

Stephane.

No for this case, I only used SnappyHexMesh.
Actually I made it coarser at the interface and it ran fine. But as I said I do not know the exact settings which will give a good mesh for each case.

When things do not work out it is normal to think that we are doing some mistake, BUT in this case my guess is that the GGI algorithm is broken and needs fixing. Most of the people who have complained here would be able to run their simulation just fine if they used fluent or starccm+ . If they run fine of commercial code then grid is alright.

My opinion is that most probably the issue is with implementation and this could not be removed by fixing mesh.

Could you post your broken case with a 'Allrun' script, it might be easier to see if it's some mistake in the mesh generation if you share your case.

Hi,

I'm still trying to understand why my case crashes.

Hereafter is the logfile of the checkMesh command:
----------------------------------------------------------------------
/*---------------------------------------------------------------------------*\
| ========= | |
| \\ / F ield | OpenFOAM: The Open Source CFD Toolbox |
| \\ / O peration | Version: 2.1.x |
| \\ / A nd | Web: www.OpenFOAM.org |
| \\/ M anipulation | |
\*---------------------------------------------------------------------------*/
Build : 2.1.x-500b378f6ba9
Exec : checkMesh
Date : Feb 14 2012
Time : 14:19:40
Host : "cfs10"
PID : 6797
Case : /shared/sanchi/OpenFOAM/sanchi-2.1.x/SMP11_pimpleDyMFoam_7_skew
nProcs : 1
sigFpe : Enabling floating point exception trapping (FOAM_SIGFPE).
fileModificationChecking : Monitoring run-time modified files using timeStampMaster
allowSystemOperations : Disallowing user-supplied system call operations

// * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * //
Create time

Create polyMesh for time = 0

Time = 0

Mesh stats
points: 1660241
faces: 4421588
internal faces: 4219206
cells: 1397571
boundary patches: 8
point zones: 0
face zones: 2
cell zones: 1

Overall number of cells of each type:
hexahedra: 1191559
prisms: 36641
wedges: 0
pyramids: 0
tet wedges: 104
tetrahedra: 0
polyhedra: 169267

Checking topology...
Boundary definition OK.
Cell to face addressing OK.
Point usage OK.
Upper triangular ordering OK.
Face vertices OK.
*Number of regions: 2
The mesh has multiple regions which are not connected by any face.
<<Writing region information to "0/cellToRegion"

Checking patch topology for multiply connected surfaces ...
Patch Faces Points Surface topology
inlet 1496 1660 ok (non-closed singly connected)
outlet 448 465 ok (non-closed singly connected)
outerCylinder_PATCH 3328 3392 ok (non-closed singly connected)
blades_PATCH 106518 137882 ok (non-closed singly connected)
hub_PATCH 12592 15805 ok (non-closed singly connected)
shaft_PATCH 30424 30664 ok (non-closed singly connected)
AMI1 23788 23905 ok (non-closed singly connected)
AMI2 23788 23905 ok (non-closed singly connected)

Checking geometry...
Overall domain bounding box (-571 -600 -600) (2030 600 600)
Mesh (non-empty, non-wedge) directions (1 1 1)
Mesh (non-empty) directions (1 1 1)
Boundary openness (1.25554e-16 3.29472e-17 -2.55368e-16) OK.
Max cell openness = 3.71866e-16 OK.
Max aspect ratio = 5.74628 OK.
Minumum face area = 0.032093. Maximum face area = 3797.06. Face area magnitudes OK.
Min volume = 0.0464591. Max volume = 168535. Total volume = 2.93458e+09. Cell volumes OK.
Mesh non-orthogonality Max: 65.511 average: 10.0911
Non-orthogonality check OK.
Face pyramids OK.
***Max skewness = 5.21337, 5 highly skew faces detected which may impair the quality of the results
<<Writing 5 skew faces to set skewFaces
Coupled point location match (average 0) OK.

Failed 1 mesh checks.

End
----------------------------------------------------------------------

Could someone explains me the following lines:
*Number of regions: 2
The mesh has multiple regions which are not connected by any face.
<<Writing region information to "0/cellToRegion"

And the max skewness error appears only after I did the command:
createBaffles -internalFacesOnly -overwrite innerCylinderSmall '(AMI1 AMI2)'

I need help to eliminate these errors and improve the mesh.

Regards,
Stephane.

Vincent,

What format do you use for geometry parts (stl, obj or other) ?
Each part has a separate file or all parts are together into 1 unique file ?

Is your shaft divide in 3 parts (like the propeller tutorial) or is it a unique part ? I ask you this because my intersections between the shaft and the cylinders (innerCylinder and innerSmallCylinder) is not very clean.

Regards,

Stephane.

>Overall domain bounding box (-571 -600 -600) (2030 600 600)
Big domain?

The geometry file that you use for snapping to the AMI cylinder, does it have high enough resolution compared to the edge length of the final mesh?

I don't know about your problems with unclean intersections, sounds strange. Any picture?

Hi,

Now my geometry has only the blades and a small hub. I don't have the shaft. So there is no more intersections between shaft and AMI regions. The case still crashes.

I think the problem is linked with the AMI surfaces. Maybe with my STL surfaces of the innerSmallSurface.

I will try to take the propeller tutorial and only replace the blades with mine and see what happens.

Regards,
Stephane

Hi Stephane,

I don't have access to the files right now, but I think I was using only one stl file for the blades and the shaft. However, it was a specific case since my shaft was short with a finite length (not going out of the domain like in the tutorial) and could be integrated fully into the cylinder part.

Hi Johan, hi Vincent,

Now I run the propeller case with my own propeller inside (without shaft). Til now it is running ... I will be happy when 1 root will be finished.

So the problem could be my innerSurfaceSmall.stl file, which is used for creating the AMI1 and AMI2 surfaces.

Which CAD software are you using to create STL file ?
I have found in the OF-forum that it is better to work with OBJ files because there is no discretization in triangles. In the propeller tutorial only OBJ files are used. Do you know how to create these OBJ files ?

Regards,
Stephane

Hi Stephane

you could try this

http://meshlab.sourceforge.net/

It can import stl and export obj.

I haven't found any cad (free) that can do direct to obj

Greetings to all!

But... OpenFOAM can do that since 2.0.0!! Well, not do CAD directly, but can convert directly!
If I remember correctly, you can do this with either surfaceFeatureConvert or surfaceTransformPoints! It can actually convert between several formats! Simply use a dud extension and it will tell you what extensions it supports.

Best regards,
Bruno

Hi Niels, hi Bruno,

thanks for your messages.

I have improved the mesh.
Nevertheless the case still crashes after:

AMI: Patch source weights min/max/average = 4.38449e-09, 1.09515, 0.999895
AMI: Patch target weights min/max/average = 0, 1.06587, 0.999773

I think I will leave this case aside because I am not able to fix what's wrong.

Regards,
Stephane.

Hi again

A colleague of mine just had the same error and specifically the 0(zero) value in this line is the culprit.

This means (from what I can gather) that there is a(some) cell(s) that has no overlapping of a neighbor face.

What he found was that the layers in the mesh made some cells way too fine just at the AMI interface. He lowered the amount of layers and everything was working.

I urge you to post a bug on the openfoam.com mantis.

At least if they could implement a check for uncovered faces at the AMI and inform the user that the mesh/setup is bad/wrong and exit the solver gracefully instead of showing the garbage it shows now.

Best

If you post your case it will be easier to help, skip the propeller if it's confidential (as long as the case will still crash without it).

Hi again,

Now my propeller case runs. The problem was the AMI1/AMI2 interface.

I have done my background mesh using ICEM hexa. See attached pictures. The pink/blue line is the AMI interface. I don't do any kind of refinement on this interface.

During my siimulation time I often have:
AMI: Patch source weights min/max/average = 1, 1.00001, 1
AMI: Patch target weights min/max/average = 1, 1.00001, 1

Soon I will post a move.

Regards,
Stephane.