Define_dpm_drag udf
 

Hello,

I have a fundamental question, because I'm confused. In the UDF DEFINE_DPM_DRAG what value does the Fluent read? A drag coefficient Cd, which is then incorporated by the program to the force Fd=18μCdRe/(ρpDp^2 24), or the (18 Cd Re/24). Then in the second case what force does the program induce to the particles?

In Fluent manual it says the value returned by the UDF should be:

18*cd*Re/24

But in the example drag force UDF, the value returned is clearly not this. For example see the example code below in Fluent manual:

/************************************************** *********************
UDF for computing particle drag coefficient (18 Cd Re/24)
curve as suggested by R. Clift, J. R. Grace and M.E. Weber
"Bubbles, Drops, and Particles" (1978)
************************************************** **********************/

#include "udf.h"

DEFINE_DPM_DRAG(particle_drag_force, Re, p)
{
real w, drag_force;

if (Re < 0.01)
{
drag_force=18.0;
return (drag_force);
}
else if (Re < 20.0)
{
w = log10(Re);
drag_force = 18.0 + 2.367*pow(Re,0.82-0.05*w) ;
return (drag_force);
}
else
/* Note: suggested valid range 20 < Re < 260 */
{
drag_force = 18.0 + 3.483*pow(Re,0.6305) ;
return (drag_force);
}
}

In Fluent manual it says: The value returned to the solver must be dimensionless and represent 18 * Cd * Re / 24.

There is no 18*cd*Re/24 term in the above code.

Can any one please explain why they mentioned it in the manual but do not use it in the example code?

Thank you.

The Fluent manual says the return value should represent 18 * Cd * Re / 24. That does not mean that you have to calculate this explicitly, that is why you don't see it in the code.

If you have a simulation in which you want 18*Cd*Re/24=1, then your UDF should return 1.

The UDF that you quoted calculated (for Re>20) 18*Cd*Re/24 = 18.0 + 3.483*pow(Re,0.6305).

Thank you for your reply. So If I know the drag coefficient as a function of Reynolds number, which is almost always the case, I just multiply that with 18 Re/24 to feed it to Fluent to compute drag force. For example, using well known Morsi and Alexander (1972) correlations for computing drag on a sphere this would be correct, with cd being drag coefficient:

if(Re<0.1){

cd=24.0/Re;
drag_force=18*cd*Re/24;

}else if(Re>0.1 && Re<1.0){


cd=22.73/Re+0.0903/(pow(Re,2))+3.69;
drag_force=18*cd*Re/24;

}else if(Re>1.0 && Re<10){

cd=29.1667/Re-3.1889/(pow(Re,2))+1.222;
drag_force=18*cd*Re/24;

}else if(Re>10 && Re<100){

cd=46.5/Re-116.67/(pow(Re,2))+0.6167;
drag_force=18*cd*Re/24;

}else if(Re>100 && Re<1000){

cd=98.33/Re-2778.0/(pow(Re,2))+0.3644;
drag_force=18*cd*Re/24;

}else if(Re>1000 && Re<5000){

cd=148.62/Re-4.75e-4/(pow(Re,2))+0.357;
drag_force=18*cd*Re/24;

}else if(Re>5000 && Re<10000){

cd=-490.546/Re+57.87e4/(pow(Re,2))+0.46;
drag_force=18*cd*Re/24;

}else if(Re>10000 && Re<50000){

cd=-1662.5/Re+5.4167e6/(pow(Re,2))+0.5191;
drag_force=18*cd*Re/24;

}

return(drag_force);

I agree with Pakk.
One thing to note is that Cd tends towards (24/Re) at low values of Re, so (Cd*Re/24) tends towards 1. This is why you see return values of 18.0 or (18.0 + other stuff) in the example.
Some comments on your example:
1) Why not move the repeated line "drag_force=18*cd*Re/24" outside the if... block, so you only need to see it once, and you can tell without checking that it applies to all branches?
2) I would stop using the example's variable name "drag_force", which is unhelpful.
3) This is a serious point: look what happens when Re is exactly 1.0 (for example)! None of the if()...else()... tests are satisfied, so you get a zero answer (I think). MUCH better to use "if(Re<0.1){...}else if(Re<1.0){...}". Exact values are presumably rare in practice, but then what about Re>=50000? Better to put in explicit behaviour here -- possibly zero -- rather than rely on obscure C features like zero initialization.