Learning Forum

[Engineer86]

Hi,

I’m trying to model a small 4 bladed rotor and have two hopefully small queries.   The model consists of a 360 mm diameter rotor with 4 blades of 70mm chord.  The rotor rotates at 500 RPM CCW which gives a chord based Reynold’s number of approx. 40,000.  Each of the 4 blades pitches in a sinusoidal manner to +/-45 degrees as the rotor rotates, in one rotor rotation.  The rotor geometry is shown in image 1 below. 

To achieve the mesh motion I’ve created a Define_CG_Motion UDF for the rotor and each of the blade regions, and defined a dynamic mesh for each treating them as a rigid body.   The moving meshes are working as they should in preview mesh motion, but one thing I am finding is that there is a velocity gradient across each of the blade interfaces as shown in image 2.  There is a non-conformal mesh at the boundary due to each part being imported as separate bodies from Solid works. 

I’ve tried conformal meshes and refined the mesh in this area to something that is really fine and the problem persists.  Along with structured and unstructured meshes.  I’ve also tried a 0.05mm gap at the interface and the situation is the same.  The velocity discontinuity is typically only 1-2 mesh elements high. 

I've checked the model setup and can't see anything else that could cause this.  I've also undertaken a time step sensitivity analysis down to 0.25deg/step and it's still the same.  I am solving the problem with the k-ω SST model with low Reynold’s Correction.  I’m using a coupled based solver and have the residuals set to 1e-4.

The overall geometry extends to 20 x rotor diameter on all sides.   The rotor is essentially a small rotor in a large room with no imposed free stream velocity.  The rotor generates its own wake so I have assigned each of the boundary conditions as symmetry so the normal velocity component and pressure at the symmetry plane is zero.  I am not sure if this is the best boundary condition?  If I used a velocity inlet it would be zero.

Any information on the two queries would be much appreciated.

[Rob]

Not sure how we missed this, but feel free to bump after a few days. 

You shouldn't need dynamic mesh for this, the sliding mesh is sufficient, and I'd suggest looking at the effect of absolute & relative motion. We've got a tutorial (that I can't share) on this showing the set up. 

Discontinuity doesn't look severe, but still needs checking. Have a look at the cell size on either side of the interface and post a couple of images (zoom into the interface). Also check position incase you've got an overlap or gap. This isn't quite it, but does show what I mean by absolute/relative motion. 

https://www.youtube.com/watch?v=93hxZuIA75I

 

[Engineer86]

 

I’ve looked at the setup on the YouTube video and some other data I found with regard to relative velocities at the blade/rotor interfaces and this is how my model is setup.  To get the sinusoidal blade motion I’ve been using DEFINE_CG_MOTION.  But as a check I removed the UDF totally and reran the model using the same mesh and time step, but this time used sliding meshes only with the rotor rotating at 900 rpm and a blade rotation of 100 rpm for each blade ignoring the sinusoidal motion.  With the sinusoidal motion ignored the velocity discontinuity disappears.

 

This made me think that there was an issue with the DEFINE_CG_MOTION UDF used with the dynamic meshes.  To check this I’ve written a DEFINE_ZONE_MOTION UDF so that the motion can be defined with sliding meshes, but the issue is still the same.  The structured mesh that I’m using either side of the blade interfaces is shown below.  The current time step is 9.25e-5 seconds which gives 0.5 deg/step of rotor rotation.  The plot shown has a 0.05mm gap at the interface.  I've also run the model with no gap and the issue persists assuming the same mesh.  The walls at the interface have a no slip condition which is the default.   Around the circumference of the interface there are approx. 500 cells at present.  I'm not sure what the mesh size at the interface needs to be based on.  The blade region is shown in the darker red below.

 

[Rob]

The walls shouldn't do anything: they're there for when the interface zones don't overlap. In this case you should have full overlap. 

The mesh pairing looks OK, where is the 0.05mm gap? Does your UDF have a fixed speed? 

 

[Engineer86]

Hi,

 

The 0.05mm gap is currently at the position shown by the red arrow below.  In the final model this will be removed to give full overlap as you say.  My initial studies had full overlap and the issue was the same.  I included the gap to see if the overlap was the issue, but it looks that this isn’t the case. 

 

There are 5 UDF’s in total, one for the rotor region and one for each of the blades.  The speed for the rotor UDF is fixed at 900 RPM for the current study.  And the fixed time step used in Fluent gives a rotor rotation of 0.5 deg/time step.  The speed for each of the blades is not constant and varies in a sinusoidal manner, so it’s continually changing as the rotor rotates.

">

 

 

[Rob]

Drop the UDF for the main rotor is it's constant speed. Are the smaller rotors then set to rotate locally relative to the adjacent zone? How does the convergence look? Turn node values off too, that way we can check if it's the solver or post processing that's at fault. 

[Engineer86]

Hi,

I’ll take out the UDF for the main rotor as its constant speed, the rotor always rotates CCW.  Each blade then rotates locally relative to the main rotor CCW from 12 o’clock to 6 o’clock then CW from 6 o’clock to 12 o’clock, to give the sine wave blade motion.

I have been checking convergence by calculating the change in lift and drag forces for subsequent rotor rotations through the lift and drag monitors.  I can’t get the change better than 1-2%.  The curious thing is that the blades at the 12 and 6 o’clock (blade 1 and 3) positions show reasonable agreement and the blades at the 3 and 9 o’clock (blade 4 and 2) positions are close, but they are slightly different to one another, despite the mesh and setup for each being identical for all, they should all be the same. This is shown below for the last rotation cycle that is 13680 to 14400 time steps or 19-20^th rotation.  It doesn't improve if I keep running the model.

The plots for velocity magnitude are below with the node values turned on and off.  I’m using the k-omega SST model with low Re correction, and the coupled solver for velocity /pressure coupling.  Everything else are the default Fluent settings including the under relaxation factors apart from I’m using the dual time formulation. 

I’m using a velocity inlet at 0 m/s as there is no free steam on the model, with a pressure outlet and two walls as the boundary conditions.  The rotor generates its own wake.

">

Node values on - velocity magnitude

[Rob]

Set the inlet as 0 Pa too. That shouldn't do much but it's not zero velocity either. 

Check the overlap on the interface too: I've not seen this flagged into support so it's likely to be something in this specific model. 

[Engineer86]

 

Thanks for that. 

 

In terms of the interface overlap, currently I’ve made the diameter of the interface the same diameter on both the rotor and blade region, so that the parts are touching at the interface.  I assume this is correct?  And that the bodies don’t physically interfere. 

 

For the 0 Pa inlet, would this then be a pressure inlet?

 

May it’s a model creation problem, which is something I can look into.

 

[Rob]

Correct - the faces/edges should be in the same place. There's an interface checking tool in the solver: make sure you're looking at over 99.9% contact on the interface. 

Pressure inlet, yes. That way the blades can push/pull air as needed.