F_UDMI versus C_UDMI

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

 March 27, 2018, 19:21 F_UDMI versus C_UDMI #1 New Member   Matt Join Date: Mar 2018 Posts: 11 Rep Power: 8 I'd like to know how different the application of F_UDMI and C_UDMI is. In DEFINE_DPM_EROSION example of the manual: F_UDMI(f,t,AVG_DIAMETER) = (P_DIAM(p) + num_in_data * F_UDMI(f,t,AVG_DIAMETER)) / (num_in_data + 1); C_UDMI(c0,t0,AVG_DIAMETER) = F_UDMI(f,t,AVG_DIAMETER); /* Average velocity normal to wall of particles hitting the wall:*/ F_UDMI(f,t,AVG_RADI_VELO) = (vel_ortho + num_in_data * F_UDMI(f,t,AVG_RADI_VELO)) / (num_in_data + 1); C_UDMI(c0,t0,AVG_RADI_VELO) = F_UDMI(f,t,AVG_RADI_VELO); F_UDMI(f, t, NUM_OF_HITS) = num_in_data + 1; C_UDMI(c0,t0,NUM_OF_HITS) = num_in_data + 1; F_UDMI value is copied to C_UDMI. Why is that necessary? Thanks

 March 28, 2018, 05:08 #2 Senior Member   Join Date: Nov 2013 Posts: 1,965 Rep Power: 26 F_UDMI(f,t) is the value of the UDM on a face. C_UDMI(c,t) is the value of the UDM in a cell. In your example, the "Average velocity normal to wall of particles hitting the wall" is calculated on wall faces (which is the most logical thing to do). For some reason unknown to me, this information also needs to be available on the cell closest to the wall, the the programmer copied this information. sthinmind likes this.

 March 28, 2018, 09:45 #3 New Member   Matt Join Date: Mar 2018 Posts: 11 Rep Power: 8 Thanks for your response. I find this example of the manual very confusing! While at it, I'm not able to use the DEFINE_ON_DEMAND(reset_UDM) for resting my UDM's . It gives an error. DEFINE_ON_DEMAND(reset_UDM) { /* assign domain pointer with global domain */ domain = Get_Domain(1); reset_UDM_s(); } Does this code work for only this example? if not what changes I need to make? The way I reset my UDM's right now is to loop through all cells and make their values equal to zero: thread_loop_c(t,d) { begin_c_loop(c,t) { for(i=0;i<7;i++) C_UDMI(c,t,i)=0.0; } end_c_loop(c,t) }

 March 28, 2018, 09:50 #4 Senior Member   Join Date: Nov 2013 Posts: 1,965 Rep Power: 26 In the example in the manual, the function "reset_UDM_s" is defined. And their definition is essentially what you are also doing. "reset_UDM_s" is not an internal Fluent function, you have to write it (or copy it from the manual). sthinmind likes this.

 March 28, 2018, 10:07 #5 New Member   Matt Join Date: Mar 2018 Posts: 11 Rep Power: 8 Now it make sense Thanks . I have another question then. In that part of the code where "reset_UDM_s" is defined: void reset_UDM_s(void) { Thread *t; cell_t c; face_t f; int i; ..... "t" is used for both cell thread and face thread. Thread_loop_f (t, domain) and Thread_loop_c(t, domain). Are they the same thing?!

 March 28, 2018, 10:11 #6 Senior Member   Join Date: Nov 2013 Posts: 1,965 Rep Power: 26 Yes, both are threads. sthinmind likes this.

 March 28, 2018, 10:18 #7 New Member   Matt Join Date: Mar 2018 Posts: 11 Rep Power: 8 If they both are the same thing, then why t0 is defined later in DEFINE_DPM_EROSION. Why not use t for both F_UDMI and C_UDMI?

 March 28, 2018, 10:26 #8 Senior Member   Join Date: Nov 2013 Posts: 1,965 Rep Power: 26 Because in DEFINE_DPM_EROSION, they want to use two threads at the same time, one for a cell and one for a face. So you need two different thread variables. In reset_UDM_s, first the thread t is used for face threads, then for cell threads. Never for two at the same time. Still, the programmer could have used two different thread variables for this, the cost for this (memory-wise) would be negligible (or maybe even non-existent if the compiler is smart enough). It's just a choice. sthinmind likes this.

 March 28, 2018, 12:05 #9 New Member   Matt Join Date: Mar 2018 Posts: 11 Rep Power: 8 I have the following code to calculate the number of particles hitting a boundary and save it to a C_UDMI. It works fine and I can plot the C_UDMI contour DEFINE_DPM_BC(OSU_Deposition_Model_R1,p,t,f,f_norm al,dim) { #if !RP_HOST Thread *tcell=P_CELL_THREAD(p); cell_t c=P_CELL(p); Domain *d; d=Get_Domain(1); C_UDMI(c,tcell,0) += 1.; return PATH_ABORT; #endif } But if I try to save the same information in a F_UDMI. I get 0 value everywhere when I plot the user defined memory contour: DEFINE_DPM_BC(OSU_Deposition_Model_R1,p,t,f,f_norm al,dim) { #if !RP_HOST Domain *d; d=Get_Domain(1); // Thread *t; // face_t f; F_UDMI(f,t,0) += 1.; return PATH_ABORT; #endif } I saw your response to this in "define_profile and F_UDMI" thread. Is it just a bug in FLUENT or is there any way to plot F_UDMI?

 March 29, 2018, 03:30 #10 Senior Member   Join Date: Nov 2013 Posts: 1,965 Rep Power: 26 I don't know if it is a bug, but I considered it as "unexpected behavior".

July 14, 2021, 04:55
#11
New Member

WB
Join Date: Jul 2021
Posts: 13
Rep Power: 4
Quote:
 Originally Posted by pakk I don't know if it is a bug, but I considered it as "unexpected behavior".

 July 14, 2021, 14:49 #12 Senior Member   Join Date: Nov 2013 Posts: 1,965 Rep Power: 26 No. Why do you need my email address to ask a question??? Just so it here. __________________ "The UDF library you are trying to load (libudf) is not compiled for parallel use on the current platform" is NOT the error after compiling. It is the error after loading. To see compiler errors, look at your screen after you click "build".

 Tags dpm model, udf and programming, user defined memory