Law of the wall: komega vs. SpalartAllmaras (simpleFoam)
1 Attachment(s)
Hi everyone,
I'm new to OpenFOAM, and in preparation for a more complex simulation I'm currently working on evaluating some turbulence models on a simple mesh. I have a 2Dflow between two smooth noslip walls. Boundary conditions on inlet and outlet are periodic, except for a pressure jump. I'm using simpleFoam and tried out both komega SST and SpalartAllmaras turbulence models, with all default coefficients, and compared the results. This plot is for a mesh with a wall y+ of 0.5 (I get the same results using different mesh resolutions). Attachment 18471 I'm not sure what I'm supposed to get, but I figure the komega SST results are quite good, whereas the SpalartAllmaras results look unusable. The Spalart results can't be the way they're supposed to be, can they? I must be doing something wrong! Except for the nuTilda file, the settings are exactly the same, so here's my nuTilda file: Code:
dimensions [ 0 2 1 0 0 0 0 ]; Are there any other configuration files that I should post here? Thank you! EDIT: Btw, this is OF 2.1 
Hi MrFourier,
Do you find something? I have a similar problem Thanks for your help 
Hi Valentin,
Did you find something? Best Ye 
Hi.
As I am having trouble in making the SST run, could you please post the rest of your files for the setup? My solution does not converge and I cannot understand why. 
Anastasios what is the problem? Post your relevant settings.

Quote:
My settings are the following: Initial conditions for U Code:
dimensions [0 1 1 0 0 0 0]; Code:
dimensions [0 2 2 0 0 0 0]; Code:
dimensions [0 2 2 0 0 0 0]; Code:
Code:
dimensions [0 2 1 0 0 0 0]; Code:
solvers Code:
ddtSchemes With the above settings the solution converges but the values are strange; I have values in the flow field greater than the input velocity. 
Quote:
At your inlet you put in some constant velocity profile. Now, at the bottom wall a boundary layer develops with increasing size along the flow direction. In this boundary layer the velocity is low. But the mass flow through each vertical line (integrated) must be constant. Thus, if you have a lower velocity at the bottom you must get a higher value at some other places. 
Quote:

Does it work if you set inlet and outlet to zerogradient and the top wall to some fixed velocity value?

Quote:

2 Attachment(s)
Quote:
My main problem seems to be the pressure convergence. In both the very fine mesh (~2100000 cells) and the coarse presents a very oscillatory behavior. In the fine mesh after some iterations it seems to somehow blow up. Please find attached the residuals for both cases. I tried to reduced the order of the Laplacian but the same. 
1 Attachment(s)
Quote:

I would try to run it with gradient limiters. Go for
Code:
default cellMDLimited Gauss linear 1.0; In my experience, the convergence of the komegasst model strongly depends on the gradient limiters. 
Quote:
In any case, I solved the issue with the inaccuracy. FYI, the wallShearStress DOES NOT WORK FOR LOWRE GRIDS. Calculating u_tau with the wallGradU utility resulted in correct results. 
1) Did you deactivate ("//") the gradients for U and p and set all the gradients as I suggested?
2) Are you sure, you use the correct syntax for relaxation factors? I use them like http://www.openfoam.org/docs/user/fvSolution.php 
Quote:
If I use the gradscheme you propose for default, the result is convergence in higher values again with this small oscillation. I cannot understand why. At the moment I compromise with this as the results at least for the flat plate flow are satisfactory. To be honest I can understand the difference of the solver schemes, but I do not have the intuition. It is too mathematical for me and I have not been taught such advanced linear algebra topics. I will use some more complicated models and let you know. 
Can you upload the complete setup somewhere?

Quote:
I followed your advice and changed the gradient schemes. That behaved correctly. However, the most important issue for the accuracy results was to understand that the wallShearStress utility outputs in m2/s2, which is Pa/rho and not Pa. That was a big mistake which took me a lot to understand to be honest I hadn't paid attention. Thank you very much for your help anyway. 
All times are GMT 4. The time now is 13:54. 