A new wall function based on the velocity field----strange result
2 Attachment(s)
Hi,all:
Recently, I was implementing a new type of wall function into OF based velocity. As done in OF, the wall function is implemented based on nut or nuSgs for eddy viscosity. While for non-linear model, it's not applicable. Instead, it is needed to implement a wall function based on velocity so that it is more general. As in wall function theory, the tangential velocity is modified, the idea is to devide the velocity into the wall-normal velocity and tangential velocity: U=Uver+Ut the wall-normal velocity can be obtained by: Code:
const vectorField wallnormal=U.snGrad()/max(mag(U.snGrad()),VSMALL); Code:
const vectorField wallnormal=patch.nf(); Code:
const vectorField Ut=(U-Uver)/max(mag(U-Uver),VSMALL); Code:
const vectorField patchnormal=-patch().Sf()/patch().magSf(); y>11, u+=ln(Ey+)/K y<=11,u+=y+ Code:
if (yplus>11) Does anyone have any idea? here is the code: Attachment 41875 Attachment 41876 Xianbei |
Another problem I'm facing is the way I calculate the wallshearstress used for yplus calculation. In my code, the magnitude of wallshearstress vector is used, while if I change it to:
Ut&wallshearstress to get the tangential component of wallshearstress, then the calculation break down:eek: I don't know how do this occur!! edit1: this is due to that the wallshearstress may be 0 and sqrt(0) is not allowed.However, the result is not correct. Does anyone have similar experience? |
Well, I found that it may be not possible to implement such a wall function in OF because that the boundary field of U would not correct during the calculation. Therefore, no matter how I change the formulation of Uw, the result is not affected. So it would only be possible to modify the SGS stress just like the process in nuSgsUSpaldingWallFunction.
Another problem is that the gradient operation can be used as following: Code:
const fvPatchVectorField& U = lesModel.U().boundaryField()[patchi]; Edit 1:solved, use "fvc:;grad(lesModel.U())" |
Hi, all:
After further investigation, I found that the reason why wall function on U got incorrect result was that the field never changed! Here is two steps of the calculations: case1: without wall function: Code:
Time = 0.2 Code:
Time = 0.2 That means the boundary field is not modified during the calculation when wall function is applied! How can I make it take effect during the calculation? In the code, fixedValueFvPatchVectorField::evaluate() is called. In the description, this function is to evaluate the patch field. How can it be that the patch field is not changed??? Any idea is welcome! Xianbei |
As U.correctBoundaryConditions() is called in the solver, it's strange that U is not corrected. The correctBoundaryConditions is explained here, it will call the evaluate() function in the boundary condition applied. So in my code, U.correctBoundaryConditions() should call evaluate() and correct the velocity field, however, no change is seen.
|
Quote:
I read your thread and I know what you research is about DNS, and so do I, Now I face a hard question is that how do calculate y+ in DNS,you know there is no any codes about calculating y+ in DNS. I saw your answer in other thread about y+ about DNS,but you didn't show how,Can you show me? my email is : tzqfly2009@163.com |
Quote:
For a DNS calculation , a simple way to achieve this is using the velocity gradient. If the mesh is fine, you can use gradU=u1/y1, here, 1 represents the value at the first node near-wall. tau_wall=nu*gradU, u_tau=sqrt(tau_wall), so you can calculate the y+ Xianbei |
All times are GMT -4. The time now is 06:44. |