[thedal]

This is a trial start to calculate yplus at all cell centers.

#include "udf.h"


real get_yplus(cell_t c, Thread* t, Domain* domain)
{
// Declaration
int count, thread_count;
real result, cell_x_value, face_x_value, nu, dist, utau, shear, test;
real cell_centroid[ND_ND];
real face_centroid[ND_ND];
Thread* ft;
face_t f;

shear = 1;
C_CENTROID(cell_centroid, c, t);
cell_x_value = cell_centroid[0];

printf("Cell Centroid: %g\n", cell_x_value);
thread_count = 1;
thread_loop_f(ft, domain)
{
printf("%d\n", thread_count);
if (THREAD_TYPE(ft) == THREAD_F_WALL)
{
count = 1;
shear = 2;
begin_f_loop(f, ft)
{

F_CENTROID(face_centroid, f, ft);
face_x_value = face_centroid[0];
if (cell_x_value == face_x_value)
{
shear = 3;
test = F_STORAGE_R(f,ft,SV_WALL_YPLUS_UTAU);
printf("%d \t %g\n", count, face_x_value);
break;
}
count += 1;
}
end_f_loop(f, ft)
}
thread_count += 1;
}

return shear;
// nu = C_MU_L(c, t)/C_R(c, t);
// dist = C_WALL_DIST(c, t);
// result = (utau*dist)/nu;
// return result;
}




DEFINE_ADJUST(yplus, domain)
{
Thread* t;
cell_t c;
face_t f;


/* Fill UDS with the variable. */
thread_loop_c(t, domain)
{
begin_c_loop(c, t)
{
C_UDSI(c, t, 0) = get_yplus(c, t, domain);
}
end_c_loop(c, t)
}


thread_loop_f(t, domain)
{
if (THREAD_STORAGE(t, SV_UDS_I(0)) != NULL)
{
begin_f_loop(f, t)
{
if (BOUNDARY_FACE_THREAD_P(t))
{
F_UDSI(f, t, 0) = 0;
}
else
{
F_UDSI(f, t, 0) = ((get_yplus(F_C0(f, t), THREAD_T0(t), domain) + get_yplus(F_C1(f, t), THREAD_T1(t), domain)) / 2);
}
}
end_f_loop(f, t)
}
}
}

This UDF returns 3 at certain cells and 2 at certain cells. Why is it so? Why is that cell centers with x values matching with some face-centers not matched at all cells?

[sbaffini]

Didn't actually read the code deeply but, do you understand why there isn't an y+ for all cells but only for near wall ones in most codes?

Is your geometry fully cartesian and flow homogeneous along x, like a channel, so that using the same x coordinate makes any sense to propagate y+ inside the domain?

If so, my suggestion is to do this in postprocessing instead of using Fluent UDF, as it requires a better understanding of UDF and the effort would be wasted, considering the limited applicability of your hypothesis... unless of course, you need it in a model at runtime; but then, maybe Fluent is not the best tool (altough, if needed, it can be done, you just need to debug your UDF better)