|
[Sponsors] |
Correct the value of Velocity gradient at wall iteratively |
|
LinkBack | Thread Tools | Search this Thread | Display Modes |
May 17, 2020, 22:31 |
Correct the value of Velocity gradient at wall iteratively
|
#1 |
Member
Abhinand
Join Date: Jun 2016
Posts: 75
Rep Power: 9 |
Hi,
I have a problem where I simulate a flat plate boundary layer with no slip condition at the wall. I calculate the value of wall shear iteratively and I need it to update to the solution. I cannot put an UDF at the wall since it will change the boundary condition from no-slip. The velocity at the wall still stays at 0. I want a way to update the dU/Dy a the wall without changing the value of wall velocity from zero (meaning it has to change the value of velocity of node adjacent to wall) Thank you |
|
May 18, 2020, 03:58 |
Wall shear and no-slip
|
#2 | |
Senior Member
|
What is implied by
Quote:
__________________
Regards, Vinerm PM to be used if and only if you do not want something to be shared publicly. PM is considered to be of the least priority. |
||
May 18, 2020, 17:11 |
|
#3 | |
Member
Abhinand
Join Date: Jun 2016
Posts: 75
Rep Power: 9 |
Quote:
My problem statement is correcting the gradient for a pretty coarse grid where I know that the value computed using fluent is wrong. Fluent calculates the value of the velocity of the node next to the wall using the gradient computed at the wall right? And the wall shear is calculated using the gradient at the wall. I want to find a way where fluent accepts the new value of gradient of the wall from the user and uses the new value to calculate the next iteration. Can you explain how I'm overconstraining the solver. If you can explain what variables I'm overconstraining I can fix that by giving the correct values accordingly when I need to change the gradient. Thanks Last edited by Abhinand; May 18, 2020 at 19:05. |
||
May 19, 2020, 08:02 |
Velocity Gradient and Shear Stress
|
#4 |
Senior Member
|
Why do you think that the velocity field calculated by Fluent is wrong? Is it because the mesh is very very coarse? What is the value and which wall treatment are you using?
Fluent does not calculate velocity from its gradient, rather, it is the other way around. Flow equations are solved for velocity and not for gradient. Gradient calculation is done using the flow-field. As far as velocity field near the wall is concerned, it is either resolved or modeled using wall treatments, such as, standard wall function. If you wish to apply gradient, then, you can simply apply it by changing the condition from no-slip to specified shear. However, that would imply some slip. The theory of boundary layer is that flow within the boundary layer is lesser than that in the core for same area because velocity at the surface is 0 and within the boundary layer it increases from 0 to some finite value. If you maintain 0 velocity at the wall, which is no-slip and accurate, and also specify the velocity gradient, i.e., the thickness of boundary layer and momentum displacement thickness, then you will not be able to maintain conservation of mass and momentum since a certain amount of mass and momentum must pass through the boundary layer. And this depends on Re number. Ultimately, this would lead to a boundary layer profile that is predicted by wall functions or resolved by Fluent. If you want to apply a gradient and no-slip, you can use a UDF that applies 0 velocity at the wall and a velocity based on your own gradient calculation at the first cell center. But do prepare for divergence and non-conservation issues.
__________________
Regards, Vinerm PM to be used if and only if you do not want something to be shared publicly. PM is considered to be of the least priority. |
|
May 20, 2020, 13:37 |
|
#5 |
Member
Abhinand
Join Date: Jun 2016
Posts: 75
Rep Power: 9 |
Vinerm,
Thanks for you reply. Yes I do believe the velocity field is wrong coz I'm working with a very coarse mesh and I want to correct it. If my understanding is correct, you are saying if I can affect the gradient at the wall by changing the velocity at the first cell center? Is it correct to assume that changes to values of fluent variables should be done only to cell centres and not node values coz the gradient using least square uses cell center values? I want to eventually improve the wall shear for a coarse mesh by changing the gradient. And you said the wall functions might also work with that which might produce divergence issues. Is there a way where I can specify just the gradient at the wall and fluent just uses the value given by UDF and then starts computing the solution ignoring the wall functions? |
|
May 20, 2020, 13:57 |
Gradient at the Wall
|
#6 |
Senior Member
|
If you want to specify gradient at the wall, then that is straightforward; just apply shear stress after selecting Specified Shear condition. However, this will only maintain shear and not no-slip. Why are you using a coarse mesh? And how coarse is it?
__________________
Regards, Vinerm PM to be used if and only if you do not want something to be shared publicly. PM is considered to be of the least priority. |
|
May 20, 2020, 20:32 |
|
#7 |
Member
Abhinand
Join Date: Jun 2016
Posts: 75
Rep Power: 9 |
I do not want to use specified shear as a boundary condition coz it changes the flow completely. My aim is to improve a coarse mesh and that's the reason I want to correct the velocity gradient which directly affects the wall shear. If I can find a way to decouple or force fluent not to use wall functions, then my problem will not be overconstrained right?
Is there a way to do that? My mesh is pretty coarse and I'm sure it does not give a good solution |
|
May 21, 2020, 07:41 |
Gradient at the Wall
|
#8 |
Senior Member
|
Specified Shear is same as wall gradient, except that it is multiplied by the viscosity of the fluid. There is at least one way to disable wall-function; use a UDF for wall function and, actually, you can use that UDF to implement what you want to implement. Keep no-slip at the wall and use DEFINE_WALL_FUNCTIONS to apply a gradient.
__________________
Regards, Vinerm PM to be used if and only if you do not want something to be shared publicly. PM is considered to be of the least priority. |
|
May 21, 2020, 14:05 |
|
#9 | |
Member
Abhinand
Join Date: Jun 2016
Posts: 75
Rep Power: 9 |
Quote:
Thanks |
||
May 21, 2020, 14:19 |
Rsm
|
#10 |
Senior Member
|
If you are using RSM, then you cannot use UDF for wall function. UDF can be used only with . However, if you are using RSM then it would be very difficult to apply gradient as well since the turbulence is anisotropic. You cannot use simple equation to apply gradient.
__________________
Regards, Vinerm PM to be used if and only if you do not want something to be shared publicly. PM is considered to be of the least priority. |
|
May 21, 2020, 14:49 |
|
#11 | |
Member
Abhinand
Join Date: Jun 2016
Posts: 75
Rep Power: 9 |
Quote:
If we are using a define adjust to alter the velocity such that the gradient of velocity is in turn affected, what is the best way to change it. Does fluent calculate using cell centre values or node values? I was under the impression that define adjust should not be done to node values since node values are as a result of calculation from the cell centre values. Thank you |
||
May 21, 2020, 16:26 |
Velocity adjustment
|
#12 |
Senior Member
|
Fluent solves at cell centers, so, it is only by changing the values at the cell center would you be able to affect the solution. However, DEFINE_ADJUST is executed before every iteration, i.e., whatever changes you make will be lost since the immediately followed flow iteration will update the solution. So, one solution to do this is as follows.
1. Separate out the region that contains first cell adjacent to the wall. Make it a separate cell zone. 2. Within this cell zone, fix the velocities. Once fixed, Fluent will not solve flow in this cell zone but would expect the flow velocities to be given by user. 3. For fixed velocities, use DEFINE_PROFILE function and define the velocities at the cell centers. I don't guarantee that this method will work but it might. A more sophisticated solution would be to change the coefficients of the matrix such that the solution achieved is as per your requirement. But this requires knowledge of discretization schemes and possibly even multigrid. It is quite possible that there is some straightforward solution for this, such as, by applying the DEFINE_PROFILE at the wall and using that function to set velocity at the wall to 0 (for no-slip), also using the same function to change velocity at the centers of the adjacent cells, and set the matrix coefficients in the adjacent cells such that Fluent does not update the solution in those cells while iterating, such as, by modifying value of URF to 0 only in the cells adjacent to the boundary.
__________________
Regards, Vinerm PM to be used if and only if you do not want something to be shared publicly. PM is considered to be of the least priority. |
|
May 27, 2020, 12:36 |
|
#13 | |
Member
Abhinand
Join Date: Jun 2016
Posts: 75
Rep Power: 9 |
Quote:
Moreover if I find the cell centre velocities adjacent to wall, it is by intuition and obvious it's non-zero. I don't follow why DEFINE_ADJUST cannot help? In the manual it says define adjust is also one way to alter a solution right. So what you say works by overwriting, we cannot do any kind of manipulation to the solution through define adjust and wouldn't it be a waste, since the only possible way of changing the solution is a writing a UDF for define profile for each boundary face? For splitting into two cell zones Do you mean separating the grid into two domains such that I get two domains or cell zones in my cell zone interfaces? I've seen from my previous simulations that when I split a grid into two parts there would be 3 cell zones with one zone as the interface joining the two other parts (like a line) Can you explain a little bit more why and how to proceed this way? Thank you |
||
May 27, 2020, 13:08 |
Define_profile
|
#14 |
Senior Member
|
You can use DEFINE_ADJUST or DEFINE_PROFILE, however, DEFINE_PROFILE makes it easier to access the cells adjacent to the wall since it already provides access to the wall faces where you need to set no-slip condition. Furthermore, single function will set both, no-slip as well as gradient. Since you want to apply your own formulation for gradient, and you know that the velocity at the wall is 0, you can calculate the velocity at the center of the adjacent cell using definition of gradient, i.e., ratio of velocity at the cell center and the distance of the cell center from the wall.
Whether you use DEFINE_PROFILE or DEFINE_ADJUST, Fluent will overwrite the cell center values based on the current solution. Since the field is solved at the centers of the cells, there is no modification done at the face centers of the external boundaries. Therefore, user can and has to provide values at the face centers of the external boundaries. But values at the cell centers are always solved by Fluent. So, if you don't want Fluent to update the velocities at the centers of the first cell layer from the wall, you need to separate it out from the rest of the domain. When a cell zone is separated into two or more cell zones, Fluent does not create interfaces. It creates interior and user does not need to do anything with that.
__________________
Regards, Vinerm PM to be used if and only if you do not want something to be shared publicly. PM is considered to be of the least priority. |
|
|
|
Similar Threads | ||||
Thread | Thread Starter | Forum | Replies | Last Post |
UDF for suction velocity on a wall | ahmed425 | Fluent UDF and Scheme Programming | 0 | November 2, 2017 09:50 |
velocity BC for pourous wall (pressure dependendend darcy law) | StefanW | OpenFOAM Running, Solving & CFD | 1 | May 29, 2017 07:53 |
A new wall function based on the velocity field----strange result | huangxianbei | OpenFOAM Programming & Development | 6 | September 30, 2015 07:52 |
Radiation interface | hinca | CFX | 15 | January 26, 2014 17:11 |
Errors running allwmake in OpenFOAM141dev with WM_COMPILE_OPTION%3ddebug | unoder | OpenFOAM Installation | 11 | January 30, 2008 20:30 |