Divergence only by lengthening of simulated geometry, buoyantPimpleFoam
Hi guys! I am totally new to this forums, and am looking for some input on a matter of simulating purely buoyancy-driven flow.
I have a model of a vertical pipe with inversely stratified water, the interface being in the centre. The top water is 370 K and the bottom is 470 K. I have used NIST to produce my own polynomials for water properties. The pressure is 7 MPa, and I am absolutely certain the polynomials are valid outside of my temperature interval. The solver is buoyantPimpleFoam, so that heat transfer is also modeled. So when relaxed, the water should mix by buoyancy forces. My 250 cm long pipe with 20 cm diameter doesn't diverge, but multiplying the length by 8 (and thus also the number of cells) does. The pressure field reaches 1001 iterations in every time step, and after about 0.9 seconds the residual is too great. Any other parameter is solved for in 1 iteration. It is apparent to me that most probably the buoyancy forces become too great, and the vast acceleration of the fluid parcels simply make the physics problematic. I myself understand the physics and fluid mechanics, and recieved help from a teacher in setting the numerics, e.g. correctors and relaxation, etc. My only set boundary conditions except zeroGradient in temperature, and no-slip in U, is 7 MPa pressure on top, and fixedFluxPressure on the walls. I have set nOuterCorrectors to 3, and nonOrthogonalCorrectors 0 (changing the latter didn't make a difference, I found). I have a relaxation factor of 0.5 for all parameters. in controlDict i juse adjustable time steps, with a maximum Co of 0.5. With 8 CPUs, I simply decompose the pipe vertically and solve in parallel. Other than the lengthening, the model is completely identical to the one that did not diverge. QUESTION: Is there any way to make this model work, other than refining the mesh so much that it becomes unpractical to finish the simulation within reasonable times? I am running the finer mesh now (3 million cells), but so far there are only slightly lower residuals in p_rgh. (I am validating the model against an experiment, so I need at least 150 seconds of the simulations. With 8 CPU's at hand, that time is precious to my project.) Thank you for any input |
Also, I have k-epsilon turbulence, RASmodel and blockMesh. I have temporarily doubled the maxIter for p_rgh, to see how that goes.
|
I think it would help if you could post you boundary conditions here (the files in the "0" directory). And also the files in the system directory.
|
Hi Carl-Magnus,
Welcome to the forums! I think this thread might help you http://www.cfd-online.com/Forums/ope...watertank.html Although the title says buoytantSimpleFoam they end up talking about the pimple version of the solver. One thing you could try is to force the dpdt term to zero as suggested here. Personally I have some doubts about using icoPolynomial with a compressible solver. In your case suspect one would have to develop a compressible version of icoPolynomial. If you attempt that then maybe this thread is of use http://www.cfd-online.com/Forums/ope...ion-state.html Best Regards Nicolas |
Quote:
Code:
Courant Number mean: 1.20916 max: 1.74202 Code:
// * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * // Code:
// * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * // Should I perhaps invest time in implementing the water property data libraries into my OpenFOAM distribution? (Don't recall the name of it, but XSteam utilizes it.) |
Quote:
Thank you for all advice, I will definitely look into it after lunch. BTW, look at the courant number (code in my post above) - can it not just be that my case has a too great buoyant force? Such a courant number can result from a sudden acceleration, right? I do not know how good the self-adjustable time stepping works in OpenFOAM, but I presume there are limitations. |
Hi,
My guess is that the high courant numbers are a symptom, not a cause. Although I have seen cases where the variable time stepping caused problems I don't think it's a problem for your case. However it's so easy to rule out. You could try with a fixed, small time step. Restart the solution from some time where the solution seems stable (maybe t=0.8) and see what happens. Quote:
/Nicolas |
Quote:
Yes, I also understand the courant number is a symptom. Thank you for confirming that the adjustable time step should be good enough! Since I have no written data due to the early divergence, I cannot restart it close to the point of divergence. But I will definitely re-run it for about 1.5 seconds, and write out every 0.1 seconds, to see if the physics are messed up. Thank you all for the kind feedback! I will hit you back with any updates. |
Perhaps I should also supply you with my blockMeshDict, although I would not hope it is the problem since I have lengthened a functioning mesh, without ruining the aspect ratio.
Code:
// * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * // |
Hi all,
I have now some written data on the divergence. This time it stopped at 0.8, again with a high Courant number. Code:
diagonal: Solving for rho, Initial residual = 0, Final residual = 0, No Iterations 0 http://s14.postimg.org/nnu704b75/Uma...Divergence.png greenshot screen capture Here is a picture of my mesh. I chose the weird design just to get a better aspect ratio of the cells. http://s30.postimg.org/573rsu901/cyl_Mesh.png how to do a screenshot on a pc I am preparing a fine mesh, and attempting to solve the coarse one from 0.8 s with a manually set, much smaller time step. |
Hi,
As i suspected, there was nothing wrong with the adjustable time step; even with the smallest manual stepping (1e-7 s) the simulation would not converge, starting from 0.8 s. Still > 1400 iterations for p_rgh. I am queuing running a simulation with easier properties; atmospheric pressure, thus more incompressible. Please give feedback if you see something problematic with my mesh; meshing is not my experienced side, but this one (above) seems nice enough for OpenFOAM to handle. Otherwise I will keep you posted on the progress with the fine mesh run. |
Hi,
Did you try setting dpdt off yet? I'm feeling quite confident that your case will run if you do so. I did try to implement a compressiblePolynomial. It's based on icoPolynomial but additionally a polynomial for the compressibility has to be entered. I tried it on the hot room tutorial, but even with compressibility added, it crashes. Both icoPolynomial and my compressiblePolynomial runs just fine when dpdt is turned off. The simulation will also diverge as soon as dpdt is turn on if initialized with dpdt off. I suspect that dpdt will diverge for incomressible liquids as a direct consequence of the definition of incompressible. I mentioned this here. Now how, one motivates that dpdt can be safely neglected is another thing. I suspect that the same thing is done in fluent. At least from what I understand of the theory manual. Good luck. Nicolas |
Quote:
Thanks for the heads up on that. When I now came to work, the "easier" simulation above mentioned had converged for 2 s, i.e. past the before time where it diverged. I will restart it now from 2 s; if it diverges, I will turn dpdt off. Next will also be to implement the water property libraries; I just recieved them from Roman. I also started two simulations of the actual case my work is focused on, which has a nicer aspect ratio (diameter 2 dm, height 2-3 m). They didn't diverge up to 150 seconds. This is good news, but I still need to validate my model against the nasty one. I will keep you posted on how the continued run goes - and thank you again for the great help. Best regards, Carl-Magnus |
Hi everyone;
Posting an update now as promised. My simulation is still running, coming up on its 11th second (in a week...). So, ehrm, this might take a while. Do you know if a maximum courant number larger than 0.5 would work? (That is kind of a default value I have used from tutorials and other models). Changing that would be the only way to speed up the simulation I believe. Other than that, thank you for all the help; hopefully the problem is now solved. I will still look into employing the property libraries, to make the physics nicer to the solver. Best regards, Carl-Magnus |
Hi,
I happy to hear it worked for you. Did you have to turn off dpdt or did it work with it switch on and varying density? You could get a simulation to "work" with high Co. By increasing the outer iterations and introducing under relaxation. (will this improve the speed of the simulation?). I've seen post in this forums of people running with max Co as high as 2-4. It's however difficult to say if it's a good idea. The best way to find out is to try. Why not try to run with Co > 0.5 and compare it to your present case? Just restart with a higher Co. Let it run for a day or two and compare. Was it faster? Did the solution change? Since you have a simple geometry you probably have high Co in large parts of the domain and any errors introduced by the high Co will affect a large part of the domain. And using high Cos is probably not the best approach. If that's not the case and you have high Co in just a few cells consider remeshing instead of running with high Co. Best Regards Nicolas |
Quote:
I changed the model to atmospheric pressure, and the polynomials as well. Then it became more incompressible, and icoPolynomial probably works better. The simulation is still in the most transient phase (10-20 s) where most accelerations occur. I may wait until monday before taking further measures; I would expect the water to slow down by then. Can I turn dpdt off while restarting, or will that mess things up? Otherwise, I will look into the Co and the property libraries to make things more realistic. Best regards, Carl |
Hi,
I don't think you can turn it off while running. Well maybe you can but it's not a good idea. As far as I understand the code, it will stop updating dpdt if you turn it off while the simulation is running. It won't reset dpdt=0. On the other hand, I don't think you need to restart in order to turn of dpdt. Just stop the simulation. /Nicolas |
All times are GMT -4. The time now is 08:51. |