[jgross]

Hello,

I am using MRFSimpleFoam from OF Extend 4.0 (mainly because I would like to use grid generalised interface feature not available on OF v5.0) to simulate internal 2D flow through a centrifugal pump.

I am finding the simulations are not meeting residual criteria, as the simulations will always run until the final time specified. Upon inspection of the data, it is easy to see that the solutions have approximately converged, as there is not much deviation in quantities such as flow rate and head from a certain point (see the FlowRateAndHead.jpg).

Furthermore, if I perform a grid convergence study, I do not reach a grid converged solution until approximately 1.5e+6 - 2e+6 elements (see the GridStudyQ.jpg). I am using an unstructured mesh (you can see an example of a coarse mesh in 2DPumpGeometry.png), so I expect more elements to be required. However, this seems fairly unreasonable for a quasi-steady state simulation.

All of this together is making the run times much longer than I would expect for a 2D quasi-steady state simulation (see GridStudyTime.jpg).

I have also copied the case folder to my OneDrive account and a link is available here

https://universityofcambridgecloud-my.sharepoint.com/:f:/g/personal/jg847_cam_ac_uk/EvQU4R0beL1As7yFza5dggIBppKNJlUoea85_LD5jhENVg?e=sfNQIe

Any suggestions for improving the convergence and run time for this would be greatly appreciated.

Regards,
J

[jgross]

No one?

Ok, well I'm approaching this in two ways.

I'm remeshing with a structured boundary layer to cut down on the number of mesh elements necessary. Also I'm going to try to use other software (e.g. Ansys) to see if the problem really is quite difficult, or if OF is just slow.

I'll try to post results here if it helps anyone else.

James

[arvindpj]

In OF 5. you can use CycliAMIs to achieve the same effect.

I am curious why it would require 2Mil cells for 2D?

I find similar simulation times between Fluent and OF and it converges quite fast (for my cases < 2000 iterations even for 3D)

Initialize with potentialFoam. Reduce solver tolerance for P and others initially. Start with 1st order schemes and later switch to 2nd order.

My recommend setting for Pressure bc:

    inlet
    {
        type            totalPressure;
        rho             rho;
        psi             none;
        gamma           1;
        p0              uniform 0;
        value           uniform 0;
    }
    outlet
    {
        type            fixedValue;
        value           uniform 0;
    }

[jgross]

Hi Arvind,

I won't be able to try those suggestions until Sunday. I just wanted to thank you for your response. I will post results here after.

Regards,
James

[jgross]

Hi people,

So I've switched over to using cyclicAMI BCs and OFv5, incorporated the suggested pressure BCs at the inlet and outlet, and I've initialised with potentialFoam.

Unfortunately I haven't had the chance to play around with modifying schemes during simulation. Right now, I'm trying to focus on ensuring the simulation gives results that are physical.

In particular, the pressure side and suction side have been flipped because I changed the blade orientation (see attached picture). What is peculiar though is that I cannot just simply modify the rotation angle in MRFProperties, as the solver diverges if I try to do that.

Does anyone have any experience with the solver divergence when swapping the direction of rotation?

J

[jgross]

Improved the convergence by changing the mesh such that it used a structured mesh on the BL and unstructured in the rest of the flow domain. Also by changing the schemes and relaxation parameters, I was able to improve the convergence of the problem.

All in all, it was mostly a meshing issue. Garbage in, garbage out.

J

[Lookid]

As I am also working on a centrifugal pump with foam extend, I'll post here:

I have a mixingPlane boundary conditions between the outlet of the impeller and the volute.
The thing is the impeller is periodic, and the velocity at the outlet of my periodic impeller is averaged over the 360° inlet of the volute instead of being averaged+multiplied by the total number passage. The result is that the flow rate in the volute is 1/6 of the one it should be. But alleast the average is nice ^^. (see attachement for geometry + averaging)

Does someone know how to solve this problem? I suppose the problem lies in this boundary conditions. You can specify some things in the discretization of the ribbonPatch, for example in my case, inside the boundary file :

blablabla

    MP_impellerVolute
    {
        type            mixingPlane;
        nFaces          6690;
        startFace       2229324;
        shadowPatch     MP_voluteImpeller;
        zone            MP_impellerVoluteZone;
        coordinateSystem
        {
            type            cylindrical;
            name            mixingCS;
            origin          ( 0 0 0 );
            e1              ( 1 0 0 );
            e3              ( 0 0 1 );
            inDegrees       true;
        }
        ribbonPatch
        {
            sweepAxis       Theta;
            stackAxis       Z;
            discretisation  bothPatches; //slavePatch masterPatch userDefined
        }
    }
    MP_voluteImpeller
    {
        type            mixingPlane;
        nFaces          22946;
        startFace       2236014;
        shadowPatch     MP_impellerVolute;
        zone            MP_voluteImpellerZone;
    }

blablabla

Maybe you can specifiy the right thing with userDefined but i have no idea how to write it and I can't find any examples.

Bonus question :
How exactly are defined e1 and e3 ? And thus the sweep and stack Axis according to this?
Read this https://www.slideshare.net/fumiyanoz...using-openfoam slide#75, but still I don't get it completely.

Thanks