UDF Problem
 

Hi all,

I have written an UDF (attached below) in order to calculate the volume weighted falling velocity of my free falling droplet, and use this velocity as the velocity inlet boundary condition. With this UDF, I hope to fix my falling drop in the calculation domain, so I can use a smaller domain, which is refined at the 2-phase interface on the drop.

The UDF is interpreted succesfully, but the problem is, when I try to hook it at the velocity inlet BC panel, the program hangs like it gets into an infinite loop. So I have to kill the fluent session. Does any one have a suggestion about that?

Thanks in advance, here is the UDF:

#include "udf.h"

#include "sg_mphase.h"

DEFINE_PROFILE(fall_velocity,thread,nv) {

real fall_vel_drop; real fall_vel_volweighted; real vol_tot; face_t f; cell_t c; Thread *t_phase2=THREAD_SUB_THREAD(thread,1);

begin_c_loop(c, t_phase2) {

fall_vel_volweighted += C_V(c,t_phase2)*C_VOLUME(c,t_phase2);

vol_tot += C_VOLUME(c,t_phase2); } end_c_loop(c, t_phase2)

fall_vel_drop=fall_vel_volweighted/vol_tot;

printf("Volume average y_velocity of drop: %g\n",fall_vel_drop);

begin_f_loop(f,thread)

{

F_PROFILE(f,thread,nv)=fall_vel_volweighted/vol_tot;

} end_f_loop(f,thread)

}

Re: UDF Problem
 

Hi, Effectively there is some mistakes in your UDF. *t_phase2=THREAD_SUB_THREAD(thread,1) is a FACE THREAD and your using it has CELL THREAD when you do your begin_c_loop.

Try this: Thread *t_phase2=THREAD_SUB_THREAD(THREAD_T0(thread),1)

hope this help, i do not have time to read read it, i will double check tomorrow ! thomas

Re: UDF Problem
 

Hi, i think the message i posted yesterday was not clear cause i was kinda in a hurry sorry. So i am gonna repeat it.

In your UDF *t_phase2=THREAD_SUB_THREAD(thread,1) is the FACE thread of the secondary phase. That does not fit in the begin_cell_loop macro. Your macro will work if you replace *t_phase2=THREAD_SUB_THREAD(thread,1)

BY

*t_phase2=THREAD_SUB_THREAD(THREAD_T0(thread),1). This will give you the cell thread of the phase indify by the phase domain index '1'. THREAD_T0(thread) is the macro which gives you the cell thread adjacent to face thread you define in your define_profile macro.

thomas

Re: UDF Problem
 

Thanks Thomas, I've tried your suggestion. But the problem still exist. When I hook it after I initilize and patch my drop, I get the following output (at least something:)):

Volume average y_velocity of drop:0 Volume average y_velocity of drop:0

which is correct for the beginning, but then the fluent hanged again. When I hook the UDF before I initialize and patch the drop, then I am able to hook it at velocity inlet BC without any failure, but then, when I try to initialize the solution, the same problem comes again, and fluent is hanged. Program seems to get into an endless loop, and I don't understand why! here is the corrected UDF once again:

#include "udf.h" #include "sg_mphase.h"

DEFINE_PROFILE(fall_velocity,thread,nv) {

real fall_vel_drop; real fall_vel_volweighted; real vol_tot; face_t f; cell_t c;

Thread *t_phase2=THREAD_SUB_THREAD(THREAD_T0(thread),1);

begin_c_loop(c, t_phase2) {

fall_vel_volweighted += C_V(c,t_phase2)*C_VOLUME(c,t_phase2);

vol_tot += C_VOLUME(c,t_phase2);

} end_c_loop(c, t_phase2)

fall_vel_drop=fall_vel_volweighted/vol_tot;

printf("Volume average y_velocity of drop: %g\n",fall_vel_drop);

begin_f_loop(f,thread) {

F_PROFILE(f,thread,nv)=fall_vel_volweighted/vol_tot; } end_f_loop(f,thread)

}

Re: UDF Problem
 

which model are you using ?

Re: UDF Problem
 

hi,

My model is:

2D dp, segregated, VOF, laminar, unsteady.

Re: UDF Problem
 

I have tried it on 3D case, and it did not work either.

Re: UDF Problem
 

Hi, First of all, to compute a cell volume in 2D use the macro C_VOLUME_2D(c,t). Also initialize your vol_tot & fall_vel_volweighted variables each time your calling the define_profile macro. To do this you have 2 ways. 1 - Add the line vol_tot =0; and fall...=0; before your 2 cell and face loop. 2 - Or you can use a define_adjust.

I would advice you to check when your define_profile is called to updated your inlet BC. I personally think you only need to update it every time step and not every iteration. Also the way i see your udf, your using a define_profile for each velocity component. Make sure you are hooking up your udf correctly and check if using the velocity magnitude instead of the components would not help. Also chekc the velocity sign you get are patching.

Finally when you say that fluent is hangged, how long did you wait ? if i remember your case you have a large number of very smal cells and do not forget VOF model is very demanding in term of CPU. Try to run fluent in parallel.

hope this could help you to solve your problem. thomas

Re: UDF Problem
 

I really appreciate that you give your time and help me. I have almost 1 month left to deadline of my ms. thesis, and still fighting with fluent!

I've tried your suggestions. I've recognised that I was hooking it to "velocity magnitude" in the velocity inlet panel. Since I am intersted only with the velocity component in the direction of the falling drop (-y direction), I try to hook it to "y-velocity" using the velocity specification method of "components". Now it is not hanged, but it causes SEGMENTATION VIOLATION error. I feel that it tries to get or access a parameter, that it should not or not allowed to.

But, I feel that I am getting closer to the solution, with your support ;)

Re: UDF Problem
 

SEGMENTATION VIOLATION error CAN be due to UDMI undeclared. Go to DEFINE > UDF > memory and declare your UDMI number. I confirm that depending on your number of cells and your number of iteration per time step, the way you programm your UDF will be very demanding in computation time. Do not hesitate to ask if you want a better way asking for less computation time. thomas

Re: UDF Problem
 

But I did not use User Defined Memory macros in my UDF. Why should I initialize UDMI?

Do you mean that there is a more efficient way to do the same task, that is, to calculate the falling velocity of my drop, and to use it in a way to fix the drop in the calculation domain?

I have thought of directing my UDF to "moving ref. frame", in the fluid zone BC panel, but unfortunately it is not possibble. I can't think of any other way. Do you have an idea?

Re: UDF Problem
 

My idea would be to update your inlet BC not each iteration but every 2 or 3 time step (less at the beginning). This is possible using the macro DEFINE_EXECUTE_END and an euclidian division.

thomas

Re: UDF Problem
 

well, if I can fix my UDF problem, a mesh having not more than 20k cells would be enough for my single drop problem.

But the overall calculation time may anyway increase, just because that with the much more refined cells at the interphase, then I would probably need much smaller time steps in VOF algorithm. According to my experience, it is not easy to deal with VOF when you have cells on the order of microns!

Re: UDF Problem
 

Hi Thomas,

I overcome seg. error, by hooking my UDF not to velocity inlet BC, but to fixed value, y-velocity in the fluid BC. With the following changes the program works:

#include "udf.h"

#include "sg_mphase.h"

DEFINE_PROFILE(fall_velocity,thread,nv) { real fall_vel_drop; real fall_vel_volweighted=0; real vol_tot=0; face_t f; cell_t c; Thread *t_phase2=THREAD_SUB_THREAD(thread,1); Thread *t_phase1=THREAD_SUB_THREAD(thread,0); real i=0; real j=0;

begin_c_loop(c, t_phase2) {

fall_vel_volweighted +=

C_V(c,t_phase2)*C_VOLUME_2D(c,t_phase2);

vol_tot += C_VOLUME_2D(c,t_phase2);

i=i+1;

printf("i= %g\n",i); } end_c_loop(c, t_phase2)

fall_vel_drop=fall_vel_volweighted/vol_tot;

printf("Volume average y_velocity of drop: %g\n",fall_vel_drop);

begin_c_loop(c,t_phase1)

{

F_PROFILE(c,t_phase1,nv)=fall_vel_volweighted/vol_tot;

j=j+1;

printf("j= %g\n",j);

} end_c_loop(c,thread)

}

Using the counters i and j, I recognise that, the fist loop, begin_c_loop(c, t_phase2), calls not only secondary phase cells as I wanted, but all the cells in the domain. The same applies also for the second loop, begin_c_loop(c,t_phase1), which normally should call only primary phase cells, but it calls all the cells in the domain. Therefore, my UDF demands too much calculation time. I could't figure out what may be wrong with it. Do you have an idea?

My second question is about your suggestion to use DEFINE_EXECUTE_END. How can I integrate it to my UDF. I've read the manual, but quite confused, because I need to hook my DEFINE_PROFILE UDF in BC panel, but DEFINE_EXECUTE_END macro should be hooked differently. So how to combine these two?

I greatly appreciate your help,

Regards

Özgür

Re: UDF Problem
 

Hi It is natural that a Begin_c_loop test all cell of your domain. Even if a phase is not present in a cell, its thread exist ! -> check the notion of pointer. Also as the velocity field is shared between the phase throughout the domain ( only one set of momentum equation), I do not think C_V(c,phase1) is different of C_V(phase2). Apparently in VOF it is not a test on the thread you have to do but a test on the volume fraction of the phase. So as i am not sure to be very clear i rewrote quickly your UDF, resd it, test it and tell me. Remark that i am not doing anything in the cells where the interface exist (volume fraction of each are between (0,1)

DEFINE_PROFILE(fall_velocity,thread,nv)

{ real fall_vel_drop; real fall_vel_volweighted=0; real vol_tot=0; face_t f; cell_t c; Thread *t_phase2=THREAD_SUB_THREAD(thread,1); Thread *t_phase1=THREAD_SUB_THREAD(thread,0);

begin_c_loop(c,t_pahse1) { /* Inside the drop */ if (C_VOF(c,t_phase1) == 1) { fall_vel_volweighted += C_V(c,thread)*C_VOLUME_2D(c,thread); vol_tot += C_VOLUME_2D(c,thread); }

} end_c_loop(c,t_phase1)

fall_vel_drop=fall_vel_volweighted/vol_tot;

begin_c_loop(c,t_phase2)

{ if (C_VOF (c,t_phase2) == 1) { F_PROFILE(c,thread,nv)=fall_vel_volweighted/vol_tot; } } end_c_loop(c,t_phase2)

}

Hope this help thomas

Re: UDF Problem
 

Hi Thomas,

Thanks for giving your time for my problem.

I implemented a similar IF caluse to my UDF, as I posted as a new thread yesterday, but a "not a number" error appears this time.

Anyway, I am still not sure about how to implement DEFINE_EXECUTE_END into my existing UDF, and how to hook it. Even apart from all those, I have strong doubts about the method I am using to fix my drop in the domain. I am actually trying to do a kind of coordinate transformation(from non-inertial to inertial-ref. frame moving with the same velocity of my drop) artificially, since it is not possible to define UDF in the Moving Ref. Frame Panel. But when I change the cell values in the fluid domain (with 2nd loop), then in those cells, the momentum equations are not solved anymore, but just the value I've given is assumed. Therefore, I am not sure that this way will work. What the most of the people are doing is, they are solving for modified N-S equations defined w.r.t. a non-inertial ref. frame.

Thanks again for your contribution to my problem.

Regards,

Özgür

dear Ozgur, my phd thesis is about rising droplet, but due to long rise time, i have to shift it to moving frame, can you tell me have you obtained the true code format or any reference? thenk you

can any body help me in this regard? i have the same problem too.

hi , can you give a little detail about your problem ?