Compressible epsilon blows up
2 Attachment(s)
Hi All,
I'm simulating a conjugate heat transfer across a flat plate in a rectangular channel. I modified the multiRegionHeater tutorial in OF 1.7.0, and used k-epsilon turbulence model. The Case geometry setup is shown in the attached PNG file. Basically, the top and bottom air is turbulent (Re ~ 10^6). The top air is hot at 746K, while the bottom air is cold at 288K. The two flow regions are separated by a solid plate. I ran the case with realizableKE model, and the simulation blew up after 38 iterations. Here is the last few iterations before it blowing up: Code:
Time = 36 I have attached the /system and /constant files. The case ran well with KwSST model. Thank you in advance. Best Regards, Stefano Attachment 5083 Attachment 5084 |
Hi Stefano
did you try to switch to another div scheme for epsilon? You are using different Schemes in top and bottom air. My suggestion is, try in the limtedUpwind scheme, that you are using in the bottom area or a limitedLinear scheme. You also can dry to reduce the relaxtionFactors for epsilon to 0.5. Regards |
Hi Friedrich,
Thank you for your reply. Quote:
Quote:
It returns the following error: Code:
[1] --> FOAM FATAL IO ERROR: I found the following schemes ran: Code:
divSchemes After about 50 iterations, the simulation blew up again. Epsilon reached -4839598, and k reached -3402. Temperature and rho on bottom air also reached unrealistic extremes. The weird thing is that the top air and solid seems okay. Here is the extract of the last iteration: Code:
Time = 53 It's getting pretty desperate here. Best Regards, Stefano |
Hi Stefano
how are your result with upwind? I know it's just 1st order and I also prefer higher order schemes, but it is stable. Can you please post you fvSchemes with the limited schemes, that is not working. I would like to take a look and understand why not. Maybe somebody with more experience can help you, until now I have no real new suggestion. |
Hi Friedrich,
My apologies for delay in responding to your post. The upwind result was not satisfactory when compared to Fluent. That is the reason I tried the 2nd order scheme. Quote:
Quote:
This is my fvSchemes that works: Code:
divSchemes The y+ for this model is up to 900. That is probably the reason of it blew up. I also had to put all under-relaxation factors to 0.1 for it to work. Even then, I had poor pressure convergence even after 4000 iterations! With OF, it is hard to distinguish if the problem is caused by improper BC setup, poor mesh or solver setup. I tried to eliminate the first two factors by using standard BC as everyone recommended and structured grid. Another thing, for compressible solver with high temperature, is it better to use fixedValue for velocity inlet or flowRateInletVelocity? The flowRateInletVelocity always gave the wrong inlet velocity when I tried it. Thank you very much for your help. I hope we can continue this discussion. Best Regards, Stefano |
Reg - Y+
Dear Stefano,
Could you please tell me what you mean by y+? I am not aware of it. Thank you Hari |
Reg - Y+
Dear all,
Could you please tell me what y+ mean ? I am not aware of it. Thank you Hari |
Hallo hariya03,
y+ is a dimensionless factor which is used by wall function to compute the velocities at the wall, i.e. the velocities are not obtained form a empirical mathematical model. See Versteeg. swahono, you set relaxation factor to 0.1: could you please tell me how your maxCo number is bounded. Moreover, could you post you fvSolution and fvSchemes and a cross section plot of your mesh. |
Reg - Y+
Thank you Mr.Claus,
I hope the Velocity at the wall will be zero. So May I know how it computes the velocity? Did in "versteeg " the same denotion were used sir? Thank you for your reply. Hari. |
1 Attachment(s)
Quote:
Quote:
Code:
solvers My Mesh is attached. I just used blockMesh. Quote:
- What Hari referred to was the use of "wall function" to compute the U, k and epsilon profiles near the wall (inside the boundary layer). This is based on the friction velocity , u*. Simply put, if your yPlus is small, means your first grid point is well within the boundary layer. Most wall function works between yPlus of 30 - 100. In SimpleFoam, pisoFoam, rhoSimpleFoam and rhoPisoFoam you can compute yPlus by using >> yPlusRAS This utility does not work with chtMultiRegionFoam without modification to the source code. I used Fluent to checked my yPlus in this case. If I have time I will try to modify the yPlusRAS to work with chtMultiRegionFoam. Best regards, Stefano |
Unfortunately, I didn't post you maxCo number, but I would recommended to reduce it a bit. But more dramatically, in you SIMPLE entries the keyword
nCorrectors does not appear. You should write, e.g. before nOrthogonalCorrectors, nCorrectors 5; Start with five is fine and then increasing or decreasing it accordingly. In your scheams directors you use limited 0.333 but nOrthogonalCorrestors is here set to zero. Do you have non-Ortho. cells? If yes then set nOrthogonalCorrectors 3; as starting point. In the run of the simulation you can adjust them accordingly. For now, that's all. Just post if stuck. |
All times are GMT -4. The time now is 21:39. |