[chubb87]

Hello,

there is an issue with high-frequency pressure oscillations for simulations with pimpleDyMFoam and transientSimpleDyMFoam (for rotating machinery), which was confirmed by independent research groups.
These oscillations are unphysical and are definitely connected to the AMI interface (correlate with circumferential number of cells of stator & with rotor-frequency).
After detailed examination of a simplified testcase (see attachment) we are sure about that.
This problem was examined primarily with OpenFOAM 2.1.x, but occurs also with OpenFOAM 2.3.x.

Has anyone noticed this phenomenon and/or has a solution?

Thanks a lot in advance.
Martin


Attachments with links:
Modelpump-pimpleDyMFoam-OF-2.1.x: transient set-up including the initial solution, https://dl.dropboxusercontent.com/u/...F-2.1.x.tar.gz
turboPerformance-OF2.1: functionObject for the head evaluation, https://dl.dropboxusercontent.com/u/...e-OF2.1.tar.gz

[wyldckat]

Greetings Martin,

I was curious and took a quick look at the mesh in your case, as well as to the "fvSolution" and "fvSchemes" files.

What I can see is that:

1. The "correctPhi" line is missing from the "PIMPLE" block at "fvSolution". Although I'm not certain how important it might be.
2. The relaxation factors in "fvSolution" look very strange to me... 0.9 seems too relaxed.
3. Attached are a couple of images that show the surface mesh on the AMI patches. The images and respective files names should be self-explanatory.
   The problem is that they seem to reveal bad surface mesh interface between the two mesh regions, because those very thin mesh slivers are most likely the ones responsible for the high-frequency you're seeing the graphs.

From past cases I've seen, where the mesh is more important than people give it credit: OpenFOAM: Interesting cases of bad meshes and bad initial conditions, the "Case two" on that blog post refers to an example of how bad mesh refinement transitions can be if created in the wrong place.


To conclude, I strongly suggest that you try either using an identical mesh resolution in the inside and outside regions; or at least use a 2:1 proportion. In addition, it might be better to use a fixed deltaT, which is a multiple that correlates the location of the cell faces on the AMI patches with the rotation speed, so that you can avoid getting sliver-like face interfaces.

Best regards,
Bruno

[chubb87]

Dear Bruno,

thank you very much for investigating my case.

Regarding your comments, I can say the following:

1. CorrectPhi is not the reason for the oscillations. I also ran the calculations with that option activated and the oscillations were still present.

2. The same applies to different relaxation factors.

3. Shouldn’t the AMI interface be able to handle small jumps in mesh resolution. A transition from 60 to 72 cells in circumferential direction is not a bad transition, and in axial direction it is even a 1:1 match. I do not consider it satisfactory if the AMI cannot cope with that. For our real-world cases it is not possible to always make sure the mesh is 1:1 or 2:1.

Kind regards,
Martin

[JNSN]

Hi Martin,

have you tried to tighten the tolerance for p, e.g. 1e-8? Sometimes this helps to reduce such oscillations.
Or may change linearUpwind to something like blended 0.8 linear upwind. Should be slightly more diffusive, but also may reduce the oscillations.

Best regards,
Jan

[wyldckat]

Greetings to all!

To add to Jan's answer, there is also the presentation "OFW09.0005 How grid quality affects solution accuracy" at http://openfoam-extend.sourceforge.n.../download.html - which should give some more ideas.

In addition, in OpenFOAM 2.3.0 were introduced a few more features which might solve a bit these issues: http://www.openfoam.org/version2.3.0/ami.php

Originally Posted by chubb87

3. Shouldn’t the AMI interface be able to handle small jumps in mesh resolution. A transition from 60 to 72 cells in circumferential direction is not a bad transition, and in axial direction it is even a 1:1 match. I do not consider it satisfactory if the AMI cannot cope with that. For our real-world cases it is not possible to always make sure the mesh is 1:1 or 2:1.

The presentation I mentioned above should shed some lights on this, since AMI is not a silver bullet; it should still be susceptible to the usual mesh related issues that OpenFOAM has got, hence my comment of 1:1 and 2:1. You might also want to try out the GGI feature currently in foam-extend 3.1, which was initially implemented a few years earlier in the Extend variant 1.4-dev (I think), than the AMI implementation in the official OpenFOAM version.


Yet another example of how significant is the mesh, is if when running a transient simulation, even without any dynamic meshing, there is a very small cell that has fluid passing through it at a very high speed, where the Courant Number will sky rocket for that very small cell, and/or forcing the deltaT step to reduce to very small values. There are several possible workarounds, but the best solution is to try and improve the mesh in that particular location; any workaround will very likely be suboptimal.

Best regards,
Bruno

[chubb87]

@Jan:
Unfortunately tightening the tolerances does not reduce the oscillations.
I also tried more diffusive schemes, even pure upwind does not yield less oscillations.

@Bruno:
Thanks for the links.
I tested the option "lowWeightCorrection" (the only new feature I have influence on that might help), but that does not reduce the oscillations, nor does the variation of "meshTolerance".
I actually tried the GGI-feature in foam-extend-3.1, but without improvement. In that regard the two interface methods behave equivalently.
The geometry is very simple and the mesh is fairly clean, we have made sure of that (also tried different conversion mechanisms). I appreciate your advice regarding the mesh, but in my opinion that it is not the reason for the oscillations.

Best regards,
Martin

[Bandfrosch]

Hello all,
after having a look in my dirty tricks chamber , I found :

modifying point coordinates on both interfaces reduces these wiggles.
Just twist each interface about one cell's angle , variing angle from z = 0 to z = 0.1,
so that ami weights ( or cell faces overlap ) do not have sudden jumps while rotating.

Too sad that the wiggles do not disappear completley ...

Please find attached a "twisted" points file.

Attachment 34303

Attachment 34304

Attachment 34305

Attachment 34306

Attachment 34307



This twisting was done via a super ugly shell script :
assuming constant/polyMesh/points.gz was backed up to constant/polyMesh/pointsOrig.gz

# do some sed awk magic, find points with distance 0.05 from z axis, apply diferential rotation to them, write back to polyMesh dir

cp constant/polyMesh/pointsOrig.gz .
gunzip -f pointsOrig.gz

cat pointsOrig \
| sed 's/(/( /' \
| sed 's/)/ )/' \
| awk '/\(/ {
x=$2;y=$3;z=$4;
r2=$2*$2+$3*$3;
if( sqrt((r2 - 0.0025)*(r2 - 0.0025)) < 1e-6)
{
if( NR >= 7149 ) angle=atan2(1,0)*4*0.013 * z / 0.1 * 2.0;
else angle=atan2(1,0)*4*0.013 * z / 0.1 * -1.0;
xDash= x*cos(angle)+y*sin(angle) ;
yDash=-x*sin(angle)+y*cos(angle);
{ printf "/*"x" "y " "z"*/" "("xDash" "yDash" "z" )\n" ; next }
}
}
{
print $0
}' > points

# zip the processed points file
gzip -f points

# put back to polyMesh dir
cp points.gz constant/polyMesh/




I am sure ,there are several tricks like this out in the wild ...

Bandfrosch

[Bandfrosch]

Sorry , links do not work ...

Mesh view from above :

mesh1.png

Mesh view from below :

mesh2.png

twisted AMI patches :

mesh3.png


Volume flow comparison :

vDot.png

points.gz file :


points.gz




Hope it works this time ....

Bandfrosch

[chubb87]

Hello Bandfrosch,

thanks very much for providing this idea and script. It really reduces the oscillations a bit. I have applied it from the middle (axial direction), such that the cells get twisted 2 cells in circumferential direction with the same total twist at both endings.

I doubt though, whether this trick is practical for real pumps and testing this right now. In order to reduce the oscillations completely, I guess this trick has to be combined with mesh refinement and/or 1:a matching interfaces, where 'a' is an integer.
Hopefully in future OF versions there will be a more useful AMI-implementation.

Regards,
Martin

[wyldckat]

Greetings to all!

FYI: A few days a similar report was filled on the official bug tracker for OpenFOAM, which seems to shed some more light on the source of this problem: http://www.openfoam.org/mantisbt/view.php?id=1421

Best regards,
Bruno