[souria]

Hey everyone,

I try hardly to figure out the problem of an UDF but in vain.
I want to get particles informations (position) when the particle is trapped, but I get an empty file at the end !!!

Here's the UDF :


#include "udf.h"
#include "sg.h"
#include "dpm.h"
#define WALL_ID 5

DEFINE_DPM_SCALAR_UPDATE(particle_coords, c, ct, initialize, p)
{
#if !RP_NODE
real A[ND_ND];

int n;
face_t f;
Thread *ft;
c_face_loop(c, ct, n);
{
f=C_FACE(c, ct,n);
ft=C_FACE_THREAD(c, ct, n);
if(NNULLP(ft))
{
if(THREAD_ID(ft)== WALL_ID)
{
p->user[0] = p->state.pos[0];
p->user[1] = p->state.pos[1];
p->user[2] = p->state.pos[2];

}
}

}
#endif
}



DEFINE_DPM_OUTPUT(Particle_coords_output, header, fp, p, thread, plane)
{
#if !RP_NODE
char name[100];
if(header)
{
if (NNULLP(thread))
par_fprintf_head(fp,"%s %d\n", THREAD_HEAD(thread)->dpm_summary.sort_file_name,11);
else

par_fprintf_head(fp,"%s %d\n", plane->sort_file_name,11);

par_fprintf_head(fp,"%10s %10s %10s\n","X", "Y", "Z");
}
else
{
sprintf(name,"%s:%d", p->injection->name,p->part_id);
fprintf(fp,"%10.6g %10.6g %10.6g\n", p->user[0], p->user[1], p->user[2]);
}

#endif
}


Thanks for your help, I appreciate it so much

Souria

[pakk]

Instead of these two macro's, it is much easier to write a DPM_BC that prints the position of the particle to a fail and returns "PATH_ABORT".
Then, apply that boundary condition on all walls where you want the particles to be trapped.

[souria]

Originally Posted by pakk

Instead of these two macro's, it is much easier to write a DPM_BC that prints the position of the particle to a fail and returns "PATH_ABORT".
Then, apply that boundary condition on all walls where you want the particles to be trapped.

I used this in order to put "Trap" condition in the boundary conditions. And then, get particles positions...
In case using "Path ABORT", means I will get all particle that are susceptibles to touch the wall (means : there is no difference between the "reflected" and the "trap" condition) ! I don't know if I m clear (or if what Im saying is rationale !)

[pakk]

No, it is not clear to me...

If you use PATH_ABORT, you are using a user-defined boundary condition. Thus not "reflected", and not "trapped", so I don't know what you mean by 'there is no difference between the "reflected" and the "trap" condition'.

The effect of PATH_ABORT is that the calculation is stopped. Just as in the "trapped" boundary condition.

[souria]

If I use DPM_BC, I couldn't choose either Trap or reflected ! The UDF DPM_BC will remplace it.
So, I should write an UDF which first order a particle trapping and then collcetion of information, this is what I understand from DPM_BC.

My worry is : 1) I don't really know how to fixe the boundary conditions to "Trap" with an udf ?

I just do it the reflected case, it's easer, everytime a particle touch the wall-bottom the UDF gives it's position, velocity ...etc

Originally Posted by pakk

No, it is not clear to me...

If you use PATH_ABORT, you are using a user-defined boundary condition. Thus not "reflected", and not "trapped", so I don't know what you mean by 'there is no difference between the "reflected" and the "trap" condition'.

The effect of PATH_ABORT is that the calculation is stopped. Just as in the "trapped" boundary condition.

[pakk]

Originally Posted by souria

If I use DPM_BC, I couldn't choose either Trap or reflected ! The UDF DPM_BC will remplace it.
So, I should write an UDF which first order a particle trapping and then collcetion of information, this is what I understand from DPM_BC.

My worry is : 1) I don't really know how to fixe the boundary conditions to "Trap" with an udf ?

I just do it the reflected case, it's easer, everytime a particle touch the wall-bottom the UDF gives it's position, velocity ...etc

You fix the boundary condition to "trap" by returning "PATH_ABORT".

I don't understand why you say the reflected case is "easier". It is not... Just write a DPM_BC, that does two things:
1. Write the position of the particle to a file.
2. return PATH_ABORT.

It will be much shorter than the codes you wrote before.

[souria]

Here my UDF to get the particle position in wall bottom, I use at the end Pathh_ABORT, but all particles are escaped, there's no trapping one !

Could please tell me, what I miss about traping condition.

Here's my UDF :

# include "udf.h"
# include "dpm.h"

/*P_TIME(p) : current particule time, P_DT(p) : current particle time step*/

DEFINE_DPM_BC(bc_wall_bottom,p,t,f,f_normal,dim)
{

FILE * f1; FILE * f2; float x; float y; float z; float velpu;
float velpv; float velpw; float ID; float tim; float tep; float u; float v; float w;
f1 = fopen ("C:\wall_bottom_xyz.txt", "a");
f2 = fopen ("C:\wall_bottom_paramters.txt", "a");

x=P_POS(p)[0]; y=P_POS(p)[1]; z=P_POS(p)[2]; velpu=P_VEL(p)[0];
velpv=P_VEL(p)[1]; velpw=P_VEL(p)[2];ID=p->part_id;
tim=P_TIME(p);tep=P_DT(p);

fprintf (f1, "%f %f %f\n",x,y,z);
fprintf (f2, "%f %f %f %f %f %f %f %f %f %f %f %f\n",x,y,z,velpu,velpv,velpw,u,v,w,ID,tim,tep);

p->part_id,

fclose(f1); fclose(f2);
return PATH_ABORT;
}

Thanks a lot for your reply.

Originally Posted by pakk

You fix the boundary condition to "trap" by returning "PATH_ABORT".

I don't understand why you say the reflected case is "easier". It is not... Just write a DPM_BC, that does two things:
1. Write the position of the particle to a file.
2. return PATH_ABORT.

It will be much shorter than the codes you wrote before.

[pakk]

OK, I remembered the wrong status.

As you can see in the file dpm_types.h (somewhere in your fluent installation), there are seven different DPM_statuses:

1. PATH_END,
2. PATH_ACTIVE,
3. PATH_BREAK,
4. PATH_ABORT,
5. PATH_STOP,
6. PATH_NON_LOCAL_PERIODIC,
7. PATH_NON_LOCAL

Apparently, PATH_ABORT corresponds to "escape". PATH_ACTIVE corresponds to the normal status, where the calculation should continue. The last two you can probably ignore, so there are three statuses left: END, BREAK and STOP. One of them corresponds to "trapped" particles. As you see, the names are confusing. If you ask me, Fluent should use PATH_TRAPPED and PATH_ESCAPED for trapped resp. escaped particles, that would be much clearer.

Anyway, I never understood the distinction between trapped and escaped particles, as far as I know they are treated the same numerically.

[Saidul]

Initially I tried with the following UDF to get the trapped particle coordinates. I activated my UDF at the beginning from
Define->User define-> Function -> compile and then from the boundary condition tab

boundary condition->wall->DPM->boundary condition type->user define function and activated the UDF

Then run the simulation and I got an output file named dpm_coordinates_28. The problem is I got lots of coordinates. Suppose in my model I injected 10000 particle but after 200 iteration I got 14000 coordinates in my output file. Another problem is it printed same x,y,z coordinates for multiple times. An output file attached.

Could you please tell me what is happening? Is my UDF incorrect?

Looking for your help.

Saeed

#include "udf.h"
DEFINE_DPM_BC(dpm_coordinates_28,p,t,f,f_normal,di m)
{ FILE * f1;
float x=0;
float y=0;
float z=0;
f1 = fopen ("Z:\\dpm_coordinates_28_xyz.txt", "a");
x=P_POS(p)[0];
y=P_POS(p)[1];
z=P_POS(p)[2];
fprintf (f1, "%f %f %f\n",x,y,z);
fclose(f1);
return PATH_ABORT; }

[pakk]

It looks like you are running parallel with three processes. (Am I right?) The udf is loaded on each of those processes, so each proces saves to the file.

Two things you can do:
1. Ignore the fact that you get each line three times.
2. Change the udf such that only one proces writes to the file.

To be honest, I normally just ignore the extra lines.

[Harry321]

Hi,

I think it is caused by processes which runs parallel. This is only one thing which I can think of. Try to send values to HOST and than using HOST to print variables to file.

For example: node_to_host_real(mass_flow, division_nb); but this part is quiet good covered by UDF manual.

Do you run your simulation on Linux or Windows?

[Harry321]

Btw

c_face_loop(c, ct, n);
{
}

If you use parallel UDFs you need to be sure that you are not looping over "mirror" faces and cells. For each process Fluent add some "mirror" faces and cells which are used in looping, but it can make errors (wrong values).

[Saidul]

No, my processing option is serial and I am not sure about three processes. Honestly speaking, it is really difficult to ignore the extra line by manually. Suppose I have 10000 lines in my output file, so it's really difficult. Could you please tell me, is there any easy way to ignore the extra lines.

Another point is, how can I change the UDF that it will write one process to a file. I think it will be really good option.

Thanks in advance.

Saeed

Originally Posted by pakk

It looks like you are running parallel with three processes. (Am I right?) The udf is loaded on each of those processes, so each proces saves to the file.

Two things you can do:
1. Ignore the fact that you get each line three times.
2. Change the udf such that only one proces writes to the file.

To be honest, I normally just ignore the extra lines.

[Saidul]

Hello,
My simulation is serial processing and my platform is windows 7 (64 bit).

Originally Posted by Harry321

Hi,

I think it is caused by processes which runs parallel. This is only one thing which I can think of. Try to send values to HOST and than using HOST to print variables to file.

For example: node_to_host_real(mass_flow, division_nb); but this part is quiet good covered by UDF manual.

Do you run your simulation on Linux or Windows?

[Harry321]

you may try:

DEFINE_DPM_BC(dpm_coordinates_28,p,t,f,f_normal,di m)
{
#if !RP_NODE
FILE * f1;
f1 = fopen ("Z:\\dpm_coordinates_28_xyz.txt", "a");
#endif
float x=0;
float y=0;
float z=0;
#if !RP_HOST
x=P_POS(p)[0];
y=P_POS(p)[1];
z=P_POS(p)[2];
#endif
node_to_host_real_3(x, y,z);
#if !RP_NODE
fprintf (f1, "%f %f %f\n",x,y,z);
fclose(f1);
#endif
# if !RP_HOST
return PATH_ABORT;
#endif
}

unfortunately I have no opportunity to check if it works in that way. For sure if it will not run in parallel you can use in this way in serial.

[Saidul]

Hello,
I tried to compile with this UDF and I tried with both serial and parallel but it shows error. Image attached for your kind information.

Saeed

Originally Posted by Harry321

you may try:

DEFINE_DPM_BC(dpm_coordinates_28,p,t,f,f_normal,di m)
{
#if !RP_NODE
FILE * f1;
f1 = fopen ("Z:\\dpm_coordinates_28_xyz.txt", "a");
#endif
float x=0;
float y=0;
float z=0;
#if !RP_HOST
x=P_POS(p)[0];
y=P_POS(p)[1];
z=P_POS(p)[2];
#endif
node_to_host_real_3(x, y,z);
#if !RP_NODE
fprintf (f1, "%f %f %f\n",x,y,z);
fclose(f1);
#endif
# if !RP_HOST
return PATH_ABORT;
#endif
}

unfortunately I have no opportunity to check if it works in that way. For sure if it will not run in parallel you can use in this way in serial.

[Harry321]

Ohhh :/
so maybe this macro (DEFINE_DPM_BC(dpm_coordinates_28,p,t,f,f_normal,d i m)) cannot use HOST only computing nodes, but it that case I don't know how to print out variables to the file without overlapping.
I used similar macro to writing variables to file but it was implemented in DEFINE_ADJUST.

Btw in fluent it is better to use real instead of float (if you use real, fluent will choose, instead of you, a proper format which will depend on double precision or not)

[Saidul]

Ok, many thanks. If you get any idea regarding this problem please let me know. I am badly looking to fix the problem.

Thank you again.
Saeed

Originally Posted by Harry321

Ohhh :/
so maybe this macro (DEFINE_DPM_BC(dpm_coordinates_28,p,t,f,f_normal,d i m)) cannot use HOST only computing nodes, but it that case I don't know how to print out variables to the file without overlapping.
I used similar macro to writing variables to file but it was implemented in DEFINE_ADJUST.

Btw in fluent it is better to use real instead of float (if you use real, fluent will choose, instead of you, a proper format which will depend on double precision or not)

[Saidul]

Hello,
I made small modification on my UDF and now is it not writing multiple number of file (file attached). But the problem is, I am getting lots of coordinates. Suppose, I injected 1054 particle by using the nodes of the inlet and my case is steady state. After 100 iteration I got 92000 coordinates in my file. But if I set the boundary condition as Trap, then after 100 iteration number of trapped particle is 156.

What is happening? Is it feasible to get 92000 coordinates after 100 iteration?

#include "udf.h"
DEFINE_DPM_BC(dpm_coordinates_10feb,p,t,f,f_normal ,dim)
{ FILE * f1; FILE * f2; float x=0; float y=0; float z=0;
f1 = fopen ("Z:\\dpm_coordinates_10feb_xyz.txt", "a");
f2 = fopen ("z:\\dpm_coordinates_10feb_injection_file.txt" , "a");
x = p->state.pos[0];
y = p->state.pos[1];
z = p->state.pos[2];
fprintf (f1, "%f %f %f\n",x,y,z);
fprintf (f2, "((%f %f %f 0 0 0 0 0 0 ) name )\n",x,y,z);
fclose(f1);
fclose(f2);
return PATH_ABORT; }

Originally Posted by pakk

It looks like you are running parallel with three processes. (Am I right?) The udf is loaded on each of those processes, so each proces saves to the file.

Two things you can do:
1. Ignore the fact that you get each line three times.
2. Change the udf such that only one proces writes to the file.

To be honest, I normally just ignore the extra lines.

[pakk]

Do you remove "Z:\\dpm_coordinates_10feb_xyz.txt" every time before you start the simulation?