The following article challenges some of the long-standing 'myths' surrounding CFD:

http://machinedesign.com/ContentItem...ythsofCFD.aspx

these topics seem ideal for a discussion forum, so as the article is fairly recent it seems worth posting here. Comments welcome.

One myth that I still think is valid is that CFD is difficult. Code vendors tend to want to tell their customers that all designers can and should use CFD. However, this would require very strict best-practice guidelines and validations of exactly how CFD should be used for the application of interest. If you put a CFD tool in the hands of someone without any previous experience of CFD and no guidelines on how to use it he will most likely not produce any reliable results. CFD is still somewhat of a black box that requires experience to produce realistic results. You need to know which turbulence models, combustion models, gas models etc that work for your particular application. If you do not know how your mesh should look to resolve the important physics you will not get very reliable results from a CFD simulation.

You are right up to a point. General purpose software generally tend to have several of everything - turbulence models, differencing schemes, mesh topologies etc, some of which, like turbulence models have a relatively narrow range of applicability, and vastly differing computational cost. Faced with a selection, the user requires experience in order to select an appropriate option. This is compounded as not all combinations work equally well, either numerically of physically. So, in the context of general purpose CFD I agree with you.

Flomerics produces specific purpose software like FLOTHERM, which has allowed thousands of electronics companies to improve the design of their equipment without the need for any CFD knowledge. This is because the product does not allow the user choice over the above. They do need to have knowledge of the physics of the problem they are trying to solve, and hence be able to decide that the results are realistic. Some CFD issues of course remain under the users control, like mesh refinement, but the intention is to make the software as safe to use as possible. EFD and Floworks follow a similar philosophy in that they provide a combination of mesh topology, differencing scheme, near wall treatment etc. that are designed to work well for a wide range of applications, and in particular are designed to work well together. There are many mechanical designers that do not have the background to be CFD experts, yet need to use CFD in their jobs, usually within a narrow field of application. Typically they understand the physics of their application pretty well, so validation becomes very important as it is necessary to prove that a particular software solution can give accurate results.

Yea, for application oriented codes like Flotherm I might agree with you. But for a general purpose code I am quite convinced that there exists no single mesh topology, turbulence model, differencing scheme, convergence criteria, etc. that will work well for a wide range of applications.

It requires experience to be able to tell which mesh, turbulence model, differencing scheme, convergence critera etc. that should be used for a particular type of application. I have not seen any code that can replace an experienced CFD user in making these selections and evaluating the validity of the results afterwards.

Validation can of course solve this problem, but only if you validate your code on an application similar to the one you want to predict. One important part of a validation excercise is just to learn which models and which methods that work best for your particular application.

The other key element in successful CFD is of course good quality support and training. If you have someone to turn to when it all goes wrong that is bound to help. There seems to be this drive to push button CFD (EFDLab, Fluent for CATIA, STAR-CAD etc etc) which is all well and good but without decent CFD knowledge you are not going to ge very far. CFD is a real GIGO application so you need someone decent at the end of the phone to turn to, and this isn't just about people being able to tell you which button to press but also have the CFD background to tell you where you are going generally.

P.S. This isn't going to continue as a glorified Flowmerics advertising formum is it? John obviously works for them and it is fair enough he is trying start some discussions but it is fairly thinly veiled marketing at the moment!

I think we are slightly cross purposes here. There are a number of very challenging applications where considerable expertise is required on the part of the user. You mentioned combustion in your earlier post. Because combustion physics is very complex and highly dependent on the situation choosing the right model requires considerable knowledge not just of the physics but also the numerical options available and their respective limitations. However, these are only a small fraction of the problems to which CFD can be usefully applied.

John, no argument about the need for good support. I was keen to provide at least some content for the first visitors to the forum to encourage them to post and return. The hope is that will become a useful technical resource.

Also what looks like a very simple case to predict can cause significant problems in a CFD code. Here are a couple of examples:

Most turbulence models have problems to predict stagnation flows. As soon as you have a stagnation region that affects the flow downstream you will quickly run into turbulence modeling problems.

Another problem is when you have fairly low Reynolds numbers and large parts of the boundary layers remain laminar. Predicting laminar-turbulent transition is very difficult and requires detailed knowledge of the particular application. With a normal two-equation model you will almost always predict turbulent boundary layers all the way. This is often not a conservative prediction and if you are unlucky the real case will separate the laminar boundary layer and not have a flow field that is even close to the fully turbulent CFD results that you predict.

I can go on and on and talk about other problems that often occur in what looks like simple CFD cases. The fact that there are applications that are even more difficult to predict does not make normal CFD a simple and problem free task.

I can't comment on your specific examples, but I do take the point. What can seem a simple problem may not be straightforward. Many years when I was at CHAM I remember having considerable trouble getting a developing laminar pipe flow case to converge, and eventually discovering that lack of damping on the radial velocity component was to blame. A diffusion-based false timestep value fixed the problem. I guess this illustrates the importance of validation, and an understanding of the physics!

The idea is good, to have a simpler way to perform things. Look at FEA codes, my colleagues hardly had to know anything much about the code or trials and errors with the settings. They can get results quicker and often very good correlation. From business or industry point of view, delivering results on time matters the most. Expertise in handling the tool without yielding results on time is not appreciated. CFD code has been marketed as an area of study instead of a useful tool; just look at the name! Nastran or Ansys didnt produce FEA code but rather limited area of structural computation code. There are limits in Nastran which they dont bother and let Abaqus or Marc perform. CFD commercial codes should be that way; specifically tailored and not overcost. Star-CD came up with good ES modules for people in suitable industry but as an add-on to the existing code instead of an exclusive tailored code, which could attract more customers and revenues if only they had revolutionized their sales operation, I think. Most people in industry, get stuck with the same fluid problem for years, doing it routinely so they dont have to bother about supersonic flow if they do combustion nor do they bother about transition if they do only mixing.

Niche. That is exacty right. EFD is aimed at mechanical designers working on a specific range of applications, such as valves or pumps or electronics with complex geometry. Usually during the evaluation they model a typical application, thereafter they need to explore the design space for each new design or design variant. That typically means making lots of design (i.e. geometry) changes. Typically the physics being solved is not particularly challenging, although EFD does handle some specific complex flow features well, like non-Newtonian flows and cavitation for example. Interestingly it does find use by consulting engineers - Voxdale for example: http://www.voxdale.be

Geez, you have to realize (or at least be aware of) the fundamental differences between FEA and fluid PDEs, first order convective terms and turbulence driving, thus requiring excessive numerical diffusion to converge commercial stuff, and dispersive oscillations when not controlled, you are exactly illustrating the problem with this bright approach of CFD for the masses, if you smear your little supply diffuser and have no clue it happened what's the point of all the iterations

This might liven this discussion up and it is all in good fun:

Come on guys. You can't ski powder unless you get in it. Further, the underlying tone that is present in this discussion is that CFD is an elitest sport - this kind of ticks me off in a low emotional content sort of way.

One has to make the distinction between engineering and scientific endevour and the situations risk. In many situations almost any analysis is better than no analysis which is a situation many people are in. Not everbody is designing hypersonic re-entry vehicles where the test cost is enough to justify detailed methods and various validation schemes to acquire confidence sufficient to actually do a test. Some people just try to get the nozzel on a garden hose to have a more flow. And what about the person trying to get his firms line of pool filter manifolds to get more or less even flow through every port (say a 10% variation over the no analysis method of in excess of 100%)? Do these problems required a Phd and some labour intensive hard to use CFD code? Is it even a good use of a Phd's time from a societal perspective for that matter? How about the elctronics designer who is just trying to ensure that his components are not marginal at his max environment temp? Some of these guys just don't realize off the top of their head where an eddy is going to form - imagine that.

In these sorts of situations what do you think the benefit ratio between the results provided by an "EFD" analysis tool versus no analysis or to the Phd running a hard to use scientific code? Those of you with elitest views of this field need some exposure to what your average engineer in say a fluid handling shop faces every day. Designers are interested in lowering the surprise ratio not in getting an answer to another order of magnitude in accuracy. They are just trying to get it in the ballpark of success.

Argue that one with a turbulence model issue.

Ah that was fun....

"All models are wrong, but some are useful". G. E. Box.

Really nicely posed viewpoint Bill

Thanks. Its all an approximation an it is good to keep that front and center.

Nope, has almost nothing to do with specific software, arguably most commercial stuff is written to converge for the broadest class of problems and any major or "less" major vendor would have "simplified" CAD oriented versions. The elitist question is different though, reminds me of the Holiday Inn commercial, when I fly I want a professional at the controls, why would CFD be any different? It is based on solid and fundamental science and not having any clue even about the basics of what you are solving like comparing stress modeling to flow problems is rediculous and in elitist words "cheapens" the experience and believe it or not from a business standpoint no results is better then scrwd results, at the end of the day your company's name is the most important asset and you lose it and a load of money with it by mindlessly pushing buttons believing that whatever comes out of the code has some relationship to reality...Mind you I am not advocating exactly all the streaks at the wall for Lab optimization, but when an architect and ME go back and redesign a whole bunch of holding rooms because you told them the temp. is below target and it's not, trust me it's a problem and trust me your boss would hear from them and the question would be why in the world are you pushing buttons when you don't even realize the eddy is supposed to be forming here...

Sorry for my delay.......

That is a completely different issue. That is an issue that is very dear to my heart which is how does a company ensure that the information that they base their decisions on is sound. While "expertise" is certainly something of value, even good people get surprised, hopefully less often that not so good people. Risk management is a very central element in using CFD or FEA or any other simulation technology not to mention engineering in general. Betting the farm on the basis of a CFD simulation alone is not a top notch move. Of course the response form the Elitist crew will be that it can be done. And I will agree, but lets not foget that a vast array of learned skill and experience will also be a major contributor to making a high end bet. My essential point in all this is that one can dive in a give it a go but appreciate what you don't know and don't go betting the farm. That's just stupid. Also, the guyor gal flying the airliner started out on a Cessna 150 or lesser aricraft.

I think we are converging sort of... the problem is inexperienced people do not get surprised at all, they just do not know any better, that's how you get people running LES on 50000 cells in a floor plan (clearly not an issue for this particular software since they do not have the capability?) and getting amused at how it all seems to be so cute and real, btw just go get maya, better movies... but, yeah engr. design and not a research Lab is what you are looking for most of the time, you just need a professional to oversee the farm (not to push buttons) and it is a job of a professional to get surprised, and the last thing I want to hear is "on behalf of the ground crew welcome to the flight to ... and now I will go fly the plane)

Like I said at the outset you can't learn how to ski powder unless you get in it. Though it is nice to have some one to follow who can just shred it up in the steep and deep. Helps with the humility too.

That's all good comment, and something I would like to add is that the marketing assertion that "other, traditional" CFD codes are too difficult to use is just nonsense. Commercial CFD codes have been pretty easy to use for quite a while now. In my experience, it is actually easier to use and abuse these codes than it is to do a really good solid model in the CAD packages.

That aside, a disturbing trend that I have recently encountered is the assumption that just because you can drive a CAD-integrated CFD code (not mentioning any names), that automatically makes you knowledgeable in fluid dynamics. This is just so much of a cliche .... I have seen some of EFD's marketing materials where the point is made that the tool has been developed for designers who do know their relevant physics. That's a very important statement, but it seems to have been lost on some of the users.