Among the mechanical designer's many responsibilities, there is one task that routinely causes a pang of hesitation: fluid flow analysis. Why? Because most engineers remember studying the subject in college and being grateful that their career plans were taking them in a different direction.
The study of fluid flow has long been regarded as a science by some, an art by others. The underpinning is a mathematical regime so complex and mysterious that it has its own name: the Navier-Stokes equations. Developed by a pair of 19th-century geniuses exploring the realm of mechanics, the equations have been a rite of passage for generations of engineering students. Some aspects of the Navier-Stokes equations are actually said to be insoluble by human hands and instead must be solved with the use of numerical approximations known as Computational Fluid Dynamics (CFD).
Fluid flow is an increasingly common part of product design. Increasingly, devices that were once purely mechanical incorporate control electronics and sensors and are expected to operate with essentially no human intervention. Consider a fire suppression system's valves and conduits. They must deliver their payload flawlessly when it is needed. And only by thoroughly evaluating the “what-ifs” of the suppressant flow can this level of performance be assured. Any mechanical engineer developing a device that conducts air, gases or liquids-or even sand or oatmeal-needs a way to predict the fluid flow response.
CFD is the most widely accepted solution, but it can present a challenge for mechanical engineers who lack special training. Imagine designing, for example, a manifold that conducts atomized fuel. Prior to a CFD analysis, voluminous details about the product's dimensions and topology must be fed into the process. If the fluid flows through hollow areas in the design, these must be separately defined and modeled as solids. Something called a “mesh” must be devised and boundary conditions defined. It's no wonder that mechanical engineers usually turn to CFD specialists to handle the translations and computations.
Unfortunately, many of today's design project deadlines do not allow for the time it takes for conventional CFD analysis. Iterative cycles of refinement are often needed but CFD complexities can limit the number of repetitions. Equally important, conventional CFD usually cannot commence until the design is at a relatively advanced stage.
Look at the prevailing method of mechanical design today. The engineer works at a PC or workstation running one of the big MCAD applications. The MCAD toolset automates many labor-intensive calculations and record-keeping operations. It imposes design rules and checks the user's work. It draws and dimensions the emerging device on-screen while recording details about solids, surfaces, apertures, outlets, and chambers.
Finding and Fixing a Disconnect
The astute observer will notice that this is exactly the information the CFD process needs. But there is a long-standing disconnect between MCAD and CFD, and this must change. There is no expedient way for the MCAD application to deliver its knowledge to the flow analysis tool. The MCAD and CFD domains have always been disparate worlds, speaking different languages. Complex transfers between the environments add time and increase the likelihood of errors. Where the engineer sees smooth curves and angles, the CFD tool needs to see a “mesh” derived by discretizing continuous features into small localized domains that can be analyzed individually. Figure 1 depicts a cross-sectioned valve whose flow areas have been meshed for CFD analysis. This is a very complex operation requiring decisions about the size, shape, and placement of the cells that make up the mesh.
Clearly, there is a need for some form of integrated toolset that will enable the designer to run CFD analysis procedures from the comfort of his or her MCAD workstation Absent such a solution, CFD analysis will continue to be a pacing item in the mechanical design timeline.
Fortunately the simulation and modeling industry has listened and alternatives are emerging. Some tools have evolved to allow design engineers to conduct analysis “up-front” by offering special interfaces CFD from to CAD. These interfaces make it easier to conduct analysis but require users to deal with two different GUIs when transferring geometry between the two environments. And meshing is still left to the designer.
Concurrent CFD is another, newer approach. Concurrent CFD is CAD-embedded, therefore it enables mechanical design engineers to analyze and optimize their designs directly within leading mainstream MCAD environments. This can save up to 75% in analysis time when compared to conventional CFD. Initiating a CFD analysis is no more difficult than running commands under the customary MCAD menus.
True concurrent CFD tools such as Mentor Graphics' FloEFD spare the designer from time-consuming operations associated with traditional and up-front CFD tools and provide the following advantages:
- A concurrent CFD application shares MCAD geometry data without the need for export or translation.
- These same tools generate optimized meshes automatically. The importance of this feature is hard to overstate, since it applies “expertise” that formerly came only with specialized CFD training and experience.
- The tools also perform cavity modeling automatically, rendering “hollow” spaces as solids so they can be meshed to predict their flow response.
- Concurrent CFD speeds what-if analysis. Models can be set up, cloned, and subjected to multiple analysis scenarios without the need to reassign boundary conditions or material properties.
A fairly routine CFD analysis can produce an impressive result. Figure 2 illustrates a lamp design showing the air flow around the exterior of the device, with color-graded details about temperature changes as the air travels over the heat source-a power LED.
The Transformation Ahead
I believe concurrent CFD can have a transformative effect on the mechanical design discipline. Integrating once-daunting CFD procedures into the MCAD realm will free engineers to try out their most adventurous ideas and see the results almost immediately. It is a situation that fosters experimentation, learning, and innovation.
Of course there are other factors. First, designers who have efficient, easy-t0-use CFD capabilities at their fingertips will check fluid flow behaviors early and often. This will prevent errors and misconceptions from being perpetuated through the design process.
Second (and directly related to the first issue), embedded concurrent CFD tools will enable more thorough testing without unreasonably extending project timelines. Of course, this will have a favorable impact on project costs as well. In the past it has been common practice to bring in external CFD resources late in the process, only to learn that the MCAD prototype's behavior is not as expected. Back to the drawing board!
Third, designers will gain a more systemic view of their device's behavior. As they become better acquainted with the intricacies of fluid flow (thanks to their hands-on work with CFD) they will learn to anticipate the fluid flow characteristics and needs of their designs-even if these attributes are incidental to the device's main functions.
We are on the threshold of a paradigm shift in mechanical design. Fluid flow analysis and CFD have always played a necessary role in product development. But the shift of CFD from discrete external discipline to integrated MCAD function will enable a faster, more agile, more productive design process.
By Erich Buergel, General Manager, Mechanical Analysis Division, Mentor Graphics Corp.
Commentary By Jeffrey Rowe, Editor
Our thanks go out to Erich Buergel of Mentor Graphics for providing this article on the increasing necessity of integrating CFD with MCAD. Once the domain of specialists, I see CFD going much the same direction that FEA took a few years ago - wider acceptance and use by non-specialists. A definite trend for the future.
I do remember, though, in engineering school that fluid mechanics (of which CFD is a branch) was one of the “weed-out” classes that separated those of us who would go on to become engineers, and those who were forced to switch to other curricula, such as liberal arts (not that there's anything wrong with that).