CFD Online Logo CFD Online URL
www.cfd-online.com
[Sponsors]
Home > Forums > Software User Forums > ANSYS > FLUENT > Fluent UDF and Scheme Programming

udf access violation

Register Blogs Members List Search Today's Posts Mark Forums Read

Reply
 
LinkBack Thread Tools Search this Thread Display Modes
Old   September 2, 2014, 02:27
Question udf access violation
  #1
Member
 
sean read
Join Date: Sep 2014
Location: Melbourne, Australia
Posts: 41
Rep Power: 11
seanread is on a distinguished road
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!
seanread is offline   Reply With Quote

Old   September 2, 2014, 03:52
Default
  #2
Sun
Senior Member
 
Sun's Avatar
 
Join Date: Nov 2010
Posts: 103
Rep Power: 15
Sun is on a distinguished road
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!
Sun is offline   Reply With Quote

Old   September 2, 2014, 05:03
Default
  #3
Member
 
sean read
Join Date: Sep 2014
Location: Melbourne, Australia
Posts: 41
Rep Power: 11
seanread is on a distinguished road
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!
seanread is offline   Reply With Quote

Old   September 2, 2014, 18:00
Default
  #4
Sun
Senior Member
 
Sun's Avatar
 
Join Date: Nov 2010
Posts: 103
Rep Power: 15
Sun is on a distinguished road
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!
Sun is offline   Reply With Quote

Old   September 3, 2014, 21:37
Default
  #5
Member
 
sean read
Join Date: Sep 2014
Location: Melbourne, Australia
Posts: 41
Rep Power: 11
seanread is on a distinguished road
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!!!
seanread is offline   Reply With Quote

Old   September 4, 2014, 12:28
Default
  #6
Sun
Senior Member
 
Sun's Avatar
 
Join Date: Nov 2010
Posts: 103
Rep Power: 15
Sun is on a distinguished road
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:
Quote:
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).
One more thing C_FACE macro is defined in mem.h header. Add this line at the top
Code:
#include "mem.h"
Sun is offline   Reply With Quote

Old   September 8, 2014, 23:41
Default
  #7
Member
 
sean read
Join Date: Sep 2014
Location: Melbourne, Australia
Posts: 41
Rep Power: 11
seanread is on a distinguished road
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
seanread is offline   Reply With Quote

Old   September 14, 2014, 11:34
Default
  #8
Sun
Senior Member
 
Sun's Avatar
 
Join Date: Nov 2010
Posts: 103
Rep Power: 15
Sun is on a distinguished road
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.
Sun is offline   Reply With Quote

Reply

Tags
udf, udf and programming

Thread Tools Search this Thread
Search this Thread:

Advanced Search
Display Modes

Posting Rules
You may not post new threads
You may not post replies
You may not post attachments
You may not edit your posts

BB code is On
Smilies are On
[IMG] code is On
HTML code is Off
Trackbacks are Off
Pingbacks are On
Refbacks are On


Similar Threads
Thread Thread Starter Forum Replies Last Post
specified shear at wall - temperature gradient - UDF - access violation error senD Fluent UDF and Scheme Programming 9 September 18, 2014 08:29
udf error : access violation butterfly007 Fluent UDF and Scheme Programming 2 June 1, 2012 12:01
Access violation error pointer to a file salihovic FLUENT 0 February 8, 2011 11:18
About The fatal error ACCEss violation sosososo1114 FLUENT 1 April 6, 2010 23:00
access drag coeff and udf for granular temp jwwang FLUENT 0 May 22, 2006 01:48


All times are GMT -4. The time now is 17:44.