[wildfire230]

I am trying to simulate pipe flow with icoFoam. As I understand it, the longest dimension of the cells should be lined up with the direction of the flow. Therefore, I have designed my mesh as seen in the attached image.



However, with this geometry, icoFoam requires 1000 iterations to solve for the pressure, and the cumulative error builds up until the simulation fails. However, if I modify my mesh as seen in the following image, the simulation runs successfully, and converges quickly.



Does anyone understand why this is the case? I have had a similar problem when I try to simulate the pipe flow with Reynolds numbers less than 10, even with the mesh that converges for Reynolds numbers greater than 10. The number of iterations needed to solve for the pressure becomes 1000 for each time step.

[kev4573]

What are the boundary conditions and solver settings?

[wildfire230]

I have zero pressure gradient on the inlet and on the walls with fixed uniform value of 0 at the outlet. I have fixed uniform velocity of (0 0 0) on the walls, a fixed uniform value of (1 0 0) at the inlet and zero gradient at the outlet.

my fvSchemes:

ddtSchemes {
default Euler;
}

gradSchemes {
default Gauss linear;
grad(p) Gauss linear;
}

divSchemes {
default none;
div(phi,U) Gauss limitedLinearV 1;
}

laplacianSchemes {
default none;
laplacian(nu,U) Gauss linear orthogonal;
laplacian((1|A(U)),p) Gauss linear orthogonal;
}

interpolationSchemes {
default linear;
interpolate(HbyA) linear;
}

snGradSchemes {
default orthogonal;
}

fluxRequired {
default no;
p;
}

my fvSolution:

solvers
{
p
{
solver GAMG;
tolerance 1e-6;
relTol 0.01;
smoother GaussSeidel;
nPreSweeps 0;
nPostSweeps 2;
cacheAgglomeration on;
agglomerator faceAreaPair;
nCellsInCoarsestLevel 10;
mergeLevels 1;
}

U
{
solver PBiCG;
preconditioner DILU;
tolerance 1e-05;
relTol 0;
}
}

PISO
{
nCorrectors 2;
nNonOrthogonalCorrectors 0;
pRefCell 0;
pRefValue 0;
}

[kev4573]

Check that your time step is adjusted properly for the fine mesh and that the "adjustTimeStep" option is enabled.

Might also try these solver settings (from the icoFoam elbow tutorial). The relTol of 0.01 in your input file may also be the issue. That value is typically only set non-zero if you are also solving for pFinal or p_rghFinal as in the pimpleFoam solvers.

 p
    {
        solver          PCG;
        preconditioner  DIC;
        tolerance       1e-06;
        relTol          0;
    }


    U
    {
        solver          PBiCG;
        preconditioner  DILU;
        tolerance       1e-05;
        relTol          0;
    }

And if all you're interested in is steady flow, you might check out simpleFoam, which is a steady-state solver.

[wildfire230]

Thanks for the advice. I have adjustableTimeStep running with a maximum Courant number of 0.3. I am still having the problem with the different solver settings. Here is an example output from a single time step:

Time = 0.018645

Courant Number mean: 0.02482955396171297 max: 0.08851514805781512
deltaT = 0.004604071946771764
DILUPBiCG: Solving for Ux, Initial residual = 0.03167164049957712, Final residual = 1.502872269799705e-06, No Iterations 4
DILUPBiCG: Solving for Uy, Initial residual = 0.5458185015077289, Final residual = 7.028177301864205e-06, No Iterations 7
DILUPBiCG: Solving for Uz, Initial residual = 0.03484942589707333, Final residual = 3.888450996297084e-06, No Iterations 4
DICPCG: Solving for p, Initial residual = 0.1554187396917251, Final residual = 0.2420298067075191, No Iterations 1001
time step continuity errors : sum local = 0.0004677898450645965, global = 2.274942150604063e-06, cumulative = -7.265073506196009e-05
DICPCG: Solving for p, Initial residual = 0.9004703410408016, Final residual = 0.2263237242487491, No Iterations 1001
time step continuity errors : sum local = 0.0001514815359998497, global = -1.879371394446561e-06, cumulative = -7.453010645640664e-05
ExecutionTime = 390.45 s ClockTime = 391 s

You can see the No Iterations = 1001 for the pressure. Do you have any other ideas about what could be the problem? It's correct that the longest edge of a cell should be in the direction of the fluid velocity, right? Could the problem be somehow caused by the mesh density, or something like that? Also, do you know if there is a minimum Reynolds number that can be used with icoFoam?

Thanks again.

[kev4573]

The cells do look big in the flow direction, may want to try increasing resolution there. I'm not aware of any lower limit on Re.

Other things to try - 1) write out every time step and find where p and U are blowing up. 2) Run potentialFoam to double check your boundary conditions and mesh. 3) Run checkMesh to look for any strangeness 4) Take your mesh that works, and just increase the radial mesh resolution. 5) post your case files. 6) Increase flow direction mesh resolution near inlet of pipe.

[wildfire230]

Thanks for the help. It does seem to be an issue with the cells simply being to long in the flow direction, just by some comparisons with a rectangular duct test case. Do you know of any reason why low Reynolds numbers ( < 10 ) would similarly cause the number of iterations required to solve for pressure to become very large (1000+). These two problems seem related somehow, but I'm not sure how. Even the cavity tutorial has this issue when you try to make the Reynolds number 1 or 0.1, etc...

[kev4573]

I don't know why you are having issues with low Reynolds numbers. I just ran the cavity tutorial at a Re number of 0.01 without issues. Can you post your case files?

[wildfire230]

I'm not sure how to post my case files, but I just double checked all of them against the default cavity tutorial files and they are identical. The only thing I've changed is nu in the transport properties. When I use nu = 1, which should correspond to a Reynolds number of 0.1, I believe, my Courant number explodes and the simulation terminates at t = 0.25 seconds. If this is running successfully for you, I can't understand what's going on.

The only thing I can think of is that I made the slight modifications to icoFoam.C to allow an adjustable run time. Perhaps I somehow damaged the solver???

[kev4573]

Ah okay. I changed the velocity instead of 'nu'. When I change 'nu' the Co does blow up. If you take the time step down an order of magnitude this seems to fix the problem. Not sure why changing 'nu' causes this case to fail..