[chakshu]

Hello All,

I hope you guys are doing great.

I am trying to simulate a propeller using MRF (Multiple Reference Frame). I tried with SRSFSimpleFoam as well, but I did not manage to acheive convergence (post).

The propeller under consideration is a UAV propeller. I have created a mesh in Ansys and converted the mesh into OpenFoam format. The geometry is attached in this post. The propeller blade is situated in a cylindrical domain with a inlet, outlet and shroud. The BCs are also specified in the geomtery. Fist of all can you please check if the BCs are correct. A rotating frame is given by rot_frame cellZone as shown in geometry file.

I am using the spalart allmaras model for the sake of simplicity. I run the simulation for 1000 time steps, and it runs without diverging. I am monitoring the forces on the blade as well. When I check the values of the force, the force in z direction (the rotational axis) is very small (around ~0.003N), where as force sin x and y are negligible. And when I check the velocity and pressure in the domain at 1000 timestep, I see zero velocity and pressure everywhere (see attached figures) in the domain except the blade. And the pressure variation is almost negligible on the blade. It seems there is no transfer of fields between two rotaional and stationary domains. So I need some kind of interface between rotating and stationary volume.

What could be the possible reason for this. I don't think I need AMI for this case, correct me if I am wrong.



Below I attach the relevant files for the case.

I seek help from the community. I hope someone can guide me. Thanks in advance.

/*--------------------------------*- C++ -*----------------------------------*\
| =========                 |                                                 |
| \\      /  F ield         | OpenFOAM: The Open Source CFD Toolbox           |
|  \\    /   O peration     | Version:  v1912                                 |
|   \\  /    A nd           | Website:  www.openfoam.com                      |
|    \\/     M anipulation  |                                                 |
\*---------------------------------------------------------------------------*/
FoamFile
{
    version     2.0;
    format      ascii;
    class       volVectorField;
    object      U;
}
// * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * //

dimensions      [0 1 -1 0 0 0 0];

internalField   uniform (0 0 0);

boundaryField
{
    blade
    {
        type            noSlip;
    }

    shroud
    {
        type            pressureInletOutletVelocity;
        value           $internalField;
    }

    inlet
    {
        type            fixedValue;
    value        uniform (0 0 0);
    }

    outlet
    {
        type            pressureInletOutletVelocity;
        value           $internalField;
    }
}

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

/*--------------------------------*- C++ -*----------------------------------*\
| =========                 |                                                 |
| \\      /  F ield         | OpenFOAM: The Open Source CFD Toolbox           |
|  \\    /   O peration     | Version:  v1912                                 |
|   \\  /    A nd           | Website:  www.openfoam.com                      |
|    \\/     M anipulation  |                                                 |
\*---------------------------------------------------------------------------*/
FoamFile
{
    version     2.0;
    format      ascii;
    class       volScalarField;
    object      p;
}
// * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * //

dimensions      [0 2 -2 0 0 0 0];

internalField   uniform 0;

boundaryField
{
    blade
    {
        type            zeroGradient;
    }

    shroud
    {
        type            fixedValue;
    value        uniform 0;
    }

    inlet
    {
        type            zeroGradient;
    }

    outlet
    {
        type            fixedValue;
    value        uniform 0;
    }
}

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

/*--------------------------------*- C++ -*----------------------------------*\
| =========                 |                                                 |
| \\      /  F ield         | OpenFOAM: The Open Source CFD Toolbox           |
|  \\    /   O peration     | Version:  v1912                                 |
|   \\  /    A nd           | Website:  www.openfoam.com                      |
|    \\/     M anipulation  |                                                 |
\*---------------------------------------------------------------------------*/
FoamFile
{
    version     2.0;
    format      ascii;
    class       volScalarField;
    location    "0";
    object      nut;
}
// * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * //

dimensions      [0 2 -1 0 0 0 0];

internalField   uniform 0;

boundaryField
{
    blade
    {
        type            fixedValue;
        value           uniform 0;
    }

    shroud
    {
        type            fixedValue;
        value           uniform 0.14;
    }

    inlet
    {
        type            fixedValue;
    value        uniform 0.14;
    }

    outlet
    {
        type            fixedValue;
    value        uniform 0.14;
    }
}


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

/*--------------------------------*- C++ -*----------------------------------*\
| =========                 |                                                 |
| \\      /  F ield         | OpenFOAM: The Open Source CFD Toolbox           |
|  \\    /   O peration     | Version:  v1912                                 |
|   \\  /    A nd           | Website:  www.openfoam.com                      |
|    \\/     M anipulation  |                                                 |
\*---------------------------------------------------------------------------*/
FoamFile
{
    version     2.0;
    format      ascii;
    class       dictionary;
    location    "constant";
    object      MRFProperties;
}
// * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * //

MRF1
{
    cellZone    rot_frame;
    active      yes;

    // Fixed patches (by default they 'move' with the MRF zone)
    nonRotatingPatches ();

    origin    (0 0 0);
    axis      (0 0 -1);
    omega     50;
}

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

/*--------------------------------*- C++ -*----------------------------------*\
| =========                 |                                                 |
| \\      /  F ield         | OpenFOAM: The Open Source CFD Toolbox           |
|  \\    /   O peration     | Version:  v1912                                 |
|   \\  /    A nd           | Website:  www.openfoam.com                      |
|    \\/     M anipulation  |                                                 |
\*---------------------------------------------------------------------------*/
FoamFile
{
    version     2.0;
    format      ascii;
    class       polyBoundaryMesh;
    location    "constant/polyMesh";
    object      boundary;
}
// * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * //

4
(
    inlet
    {
        type            patch;
        nFaces          9354;
        startFace       33447256;
    }
    shroud
    {
        type            patch;
        nFaces          71923;
        startFace       33456610;
    }
    outlet
    {
        type            patch;
        nFaces          9433;
        startFace       33528533;
    }
    blade
    {
        type            wall;
        inGroups        1(wall);
        nFaces          118780;
        startFace       33537966;
    }
)

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

Let me know if I am missing some important information to be included. Many thanks.

[Ngaru]

From your U dictionary there seem to be no flow velocity given in the domain.

[chakshu]

Hello,

Thank you so much for replying. Finally someone replied.

First of all, I think I forgot to mention that I use force functionObject in controlDict to calculate the forces.

Indeed, the inlet velocity was zero as I was trying to simulate the hovering case. My first question, do we need to have some separate BC for simulating hover case?

And next, I also did a simulation with the inlet velocity of 10 m/s and a rotational speed of 100 rps (6000 rpm). I am getting a thrust (force in z) of 0.37N. The value seems to be reasonable but the direction is opposite, with the current configuration I expect the thrust force to be in negative. And to confirm that, I plotted the pressure contour as well (shown in attached picture). The flow is coming from up to down, and there is more pressure on the top of the blade as compared to bottom, which explains the direction of thrust as well. I am totally confused why is this happening. I tried to reverse the direction of rotation as well, but still the same results in terms of direction of thrust and pressure contour.

Let me know if you know what could be a possible reason for this behaviour.

Thank you.

[chakshu]

Hello,

Update: I think I am able to get some meaningful results with the above settings. There was a very silly mistake I was making, while specifying the MRFProperties, the rotational speed is to be given in rad/s and I was assuming it to be rps. The blade which I was simulating is not designed for very low RPMs. So, that worked for me.

Might be useful for someone

[gabrielfelix]

Yeah, rotational velocity in MRFProperties is definitely rad/s. All units are in SI. You should also include in the nonRotatingPatches line the patches that are in the MRF but are no moving with it, like the AMI1 and AMI2 patches. These are the limits of the rotating region and they dont move with it.

Try setting up in MRFProperties files:

nonRotatingPatches (AMI1 AMI2);

Check MRFSimpleFoam + CyclicAMI = Flux not conserved at AMI Interface

My pressures were in the wrong side of the propellers as in your figures. The nonRotatingPatches modification solved the problem as well as made my forces and moments be closer to my analytic BEM results.

[chakshu]

Hi Gabriel,

Thanks for your reply. I will try the non rotating patches as well although now it is giving realistic thrust and torque values.

Another thing: When I use spalart allamaras it converges, but when I try to use komegasst model, it really needs high value of omega (high dissipation) for convergence, otherwise I get very high values of forces and time step continuity error increases. Does anyone know the reason for this?

Thanks in advance.


Regards,
Chakshu

[Fouch]

Hi,
Same problem for me regarding dissipation of omega…

[chakshu]

Hey,


Are you also using MRF with SimpleFoam? And what is your application?

[Fouch]

I have the diffusion issue with simpleFoam and rhoSimpleFoam. Yes I am using MRF.

[chakshu]

Hi everyone,

Following the above threads. I have been trying to perform a simulation for propeller using MRF SimpleFoam in OpenFoam. The propeller I am using as a test case is APC 10x4.7SF. I am simulating a hover case.

1. Mesh size is around 13M, and in checkMesh, it does not throw any error, except few cells above non-orthogonal (which is more of a warning).
2. Solver: I am using kOmega SST, with first order discretization schemes for k and omega
3. The simulation converges, with 1100 iteration, but as I mentioned in one of the above posts, I have to use high values of omega, that is still the same.
4. Results: at 4000 RPM, thrust = 1.92N, experimental thrust = 2.5N, simulation torque = 0.032 Nm, experimental torque=0.041 Nm.

As you can see, the results are under-predicted, I would like to understand the reason for this. I have the following questions:

1. Is this normal to have under-predicted values because I am using first order discretization for k and omega?
2. Can it be imporved by mesh?
3. I tried to switch to second order dicretization but I get a very high value of forces of the order e39 i.e. solution diverges.
4. Changing the model? I am not sure if it would help.
5. Any other suggestion to achieve results close to the experimental value: or any other approaches.

I got same behaviour with one of the other blade as well. I would really appreciate the inputs from the community.

Thanks in advance.
Regards,
Chakshu

[fedenr]

Hi Chakshu,


In my experience k omega SST is not the best turbulence model to simulate propellers.
Comparing kEpsilon and kOmega SST I have found that kEpsilon matched the experimental results quite well while kOmega SST underpredicts them.

On the other hand, since you mention the mesh, it is always advisable to perform a mesh independence study to ensure that it is not affecting the solution.

[chakshu]

Hi Federico,

Thanks for your reply.

Okay, I will try k-epsilon model. The reynolds number of operation would be below 60-70k. Do you think k-epsilon could be better suited in this range?

[chakshu]

Hi,

Update: I finished running simlulation with kepsilon, I got almost same value for Thrust (as compared to kOmega), where as torque value is close to the experiments, but overall, efficiency/FOM is totally off (as compared to experiments and kOmega).

• Also, I would like to know if using paraller computing could effect the accuracy of the solution? For my case, I am using 14 processors with hierarchical method (1, 1, 14), with cylindrical domain being in z direction.

• @fedenr as you said, you were able to get results close to experiments with Kepsilon, may I know what was your testcase (which propeller, which discretization schemes you used, was it with MRF method, steady etc)? I would like to compare my testcase to find the source of error. It would really help me if you could share this information. You can contact me on my email if you want: deorachakshu03@gmail.com.

In general: Can it be said that for steady simulation and MRF we will always under-predict (or is it too vague a statement)? Let me know what do you guys think?

Thanks in advance.

Regards.

[chakshu]

Hi everyone,

I think I found why my forces were under-estimated. I was using force library to calculate forces on the propeller. I had the following information in my force file:

/*--------------------------------*- C++ -*----------------------------------*\
| =========                 |                                                 |
| \\      /  F ield         | OpenFOAM: The Open Source CFD Toolbox           |
|  \\    /   O peration     | Version:  v1912                                 |
|   \\  /    A nd           | Website:  www.openfoam.com                      |
|    \\/     M anipulation  |                                                 |
\*---------------------------------------------------------------------------*/

forces
{
    type          forces;

    libs          (forces);

    writeControl  timeStep;
    timeInterval  1;

    log           yes;

    patches       ("propeller");
    rho           rhoInf;     // Indicates incompressible
    log           true;
    rhoInf        1;          // Redundant for incompressible

    CofR          (0 0 0);    // Rotation around centre line of propeller
    pitchAxis     (0 1 0);
}


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

For rhoInf, I was using 1, whereas for my case (air) it should be 1.225. So, after changing the rho, my predictions are relatively close to the experiments. However, the simulation is still under-predicting as compared to experiments, but the error can be reduced to 5-6% for torque and thrust.

[Fouch]

Hi,

Could you share your fvSolution and your fvSchemes ?

[fedenr]

Hi Chaksu,


Unfortunately I cannot share the propeller geometry. As for the configuration, it's a transient simulation using sliding mesh. The schemes I use are the following:

ddtSchemes
{
    default         Euler;
}

gradSchemes
{
    default         Gauss linear;
    grad(p)         Gauss linear;
    grad(U)         cellLimited Gauss linear 1;
}

divSchemes
{
    default         none;
    div(phi,U)      Gauss linearUpwind grad(U);
    div(phi,k)      Gauss upwind;
    div(phi,epsilon) Gauss upwind;
    div((nuEff*dev2(T(grad(U))))) Gauss linear;
}

laplacianSchemes
{
    default         Gauss linear limited corrected 0.33;
}

interpolationSchemes
{
    default         linear;
}

snGradSchemes
{
    default         limited corrected 0.33;
 }

As for the parallel calculation, it should not affect it, or at least not noticeably. I have launched this same case for different number of cores and I have not observed any strange behavior in that sense.


I see that you seem to have already found the source of the error. A difference of ~ 5% seems acceptable to me, although it depends on the level of accuracy you require. In my case the error, depending on the rotation speed, ranges between 1 and 3% (also under-predicting), but obviously at the cost of a much higher computational cost (transient case).


What I find curious is that you get almost the same results with kOmega and kEpsilon. It is possible that I am not getting the same results because of some problem with the mesh. I will try to check it.