CFD Online Logo CFD Online URL
www.cfd-online.com
[Sponsors]
Home > Forums > OpenFOAM Running, Solving & CFD

Strange high velocity in centrifugal pump simulation

Register Blogs Members List Search Today's Posts Mark Forums Read

Reply
 
LinkBack Thread Tools Display Modes
Old   July 4, 2014, 22:29
Default Strange high velocity in centrifugal pump simulation
  #1
Senior Member
 
Huang Xianbei
Join Date: Sep 2013
Location: CAU,China
Posts: 277
Rep Power: 5
huangxianbei is on a distinguished road
Hi,all:
I'm simulating a centrifugal pump's impeller with single channel, so I use SRFSimpleFoam to do a steadystate simulation. I refer to the settings of fvsolution and fvschemes Water pump OpenFOAM 15 ANSYS CFX 110 comparation
The operating condition is n=725rpm and flow rate is 3.06L/s , indicates 0.914m/s at inlet.
Here is a image of the pump
huangxianbei is offline   Reply With Quote

Old   July 4, 2014, 22:32
Default
  #2
Senior Member
 
Huang Xianbei
Join Date: Sep 2013
Location: CAU,China
Posts: 277
Rep Power: 5
huangxianbei is on a distinguished road
here is the initial conditions
k
Code:
dimensions      [ 0 2 -2 0 0 0 0 ];

internalField   uniform 0.002;

boundaryField
{
    in
    {
        type            fixedValue;
        value           uniform 0.002;
    }
    out
    {
        type            zeroGradient;
    }
    part_1
    {
        type            kqRWallFunction;
        value           uniform 0.002;
    }
    hub
    {
        type            kqRWallFunction;
        value           uniform 0.002;
    }

shroud
    {
        type            kqRWallFunction;
        value           uniform 0.002;
    }
 bo
    {
        type            kqRWallFunction;
        value           uniform 0.002;
    }
 bi
    {
        type            kqRWallFunction;
        value           uniform 0.002;
    }
ss
    {
        type            kqRWallFunction;
        value           uniform 0.002;
    }
ps
    {
        type            kqRWallFunction;
        value           uniform 0.002;
    }

    peri1
    {
        type            cyclic;
        value           uniform 0.002;
    }
    peri2
    {
        type            cyclic;
        value           uniform 0.002;
    }
}
nut
Code:
dimensions      [ 0 2 -1 0 0 0 0 ];

internalField   uniform 0;

boundaryField
{
    in
    {
        type            calculated;
        value           uniform 0;
    }
    out
    {
        type            calculated;
        value           uniform 0;
    }


part_1
    {
        type            nutkWallFunction;
        U               Urel;
        value           uniform 0;
    }
    hub
    {
        type            nutkWallFunction;
        U               Urel;
        value           uniform 0;
    }

shroud
    {
        type            nutkWallFunction;
        U               Urel;
        value           uniform 0;
    }
 bo
    {
        type            nutkWallFunction;
        U               Urel;
        value           uniform 0;
    }
 bi
    {
        type            nutkWallFunction;
        U               Urel;
        value           uniform 0;
    }
ss
    {
       type            nutkWallFunction;
        U               Urel;
        value           uniform 0;
    }
ps
    {
        type            nutkWallFunction;
        U               Urel;
        value           uniform 0;
    }

    peri1
    {
        type            cyclic;
        value           uniform 0;
    }
    peri2
    {
        type            cyclic;
        value           uniform 0;
    }
}
omega
Code:
dimensions      [ 0 0 -1 0 0 0 0 ];

internalField   uniform 0.02;

boundaryField
{
    in
    {
        type            fixedValue;
        value           uniform 0.02;
    }
    out
    {
        type            zeroGradient;
    }
part_1
    {
        type            omegaWallFunction;
        U               Urel;
        value           uniform 0.02;
    }
    hub
    {
        type            omegaWallFunction;
        U               Urel;
        value           uniform 0.02;
    }

shroud
    {
        type            omegaWallFunction;
        U               Urel;
        value           uniform 0.02;
    }
 bo
    {
        type            omegaWallFunction;
        U               Urel;
        value           uniform 0.02;
    }
 bi
    {
        type            omegaWallFunction;
        U               Urel;
        value           uniform 0.02;
    }
ss
    {
       type            omegaWallFunction;
        U               Urel;
        value           uniform 0.02;
    }
ps
    {
        type            omegaWallFunction;
        U               Urel;
        value           uniform 0.02;
    }

    peri1
    {
        type            cyclic;
        value           uniform 0.02;
    }
    peri2
    {
        type            cyclic;
        value           uniform 0.02;
    }
}
p
Code:
dimensions      [ 0 2 -2 0 0 0 0 ];

internalField   uniform 0;

boundaryField
{
    in
    {
        type            zeroGradient;
    }
    out
    {
        type            fixedValue;
        value           uniform 0;
    }
    part_1
    {
        type            zeroGradient;
    }
    hub
    {
        type            zeroGradient;
    }

shroud
    {
        type            zeroGradient;
    }
 bo
    {
        type            zeroGradient;
    }
 bi
    {
        type            zeroGradient;
    }
ss
    {
       type            zeroGradient;
    }
ps
    {
        type            zeroGradient;
    }

    peri1
    {
        type            cyclic;
    }
    peri2
    {
        type            cyclic;
    }
}
urel
Code:
dimensions      [ 0 1 -1 0 0 0 0 ];

internalField   uniform ( 0 0 0 );

boundaryField
{
    in
    {
        
        type             SRFVelocity;      
        inletValue            uniform ( 0 0 0.914 );
        relative         no;
        value            uniform ( 0 0 0 );

    }
    out
    {
        type            zeroGradient;
    }
    

    part_1
    {
        type            fixedValue;
        value           uniform ( 0 0 0 );
    }
    hub
    {
       type            fixedValue;
        value           uniform ( 0 0 0 );
    }

shroud
    {
        type            fixedValue;
        value           uniform ( 0 0 0 );
    }
 bo
    {
        type            fixedValue;
        value           uniform ( 0 0 0 );
    }
 bi
    {
        type            fixedValue;
        value           uniform ( 0 0 0 );
    }
ss
    {
       type            fixedValue;
        value           uniform ( 0 0 0 );
    }
ps
    {
        type            fixedValue;
        value           uniform ( 0 0 0 );
    }
    peri1
    {
       type            cyclic;
    }
    peri2
    {
        type            cyclic;
    }
}
huangxianbei is offline   Reply With Quote

Old   July 4, 2014, 22:37
Default
  #3
Senior Member
 
Huang Xianbei
Join Date: Sep 2013
Location: CAU,China
Posts: 277
Rep Power: 5
huangxianbei is on a distinguished road
I use kOmegaSST,while I'm not sure how to set omega correctly, is there any formulation for estimation?

Here, go on with my simulation.
I set a monitor point close to the suction side of blade outlet to see if the calculation is steady, however, I found a rather strange phenomenon
Code:
#           x      -0.09319
#           y         0.015
#           z   -0.00582998
#        Time
           10             (708.153 -482.063 -84.2791)
           20             (-731.865 -971.44 361.995)
           30             (639.399 492.4 468.239)
           40             (-300.636 -1380.19 1012.41)
           50             (-194.88 -3082.72 -231.911)
           60             (485.299 -3518.82 -432.512)
           70             (1316 -4292.53 -538.085)
           80             (1928.73 -4083.86 -1172.74)
           90             (480.997 1319.28 -2470.87)
          100             (539.042 2127.23 957.49)
          110             (-5375.99 8878.74 2416.83)
          120             (-36226.3 16654.7 4366.7)
          130             (-98909.9 -4494.45 7662.75)
          140             (-142791 -46558.3 10644.8)
          150             (-284845 -147723 20756.2)
          160             (5.24698e+08 -2.85525e+07 -2.43624e+07)
          170             (6.99645e+09 -7.93281e+08 -3.94233e+08)
          180             (1.95323e+10 -3.43447e+09 -1.16038e+09)
          190             (-1.62621e+10 -1.86164e+09 7.33979e+07)
          200             (-2.3165e+10 -7.9908e+09 6.50242e+08)
          210             (3.09272e+10 -1.4602e+09 8.878e+08)
          220             (2.91008e+10 -2.58789e+10 -2.71254e+09)
          230             (-3.83297e+11 -1.56371e+11 3.0038e+10)
          240             (-6.79308e+11 -1.97788e+11 4.6686e+10)
          250             (-1.62821e+12 -7.48888e+11 1.02044e+11)
          260             (-3.34796e+12 -2.71107e+12 2.76611e+11)
          270             (-2.99721e+12 -4.7534e+12 5.17778e+11)
          280             (-1.35913e+13 -1.01207e+13 -1.61047e+12)
          290             (-2.26852e+13 -1.54068e+13 -6.05349e+11)
          300             (-2.34315e+13 -7.01585e+12 -2.15218e+12)
          310             (-7.66376e+12 4.36892e+12 -1.3551e+12)
          320             (-4.6655e+12 3.1273e+12 -1.12806e+12)
          330             (-4.17135e+12 3.8903e+12 -9.72603e+11)
          340             (-4.65089e+12 3.1797e+12 -1.08913e+12)
          350             (-6.25636e+12 1.81316e+12 -2.67658e+12)
          360             (-9.87292e+12 -8.66844e+11 -5.06165e+12)
          370             (-2.36429e+14 -2.11397e+14 -4.20645e+13)
          380             (-2.22321e+15 -2.59051e+15 -4.26863e+14)
          390             (-9.6626e+15 -1.05104e+16 -2.15745e+15)
          400             (-9.61184e+15 -1.18926e+16 -1.85749e+15)
          410             (-8.7657e+15 -9.30405e+15 -1.3393e+15)
          420             (-1.17965e+16 -7.26078e+15 -1.05772e+15)
          430             (-1.11844e+17 -1.40191e+17 4.95792e+15)
          440             (-2.0703e+17 -1.32351e+17 3.3317e+16)
          450             (-2.90402e+17 -1.03778e+17 3.86379e+16)
          460             (-5.23649e+17 -1.26167e+17 7.09394e+16)
          470             (-7.28269e+17 -1.90686e+17 9.7137e+16)
          480             (-4.82389e+17 -1.83384e+17 7.39091e+16)
          490             (-5.67745e+17 -9.90307e+16 6.05046e+16)
          500             (-7.40366e+17 1.39949e+17 3.92672e+16)
          510             (-1.71386e+18 4.54933e+17 -6.3212e+15)
          520             (-1.36598e+18 -6.88643e+16 -1.24439e+17)
          530             (-2.43043e+18 -2.19435e+17 -2.04526e+17)
          540             (-7.27807e+18 1.60216e+18 -4.18682e+17)
          550             (-4.83848e+19 -1.06007e+19 -1.18041e+19)
          560             (-2.62584e+20 -2.47255e+20 -8.68161e+19)
          570             (-4.31522e+20 -4.36771e+20 -1.06853e+20)
As seen, the Urel goes crazy along the calculation , it can be expected to overflow after certain steps
huangxianbei is offline   Reply With Quote

Old   July 4, 2014, 22:39
Default
  #4
Senior Member
 
Huang Xianbei
Join Date: Sep 2013
Location: CAU,China
Posts: 277
Rep Power: 5
huangxianbei is on a distinguished road
fvschemes
Code:
ddtSchemes
{
    default         steadyState;
}

gradSchemes
{
    default         Gauss linear;
    
    
}

divSchemes
{
    default         none;
    div(phi,U) Gauss SFCD;
div(phi,Urel) Gauss SFCD;
div(phi,k) Gauss linear;
div(phi,epsilon) Gauss linear;
div(phi,omega) Gauss linear;
div(phi,v2) Gauss limitedLinear 0.5;
div(phi,f) Gauss limitedLinear 0.5;
div(phi,R) Gauss linear;
div(R) Gauss linear;
div(phi,nuTilda) Gauss upwind;
div((nuEff*dev(T(grad(Urel))))) Gauss linear; 
}

laplacianSchemes
{
    default         Gauss linear corrected;
laplacian(nuEff,U) Gauss linear corrected;
laplacian(nuEff,Urel) Gauss linear corrected;
laplacian((1|A(U)),p) Gauss linear corrected;
laplacian((1|A(Urel)),p) Gauss linear corrected;
laplacian(DkEff,k) Gauss linear corrected;
laplacian(DepsilonEff,epsilon) Gauss linear corrected;
laplacian(DomegaEff,omega) Gauss linear corrected;
laplacian(DREff,R) Gauss linear corrected;
laplacian(DnuTildaEff,nuTilda) Gauss linear corrected; 
}

interpolationSchemes
{
    default         linear;
}

snGradSchemes
{
    default         corrected;
}

fluxRequired
{
    default         no;
    p               ;
}
fvsolution
Code:
solvers
{
    p
    {
        solver          PCG;
        preconditioner  DIC;
        tolerance       1e-06;
        relTol          0.01;
    }

    Urel 
    {
        solver   smoothSolver;
        smoother GaussSeidel;
        nSweeps 2;
        tolerance 1e-7;
        relTol 0.01; 
    }

    k
    {
        solver          PBiCG;
        preconditioner  DILU;
        tolerance       1e-07;
        relTol          0.01;
    }

    

    omega
    {
        solver          PBiCG;
        preconditioner  DILU;
        tolerance       1e-07;
        relTol          0.1;
    }

    
}

SIMPLE
{
nNonOrthogonalCorrectors 2;
} 

relaxationFactors
{
    fields
    {
        p               0.3;
    }
    equations
    {
        Urel            0.4;
        k               0.4;
        omega           0.4;
    }
}
huangxianbei is offline   Reply With Quote

Old   July 4, 2014, 22:42
Default
  #5
Senior Member
 
Huang Xianbei
Join Date: Sep 2013
Location: CAU,China
Posts: 277
Rep Power: 5
huangxianbei is on a distinguished road
Can anyone give me some advice? I'm struggling for several days
By the way, the residual is also always among 0.3-0.5
huangxianbei is offline   Reply With Quote

Old   July 5, 2014, 02:56
Default
  #6
Senior Member
 
Huang Xianbei
Join Date: Sep 2013
Location: CAU,China
Posts: 277
Rep Power: 5
huangxianbei is on a distinguished road
hello,everyone, I tried another way, still, the problem stays the same. I think it's due to the periodic boundary, so I generate a full impeller's mesh(unstructured) and with only 3 boundaries: inlet, wall, outlet
All the setting are the same as before except without periodic boundaries, while, the velocity and pressure continues to grow and finally crashed.

I have already checked the mesh, it's ok, so there is no doubt about the geometry(for example, transform mesh with a wrong scale).The only problem my be the boundary conditions, the schemes used won't cause this unreal result , I think
huangxianbei is offline   Reply With Quote

Old   July 7, 2014, 03:07
Default
  #7
Senior Member
 
Tom Fahner
Join Date: Mar 2009
Location: Delft, Netherlands
Posts: 299
Rep Power: 12
tomf is on a distinguished road
Send a message via MSN to tomf Send a message via Skype™ to tomf
Hi,

I believe it is the schemes that cause your divergence. You use linear for the convection in the turbulent equations, but these have very high gradients near solid walls. This will lead to an unstable system. Also the SFCD scheme is not very stable. You could better use limitedLinear or perhaps even upwind for k or omega.

Regards,
Tom
tomf is offline   Reply With Quote

Old   July 7, 2014, 08:04
Default
  #8
Senior Member
 
Huang Xianbei
Join Date: Sep 2013
Location: CAU,China
Posts: 277
Rep Power: 5
huangxianbei is on a distinguished road
Quote:
Originally Posted by tomf View Post
Hi,

I believe it is the schemes that cause your divergence. You use linear for the convection in the turbulent equations, but these have very high gradients near solid walls. This will lead to an unstable system. Also the SFCD scheme is not very stable. You could better use limitedLinear or perhaps even upwind for k or omega.

Regards,
Tom
Hi,Tom:
Thank you for your reply. I changed the scheme and solution as the mixer tutorial and use K-e instead, now the result is converged.
Xianbei
huangxianbei is offline   Reply With Quote

Old   July 8, 2014, 23:05
Default
  #9
Senior Member
 
Huang Xianbei
Join Date: Sep 2013
Location: CAU,China
Posts: 277
Rep Power: 5
huangxianbei is on a distinguished road
Quote:
Originally Posted by tomf View Post
Hi,

I believe it is the schemes that cause your divergence. You use linear for the convection in the turbulent equations, but these have very high gradients near solid walls. This will lead to an unstable system. Also the SFCD scheme is not very stable. You could better use limitedLinear or perhaps even upwind for k or omega.

Regards,
Tom
Hi,Tom:
I'm facing another problem
I want to do LES calculation with the same Mesh. In fact, after computing with RANS, the y+ turns out to be <2.5 around the blade, so it's fine enough to do LES. While, when I use SRFPimpleFoam to accomplish this, the Courant number goes large very quickly in a given timestep size(deltaT), while, if I use
Code:
adjustTimeStep  yes;

maxCo           50;
It can be seen that the deltaT goes smaller and smaller, one order smaller after one step(By the way, I mapped the RANS result as the initial condition)
All the boundary conditions are the same as in RANS except the new nuSgs,which is
Code:
dimensions      [ 0 2 -1 0 0 0 0 ];

internalField   uniform 0;

boundaryField
{
    bottomWall
    {
        type            zeroGradient;
    }
    topWall
    {
        type            zeroGradient;
    }
        part_1
    {
        type            zeroGradient;
    }
    in
    {
        type            calculated;
        value           uniform 0;
    }
    out
    {
        type            calculated;
        value           uniform 0;
    }
    ps
    {
        type            zeroGradient;
    }
    ss
    {
        type            zeroGradient;
    }
    bi
    {
        type            zeroGradient;
    }
    bo
    {
        type            zeroGradient;
    }
    shroud
    {
        type            zeroGradient;
    }
    hub
    {
        type            zeroGradient;
    }
    peri1
    {
        type            cyclic;
    }
    peri2
    {
        type            cyclic;
    }
}
The LES model used is oneEq, the ddtScheme is backward,and PIMPLE settings in fvsolution
Code:
PIMPLE
{
    nOuterCorrectors 2;
    nCorrectors     2;
    nNonOrthogonalCorrectors 2;
    pRefCell        0;
    pRefValue       0;
}
I'm considering that SIMPLE algorithm should be used in transient calculation. I tried to use SRFSimpleFoam with ddtScheme backward and find it won't diverge. While I'm not quite sure if SIMPLE can be used in unsteady calculation.
Any advice is highly appreciated

Xianbei
huangxianbei is offline   Reply With Quote

Old   July 9, 2014, 03:02
Default
  #10
Senior Member
 
Tom Fahner
Join Date: Mar 2009
Location: Delft, Netherlands
Posts: 299
Rep Power: 12
tomf is on a distinguished road
Send a message via MSN to tomf Send a message via Skype™ to tomf
Hello Xianbei,

I think using maxCo = 50 for LES may not be accurate enough. You will probably not resolve the smallest time scales.

That being said, using only two outer correctors and maxCo=50 is probably the cause of the divergence. I would suggest to reduce your maxCo and/or increase the number of outer correctors for the PIMPLE solver. You may also want to use residualControl for the convergence within a time step.

Regards,
Tom
tomf is offline   Reply With Quote

Old   July 9, 2014, 09:32
Default
  #11
Senior Member
 
Huang Xianbei
Join Date: Sep 2013
Location: CAU,China
Posts: 277
Rep Power: 5
huangxianbei is on a distinguished road
Quote:
Originally Posted by tomf View Post
Hello Xianbei,

I think using maxCo = 50 for LES may not be accurate enough. You will probably not resolve the smallest time scales.

That being said, using only two outer correctors and maxCo=50 is probably the cause of the divergence. I would suggest to reduce your maxCo and/or increase the number of outer correctors for the PIMPLE solver. You may also want to use residualControl for the convergence within a time step.

Regards,
Tom
Hi,Tom:
Thank you very much. I searched a lot about the divergence in the forum and found it should be more in outer correctors for PIMPLE. I'll try and report the result soon.

Xianbei
huangxianbei is offline   Reply With Quote

Old   July 10, 2014, 03:44
Default
  #12
Senior Member
 
Huang Xianbei
Join Date: Sep 2013
Location: CAU,China
Posts: 277
Rep Power: 5
huangxianbei is on a distinguished road
Quote:
Originally Posted by tomf View Post
Hello Xianbei,

I think using maxCo = 50 for LES may not be accurate enough. You will probably not resolve the smallest time scales.

That being said, using only two outer correctors and maxCo=50 is probably the cause of the divergence. I would suggest to reduce your maxCo and/or increase the number of outer correctors for the PIMPLE solver. You may also want to use residualControl for the convergence within a time step.

Regards,
Tom
Hi,Tom:
I tried both your methods, use 20 outer correctors and residual control of p at 1e-2 and U 1e-5, also, the maxCo is limited to 5, the calculation is now proceeding well.Thank you very much
A quick question about the p residual: Is it acceptable for a residual of p to 1e-2. When setting this, the calculation can converge in 20 steps.

Xianbei
huangxianbei is offline   Reply With Quote

Old   July 10, 2014, 04:18
Default
  #13
Senior Member
 
Tom Fahner
Join Date: Mar 2009
Location: Delft, Netherlands
Posts: 299
Rep Power: 12
tomf is on a distinguished road
Send a message via MSN to tomf Send a message via Skype™ to tomf
Hi Xianbei,

Good to hear it is running.

1e-2 sounds like it is not enough, but you can only tell if you compare the results to experiment or literature. I would use at least 1e-4, but if 1e-2 is accurate enough than it is ok. I think that would be up to you to decide.

Kind regards,
Tom
tomf is offline   Reply With Quote

Old   July 10, 2014, 07:08
Default
  #14
Senior Member
 
Huang Xianbei
Join Date: Sep 2013
Location: CAU,China
Posts: 277
Rep Power: 5
huangxianbei is on a distinguished road
Quote:
Originally Posted by tomf View Post
Hi Xianbei,

Good to hear it is running.

1e-2 sounds like it is not enough, but you can only tell if you compare the results to experiment or literature. I would use at least 1e-4, but if 1e-2 is accurate enough than it is ok. I think that would be up to you to decide.

Kind regards,
Tom
Hi,Tom:
Yes,it's do sounds not enough. I run another case which is 40 outercorrectors and p 1e-3, however, most steps take the largest 40 correctors, which means a tendency of not converge to 1e-3. So I'll keep the 1e-2 case and see if the result is acceptable(comparing with experiment).
Thank you.
Xianbei
huangxianbei is offline   Reply With Quote

Old   July 10, 2014, 21:50
Default
  #15
Senior Member
 
Huang Xianbei
Join Date: Sep 2013
Location: CAU,China
Posts: 277
Rep Power: 5
huangxianbei is on a distinguished road
Quote:
Originally Posted by tomf View Post
Hi Xianbei,

Good to hear it is running.

1e-2 sounds like it is not enough, but you can only tell if you compare the results to experiment or literature. I would use at least 1e-4, but if 1e-2 is accurate enough than it is ok. I think that would be up to you to decide.

Kind regards,
Tom
Hi,Tom:
Looking for help again
I find a unexpected fact that if I decompose the domain into more parts in order to calculate in parallel, the residual rises. For example, if I decompose it into 4 parts, the residual can be below 1e-5 of p ,with GAMG solver and 1 nNonorthogonalCorrector, while if I decompose it into 16, the solution can never get a residual below even 1e-4. It's quite unacceptable for me, if I want to improve the accuracy, the speed will slow down with only 4 processors.
Is there anything I can do to avoid this?

Xianbei
huangxianbei is offline   Reply With Quote

Old   July 10, 2014, 23:07
Default
  #16
Senior Member
 
Huang Xianbei
Join Date: Sep 2013
Location: CAU,China
Posts: 277
Rep Power: 5
huangxianbei is on a distinguished road
Quote:
Originally Posted by tomf View Post
Hi Xianbei,

I think that would be up to you to decide.

Kind regards,
Tom
Hi,Tom:
Sorry for annoying. I tried many times, and find that the residual do be influenced by the number of processors used. I use the scotch method to decompose. The conclusion I can draw is that for my case, the maximum number of processor is 8 to make sure the residual of p to be below 1e-5. However, I still insist OF can be paralleled with as many processors as possible without accuracy loss.

Xianbei
huangxianbei is offline   Reply With Quote

Old   July 11, 2014, 04:30
Default
  #17
Senior Member
 
Tom Fahner
Join Date: Mar 2009
Location: Delft, Netherlands
Posts: 299
Rep Power: 12
tomf is on a distinguished road
Send a message via MSN to tomf Send a message via Skype™ to tomf
Hi Xianbei,

No problem, I will only answer when I have time available and if someone else can join the discussion and help you, that would be great as well.

About the decomposition, I remember a discussion during an OpenFOAM workshop where something similar was shown. That is to say, depending on the number of cpus used, the instantaneous results for a particular case (LES as well) differed, but the statistical parameters (average forces, standard deviation, fluctuation scales etc.) where all in agreement. I believe the comment was that the solver tolerance (fvSolution) should have been reduced by 1 or 2 orders of magnitude to have a more consistent development of the flow between different decompositions.

The mathematical reason is that you do solve a slightly different matrix-vector system and the non-linearity of the equations can cause this effect.

So I can only suggest that you tighten the tolerance on your final subiteration to have less difference between runs. Otherwise you maybe get lower residuals with 15 cpus instead of 16.

Kind regards,
Tom
tomf is offline   Reply With Quote

Old   July 11, 2014, 07:33
Default
  #18
Senior Member
 
Huang Xianbei
Join Date: Sep 2013
Location: CAU,China
Posts: 277
Rep Power: 5
huangxianbei is on a distinguished road
Quote:
Originally Posted by tomf View Post
Hi Xianbei,

No problem, I will only answer when I have time available and if someone else can join the discussion and help you, that would be great as well.

About the decomposition, I remember a discussion during an OpenFOAM workshop where something similar was shown. That is to say, depending on the number of cpus used, the instantaneous results for a particular case (LES as well) differed, but the statistical parameters (average forces, standard deviation, fluctuation scales etc.) where all in agreement. I believe the comment was that the solver tolerance (fvSolution) should have been reduced by 1 or 2 orders of magnitude to have a more consistent development of the flow between different decompositions.

The mathematical reason is that you do solve a slightly different matrix-vector system and the non-linearity of the equations can cause this effect.

So I can only suggest that you tighten the tolerance on your final subiteration to have less difference between runs. Otherwise you maybe get lower residuals with 15 cpus instead of 16.

Kind regards,
Tom
Hi,Tom:
Thank you for the details. You have helped me a lot, I really appreciate very much. Yes, maybe the result won't be affected much, however, only the residual is low enough can make one believe that the calculation is accurate enough. Thank you for your suggestion, I'll try it, if no further improvement is seen, I'll use 8 processor(Thanks God that the mesh size is not so big, 0.3 million)

Xianbei
huangxianbei is offline   Reply With Quote

Old   July 14, 2014, 23:04
Default
  #19
Senior Member
 
Huang Xianbei
Join Date: Sep 2013
Location: CAU,China
Posts: 277
Rep Power: 5
huangxianbei is on a distinguished road
Quote:
Originally Posted by tomf View Post
Hi Xianbei,

No problem, I will only answer when I have time available and if someone else can join the discussion and help you, that would be great as well.

About the decomposition, I remember a discussion during an OpenFOAM workshop where something similar was shown. That is to say, depending on the number of cpus used, the instantaneous results for a particular case (LES as well) differed, but the statistical parameters (average forces, standard deviation, fluctuation scales etc.) where all in agreement. I believe the comment was that the solver tolerance (fvSolution) should have been reduced by 1 or 2 orders of magnitude to have a more consistent development of the flow between different decompositions.

The mathematical reason is that you do solve a slightly different matrix-vector system and the non-linearity of the equations can cause this effect.

So I can only suggest that you tighten the tolerance on your final subiteration to have less difference between runs. Otherwise you maybe get lower residuals with 15 cpus instead of 16.

Kind regards,
Tom
Hi,Tom:
I find another strange thing about the yPlus. When I use RANS model in the calculation, yPlusRAS returns the y+<5 on the walls which I have specified a small distance at the first layer of grid. I run the LES case for another 1 day and the flow is steady (the monitor velocity varies much less), then I run the yPlusLES and find that the yPlus returns is much bigger than the RANS case, the yPlus is almost twice of that!! Have you ever experience this?

Xianbei
huangxianbei is offline   Reply With Quote

Old   July 15, 2014, 03:35
Default
  #20
Senior Member
 
Tom Fahner
Join Date: Mar 2009
Location: Delft, Netherlands
Posts: 299
Rep Power: 12
tomf is on a distinguished road
Send a message via MSN to tomf Send a message via Skype™ to tomf
Hi,

I have not performed any real LES cases, just played around a bit, so I can not say I have seen something similar.

Tom
tomf is offline   Reply With Quote

Reply

Thread Tools
Display Modes

Posting Rules
You may not post new threads
You may not post replies
You may not post attachments
You may not edit your posts

BB code is On
Smilies are On
[IMG] code is On
HTML code is Off
Trackbacks are On
Pingbacks are On
Refbacks are On


Similar Threads
Thread Thread Starter Forum Replies Last Post
Urgent problem! Appreciate all you help!! 3D Centrifugal Pump set up problems! RR2 FLUENT 5 April 13, 2012 08:17
Centrifugal Pump Cavitation problem or not. ismael.s CFX 13 February 27, 2012 09:00
velocity profile export from a simulation onto another sudhirlv STAR-CCM+ 1 September 12, 2010 18:57
Fluent simulation of centrifugal pump yvonne ANSYS 3 January 28, 2010 05:48
Peripheral pump CFD simulation Nevel Main CFD Forum 0 October 8, 2009 01:09


All times are GMT -4. The time now is 14:46.