CFD Online Discussion Forums - Problems with the C_FACE, C_FACE_THREAD, F_C0, and THREAD

CFD Online Discussion Forums (https://www.cfd-online.com/Forums/)

- Fluent UDF and Scheme Programming (https://www.cfd-online.com/Forums/fluent-udf/)

- - Problems with the C_FACE, C_FACE_THREAD, F_C0, and THREAD_C0 functions (https://www.cfd-online.com/Forums/fluent-udf/101971-problems-c_face-c_face_thread-f_c0-thread_c0-functions.html)

Problems with the F_CENTROID not producing unique values for unique faces

Hello,

I am working on a project with the goal of accessing a cell some distance from a wall. I start with the handle to a face thread and loop through the faces in it, take the cell those faces are adjacent to and then access the face on the other side of the cell and repeat until I am far enough away. I have constructed sample code (which crashes) below

Code:

#include "udf.h"

#define HEAT_ID 6

DEFINE_ON_DEMAND(example){        

        Thread *t;

        Domain *d;

        

        face_t f;

        face_t adjFace;

        Thread *adjFaceThread;

        cell_t adjCell;

        Thread *adjCellThread;

        

        real Ts;

        real adjCellTemp;

        real adjFaceTemp;

        

        d = Get_Domain(1);

        t = Lookup_Thread(d,HEAT_ID);

        

        begin_f_loop(f, t){

                Ts = F_T(f,t); //get cell temperature ts 

                printf("Ts= %f\n f = %d\n",Ts,f);

                adjCell = F_C0(f,t);

                printf("adjCell=%d\n",adjCell);

                adjCellThread = THREAD_T0(t);

                adjFace = C_FACE(adjCell,adjCellThread,3);

                printf("adjFace=%d\n",adjFace);

                adjFaceThread = C_FACE_THREAD(adjCell,adjCellThread,3);

                adjCellTemp = C_T(adjCell,adjCellThread);

                printf("adjCellTemp = %f\n",adjCellTemp);

                adjFaceTemp = F_T(adjFace,adjFaceThread);

                printf("adjFaceTemp=%f\n",adjFaceTemp);

                printf("T-adj-cell = %f,     T-adj-face3 = %f,\n",adjCellTemp,adjFaceTemp);

        }end_f_loop(f,t)

        

}

This code crashes towards the end when it attempts to read the adjFaceTemp using F_T(f,t), interestingly enough if I substitute adjCellThread for adjFaceThread it works (with some ridiculous temperatures). This is not the behavior I think is indicated in the documentation, it seems that the function F_T needs a face thread not a cell thread. Can someone tell me why these macros are behaving as they are? It would be a great help.

I am saying that F_T(f,ft); works if you substitute ft which is a face thread when you use a cell thread instead

So C is an all around terrible language (if your trying to debug using the interpreted function compiler) so I got fed up with it and decided to break the problem into two programs, one program to extract the data i needed from fluent (thus minimizing the amount of time spent in c) and one program in java to do the heavy lifting with multiple threads and the like.

The java program is finished and well tested with example cases and I cant figure out why it wouldn't work. Then I took a closer look at the output from my c function.

Right now thread is hard coded to be the surface i want to extract data from.

here is an exerp.

Code:

                        printf("next thread loop started\n");

                        printf("Extracting faces from thread %d\n",THREAD_ID(t));

                        begin_f_loop(f, t)

                        {

                                F_CENTROID(centroid,f,t);

                                temperature = F_T(f,t);

                                F_AREA(normalVec,f,t);

                                area = NV_MAG(normalVec);

                                fprintf(file,"%e,%e,%e/%e/%e,%e,%e/%e\n",centroid[0],centroid[1],centroid[2],temperature,normalVec[0],normalVec[1],normalVec[2],area);

                        }

                        end_f_loop(f,t);

Which produces output similar to this:

5.574897e-03,5.462289e-02,-0.000000e+00/3.478730e+02/-0.000000e+00,-2.488653e-07,2.488653e-07/2.488653e-07
6.570358e-03,5.462289e-02,-0.000000e+00/3.497709e+02/-0.000000e+00,-2.488654e-07,2.488654e-07/2.488654e-07
7.565820e-03,5.462289e-02,-0.000000e+00/3.516786e+02/-0.000000e+00,-2.488654e-07,2.488654e-07/2.488654e-07
8.561281e-03,5.462289e-02,-0.000000e+00/3.535121e+02/-0.000000e+00,-2.488653e-07,2.488653e-07/2.488653e-07

The problem is if i highlight any one of the centroids (the first 3 numbers on each line separated by commas "x,y,z/") I get 18 duplicate results.

for example here are some of line 1's duplicates:
5.574897e-03,5.462289e-02,-0.000000e+00/3.480813e+02/-0.000000e+00,-2.488653e-07,2.488653e-07/2.488653e-07
5.574897e-03,5.462289e-02,-0.000000e+00/3.493082e+02/-0.000000e+00,-2.488653e-07,2.488653e-07/2.488653e-07
5.574897e-03,5.462289e-02,-0.000000e+00/3.505020e+02/-0.000000e+00,-2.488648e-07,2.488648e-07/2.488648e-07

in groups of 4 evenly throughout all the faces in the face thread (about 23000 of them)

I guess my question now is shouldn't F_CENTROID produce a unique result for each face?

Someone please help! no one has replied!

Are you running this simulation in parallel? Does the number of duplicates equal the number of cpu?

Thank you for answering.

Quote:

Originally Posted by Daniel Tanner (Post 363041)

Are you running this simulation in parallel? Does the number of duplicates equal the number of cpu?

No this is a DEFINE_ON_DEMAND function, this is all post processing. I run the c function and then load it's output into the java program later. This is all steady state stuff. And I wish that were the case but my cpu only has 12 threads, for stability reasons i only use 4 for processing. The psu is under powered so it likes to crash under a full load. Also each thread is only processing the output from the c program, the c program is not multi-threaded.

The other thing I had considered was the geometry I was testing, it is a heat sink with 16 fins, also not a numerical match.

Interesting developement

While stepping through code in my Java program I noticed an interesting pattern between each face and its closest cell.

Face(-0.011347,0.059237,0.0)
Cell(-0.011347,0.050459,0.003125)

Face(0.01052981,0.0495872,0.0)
Cell(0.0105522,0.04980443,0.003125)

Face(-0.01333886,0.04980443,0.0)
Cell(-0.01333886,0.04980457,0.003125)

It seems an interesting pattern has developed in that the closest cell to any face seems to be on some other plain entirely (a shift of .003125). This pattern holds true for all faces in my domain.

In my definition for the centroid values i used

real centroid[2];

because I am working on something where there will never be a 2d case so i figured it would be ok to hard code it as a 3d case to make sure whoever used this code after me wouldn't make the mistake that it could be.

our of curiosity I tried

real centroid[ND_ND];

it now returns much more reasonable values (as in there are no more duplicates). For some reason unknown to me the ND_ND constant appears to be of some great importance.

I hope this prevents someone else from wasting as much time on this problem as i did.:D

Hi,

I dont inderstand one thing ,how fluent calculate gradient in cell at boundary condition ,and what is the difference between gradient and reconstruction macro (i read the udf manual but i didnt inderstood )

thank you a lot

Quote:

Originally Posted by moun139 (Post 363292)

Hey sorry I don't know what your asking, if you can be more clear I will try to help but it sounds right now like you posted in the wrong thread.