[maddalena]

Hello,
finally I have my simulation running!
the mesh is not perfect: about 4000 non-orthogonal cells out of 600000. However, I want to keep the cell number "low" to understand how to set up everything properly. For the same reason, I switched the turbulence off and considered the flow as laminar. On a second step, I will apply what both suggested above for the mesh generation & the turbulence model.
What I have noticed so far is that my pressure residual flattens after about 100 iterations, and at the same time the GAMG solver makes hundreds of iterations. The latter is due to the solver residual, that are quite low indeed:

    p
    {
        solver          GAMG;
        tolerance       1e-09;
        relTol          1e-04;
        smoother        GaussSeidel;
        nPreSweeps      0;
        nPostSweeps     2;
        cacheAgglomeration true;
        nCellsInCoarsestLevel 10;
        agglomerator    faceAreaPair;
        mergeLevels     1;
    }

    U
    {
        solver          smoothSolver;
        smoother        GaussSeidel;
        tolerance       1e-09;
        relTol          1e-04;
    }

However, increasing them, the pressure residual goes up and down and never reach convergence. this is my last simulated time output:

smoothSolver:  Solving for Ux, Initial residual = 0.00482599, Final residual = 4.45505e-07, No Iterations 8
smoothSolver:  Solving for Uy, Initial residual = 0.0339055, Final residual = 2.32396e-06, No Iterations 8
smoothSolver:  Solving for Uz, Initial residual = 0.0122788, Final residual = 1.10086e-06, No Iterations 8
GAMG:  Solving for p, Initial residual = 0.127016, Final residual = 1.26726e-05, No Iterations 151
GAMG:  Solving for p, Initial residual = 0.0437082, Final residual = 4.28262e-06, No Iterations 221
time step continuity errors : sum local = 2.32733e-05, global = -7.60473e-07, cumulative = -2.55991e-05

Can these convergence problems be due to my poor mesh quality? Or is there anything I can change to improve the convergence? I am using 2 non-orthogonal correctors, should I use more of them? I do not think this will be useful..
Suggestions?


mad

[alberto]

Usually it is convenient to keep the pressure residual lower than the others (say p: 10^-10, U: 10^-8), and to reduce the relTol to zero.

About the non-orthogonal correctors, use a number that allows the pressure equation to converge within the iteration.

Best,

[maddalena]

Hi Alberto,
just to understand what I am doing...

Originally Posted by alberto

Usually it is convenient to keep the pressure residual lower than the others (say p: 10^-10, U: 10^-8)

I am used to to that... I misread fvSolution...

Originally Posted by alberto

and to reduce the relTol to zero.

The pressure relTol or every relTol? What does this mean? That I will accept the iteration solution only if approaching the computing precision? In that way, the iteration time will be terribly high!

Originally Posted by alberto

About the non-orthogonal correctors, use a number that allows the pressure equation to converge within the iteration.

Thus if I want that the pressure has a simulation final convergence of say 10E-4, I should choose the number of nonOrthogonalCorrectors in such a way that the last time I solve the pressure equation whithin that step, I have an intial residual of 10E-4. Is that what you meant?
Thanks a lot for your suggestions.
Regards,

mad

[nileshjrane]

Originally Posted by maddalena

The pressure relTol or every relTol? What does this mean? That I will accept the iteration solution only if approaching the computing precision? In that way, the iteration time will be terribly high!

Hi,

The user guide says that relTol is the ratio of initial residual to final residual. Meaning when the residual gets below (relTol X inital residual) the solution is stopped. And if you set it to zero then the the absolute residual value u specify is used. So it doesnt take forever. I thinkit takes higher of the two numbers (i.e from relTol and the absolute value u specify) as stopping criteria.

[maddalena]

I should have checked par 4.5.1.1 of the user guide!

Summarizing:

• tolerance: is the maximum admissible ratio between the last and the next to last value;
• relTol: is the maximum admissible ratio between the last and the first residual. <-- Nilesh, you reported wrong!

Thus if relTol is zero, relTol == tolerance.

Originally Posted by nileshjrane

So it doesnt take forever.

This is always a good news...

Originally Posted by nileshjrane

I think it takes higher of the two numbers (i.e from relTol and the absolute value u specify) as stopping criteria.

Yes, in that case the computational time is always higher.
Thank you!

mad

[nileshjrane]

Hi maddalena,

This is the exact text from the UG:

USER GUIDE
Before solving an equation for a particular field, the initial residual is evaluated based on the current values of the field. After each solver iteration the residual is re-evaluated. The solver stops if either of the following conditions are reached:

• the residual falls below the solver tolerance, tolerance;
• the ratio of current to initial residuals falls below the solver relative tolerance, relTol;

Originally Posted by maddalena

Summarizing:

• tolerance: is the maximum admissible ratio between the last and the next to last value;

Tolerance is not a ratio, its just a value below which if residual goes, the solution is considered converged.

relTol: is the maximum admissible ratio between the last and the first residual. <-- Nilesh, you reported wrong!

I think i said the same think..

Yes, in that case the computational time is always higher.

No, but its exactly opposite. By higher value i meant, say tolerance sets limit as 1e-07 and relTol as 1e-03 (if relTol = 0.1 and initial tolerance = 0.01 for example), the solver will take 1e-03 as the cut-off criteria..higher value of the two, you see..as the UG says solver stops when either of the two gets satisfied, n its but obvious that the one which has higher value will get satisfied first, so your iterations will terminate sooner and you will have lesser computational time.

[alberto]

Originally Posted by maddalena

That I will accept the iteration solution only if approaching the computing precision? In that way, the iteration time will be terribly high!

The single iteration might take longer, but its convergence will be better, which results in faster drop of residuals.

Thus if I want that the pressure has a simulation final convergence of say 10E-4, I should choose the number of nonOrthogonalCorrectors in such a way that the last time I solve the pressure equation within that step, I have an intial residual of 10E-4. Is that what you meant?

Yes, or something close to that. If you run a steady-state case, it is not strictly necessary the residual goes very low, but it should not grow, and it should tend to become smaller.

Best,

[maddalena]

Thank you to both of you for the suggestions!
Now I have this fvSolution:

    p
    {
        solver          GAMG;
        tolerance       1e-05;
        relTol          0;
        smoother        GaussSeidel;
        nPreSweeps      0;
        nPostSweeps     2;
        cacheAgglomeration true;
        nCellsInCoarsestLevel 10;
        agglomerator    faceAreaPair;
        mergeLevels     1;
    }

    U
    {
        solver          smoothSolver;
        smoother        GaussSeidel;
        tolerance       1e-03;
        relTol          0;
    }

The residual are not so low, but at the moment I think they are ok. Following the criterion suggested by Alberto, I have:

SIMPLE
{
    nNonOrthogonalCorrectors 6;
    pRefCell        0;
    pRefValue       0;
}

The simulation time is really high: about 2 minutes per iteration, using 2 processors (that are all the processors I can use... ). Find attached the initial pressure history: as you can see the residual drops on the first 50 iterations, but they increase and finally diverges from iteration 50 on. This is the log file at time 50:

Time = 50

smoothSolver:  Solving for Ux, Initial residual = 0.00866536, Final residual = 0.000815573, No Iterations 2
smoothSolver:  Solving for Uy, Initial residual = 0.0404917, Final residual = 0.000930839, No Iterations 3
smoothSolver:  Solving for Uz, Initial residual = 0.0188665, Final residual = 0.000551953, No Iterations 3
GAMG:  Solving for p, Initial residual = 0.127684, Final residual = 9.3116e-06, No Iterations 458
GAMG:  Solving for p, Initial residual = 0.0403606, Final residual = 9.66437e-06, No Iterations 63
GAMG:  Solving for p, Initial residual = 0.0146646, Final residual = 9.23663e-06, No Iterations 20
GAMG:  Solving for p, Initial residual = 0.00838198, Final residual = 8.57141e-06, No Iterations 15
GAMG:  Solving for p, Initial residual = 0.00576653, Final residual = 8.45709e-06, No Iterations 13
GAMG:  Solving for p, Initial residual = 0.00450226, Final residual = 9.49696e-06, No Iterations 12
GAMG:  Solving for p, Initial residual = 0.00368982, Final residual = 8.7992e-06, No Iterations 9
time step continuity errors : sum local = 3.52275e-05, global = -6.45865e-07, cumulative = -5.60862e-05
ExecutionTime = 6313.95 s  ClockTime = 6771 s

Everything seems fine, uh?
Thus, I analyzed the velocity and pressure distribution on the domain. What I can see is that velocity increases locally on the small pipe, in a position where the flow is supposed to follow pipe theory strictly. What I think is that this is a consequence of the mesh, since its grading is not really nice there, see the attached picture. Am I right? I definitely should follow your advices on mesh generation...
Cheers

mad

[alberto]

Well, yes, the mesh needs love :-)

[maddalena]

Hi everyone,
I finally got my simulations running (including turbulence), and everything went nice with the first case that I described in the previous posts.
Then I change geometry (refer to the new file attached)

• reverse the flow direction (counterclockwise instead of clockwise)
• add a second channel parallel to the small one; in that case the diameter is about 10x;
• add a sort of deviator at the end of this new channel, which has the function to reduce the flow on this new channel in favor of the small one.

I did not changed anything on the fan pressure jump. As a consequence, velocities inside the system reduce, since the pressure losses due to the deviator are higher. The geometry does not change, but the velocities reduce => the flow mass is lower.

However, what I really want to test is to keep the mass flow fixed and calculate the pressure losses on the system. So, I am thinking to change the condition on the fan. Instead of using a standard fan BC, use the following:

• On fan inlet, fix mass flow rate:
  • velocity: flowRateInletVelocity (with a negative sign);
  • pressure: zeroGradient;
  • epsilon, k: fixedValue;
• On the fan outlet, fix pressure;
  • velocity: zeroGradient;
  • pressure: fixedValue, 0;
  • epsilon, k: zeroGradient.

I cannot use inletOutlet in place of zeroGradient since I do not know a velocity value that I can use for the inletValue condition.

What do you think about this approach? Is it logical? or are there any other solution I can use to mantain flow rate constant inside the closed loop system?

Regards

mad

[nileshjrane]

Hi,

I don't have any experience of fan BC as such. But, when i think of such situation, when in real situation my mass flow is not enough, i would increase fan rpm. U know what i mean?? i will increase fan power and thus the pressure difference across the fan. So, how about doing this?? Increase the pressure across the fan till you get the right mass flow rate. I am sure you can estimate a rough value by simple hand calculations.

Just a suggestion..

Have fun..
Nilesh

[maddalena]

Hello,

Originally Posted by nileshjrane

Increase the pressure across the fan till you get the right mass flow rate. I am sure you can estimate a rough value by simple hand calculations.

Well, this is a solution as well, but I think this is not "clever". If I would do that, every time I change the geometry I should calculate the new pressure jump to keep mass flow rate constant. If I could fix the flow mass, I will not have this problem.
In any case... I run the simulation as described yesterday during the night. Not checked results yet, however I guess there is something wrong with this approach:

Time = 500

smoothSolver:  Solving for Ux, Initial residual = 0.00914707, Final residual = 8.10372e-05, No Iterations 4
smoothSolver:  Solving for Uy, Initial residual = 0.0282209, Final residual = 8.3451e-05, No Iterations 5
smoothSolver:  Solving for Uz, Initial residual = 0.00963077, Final residual = 8.75521e-05, No Iterations 4
GAMG:  Solving for p, Initial residual = 0.0236841, Final residual = 9.83143e-07, No Iterations 236
GAMG:  Solving for p, Initial residual = 0.00560969, Final residual = 9.7794e-07, No Iterations 12
GAMG:  Solving for p, Initial residual = 0.00171942, Final residual = 9.14703e-07, No Iterations 13
GAMG:  Solving for p, Initial residual = 0.000945763, Final residual = 8.96619e-07, No Iterations 16
GAMG:  Solving for p, Initial residual = 0.000616439, Final residual = 8.78768e-07, No Iterations 15
time step continuity errors : sum local = 2.60889e+11, global = 4.1978e+10, cumulative = -2.13409e+12
smoothSolver:  Solving for epsilon, Initial residual = 1.13585e-07, Final residual = 1.13585e-07, No Iterations 0
smoothSolver:  Solving for k, Initial residual = 1.12936e-17, Final residual = 1.12936e-17, No Iterations 0

So... suggestions?

mad

[maddalena]

Hi,
I opened a new thread on the subject: http://www.cfd-online.com/Forums/ope...flow-rate.html.
However, you are my two gurus on the closed loop pipe flow subject and your opinion is important... What do you think about the approach described there?

mad

[maddalena]

Hello FOAMers,
I need one more suggestion on the turbulence model.
As I said before, for the case I am simulating:

Originally Posted by maddalena

low-Re with no wall function are suggested. However, I can use low-Re with wall function for k and epsilon -> nut set as nutLowReWallFunction, k as kqRWallFunction and epsilon as epsilonWallFunction

In order to crosscheck if this is correct, I calculated y+ at the last time step. Since I am using a low-Re + wallFunction, y+ can be y+>1. What I get is:

Patch 35 named xxx y+ : min: 0.636791 max: 4.52537 average: 1.14473

This is the smallest pipe, which is the one I am interested more. I think that these values can be ok, but not completely sure. May I have your opinion on that?
cheers,

mad

[Sylvain]

Hi everybody,

Nice thread again madalena. I'm currently working on modeling a closed loop circuit with both a fan and a porous zone (actually an heat exchanger).

To do that I used simpleFoam k-omega SST model, a fan BC, and the brand new porousBafflePressure BC. This is something I used to do in Fluent, and I try to do it on OpenFOAM now.

I succeeded in making the whole mesh with SHM and the createBaffle utility (and I'm quite proud of it).

I have ran the simulation with only the fan, worked well except that the wake of the fan didn't converge... but still the flow looks OK. When I added the porous baffle, then it became a mess. The case explodes at the tenth iteration.

From what I have read in your thread i think about many ways of improving my case:

1) maybe switch from simpleFoam to another solver, maybe a transient one like pimpleFoam (this is the solver used for the fan tutorial actually)

2) adjust schemes constants like you did, but i have to admit I'm not comfortable with that, so is it worth playing with it???

3) maybe splitting my case in such a way that my fan is no longer a baffle but a distinct inlet and an outlet with classical inlet/outlet BCs

What do you think about it? I'm wondering if those cases are naturally instables due to the closure of the circuit....

Thanks ahead for your remarks about this subject...

Sylvain