udf access violation
 

Hi all!

So I'm new to this UDF thing, trying to debug a friends discrete particle UDF. Got everything compiled fine and dandy, but when I try to display the particle tracks I get an error, fl1450s.exe received fatal signal (ACCESS_VIOLATION)

I looked at other posts, it seems (and correct me if I'm wrong) that this probably means that one of the queried variables is not currently being retrieved by the solver, but I don't know which bits in the code are qureying variables, so I don't know how to confirm this

Also apparently this was working fine back in 2010 on what would probably have been fluent 11 or 12, I'm using 14.5, maybe there's a change in syntax between the versions?

any pointers would be much appreciated!

As you've already figured it out, you are asking the solver for something which is not there. So, if you can please tell the whole story of what this UDF does (or is supposed to do) and maybe share it here, we can see where the problem is coming from.
since it's happened to me several times (and of course it is a silly one!), you might wanna check it out. Sometimes you've got the UDF hooked to the solver, but you don't have it in the correct location relative to the case and data files. Make sure the .c file is there and you haven't read it from some other locations.
Cheers!

the c files are in the same folder as the cas and dat files, and I haven't moved any of them since they were compiled so that should be okay yeah? the udf is to improve on the brownian motion force component for the lagrangian particle tracking module. Here is the code:

#include "udf.h"
#include "dpm.h"
#include "surf.h"
#include "random.h"
#include "sg_mphase.h"
#include "stdio.h"


#define ID_wall 3
#define vel_wall 0.0

Thread *thread_wall;
int flag=0;//0 unchanged, 1 changed
real vel_temp[ND_ND];
Thread *t_temp;
cell_t c_temp;//to make sure that the velocity of fluid unchanged


DEFINE_DPM_SCALAR_UPDATE(Near_wall_interpolation, c, t, initialize, p)
{

double dis_p_cell=0.0;
double dis_p_wall=0.0;
double dis_center_p=0.0;
double x_fluid[ND_ND];


real FC[ND_ND];
real XX[ND_ND];
real sum_top[ND_ND];
real sum_btm=0.0;
face_t f_wall;
face_t f_c_particle;
Thread *tf_t_particle;
int n;
int i;

///////////////particle////////////////

cell_t c_particle = RP_CELL(&(p->cCell));
Thread *t_particle = RP_THREAD(&(p->cCell));


if(flag==0)
{
//continue;
}
else
{
C_U(c_temp, t_temp)=vel_temp[0];
C_V(c_temp, t_temp)=vel_temp[1];
C_W(c_temp, t_temp)=vel_temp[2];
}

for ( i=0;i<ND_ND;i++)
{
sum_top[i]=0.0;
x_fluid[i]=0.0;
FC[i]=0.0;
XX[i]=0.0;

}

C_CENTROID(x_fluid, c_particle, t_particle);
/* CX_Message("x_fluid[0]=%f\n",x_fluid[0]);
CX_Message("x_fluid[1]=%f\n",x_fluid[1]);
CX_Message("x_fluid[2]=%f\n",x_fluid[2]);*/


dis_p_cell=sqrt(pow( (P_POS(p)[0]-x_fluid[0]),2)+pow( (P_POS(p)[1]-x_fluid[1]),2)+pow( (P_POS(p)[2]-x_fluid[2]),2));
///////////////boundary_wall////////////////

//printf("dis_p_cell=%d",dis_p_cell);
/* CX_Message("c_particle=%d\n",c_particle);
CX_Message("t_particle=%d\n",t_particle);
CX_Message("x_fluid[0]=%f\n",x_fluid[0]);
CX_Message("x_fluid[1]=%f\n",x_fluid[1]);
CX_Message("x_fluid[2]=%f\n",x_fluid[2]);
CX_Message("dis_p_cell=%.15f\n",dis_p_cell);*/

// t_wall = Lookup_Thread(domain, ID_wall);
//printf("t_wall=%d",t_wall);

begin_f_loop(f_wall, thread_wall)

{

if (F_C0(f_wall,thread_wall)==c_particle)//the particle is adjacent to the wall
{
flag=1;
c_temp=c_particle;
t_temp=t_particle;
vel_temp[0]=C_U(c_particle,t_particle);
vel_temp[1]=C_V(c_particle,t_particle);
vel_temp[2]=C_W(c_particle,t_particle);


c_face_loop(c_particle,t_particle,n)//get the cells around the cell where the particle is in.
{
f_c_particle=C_FACE(c_particle,t_particle,n);
tf_t_particle=C_FACE_THREAD(c_particle,t_particle, n);
if(tf_t_particle!=thread_wall)
{
C_CENTROID(XX, F_C0(f_c_particle,tf_t_particle), THREAD_T0(tf_t_particle));//???which thread?
dis_center_p=sqrt(pow( (P_POS(p)[0]-XX[0]),2)+pow( (P_POS(p)[1]-XX[1]),2)+pow( (P_POS(p)[2]-XX[2]),2));

sum_top[0]=sum_top[0]+C_U(F_C0(f_c_particle,tf_t_particle), THREAD_T0(tf_t_particle))/dis_center_p;
sum_top[1]=sum_top[1]+C_V(F_C0(f_c_particle,tf_t_particle), THREAD_T0(tf_t_particle))/dis_center_p;
sum_top[2]=sum_top[2]+C_W(F_C0(f_c_particle,tf_t_particle), THREAD_T0(tf_t_particle))/dis_center_p;

sum_btm=sum_btm+1.0/dis_center_p;
}
else
{
F_CENTROID(FC, f_wall, thread_wall);
dis_p_wall=sqrt(pow( (P_POS(p)[0]-FC[0]),2)+pow( (P_POS(p)[1]-FC[1]),2)+pow( (P_POS(p)[2]-FC[2]),2));
sum_top[0]=sum_top[0]+C_U(f_wall, thread_wall)/dis_p_wall;
sum_top[1]=sum_top[1]+C_V(f_wall, thread_wall)/dis_p_wall;
sum_top[2]=sum_top[2]+C_W(f_wall, thread_wall)/dis_p_wall;
sum_btm=sum_btm+1.0/dis_p_wall;
}
}
/* F_CENTROID(FC, f_wall, thread_wall);
dis_p_wall=sqrt(pow( (P_POS(p)[0]-FC[0]),2)+pow( (P_POS(p)[1]-FC[1]),2)+pow( (P_POS(p)[2]-FC[2]),2));

C_U(c_particle,t_particle)=(C_U(c_particle,t_parti cle)*dis_p_wall+vel_wall*dis_p_cell)/(dis_p_cell+dis_p_wall);
C_V(c_particle,t_particle)=(C_V(c_particle,t_parti cle)*dis_p_wall+vel_wall*dis_p_cell)/(dis_p_cell+dis_p_wall);
C_W(c_particle,t_particle)=(C_W(c_particle,t_parti cle)*dis_p_wall+vel_wall*dis_p_cell)/(dis_p_cell+dis_p_wall);
*/

C_U(c_particle,t_particle)=sum_top[0]/sum_btm;
C_V(c_particle,t_particle)=sum_top[1]/sum_btm;
C_W(c_particle,t_particle)=sum_top[2]/sum_btm;


/*CX_Message("C_U(c_particle,t_particle)=%.20f ",C_U(c_particle,t_particle));
CX_Message("C_V(c_particle,t_particle)=%.20f ",C_V(c_particle,t_particle));
CX_Message("C_W(c_particle,t_particle)=%.20f\n",C_ W(c_particle,t_particle));
*/
break;
}
else
{
flag=0;
}

//CX_Message("x-coord = %f y-coord = %f z-coord = %f\n", FC[0], FC[1],FC[2]);
}
end_f_loop(f_wall, thread_wall)
}


/* domain passed to Adjust function is mixture domain for multiphase*/
DEFINE_ON_DEMAND(zk)
{
Domain *domain;
domain=Get_Domain(1);//1 return fluid domain pointer(domain pointer using get_domain)
thread_wall = Lookup_Thread(domain, ID_wall);
}

thanks in advance!

About the .c being inside case&data files, i think that's fine.
I've gone through your code a few times. Things look alright, the only point I cannot figure out is that you've defined an integer "n" (two lines above /////particles/////) and then you are using it to loop through the cells with particles. But I cannot find where you assign any values for the "n" and actually I am not sure if this is something coming from the solver. Might not be the problem but worth a shot!

Hey Sun, thanks heaps for taking the time to help me with this problem, in relation to the integer n, I found this:

3.3.5. Looping Over Faces of a Cell (c_face_loop)

The following looping function loops over all faces of a given cell. It consists of a single loop statement, followed by the action to be taken in braces.

cell_t c;
Thread *t;
face_t f;
Thread *tf;
int n;
c_face_loop(c, t, n) /* loops over all faces of a cell */
{
.
.
.
f = C_FACE(c,t,n);
tf = C_FACE_THREAD(c,t,n);
.
.
.
}
The argument n is the local face index number. The local face index number is used in the C_FACE macro to obtain the global face number (for example, f = C_FACE(c,t,n)).

Which seems to explain the int n.

int n does, however, appear in the code that I am debugging before the c_face_loop function, and I don't know if this could be creating problems?

there are several times it appears in a form like CX_Message("c_particle=%d\n",c_particle);
however whether or not in these instances it will pick up on the value assigned to int n in the c_face_loop I don't know (my knowledge of c is very limited). I am going to try and track down the original author of the code and pick his brain as well. Will keep you posted!

Thanks Again!!!

Sean, thanks for the update and I'd be interested to know if you find out the problem. please keep me posted.

I am not sure, though, what you meant by:
One more thing C_FACE macro is defined in mem.h header. Add this line at the top

Hey Sun, I tried including the mem.h header, but the same problem is arising. Is it possible that the issue is arising due to a variation in the syntax requirements between versions of fluent? if so do you know if there is a change log publicly available for the syntaxes between versions?

thanks

Sean

Hey, sorry for this very late reply! As far as I know i don't think the problem is because of variation in syntax. Basically, a UDF is a piece of C code and if there is any updates/changes in C syntax, a modification will happen in the corresponding UDF as well. This is, though, my personal opinion, NOT necessarily a fact!
In any case have a look at this PDF file summarizing some commonly-used syntax in UDF writing.

Hey seanread,

did you find a solution for your problem?
Or can you explain me the meaning of that integer in the c_face_loop? I am facing a similar problem with that integer because I dont really understand how I can use the macro itself