Why doesn't someone create a repository for fluent UDF functions that can be accessed on the web? When a person find out an obscure function (which is usually the case it seems), they would then be able to submit it to this online database, then it would be available for everyone to use. Or would this be frowned upon by Fluent Inc.?

There is actually a small UDF ftp repository here at CFD Online. I haven't marketed it very much though so it is still quite small. You can find the repository here:

<A HREF="ftp://ftp.cfd-online.com/fluent">ftp://ftp.cfd-online.com/fluent</A>

To submit new files to the repository upload them by anonymous ftp to:

<A HREF="ftp://ftp.cfd-online.com/incoming">ftp://ftp.cfd-online.com/incoming</A>

and drop me an email describing what the UDF does.

The problem is that nobody is contibuting to it. I think this is because people are worried about giving away their secrets. People would be much happier to submit just a function and briefly stating what it does. It would be be much more user friendly (for both function entry and use) if it were html based with entry forms.

I agree that a web based form driven interface would make it more easy to use.

However, if people don't want to share their UDF's a web interface won't help much. The very few UDF's submitted to the ftp repository indicates that this is the case. Or am I wrong, would you guys who write UDF's be prepared to share them by submitting them to this kind of UDF repository?

Is the ftp interface a big problem or just a small inconvenience? I don't want to spend time on developing a web interface if people won't use it anyway.

I don't think there is any problem with an FTP site being used as a repository for UDF's at all. It is more than adequate.

The real issue is that we need a place to put the UDF functions we have found but aren't documented by Fluent. For instance, what does F_CO_THREAD(face, thread) do? An ordered list of these functions and what they do would be very useful.

The reason people don't contribute to it, is because it takes a lot of work and really what we want is not so much a udf library but a knowledge of each function macro, library call etc.

When people look at other's udfs they normally are trying to extract specific knowledge about the Fluent code from the udf, rather than being likely to reuse the udf etc. At least that's my opinion.

What I've tried to do, is to answer people's questions on udfs within the forum, rather than contribute much to the udf library. The other reason for this is that, my udfs often require whole slabs of code etc., which I've built - so to distill the udfs into compact tutorial types is not easy. I could post the code, but then that would probably add more confusion. (Take a look at some simple uds stuff I posted overa year ago).

So I don't mind the contributing through the forum etc. as it is.

I have been thinking of developing an "advanced udf" guide myself - not like Fluent "advanced" but really advanced - for over a year. But it takes time - if somebody is keen to help and perhaps sort through some code with me, then maybe qe can discuss it.

regards

Greg

ok Bob, here's some explanation:

there are functions F_C0 and F_C1 - these return the cell either side of a face. Each face is connected to two cells, so the C0 and C1 designate these cells.

to use

cell_t c0,c1;

c0 = F_C0(face,face_thread); c1 = F_C1(face,face_thread);

now to get the thread that these cells is on you can do:

t0 = face_thread->t0; t1 = face_thread->t1;

Thus to access cell c0,c1 on the sides of the face (face,face_thread), you would do:

Temp = C_T(c0,t0); Temp = C_T(c1,t1);

These sorts of thinsg are necessary when you want to determine a face flux etc.

Now, what does F_C0_THREAD do, well if you look at mem.h you'll see the definition. Eseentially it returns like face_thread->t0 like above. Similarly fo F_C1_THREAD.

Ie they return the thread of the cell on either side of the face. In shorthand you could acess the temps above using:

Temp = C_T(F_CO(face,face_thread),F_CO_THREAD(face,face_t hread);

and similarly for the c1 cell.

Hope it helps

Greg