Rotating Boundary Condition
 

Dear Edge Users,

Has anyone ever applied a non-rotational symmetric boundary condition in simulations using a rotating reference frame?
This means typically setting a translational velocity component as farfield b.c. to the (rotating) domain containing a rotor.
(Refer for instance to the case of a helicopter in forward flight).

In a rotating frame (i.e. non-zero omega in the input file) the translational velocity would be seen as a "rotating" vector.
I'd be interested in knowing whether this can be obtained with the existing bc options or would mean adding new ones.

Many thanks in advance and best regards,
m righi

Dear Marcello,

thanks for evaluating the rotating part of Edge.
I am not even sure that we ever tested running time accurately so I am glad to
hear that it works as expected. As I have said earlier, we lack projects where
rotation is involved.
On the other hand I am not sure I understand what is time dependent in you
calculation? It seems like a steady state problem to me.

I am not sure if you really need a new boundary condition.
Although we solve the governing equations in a relative frame of reference, the
equations are rewritten to include the absolute velocities instead of the
relative ones. The advantage is that the source terms are smaller and the
part with the centrifugal does not show up as a source term.
So the dependent variables, stored in the flow solver, that we solve for contain
the absolute velocity and it is also the absolute velocity that we impose
boundary conditions for.
The relation we use between absolute and relative velocities does not
depend on the time though, we use UREL = UABS - OMEGA X R
I think that in reality you would actually need some time dependency, dont you?
My knowledge about this is a bit limited as you can see.
I am not sure about this but cant you simply prescribe a constant forward
velocity as free stream?

Concerning time dependent data on boundaries many of the existing external
boundary conditions can deal with this. You could supply data at discrete times
in a separate file for the concerned boundary or boundaries, linear
interpolation will be used in between. This is also
mentioned in the users guide, section 3.4.5. The data may be global or given
node by node. E.g. the external farfield boundary condition can deal with it.
You supply the file name as an argument (data set) in the boundary condition
file, data to the data set bc_data_file.

No matter what, I write a few lines below on the necessary steps to include a
new boundary condition.
First of all I think you should have the new routine in a separate file. This
means that you have to

1. update the Makefile and then
2. do 'make depend' to update the depend.mk file including the new file.

Then a new external boundary condition is added by

1. Add the name of the boundary condition in the list of the routine dgrdal_m.f90
2. Add the call to the routine in ephybc_m.f90

That is more or less what you have to do in addition to writing the routine of
course. I propose to copy one of the external bc files called from ephybc_m.f90
and modify it.

You retrieve the variables you ask for from the data structure with the following
commands:

TTIME = GET_CHILD_R0(PGLOB,'TTIME ') ! Total time
OMEGA => GET_CHILD_R1(PDOM,'OMGROT') ! Rotation vector

Kind regards,
Peter

New Freestream BC
 

Dear Peter,

Many thanks for your kind reply. I haven't yet written the new BC but I thought I drop a few lines to explain why I believe I need it. And feel free to correct me of course!

The reason is that even if the equations are solved for the absolute velocity (or momentum) we have to consider the grid motion with respect to the surrounding environment. Within the computational domain, the motion is taken into account of course by the fictitious advective fluxes representing rotation. But not on the boundary. In other words, the computational domain turns and for instance after a quarter of a period the it will have rotated of 90 degrees. Since the reference system turns with the domain, the freestream velocity will be seen rotated by -90 degrees.

Find attached a plot of the velocity on the boundary of a rotating empty cylinder after a bit less than half revolution, using the farfield bc and a freestream U (along x). As you can see the farfield bc keeps the farfield velocity oriented like x, while the outgoing velocity has been (correctly) rotated.
Does it make sense?

Best regards,
marcello

Dear Marcello,

it makes sense.
Seems to me that only if the free stream is parallel to the axis of rotation the free stream will be constant then?

I am still not convince that you need new boundary condition. You should be able to use existing boundary conditions with a varying free stream in time. If I get it right, the free stream can be constant at each time level? Then it should be very easy to generate the file I talked above where you supply the velocity at discrete time levels. Then you could use this variation of velocity in combination with the far field boundary condition.

What do you think?

Kind regards,
Peter

Freestream BC
 

Dear Peter,

Yes of course, to both questions.

If freestream velocity is parallel to the axis of rotation the BC is stationary. This is the case of most of the turbomachinery cases.

In all other cases, a time-varying farfield velocity vector would also do the trick. I forgot to mention it yesterday.
The only issue would be to include a sufficient number of values not to affect accuracy.
I will test it asap.

Many thanks and best regards,
marcello

Rotating Farfield BC
 

Dear Peter and Edge Users,

Specifying farfield velocity as a rotating vector (in the opposite direction with respect to the rotor) by means of an external file consistently represents the combination of translation and rotation.

Here attached the result of the this on the previous example (empty cylinder) after half a revolution. Initial freestream velocity was set in x, i.e. 180 degrees difference with respect to the direction after half a rev, as it should be.

Interpolation of external bc is first order (I understand) in time. This might explain the small, grid dependent oscillations in pressure. The result was obtained with 720 value per revolution.

Best regards,
marcello