Propeller case in AMI tutorial
 

Hi Foamers,
I run the propeller case in AMI tutorial oF2.1x. One odd thing is the back flow on tip of blade and the non zero velocity in y-dir (flow dir) that not satisfy the no slip condition.(Please look the attachments)
I would like to know your comments.

The images are as below:

Hi reza,

I've only started using pimpleDyMFoam to analyse marine propellers recently so I'm definitely not an expert. I've used the modified version of the propeller tutorial to replicate the Potsdam Propeller Test Case (PPTC) results. I didn't notice the thing you pointed out until I saw your post. I looked at my results and found them to have the same features despite a much finer mesh. See the attached pictures 1 and 2 (for advance coefficient J=0.64).

It seems that these values are very small compared to the velocity at the wall originating from the rotational motion of the prop (picture 3) and don't seem to affect the pressure distribution (pictures 4 and 5) nor the forces (for this case I was within 2.5% of Kt, Kq and efficiency w.r.t. the experimental results).

None the less I would love to hear someone more knowledgeable comment on the topic to better understand it.

Hi Artur,
I would thank you for your reply.One odd thing in the tutorial is not satisfying no-slip condition on the propeller that I can see same on my case as well.
What motivated me to check out the results of the tutorial is my project. It is related to a tanker propeller model meshed by pointwise that should be compared with the experimental values for open-water and self-propelled case.
The techniques are AMI and MRF ,To approach AMI I did as below:

• create two parts as rotor(inner cylinder that is rotating)and stator (not rotating outer part) .
• merge two parts through implement mergeMeshes stator rotor.
• rename the type of boundary AMI from patch to cyclic AMI and add the neighborhood and tolerance and update 0 folder .
• use topoSet or splitMeshRegions -makeCellZones -overwrite to create the cellZones and update the dynamicmeshDic.
• Run pimpleDyMFoam as parallel on network(claster).

For MRF is almost same except the applying stitches ,stitchMesh,instead of split and Remove manually the empty boundaries (0 faces) from constant/boundaries file.
My case includes 3.5 mil cells and the results approaches converged for AMI and MRF. But what I suffers me is to have backflow for two cases on the tip of blades and a noticeable gap between the thrust force
obtained from experimental and numerical values ,around 40%,in AMI.
Furthermore,MRF shows close results to the experiment ,just 12.3% difference,would be agreeable.

I do it slightly differently. I mesh an .stl of two cylinders inside and snap the mesh of the inner one to the prop. Then I recreate the patches using topoSet much as it was done in the tutorial. But I don't see how that would affect the velocities.

Can you expand a bit about the backflow you observed? Do you think it should not be there and you think the small Ux components are responsible for it?

It is the recommendation of my supervisor,The attachments is the images from AMI and MRF,-X is the inflow direction .But i more concerned about the big gap between the AMI and experimental values that is constant and fully converged.
In addition ,you can consider the images from the tutorial case to see no slip condition doesn't satisfy in AMI .

Aren't the +ve Ux values (in your recent pictures, not the tutorial ones) close to the tips of the blades associated with the tip vortex? In which case I feel they should be there.

What sort of magnitudes are the Ux velocities on the blades of the non-tutorial prop you are evaluating? Are they also in the range of 1e-2 - 1e-3 like in the tutorial or much bigger (for my case I found them to be in this range)?

I'm not convinced that the small Ux values on the wall are the root cause of your Kt and Kq being different from the experiment (I have them too and still I get reasonable agreement) although I agree that they shouldn't be there.

Have you tried using different settings, turbulence models, etc.? I run k-omega SST, y+ around 30-40, base cell size 0.125 m refined to level 6 for a prop with 0.25 m diameter. I had to under-relax the k,omega and U field by 0.7 in order to get a stable and reliable solution. I also tend to ramp up the maxCo to 2.5-3.5 as the simulation progresses to make it faster. Apart from that my schemes and settings are not largely different from the tutorial and I observe convergence of forces and moments after about a half to one full revolution.

The images 2&3 concerned about the small positive velocity in +x-dir on the tips .It should filter the minimum velocity to be seen.
I followed the tutorial k-eps turbulent model that satisfies the experimental value for MRF. I think the tip vortex generates after tip and front of the blade not on the tip.
Not satisfying no-slip condition may make not converging to the experimental case. I want to report this as bug.

Have you tried pushing your tolerances down in the fvSolution? What y+ is your mesh at?

I didn't make the mesh.This is my fvSoloutionDic:
//
/*--------------------------------*- C++ -*----------------------------------*\
| ========= | |
| \\ / F ield | OpenFOAM: The Open Source CFD Toolbox |
| \\ / O peration | Version: 2.1.x |
| \\ / A nd | Web: www.OpenFOAM.org |
| \\/ M anipulation | |
\*---------------------------------------------------------------------------*/
FoamFile
{
version 2.0;
format ascii;
class dictionary;
object fvSolution;
}
// * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * //

solvers
{
pcorr
{
solver GAMG;
tolerance 1e-7; // 1e-5;
relTol 0.001; //0;
smoother DICGaussSeidel;
cacheAgglomeration no;
nCellsInCoarsestLevel 10;
agglomerator faceAreaPair;
mergeLevels 1;
maxIter 50;
}

p
{
$pcorr;
tolerance 1e-8;
relTol 0.001; //0.01;
}

pFinal
{
$p;
tolerance 1e-8;
relTol 0;
}

"(U|k|epsion)"
{
solver smoothSolver;
smoother GaussSeidel;
tolerance 1e-8;
relTol 0.01;
}

"(U|k|epsilon)Final"
{
solver PBiCG;
preconditioner DILU;
tolerance 1e-8;
relTol 0;
}
}

PIMPLE
{
correctPhi yes;
nOuterCorrectors 3;
nCorrectors 2; //1;
nNonOrthogonalCorrectors 2;
}

relaxationFactors
{
p 0.2;
"(U|k|epsilon).*" 0.5;

}

cache
{
grad(U);
}

// ************************************************** *********************** //

It's very similar to mine in terms of the tolerances and settings except for the 0.2 relaxation factor on p. Are you sure that it is not too low? I've found that setting it to anything below 0.5 may affect your results slightly. Maybe try with these just to make sure:

To check your y+ use the yPlusRAS utility from OpenFOAM.

Other than that I suppose it's either the mesh or something I am not aware of..

These values are the recommended by my supervisor for K-ep model.I think mesh is quite OK if we conciser the MRF is quite reasonable.

Hi,
Any progress on your side with figuring out why the no-slip condition in the flow direction is not satisfied? I have been thinking about it and I have noticed that this occurs mainly in the regions where the prop blade is becoming very thin in the direction parallel to the onset flow, probably due to an incorrect interpolation scheme selected. I'll try running a few cases with some other schemes than linear and will get back to you with my findings. Before I do that I want to run a case with a cylinder instead of the prop to see if the Ux velocity will be zero on the wall perpendicular to the flow given the much higher thickness of the body c.f. that of the prop.

Here is the picture of a rotating cylinder with flow parallel to the x axis. Free stream fluid velocity is (-1.602 0 0). You can still see regions of non-zero axial velocity on the wall of the cylinder despite:
- increased no. PIMPLE runs / timestep
- reduced tolerances on all variables to 1e-12
- adoption of smooth solver for U instead of PBiCG used in the propeller tutorial
- usage of linearUpwind and cubicCorrection schemes for U field interpolation
- reduced AMI tolerance in createBafflesDict from 1e-4 to 1e-6 (wirte precision)
- increase of the under-relaxation factors on all variables back to 1.0 (used to be 0.7 on the U, k and omega fields)

In the final attempt I tried increasing the domain size even more (it was over 6D of the cylinder in diameter and of about the same length upstream and downstream of the body). Then I also increased the AMI cylinder radius and length to move the interphase from the cylinder. Didn't help either.

There were so few differences between each combination that I am pretty convinced that the problem is someplace else.

Artur
I want to run my case by MRFSimpleFoam .
Please look at this
http://www.cfd-online.com/Forums/ope...h-problem.html
I look forward to know your idea.

I haven't got any experience in MRFSimpleFoam. It is not useful for what I am evaluating as I focus on unsteady flow, sorry.

Artur,
I did my best to make close the my result to experimental value but there is still a big gap.The positive velocity and non-overlapped cells are still alive.
In this regard I need to review what I did:
* Export two parts like Stator and Rotor from pointwise to OpenFoam
* Merge to parts as mergeMeshes Stator Rotor
* Update Boundary (Add cyclicAMi and tolerance)
* Use splitMeshRegions -makeCellZones -overwrite to make cellZones

could you please let me know your implement to make AMI
Regards
Reza

I follow the same approach as the tutorial except I use .stl files instead of .obj files. So:
1. snap mesh to a big cylinder, a small cylinder (AMI) and prop
2. select outer faces using topoSet and create outer patches
3. create the cellZones for AMI using the small cylinder
4. call createBaffles and mergeOrSplitBaffles to create the AMI interface

I don't think, however, that the way you do it is in any way inferior and so should lead to similar if not the same results..

But I am more intersted to use my mesh since the other parts of projects is related to this mesh and i need to compare them.

In that case your initial approach is the only way I can think of. Sadly, I haven't got much experience in using externally generated meshes though so perhaps someone else could help you with that issue...

If I have to work with snappy as tutirial .
It needs just switch the stl files with tut files and update the block mesh domain?!