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:
However, increasing them, the pressure residual goes up and down and never reach convergence. this is my last simulated time output:
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

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,

Hi Alberto,
just to understand what I am doing...
I am used to to that... I misread fvSolution... :o
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!
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

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.

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.
This is always a good news... ;)
Yes, in that case the computational time is always higher.
Thank you!

mad

Hi maddalena,

This is the exact text from the UG:

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

I think i said the same think..:rolleyes:

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.

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

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,

Thank you to both of you for the suggestions!
Now I have this fvSolution:
The residual are not so low, but at the moment I think they are ok. Following the criterion suggested by Alberto, I have:
The simulation time is really high: about 2 minutes per iteration, using 2 processors (that are all the processors I can use... :o). 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:
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

Well, yes, the mesh needs love :-)

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

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

Hello,
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:
So... suggestions?

mad

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

Hello FOAMers,
I need one more suggestion on the turbulence model.
As I said before, for the case I am simulating:
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:
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

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