Curious problem with generating a wave
 

Hi,everybody!
I’ve decided to enhance the case, that can be found in the following tutorial on wave generation (http://willem.engen.nl/uni/fluent/do...ernal/wave.pdf), and ran into some troubles while composing my UDF. First of all, I discovered, that I can’t control the rotation of the moving boundary, unless artificially assigning high enough value to aspecific parameter, which seemingly makes the program to jump over first step. I find that curious, and, although I got over it, I’d like to hear (read) suggestions as where the bug is. At last, I got stuck with the problem of setting the direction of the rotation of the boundary in a specific moments.
The idea was to improve the case by making boundary to swing, rather than to move back and forth, which, in my opinion, should make a better boundary condition. My udf text is as follows:
#include "udf.h"

static real time_saved = 0;
static real time_control = 0;
static real x_saved = 0;
static real x =0;
static real alpha;
static real alpha_saved = 0;
real omeg = 0;

DEFINE_CG_MOTION(wave, dt, vel, omega, time, dtime)
{
//resetting the static values for a new calculation
if(time == 0||time==dtime){
time_saved = 3.1415926/9;
alpha_saved = 0;
x_saved = 0;
time_control = 0;
Message("\n!!! time = %f !!!\n",time);

}
//check to see if sufficient time has passed
if(fabs(time_saved-time)>0.2*dtime){
// Check to see if there is data

if (!Data_Valid_P ())
{
Message("\n\nNo data->No mesh motion!!!\n\n");
return;
}
//Message("\n\nalpha = %f, x = %f, omega = %f =%f!!!\n\n",alpha,(float)(x/0.4),omega[2],omeg);
x =0.04*sin(time_saved*9)*(1-exp(-2*time_saved)); //position of the center of gravity
alpha = atan((float)(x/0.4)); //an angle, calculated so, that one of the ends of the boundary remained steady
vel[0] = (x -x_saved)/(time-time_saved); //velocity
omeg =(alpha-alpha_saved)/dtime; //value of angular velocity
omega[2] =((x>0)?-omeg:omeg); //assigning the angular velocity

x_saved = x;
alpha_saved =alpha;
time_saved = time;
//check to see if there are missed steps
time_control +=dtime;
if(time!=time_control){
Message("\n\n!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!TIME disalignment = %f!!!!!!!!!!!!!!!!!!!\n\n",(time-time_control));

}
else Message("\n\n!!!Everythingseems to be all right; TIME disalignment = %f!!!!!!!!!!!!!!!!!!!\n time =%f, control = %f\n",fabs(time-time_control),time,time_control);
}

}
Initially, the string #15 looked like this: time_saved = 0, which is only reasonable. But, as I mentioned before, in this case the angular velocity of the boundary would not update at all!
Finaly, I got stuck, trying to fix the next problem: when the center of gravity reaches x = 0, the angular velocity of the boundary during the calculation appears to change the sign. I tried to solve that by changing it once more, explicitly. Hence, directive “omega[2]= ((x>0)?-omeg:omeg);”. But it made absolutly no difference whatsoever!
Thanks foryour attention, hope someone has any idea what to do about this.

Newer mind, I've figured that out.

I'm not able to compile your UDF, I get an "undeclared identifier" report on multiple variables as time_saved etc. Do you get a lower rate of dissipation with your UDF? One possible cause for the fast dissipation could be the water depth as it is only 0.5 m in the tutorial.

It seems, that as I copyed the text of my udf here, dissapeared spaces between "real" and the names of the variables. You'll have to insert them, if you want this udf to compile.
But this udf, though it works, is way too messy. It evolved from another udf, for different purpose, and the only reason to post it here was to ask a help in detecting a bug, which turned out to be a bug in Fluent's mesh motion preview.

The is a far shorter udf that works just as well, provided (if I understead it right) that you don't use mesh implicit update:

#include "udf.h"
DEFINE_CG_MOTION(wave, dt, vel, omega, time, dtime)
{ omega[2] = -cos(9*time);
}

If you change the dimensions of your basin, some changes in the frequency and (or) magnitude will probably be necessary as well.


I realy do have less disipaiton in my results, but I've changed many other thing along with the boundary conditions.