[cdf_user]

I did much research over the internet and on this forum but I could not find answer to this. I am trying to loop over faces in a plane that I created from Surface > Plane in fluent. My aim is to get an average temperature over all faces of that plane. I know there is another way to do it using Reports>Area_WeightedAverage>Tempature > Static Temperature. However, I want to find the bulk temperature or average temperature using udf over that plane. I know the plane id of that plane from Surface > Manage. Just like we can lookup a thread from Lookup_Thread(domain, thread_ID) provided we know the id of the thread, is there a similar function that could be used to look a plane from its plane id?

[Amir]

Hi,
I think you can loop over faces of a plane if it is part of your domain not just imaginary one. so one reasonable way is to work with cells, i.e. mark and separate your desired volume and after separation it would have a specific ID. you can separate a region with little depth to work as a plane.

[cdf_user]

Oh!! so that plane is imaginary and not part of the domain. Is there a way to separate a region in my domain like the way you said (plane with small depth) using fluent or do I have to go all the way back to mesh generation to do that. I used ICEM CFD for mesh generation. If it is possible in fluent, could you please tell how to do it in fluent?

Thanks for the reply!

[Amir]

you can do that in FLUENT.
adapt->region then use hex or cylinder and specify its dimension and then mark that.(just mark do not adapt)
then in:
grid->separate->cells; separate your marked region. consequently it would be the combination of domain cells.

regards,

Amir

[nenazarian]

Hi Amir,

I know this is an old thread, but I had a quick question regarding your post.

You mentioned separating cells to create a new zone that acts as a plane, so that its id can be passed in UDF file for calculation.

My question is regarding face and cell values and how this would be affected using approach. When I try to mark a region with a small depth, the depth should be at least bigger than a cell size, meaning that the specified plane would actually consist of numbers of cells .

I would like to calculate a parameter that is the dot product of velocity and surface vector (of each patch or face) on a specified plane. I'm afraid using this approach, the udf would try to calculate the parameter in both upper and lower surfaces, using the same adjacent cell value!

I would appreciate if you let me know what you think.

Cheers,
Negin

[Amir]

Originally Posted by nenazarian

I would like to calculate a parameter that is the dot product of velocity and surface vector (of each patch or face) on a specified plane. I'm afraid using this approach, the udf would try to calculate the parameter in both upper and lower surfaces, using the same adjacent cell value!

I would appreciate if you let me know what you think.

Cheers,
Negin

Dear Negin,

This method is useful for some post-processings like reporting an average of a variable over a face, which can be estimated as the average of adjacent cell values; note that we are getting average from cells not faces.
Here, in your case, if you can find the cell values of your surface vector, you can follow the same approach because as I said, we are substituting the face-average with the cell one. You should know that the velocity vector is also a surface vector variable because of using staggered grid concept in numerical analysis, so there should be a function to retrieve the cell value of your surface vector as it does for velocity.
You can also use another approach which is modifying your grid; you can put your desire planes in your domain as interiors and use it directly in UDFs.

Bests,

[nenazarian]

Dear Amir,

Thank you for your quick response.
I believe I need to explain my problem in more details, and then I would really appreciate if you give me your feedback on the accuracy of this approach.

I would like to calculate the following parameters on different planes, as specified in the image below:

For this purpose, I have wrote this UDF file.

/************************************************** *********************
1. UDF that renames the UDMs to enhance postprocessing
2. UDF for computing the magnitude of Air Exchange Rates along the sides and top of the building arrays

************************************************** *********************/
#include "udf.h"


DEFINE_EXECUTE_ON_LOADING(udm_name, udflib)
{
Set_User_Memory_Name(0,"ACH-top");
Set_User_Memory_Name(1,"ACH-side");
}

DEFINE_EXECUTE_AT_END(sampling_face_data)
{
FILE *fp; // Pointer to the file for writing ACH
Domain *d;
Thread *t, *t0, *tt, *tt0;
face_t f;
cell_t c0, cc0;
d = Get_Domain(1);

int ID_t = 40, ID_s = 2; // This ID needs to be defined according to specified plane (!) zone being separated from main fluid zone

real NV_VEC(A); /* declaring vectors A - surface vectore */
real flow_time = CURRENT_TIME;
real dt = CURRENT_TIMESTEP;
real w, v; // w and v velocity on faces
real ACHt_in=0, ACHt_out=0, ACHt_it=0, ACHt_ot=0;
real sum_time = 0; // Sampling ACH starts after sum_time

sum_time + = sum_time + dt

t = Lookup_Thread(d, ID_t); // This command passes the specified zone id of top plane to the lookup thread
t0 = THREAD_T0(t);

tt = Lookup_Thread(d, ID_s); // This command passes the specified zone id of side plane(s) to the lookup thread
tt0 = THREAD_T0(tt);

w= F_W(f,t) ; v= F_V(f,tt) ;

begin_f_loop(f,t)
{
F_AREA(A,f,t)
ACHt = NV_DOT(w , A) ;

if (w<=0)
{
ACHt_in+ = ACHt/16;
//ACHt_it=ACHt_in*dt/flow_time; /* This would only be accurate when time averaging is started at t=0 */
ACHt_it=ACHt_in*dt/sum_time;
}
else
{
ACHt_out+ = ACHt/16;
ACHt_ot=ACHt_out*dt/sum_time;
}
}
end_f_loop(c,t)

begin_f_loop(f,tt)
{
F_AREA(A,f,tt)
ACHs = NV_DOT(v , A) ;
if (v<=0)
{
ACHs_in+ = ACHs/16;
ACHs_it=ACHs_in*dt/sum_time;
}
else
{
ACHs_out+ = ACHs/16;
ACHs_ot=ACHs_out*dt/sum_time;
}
end_f_loop(c,tt)
}
c0 = F_C0(f,t);
C_UDMI(c0,t0,0) =ACHs_it;

cc0 = F_C0(f,tt);
C_UDMI(cc0,tt0,1) =ACHs_ot;

/*fp = fopen("output_ACHt.txt","a");
fprintf(fp,"\n%d\t%e\n",f,C_UDMI(c0,t0,0));
fclose(fp);*/
}

a) I defined 2 UDMs in the same UDF, even though they are being calculated on different zones (as defined by different IDs). Would I benefit from having separate UDFs for each parameters (top and side ACH)?

b) ACH is calculated on faces, using vector A and velocity component defined on faces, but stored in the adjacent cell. In case of having a separate zone (as discussed in above conversation), representing the desired plane with one cell depth, would this calculation be accurate?


I would truly appreciate your help. I just finished the code, but still haven't compiled it. I am still trying to figure out if it physically make sense.

Cheers,
Negin

[Amir]

Dear Negin,

First of all, you have to note that your UDF would need a major revision; it's not just about few typos or commands, there are some conceptual misunderstandings, and, for sure you can handle that ....
Anyway, regarding your UDF and questions, I think you're confused in some parts like recognizing cell or face threads. According your purpose, you can just use face threads not the cell ones! You should have or create your desire planes as face threads and use their IDs in the UDF. Achieving this goal would be possible in 2 ways:
1) Separating the cells of a proper marked zone while one of its faces coincides with desire plane and others out of the domain. (In this manner, you would get both cell and face threads, and you can use the face thread ID) You can check it in a simple case to be more clear...
2) Preparing your grid again according to these new planes as interiors.
And your questions:

Originally Posted by nenazarian

a) I defined 2 UDMs in the same UDF, even though they are being calculated on different zones (as defined by different IDs). Would I benefit from having separate UDFs for each parameters (top and side ACH)?

No! there is not any interference.

Originally Posted by nenazarian

b) ACH is calculated on faces, using vector A and velocity component defined on faces, but stored in the adjacent cell. In case of having a separate zone (as discussed in above conversation), representing the desired plane with one cell depth, would this calculation be accurate?

I've responded above.

Bests,

[jose_zola]

hi amir

i was wondering if there is any way to mark cells using udf. the problem is that i created an udf to change the porosity is some area to create a cylinder inside a volume. now i need to mark the cell with the high porosity using udf. i know i can mark cell with high velocity but its not an accurate method and there is not an option to mark cell with respect to their porosity

I appreciate any help

[`e`]

Prepare cells to be marked by using User-Defined Memory and allocating a value of one (Boolean logic). Then mark the cells, for example where udm-0 = 1.

[jose_zola]

jj fdg dsgetg ztgsfg eg stgs

[`e`]

Yes, you can separate cells which have been marked to create a new cell zone which could be switched to a porous media.

[xerox]

Dear fellow CFD users,

first of all I want to thank you @Amir for your support on this toppic, as I got stuck on the excact same problem and your hints were pretty useful. I managed to build my mesh out of 2 seperate meshes with openfoam and did not stitch the identical surfaces, so that i can fuse the 2 walls in fluent later to an interior to get an ID. Up to this point everything went well.

I am working on a UDF that writes the temperature as a function of y and z into a text file. My case is a 3d pipe flow (flow direction is the z-axis) with an interior wall normal to the x-axis (like a cut plane).

My compiled UDF is working up to the line, where I want to extract

temp = C_T(c, t);

within my c_loop. I got the following error

Node 5: Process 6620: Received signal SIGSEGV.

==============================================================================
MPI Application rank 0 exited before MPI_Finalize() with status 2
 The fl process could not be started.

Interesting fact, if I want to export pressure with C_P my udf is acting fine (other variables as C_U, C_H, C_R... also do not work). If I want to export the temperature on any other boundary surface (literally just change the Lookup_Thread id) like input or output my udf with C_T is acting fine.

As in this thread mentioned by others

http://www.cfd-online.com/Forums/flu...sigsegv-2.html

it seems that I am calling for a variable that has no value, but I've turned on the energy equation.

I am pretty thankful for any advise on how to go on further, cause I've spent way to much time up to now into this case.

#include "udf.h"

DEFINE_EXECUTE_AT_END(cell_temp)
{


    int i_curr_ts;   
    FILE *f_file;
    char buffer[32];
    
    Domain *d; 
    Thread *t;
    cell_t c;
    float temp;
    real position[ND_ND];   
    float x, y, z;
    
    i_curr_ts = N_TIME;
    d = Get_Domain(1);
              
    snprintf(buffer, sizeof(char) * 32, "ts_%d.txt", i_curr_ts);

    t = Lookup_Thread(d, 4);    /*Inlet: , outlet: 12    */

    begin_c_loop(c, t)
    {
        temp = C_T(c, t);
        C_CENTROID(position, c, t);
        x = position[0];
        y = position[1];
        z = position[2];
        f_file = fopen(buffer, "a");
        fprintf(f_file, "X, Y, Z, %f, %f, %f, %f\n", x, y, z, temp);
        fclose(f_file);
    }
    end_c_loop(c, t)    
}

Kind regards!

[anonymous96_]

Originally Posted by nenazarian

Dear Amir,

Thank you for your quick response.
I believe I need to explain my problem in more details, and then I would really appreciate if you give me your feedback on the accuracy of this approach.

I would like to calculate the following parameters on different planes, as specified in the image below:

For this purpose, I have wrote this UDF file.




a) I defined 2 UDMs in the same UDF, even though they are being calculated on different zones (as defined by different IDs). Would I benefit from having separate UDFs for each parameters (top and side ACH)?

b) ACH is calculated on faces, using vector A and velocity component defined on faces, but stored in the adjacent cell. In case of having a separate zone (as discussed in above conversation), representing the desired plane with one cell depth, would this calculation be accurate?


I would truly appreciate your help. I just finished the code, but still haven't compiled it. I am still trying to figure out if it physically make sense.

Cheers,
Negin

Hi Negin
I am working on a similar problem. Can you please share your udf for ACH calculation in case you still have it? I am really stuck on it.