With the release of **SOLIDWORKS 2016**, you can simulate fluid flow around rotating bodies with much higher accuracy. In fact, this is the first time that Flow Simulation has been able to handle an instance of a “Moving Mesh” problem. Prior versions of the **Flow Simulation** could simulate propellers or turbine blades, but they did so by using a “Rotating Reference Frame” approach. Going forward, SOLIDWORKS will maintain *both *methods of solution, as they each have relative strengths and weaknesses. In this article I will compare and contrast these two methods for treating rotating flow, and pass along some tips for getting the new Moving Mesh method to converge as quickly as possible.

#### Old-School – Rotating Reference Frames (RRF)

As a point of reference, let’s consider a familiar, non-rotational flow problem. You want to test the air drag around the body of a new car. Instead of creating a really long, instrumented stretch of test-track, and driving the car down the middle of the track – we put the car in a wind tunnel. This is effectively a change in our reference frame. Instead of the road (and the air mass) being stationary, it is the car that we hold stationary, and the air mass is driven *at* the car. All the drag and pressure measurements will still be correct. Changing the frame of reference made a difficult problem, easier.

Now consider the fan blades pictured below. The shaded cylindrical region is added as a separate solid model, and within the Flow input folders, it is declared as a rotating region. When the user inputs rotational speed, the direction vector should be the direction that the solid(s) would/should move. But internally, the software will actually spin the air within that region, in the *opposite* direction to throw the air at the blades.

Clearly, when an upstream particle of air from the far-field, which is NOT spinning, first enters the RRF, there is some energy-accounting to be done. You should be familiar with this, because it is the source of important limitations of this treatment. A rotational velocity is slapped on top of the particle’s incoming velocity. This results in a higher tangential velocity for air entering at the larger radii; it adds a smaller tangential velocity near the hub; (and actually, zero tangential velocity for air entering exactly along the axis of rotation). This of course adds to the kinetic energy of the air, so a commensurate amount of Static Pressure is subtracted, so that the *Total Pressure* of the air is preserved across the RRF interface.

When an air particle leaves the RRF, (either thru the cylindrical disk face or the planar back face), then the reverse math is applied; they subtract off the tangential velocity, and add the equivalent amount of energy as increased Static Pressure.

The accuracy of this trade-off is good, as long as the flow conditions across the exit face(s) are fairly uniform. That is, it presumes that the *averaged* flow vectors across the exit face, is a fair representation of the* local* flow vectors. The flow can exit predominantly from the back, planar disk, as in the prior image. Or, the flow can exit predominantly out the outer cylinder bounding the RRF, as in the image below. Either way, there should not any nearby stator vanes, or cage struts, i.e. no features that would break up the radial symmetry of the flow field.

The second critical feature of this approach is that the Inlet boundary condition must be imposed as a Mass Flow rate, or a Volume Flow rate. Again, this amounts to a requirement that the inflow be uniform, prior to hitting the upstream face of the Rotating Reference Frames.** **

**Rotating Reference Frames – Advantages**

- This method computes relatively fast. The parts do NOT move, so the initial mesh only needs be computed once.
- This method can be used for both Steady-State, and Transient studies.

**Rotating Reference Frames – Disadvantages**

- If there are nearby struts, housings, or stators, that would disrupt the uniformity of the flow field across the outlet face(s), then the presumed enforcement of conserved Total Pressure across the RRF exit faces can produce inaccurate results. Similarly, geometric intrusions near the
*upstream*faces can reduce the solution stability and prevent convergence. - There can be other flow discontinuities, variations in the variables of state that are not uniform across the RRF boundary – these could invalidate the energy balance. For example, if you have a water flow with “cavitation” turned on, then the fluid density can vary widely within the RRF, and the trade-off of static-for-kinetic can create spurious fluid density changes. If the tips of the blades approach trans-sonic, then again there can be meaningful fluid density variations, that either get suppressed, or exaggerated, when the fluid crosses an RRF boundary.
- The rotating parts do not actually rotate. Whatever ‘pose’ the rotating parts are left in, are presumed to be representative. Consider the pair of counter-rotating props, below. The position that the props are mated to, relative to each other, can present very different form drag at different angles, when in fact the
*TRUE*operational thrust, drag, and torque will be a composite of values averaged across*all*possible positions. The best you can do with the RRF method, in cases like this, is to run cloned studies to gather results at a sampling of different positions, and then manually average them. - If the rotation speeds are very high, especially when the tip speed will be supersonic. The kinetic energy within the RRF can be so high, that the subtraction of the equivalent static pressure can result in highly negative pressures. That may not
*seem*like a problem. But consider that Static pressure within Flow is always an absolute pressure, not relative! So an absolute pressure lower than zero, cannot really happen. This creates instability in the solver when it tries to apply ideal-gas-law or other equations of state to determine density, viscosity, heat capacity, etc. The combined effect of items 2 and 4 together means that this treatment is seldom going to work for high-Mach gas flow.

#### New Tricks In 2016 – The Sliding Mesh

There’s only one disadvantage to the Sliding Mesh treatment, but this item is also what accounts for all of the advantages. That is, it is only available for a Transient analysis. You will not see the “Sliding Mesh” option in the New Study wizard, unless you first set the study type to “Time Dependent”. If you are really only interested in an averaged, steady-state result, I’ll share some tips later for getting those results *from* a transient study, as quickly as possible.

Other than that, the good news is there is very little else, as a user, that you need to know. No funky energy balances, no gross simplifying assumptions. The parts simply rotate. Consider the scroll-vane blower pictured below. The outer housing, and the 4 central stator vanes, are fixed. The fan cage rotates, so an annular solid control region (light yellow) encloses this rotating part. At any given clock-position around the housing, the blades will see a continuously-varying neighborhood, with a corresponding pressure pulse each time a blade passed closest to the wall. The lower sequence of meshed plots shows that the initial mesh (originally parallel to the static mesh) actually rotates to a new position at each time-step. This gives you the best-possible accuracy.

*Fig. 5: Position of the Sliding Mesh region shown at three (very close) time-steps*

#### Sliding Mesh – Appropriate For A Wider Range Of Problems

One of the limitations of the RRF treatment is that, for best convergence, you really need to specify either a Mass-flow or Volume-flow rate at the inlet. If you don’t KNOW the volume flow-rate, (if in fact that’s what you’re trying to figure out), then you have to *guess* at the flow-rate, and then apply goals to measure your back-pressure – and then, iterate the study, adjusting the flow rate until it produces the desired pressure-drop. Not fatal, but it *IS* a little clumsy.

But with the Sliding Mesh treatment, I don’t need to specify a flow rate, anywhere. Just a pressure condition (inlet or outlet) and the spin rate, and the physics will take care of the rest.

This enables us to now treat tank-stirring problems. So, you have fluid in an enclosure, and there is NO inlet and NO outlet, and you have a fan/pump to stir the fluid. Maybe you want to see how long it takes for a mixing-problem to homogenize, or for heat to soak-out to a uniform temperature. We can solve such a problem now, because the only boundary conditions required are the impellor speed, and a pressure condition somewhere (like at a small, static vent).

#### Sliding Mesh – For Steady-State Problems

Clearly, a moving-boundary flow problem is never really steady-state, so what we are really talking about is wanting a good time-averaged solution for the flow rates, pressure values, etc. Steady-state problems usually run quickly. But the time-varying treatment of the Sliding Mesh is always going to run slowly. Or, is it?

A lot of the problems reported to me, as my users ramp-up on this new capability, is that the time-dependent study wants to micro-step the time intervals, so the answer will take forever. That’s true, but only if you try to treat boundary conditions as steady state! What if you use time-varying boundary conditions, to let the problem ramp-up gradually to the final desired speed?

Consider the squirrel-cage blower above. If I want to know the exit flow-rate when the blower runs at 360 RPM, you could set this up with initial conditions all at zero velocities, and then apply a constant spin rate of 6 revs/second. Maybe you assume the ramp-up time will be about 2 seconds. Then hit GO. Then go get a coffee. Why? Because the disparity between the fan speed, and the quit air, is so great. The system will want to baby-step the time interval, in order to give you the most accurate result possible at every moment. In the first few hundred iterations, the problem above selects an auto time-step of 0.8 milliseconds. The time-step will eventually start to increase as the air mass starts to approach a steady-state condition – cold comfort, because you’ve already paid all that solution time up-front. The total solution time (for 2 seconds of ‘real time’) was **5 minutes, 11 seconds**.

But let’s say you don’t care about the accuracy of the ramp-up period, only that it should produce good numbers once it is up to full speed? Then you clone the Squirrel-cage study, and make only one change – that the rotation speed should be a linear ramp, from zero, to 360 rpm, over the whole 2 seconds. The initial time-steps for this study are about 50-60 milliseconds, and the study convergence is greatly enhanced, because the air mass is subjected to much more gradual changes. The CPU time is now only **2 minutes, 40 seconds**. The faster your equipment is spinning, the greater the timesaving’s from ramping it up gradually.

Finally, If you want the study to run a little past the point of reaching full-speed, you can create the Rotation boundary condition as a table instead of an equation, and give it a last quarter-second or so of steady speed, to make sure your goal plots are running flat. Sometimes I do this by instead cloning the study, and have the clone take it’s Initial Conditions, from the ramp-up study’s final conditions – and then just run the blower for another quarter-second at full speed. I’ll take that extra effort, when I want goal plots that are not cluttered up by the ramp-up interval, making it easier to pick up harmonic responses.

That’s it for now! I hope you find cool new applications where you can take Flow Simulation 2016, out for a spin.