chtMultiRegionSimpleFoam fails to solve cases without gravity
2 Attachment(s)
Dear all,
I am facing a rather peculiar problem with the chtMultiRegionSimpleFoam solver. I am interested in solving heat transfer from a solid to a fluid with a temperature dependent density, but would like to neglect buoyancy effects (for now). It seems, however, that the chtMultiRegionSimpleFoam solver is unable to solve the p_rgh equation correctly for cases where g = (0 0 0) and the (forced) velocity is low. The attached case (adapted from the planeWall2D tutorial case at OpenFOAMWiki) demonstrates the issue in a simplistic case of forced convection over a heated floor (see figure below). A bottomAir region will also be present in the solution, but can be ignored (it is not solved for). https://dl.dropboxusercontent.com/u/6518691/case.png The conjugate heat transfer causes a temperature gradient through the floor, and a thermal boundary layer in the fluid. The case solves as expected with the attached parameters where the inlet velocity is 10 m/s, but changing this value to 1 m/s (in the corresponding changeDictionaryDict) causes the solver iterations for the p_rgh equation to reach its maximum limit after a short time (here at iteration 389): Code:
Time = 388 I have tried experimenting with different combinations of boundary conditions and initializations, without success. OpenFOAM 2.2, 2.4.x and 3.0.x all cause the same behavior, so does the transient solver version chtMultiRegionFoam. The mesh is block-structured and generated by blockMesh. Comments and suggestions are highly appreciated. I also have some specific questions: - Could this be related to the way the SIMPLE algorithm is constructed? Could the issue be solved by using e.g. the SIMPLER algorithm instead and avoid solving the pressure correction equation? - My understanding of the OpenFOAM discretization is that p_rgh = p - rho*g*h_cell, such that setting g to zero should reduce the p_rgh equation to the p equation. Is this correct, or is the g*h term somehow still included in the equation system (through a momentum source term)? Best regards, Karl |
Hi Karl,
Have you tried not to give the value of 0 to the gravity but a very low one different from 0? Regards, Alex |
Alex,
Thank you for your reply! Setting g to a small nonzero value seems to be a solution; U_in = 1 m/s requires g = (0 0.01 0) to solve and U_in = 0.1 m/s requires g = (0 0.1 0) to solve. Do you have any insight into why this is the case? I have, for instance, noticed that the case diverges if gravity is applied in the x-direction rather than the y-direction (irrespective of magnitude). Could this be related? Best Regards, Karl UPDATE: The proposed solution does not always work. I'll try to post an updated case (heated channel flow) within the next days for further discussion. |
1 Attachment(s)
As mentioned in the previous post, setting g to a small nonzero value is not a general solution. Consider, for example, the attached case where only the fluid region is considered but an unheated starting length has been added. All other parameters are the same as the case above, but the p_rgh equation breaks down after about 250 iterations reaching a residual of just above 1e-4.
Any suggestions? Regards, Karl |
4 Attachment(s)
Greetings to all!
I haven't taken the time to fully diagnose the problem, but I've found the main issue. Everything can look very innocent until we start looking at the details ;). In this case:
Very well, let me briefly re-explain: simpleFoam solves the "kinematic pressure", instead of the actual pressure, because the density "rho" is constant. For air, this might seem innocuous, but for water with a "rho=1000", this means that there is somewhat of an inconsistency in the scales of values at play here. For example, rho=1000 versus U=1 can potentially lead to numerical errors a bit larger than if rho=1 versus U=1.
If we take a look at the tutorial case "heatTransfer/chtMultiRegionFoam/multiRegionLiquidHeater" in OpenFOAM 2.2.x:
The other possibility is to assume that when the pressure equation reaches this numerical precision, it could be considered as converged... although it doesn't feel like it in this case. And since residual controls don't work in multi-region cases, at least last time I checked: http://www.cfd-online.com/Forums/ope...implefoam.html - then this is not exactly the best option. There is another possibility, which is to rely on reducing the tolerance requested from "fvSolution" after several iterations. This can be achieved with the function object "timeActivatedFileUpdate": https://github.com/OpenFOAM/OpenFOAM...te/controlDict Best regards, Bruno |
1 Attachment(s)
Dear Bruno,
Thank you for your helpful diagnosis! That is indeed quite a big difference in magnitude between the pressure gradient and absolute value of pressure! Setting rho = constant, as in the tutorial you mention, is not an option in my application. Fortunately, OpenFOAM provides an "incompressible" version of the ideal gas law - incompressiblePerfectGas. I was not aware of this option since it's not used in any tutorial, but it allows the definition of a reference pressure to calculate density which is different from the pressure used in calculations. For completeness, I have attached a case that happily solves down to a residual of 1e-10 at U = 0.1 m/s. Best regards, Karl |
All times are GMT -4. The time now is 20:59. |