[Roozbeh]

Hi all

I want to write a UDF for modifying my DPM phase, using the data of the cell that the particle is currently in.

I chose the DEFINE_DPM_LAW macro for this purpose and for looping over the cells i went with:

begin_particle_cell_loop(pi, c, t) { } end_particle_cell_loop(pi, c, t)

macro.

The final code was:

#include "udf.h"
#include "dpm.h"
#include "dpm_types.h"
#include "dpm_laws.h"
#include "surf.h"

DEFINE_DPM_LAW(LawTryTwentyfour, tp, ci)
{
cell_t c = TP_CELL(tp);
Thread *t = TP_CELL_THREAD(tp);
Particle *pi;


begin_particle_cell_loop(pi, c, t)
{

TP_DIAM(pi) = TP_INIT_DIAM(pi)*(1. - ((C_T(c, t) - 290.) / 20.));

}
end_particle_cell_loop(pi, c, t)

}

Fluent 18.2 compiled it with seemingly no problem. however when i run the case using this law it gives me follwing error:

Node 5: Process xxxx: Received signal SIGSEGV
The fl process could not be started

It also corruptes program as such i cant even reopen my DPM Injection again and i have to close the software and start all over again.

any suggestion about the nature of this error?
or better how could i solve it?

thanks

[Roozbeh]

Originally Posted by Roozbeh

Hi all

I want to write a UDF for modifying my DPM phase, using the data of the cell that the particle is currently in.

I chose the DEFINE_DPM_LAW macro for this purpose and for looping over the cells i went with:

begin_particle_cell_loop(pi, c, t) { } end_particle_cell_loop(pi, c, t)

macro.

The final code was:

#include "udf.h"
#include "dpm.h"
#include "dpm_types.h"
#include "dpm_laws.h"
#include "surf.h"

DEFINE_DPM_LAW(LawTryTwentyfour, tp, ci)
{
cell_t c = TP_CELL(tp);
Thread *t = TP_CELL_THREAD(tp);
Particle *pi;


begin_particle_cell_loop(pi, c, t)
{

TP_DIAM(pi) = TP_INIT_DIAM(pi)*(1. - ((C_T(c, t) - 290.) / 20.));

}
end_particle_cell_loop(pi, c, t)

}

Fluent 18.2 compiled it with seemingly no problem. however when i run the case using this law it gives me follwing error:

Node 5: Process xxxx: Received signal SIGSEGV
The fl process could not be started

It also corruptes program as such i cant even reopen my DPM Injection again and i have to close the software and start all over again.

any suggestion about the nature of this error?
or better how could i solve it?

thanks

Update: I also tried DEFINE_DPM_SCALAR_UPDATE macro. This one has no errors but it doesn't seem to have any effect on the diameter. Particles' diameter keep constant through domain, not affected by the cell temperature.

Here is the code: (duh!)

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

DEFINE_DPM_SCALAR_UPDATE(zzz, c, t, initialize, tp)
{

TP_DIAM(tp) = TP_INIT_DIAM(tp)*(1. - ((C_T(c, t) - 300.) / 50.));

}

[obscureed]

Hi Roozbeh,


The loop "begin_particle_cell_loop" sometimes works, but only when the information needed for it is actually allocated and calculated -- and that only happens when it is required in a model in the Fluent setup, and that is very rare. Some particle-particle collision models, and maybe DEM, but that's it. So, you should not rely on that loop in most cases.


But, in your case, why would you need that loop? If you write a UDF that adjusts the parcel that it is applied to, and it is applied to every parcel eventually, then the UDF only needs to apply to the parcel in question. I would not use DEFINE_DPM_LAW, personally -- DEFINE_DPM_SCALAR_UPDATE sounds like a better choice, or maybe DEFINE_DPM_SOURCE.


So, next question: why don't you see an effect of changing P_DIAM(tp) in the UDF? This is a rather complicated question, and depends very much on the type of the DPM injection and the steady/unsteady tracking. [Also, to be honest, I cannot envisage all the options without testing.]
-- It is possible that, if Fluent is not expecting diameter changes (for example, an "inert" injection), then it never looks to see whether diameter has changed. This does not sound correct to me, but it is possible.
-- Also, what are you hoping for when the diameter reduces? -- should the mass of material in the parcel stay the same (as if the particles have fragmented), or should the mass of material in the parcel reduce (as if the particles have somehow lost mass to somewhere, in a way that has not been explained to the model)? Whichever choice you prefer, how have you explained this to the model? Sudden changes in P_DIAM could be difficult for the model to understand, especially for non-inert particle types.


I don't have a lot of good advice on how to proceed here, except to start with a tiny test model with a single, very predictable DPM parcel, which you then study intensively. Good luck!
Ed

[Roozbeh]

Originally Posted by obscureed

Hi Roozbeh,


The loop "begin_particle_cell_loop" sometimes works, but only when the information needed for it is actually allocated and calculated -- and that only happens when it is required in a model in the Fluent setup, and that is very rare. Some particle-particle collision models, and maybe DEM, but that's it. So, you should not rely on that loop in most cases.


But, in your case, why would you need that loop? If you write a UDF that adjusts the parcel that it is applied to, and it is applied to every parcel eventually, then the UDF only needs to apply to the parcel in question. I would not use DEFINE_DPM_LAW, personally -- DEFINE_DPM_SCALAR_UPDATE sounds like a better choice, or maybe DEFINE_DPM_SOURCE.


So, next question: why don't you see an effect of changing P_DIAM(tp) in the UDF? This is a rather complicated question, and depends very much on the type of the DPM injection and the steady/unsteady tracking. [Also, to be honest, I cannot envisage all the options without testing.]
-- It is possible that, if Fluent is not expecting diameter changes (for example, an "inert" injection), then it never looks to see whether diameter has changed. This does not sound correct to me, but it is possible.
-- Also, what are you hoping for when the diameter reduces? -- should the mass of material in the parcel stay the same (as if the particles have fragmented), or should the mass of material in the parcel reduce (as if the particles have somehow lost mass to somewhere, in a way that has not been explained to the model)? Whichever choice you prefer, how have you explained this to the model? Sudden changes in P_DIAM could be difficult for the model to understand, especially for non-inert particle types.


I don't have a lot of good advice on how to proceed here, except to start with a tiny test model with a single, very predictable DPM parcel, which you then study intensively. Good luck!
Ed

Hi

Thanks, Ed. Your tip on particle type was a huge help. I changed it from inert to droplet (had to define a mixture template of course) and it worked. Looks like inert particle won't let you "update" the initial particle size. It is probably becuase in the Inert option the density and the Mass are fixed and every time step the main code sets the diameter size back to follow the density and mass.
I however still have not tested scalar update for TP_RHO and TP_MASS. maybe if used correctly someone actually can modify the inert particle size.

Anyway thanks again.