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

Looping over cells in DPM

Register Blogs Community New Posts Updated Threads Search

Reply
 
LinkBack Thread Tools Search this Thread Display Modes
Old   November 8, 2018, 12:28
Default Looping over cells in DPM
  #1
New Member
 
Roozbeh Khodaverdian
Join Date: Nov 2018
Posts: 3
Rep Power: 7
Roozbeh is on a distinguished road
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 is offline   Reply With Quote

Old   November 8, 2018, 15:44
Default
  #2
New Member
 
Roozbeh Khodaverdian
Join Date: Nov 2018
Posts: 3
Rep Power: 7
Roozbeh is on a distinguished road
Quote:
Originally Posted by Roozbeh View Post
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.));

}
Roozbeh is offline   Reply With Quote

Old   November 8, 2018, 20:05
Default
  #3
Senior Member
 
Join Date: Sep 2017
Posts: 246
Rep Power: 12
obscureed is on a distinguished road
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
obscureed is offline   Reply With Quote

Old   November 9, 2018, 02:51
Default
  #4
New Member
 
Roozbeh Khodaverdian
Join Date: Nov 2018
Posts: 3
Rep Power: 7
Roozbeh is on a distinguished road
Quote:
Originally Posted by obscureed View Post
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.
Roozbeh is offline   Reply With Quote

Reply

Tags
define_dpm_law, fluent, udf


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
[snappyHexMesh] snappyHexMesh sticking point natty_king OpenFOAM Meshing & Mesh Conversion 11 February 20, 2024 10:12
[ICEM] Error in mesh writing helios ANSYS Meshing & Geometry 21 August 19, 2021 15:18
[ICEM] Problem with prism cells sidharath ANSYS Meshing & Geometry 0 September 1, 2015 08:09
snappyhexmesh remove blockmesh geometry philipp1 OpenFOAM Running, Solving & CFD 2 December 12, 2014 11:58
looping over cells Chrisi1984 OpenFOAM Running, Solving & CFD 4 August 5, 2010 03:44


All times are GMT -4. The time now is 18:57.