[Hong M.H]

Hello guys, currently i m doing a research on synthetic jet, and i have to use UDF to define the my unsteady oscillating inlet boundary.However, for the previous case i used serial and now i have to use parallel in order to speed up my progress. Thus, i have been modifying my previous UDF coding from serial to parallel according to my own understanding from fluent manual. I would like to ask is my coding right? the coding has been attached as below:

#include "udf.h"

DEFINE_PROFILE(unsteady_z_velocity, thread, position)
{
#if PARALLEL
real t = CURRENT_TIME;
float v;
face_t f;

begin_f_loop(f, thread)
{
if (PRINCIPAL_FACE_P(f, thread))
{
F_PROFILE(f, thread, position) = v;
v = 0.41*sin(3141.5927*t);
}
}
end_f_loop(f, thread)

#if RP_NODE
v= PRF_GRSUM1(v);
# endif

#endif
}




Your help is much appreciated, Thank you.

[kirmaks]

Hallo,

I think Your UDF has no parts which are dependent on which version of FLUENT (serial or parallel) is used. You may try to check if this code works:

#include "udf.h"

DEFINE_PROFILE(unsteady_z_velocity, thread, position) 
{
real t = CURRENT_TIME;
float v;
face_t f;

begin_f_loop(f, thread)
{
if (PRINCIPAL_FACE_P(f, thread))
{
  v = 0.41*sin(3141.5927*t);
  F_PROFILE(f, thread, position) = v; 
}
}
end_f_loop(f, thread)

}

Regards, Maksim

[pakk]

Originally Posted by Hong M.H

Hello guys, currently i m doing a research on synthetic jet, and i have to use UDF to define the my unsteady oscillating inlet boundary.However, for the previous case i used serial and now i have to use parallel in order to speed up my progress. Thus, i have been modifying my previous UDF coding from serial to parallel according to my own understanding from fluent manual. I would like to ask is my coding right? the coding has been attached as below:

#include "udf.h"

DEFINE_PROFILE(unsteady_z_velocity, thread, position)
{
#if PARALLEL
real t = CURRENT_TIME;
float v;
face_t f;

begin_f_loop(f, thread)
{
if (PRINCIPAL_FACE_P(f, thread))
{
F_PROFILE(f, thread, position) = v;
v = 0.41*sin(3141.5927*t);
}
}
end_f_loop(f, thread)

#if RP_NODE
v= PRF_GRSUM1(v);
# endif

#endif
}




Your help is much appreciated, Thank you.

The easiest way to test if this parallel code gives the same results as your serial version: run it, and compare results!

[Hong M.H]

Thank you for ur suggestion, Maksim...ur help is much appreciated!

[Hong M.H]

Originally Posted by kirmaks

Hallo,

I think Your UDF has no parts which are dependent on which version of FLUENT (serial or parallel) is used. You may try to check if this code works:

#include "udf.h"

DEFINE_PROFILE(unsteady_z_velocity, thread, position) 
{
real t = CURRENT_TIME;
float v;
face_t f;

begin_f_loop(f, thread)
{
if (PRINCIPAL_FACE_P(f, thread))
{
  v = 0.41*sin(3141.5927*t);
  F_PROFILE(f, thread, position) = v; 
}
}
end_f_loop(f, thread)

}

Regards, Maksim

Thank you for ur suggestion Maksim!

[Hong M.H]

Originally Posted by pakk

The easiest way to test if this parallel code gives the same results as your serial version: run it, and compare results!

Thank you for ur suggestion pak!

[obscureed]

I agree with the other comments. I would even go further than Pakk's comment: you would like to have one UDF that gives the same results in parallel and in serial. (That is, you should not try to maintain/compare a serial version and a parallel version of the same code. The UDF you presented, with all the code wrapped in "#if parallel ... #endif" fails this.)

Some minor points, mostly just programming style but with some definite benefits:
1) Since the velocity is the same for all faces, you can do the "v=..." once, before the face loop. This will be quicker.
2) I think there is no harm in applying the boundary condition to the "external" copies of faces. So, in this situation, you do not need the test "if(PRINCIPAL_FACE_P(...". But it is good to get into the habit of thinking about these side cases for parallel UDFs.
3) Why do you have "t" as a real and "v" as a float? (Just as a reminder: float in the built-in C single-precision type; real varies in Fluent UDFs according to whether Fluent is run in single- or double-precision.) A good general policy in Fluent UDFs is never to use float, and almost always use real. The occasions when you don't use real are when you want to force the UDF to use double precision -- and this might be one of those rare occasions. CURRENT_TIME returns a double (as you can guess from looking at flow.h header file).
4) It would make the code easier to read and to maintain if you defined the frequency as a preprocessor macro. This avoids the need to memorise pi, and the risk of forgetting the factor of 2. UDFs (and C) have the macro M_PI.
5) Once you have followed point 4, you can easily print out the current values of the parameters. This is reassuring, and gives you a chance of detecting any slip-up if you intend to change the values. On the other hand, printing every time the profile is called might be excessive, so you could devise some way to print less often -- I've given an example (but not compiled to test it).

Something like this:

#define PEAK_VELOCITY_IN_METRES_PER_SEC 0.41
#define FREQUENCY_IN_REVS_PER_SEC 500.
#define PRINTS_PER_PERIOD 4.
static real next_print_time = 0.;
DEFINE_PROFILE(unsteady_z_velocity, thread, position) 
{
   double t = CURRENT_TIME;
   real v;
   face_t f;

   v = PEAK_VELOCITY_IN_METRES_PER_SEC *
      sin(FREQUENCY_IN_REVS_PER_SEC*2.0*M_PI*t);
   begin_f_loop(f, thread){
      F_PROFILE(f, thread, position) = v; 
   }end_f_loop(f, thread)
   if(t >= next_print_time) {
      Message0("With vmax=%g m/s, freq.=%g rev/s: time=%g, v=%g\n",
         PEAK_VELOCITY_IN_METRES_PER_SEC,
         FREQUENCY_IN_REVS_PER_SEC,
         t,v);
      next_print_time += 1./(FREQUENCY_IN_REVS_PER_SEC *
         PRINTS_PER_PERIOD);
   }
}

[Hong M.H]

Thank you for your advises, obscureed. your comments are useful for beginners like me,i wish that i could learn more from u