Dear All

I'm still new in cfd, my purpose is to use cfd programs as a design tool the question now do I need to learn the cfd as a science (I mean to know the differential equations used and the ways to solve them) or I can simply learn a program like fluent and gambit

no you cant just learn the software, this is a very common mistake people make believing that running CFD software is the same as running CAD software, i.e. you know what buttons to press and when.

CFD is not like that at all and you need to know what happens when you hit the button, what effect it will have downstream, why you hit the button in the first place and so forth.You also need to know how to analyse results, build a decent mesh, CFD is the peak of garbage in = garbage out!

I basically agree with Ben, but let's differentiate a little more:

necessary: strong understanding of the physics involved (i.e. fluid flow, heat transfer, and whatever else you are working on), understanding of the cabilities and limits of the numerical methods you are using (conditions under which they are or aren't reliable and applicable), understanding of the influence of spatial and temporal resolution (grid resolution, choice of time steps), ability to interpret convergence histories, understanding of standard methods to test and validate numerical results

(btw: understanding of the physics requires at least an undergraduate understanding of the fundamental governing equations, and includes a basic understanding of valid physical boundary conditions)

not necessary (although it wouldn't hurt): in-depth understanding of the numerical algorithms, ability to design CFD algorithms (i.e. write CFD software, derive new models), understanding of all mathematical aspects of the governing equations, ability to derive the governing equations from first principles

Obviously this list is subjective and will look different depending on who writes it. Understanding of the numerical algorithms, their characteristics and behavior, will help a lot for debugging, i.e. understanding why you got "garbage". In putting that item into "not necessary" I am assuming that you don't work just by yourself. You should have people around you, whose expertise is more on the numerical side, and who can help you out when something goes wrong. Support teams of commercial software would claim that that's exactly what they do, but ideally you'll work in a team which collectively possesses all the above expertise.

Yes, I think Mani's description description is particularly accurate. To that I would add that you will need to take your time over it to start with. In my experience many people completely underestimate just how much effort needs to go into this to even start getting meaningful results. CFD is not a part-time job. However, there is also a tendency to underestimate just how valuable those results can be, and how much you can get from them, once things start working well.

There are companies very aggressively marketing codes that are supposed to be far easier to use, and allegedly do not require CFD experts. Be that as it may (and I'm not convinced), Mani's remark about understanding the physics will always remain valid.

Working in a multi-disciplinary group, especially when there are some experimentalists around to back you up (and vice versa), makes the world of difference.

Notwithstanding anything the CFD code marketers will tell you about the auto-meshing capability of their codes, I sometimes get the idea that getting valuable CFD results is 70% about meshing. So if you are going to pick one numerical topic to learn more about, meshing is a good candidate!

I agree with Mani and Charles. One specific learning point that seems to be skipped by many people who just "learn how to run CFD" is an understanding of the Boundary conditions and their implementation in the code they are running. For example, in Fluent I've seen people trying to use a Velocity Inlet BC for compressible flow... but in Fluent, a Velocity Inlet does not have any way of defining the Pt (for compressible flow it can't even define your Dynamic pressure due to the variation in temperature and density). Or trying to use Outflow BCs in areas where you still have influence from the geometry (not a "fully-developed" flow) simply because they don't have enough information to use a more defined BC. Or posting questions about why Fluent won't let them use a Pressure-Far-Field condition with an incompressible flow, or why when they use PFF for a pipe inlet the solution diverges... Without REALLY understanding what BCs you are using, then there's no telling what you're going to get out of a model. And what's scarier is that people present bad solutions simply because "it was a converged solution"

Continue your education. You can start learning to use the tool in parallel, assuming you have people around you that can help. Ask questions of the people around you. They're going to be your greatest asset.

These black-box codes (codes where you just give it a geometry and it does everything else) that are coming out are interesting. Anyone can run them. But is the solution any good? The problem there becomes that the person running the code doesn't know what to look for, and to make it worse, the limited tools available in the black-box codes make it hard or impossible to look for it if they did know what it was. I think these tools have come a long way, but there's a VERY long way to go before you can really trust them for much more than basic assessments and pretty pictures. And even then, I'd rather an experienced CFD person look over the setup and solution for problems.

IMHO, Jason

I just want to add one point to this discussion. Hardware knowledge. You might be the best race-car driver in the world, but without a good car you will have a hard time against lesser drivers - with better cars.

You might want do write a paper where you need results from simulations. Considering that there are numerous people doing CFD chances are you are competing against someone else (time). It won't matter if you have perfect BCs etc. if that someone publishes his/her paper before you do.

A quick peak at the following sites once in a while will really help in deciding what hardware to use:

www.xtremesystems.org www.anandtech.com www.tomshardware.com

(of course not regarding "real" number crunching machines using expensive non-maninstream CPUs, that is a whole other area)

I hassen to disagree with the previous answers in this thread most profoundly.

Chemical background. I then did a 1 week course in Fluent, learnt to try pressing all the buttons until I got the answer I wanted, matched it in numerous different physical applications.

Since then for 5 years I have been producing results for customers, not had complaints, designs have worked, brought in 0.5 million revenue and created about 40k profit for my company in that time.

And I'm always honest about being a "black-box" user. I wouldn't know the Naviers Stokes equations if they came up to me, sat on my desk and started undertaking a Lattice Boltzman simulation.

It's a question of maturity. CFD hasn't reached the level of maturity enjoyed by most other mainstream CAE tools. It is still practised by many people who have written their own codes in the past and see a commercial code as nothing more than a glossy wrapping around something they could have written themselves.

How many FEA analysts know how their codes work under the hood I wonder. And CAD users.

Taking it a step further, how many spreadsheet users could write their own spreadsheet program?

You can tell when a CAE tool is immature by the way people use it. CFDers think nothing of: hacking input files; pulling columns of number out of huge text files to make DIY plots; killing off an analysis; deleting big core files; writing big user routines.

Users of more mature tools expect to be cossetted. They want glossy GUIs and ribbon-wrapped outputs. They want the code to actually solve their problem for them. They want modelling errors to be found and fixed automatically. They want ridiculous levels of accuracy. Users of these codes do not want to know how they actually work.

And one day CFD tools will become mature.

"You might want do write a paper where you need results from simulations. Considering that there are numerous people doing CFD chances are you are competing against someone else (time). It won't matter if you have perfect BCs etc. if that someone publishes his/her paper before you do."

Actually it is more important to be the person who publishes the correct results and not the one who publishes first (ideally you should be both). In practice it's very rare to be in actual competition to get your results out faster than your competitor - good scientific research just doesn't work this way.

Personally speaking I could never run my 3D LES simulations on anything as slow as a AMD/Intel processor

I have heard that maturity argument a lot but it's really less than half the truth. Even with the most mature code you'll get nowhere without a mature user. There can be no code that takes your geometry and magically comes up with appropriate boundary conditions and a solution to your problem. Even a perfectly mature code will require input from the user, and that's one of the weak spots (the other one is interpreting the results, which no code will do for you).

Before you even start pre-processing a CFD case, you need to define the problem. That's the first point where understanding of physics comes in. There are a lot of ways to screw up by ill-posing a problem, and no code in the world will give you a valid result on an invalid unphysical problem (yes, some codes may converge to an irrelevant solution... but that shouldn't be your goal).

As Jason has pointed out in his examples, people screw up by choosing inappropriate boundary conditions, because they lack understanding of physics. The same lack of understanding will then tragically lead to the failure of interpreting the result and recognizing them as garbage.

Will these users still get a result? Maybe. Will their customers be happy with the garbage? Hopefully the customer will have some understanding of fluid flow and recognize a flawed analysis when they see it, but there is no guarantee...

Maybe part of the problem in understanding the requirements for CFD is that some people don't understand that there is more to it than just running a CFD code and make it converge. You have to be able to (1) define a physical problem, (2) use CFD to solve it, and then (3) interpret the result. No software will do steps 1 and 3 for you, regardless of how mature it is.

Maturity of your CFD code is desirable, but nothing will make up for your own immaturity.

"...learnt to try pressing all the buttons until I got the answer I wanted..."

That's so wrong, I don't even know what to say... Analysis and prediction of fluid flow has nothing to do with a trial and error game to "press buttons to get the answer you WANT".

You can't be serious (right?)

I have a question for NP, what types of flows have you tought yourself to run? I can only imagine that you have knowledge extremely limited to one field and that if you wander from that field then you are likely to be lost. When things go wrong, do you intuitivly know how to fix it or at least what avenue to start looking down or do you just pick up the phone and dial technical support? Maybe this is the type of user that we shall see in the future able to produce reasonable results in a limited field, button clickers basically.

I think that comparing CFD to FEA in terms of usage is somewhat dangerous as the physics, variables and situations involved are so vastly different and the levels of complexity so much greater in CFD (not to mention other variables such as increased mesh dependency, larger more complex meshing and vastly greater range of models and numerical schemes......) that a straight comparison would be like comparing a super computer and a PSP.

I guess it depends what you want to be in the CFD field, the monkey or the organ grinder...

I do not fully agree. Hardware gets important once you really know what you're doing and once you're really sure you're doing it the right way.

I remember having done projects that were done in parallel by other companies. While one of the companies had been running hundreds of RANS calculations using a GA, we came up with a forgotton analytical solution from the 20's and ran only one RANS calculation to check for viscous inaccuracies, which were expected to be low, and they were low, so low that we had the solution at once. No clusters, no mega computing, just using common sense.

Of course for LES people there's no other way than brute force, but it certainly doens't hold for all CFD, or better, for all aerodynamic design. Get away from that screen once in a while!

On the other hand it's complete nonsense to think that someone will publish a paper before you, only because he had a better computer. If your idea is really new, you will be the first one anyway, a race against the clock wil only occur for results that are possibly not worth publishing at all.

The client comes to you for a solution, because he doesn't know about CFD. Next, you give him some numbers, not knowing what you don't know. As the client doesn't know either, which is the reason that he came to you in the first place, he believes what you produced. You're unintentionally fooling the client by fooling yourself.

"I remember having done projects that were done in parallel by other companies. While one of the companies had been running hundreds of RANS calculations using a GA, we came up with a forgotton analytical solution from the 20's and ran only one RANS calculation to check for viscous inaccuracies, which were expected to be low, and they were low, so low that we had the solution at once. No clusters, no mega computing, just using common sense."

Well, so if you had a faster computer your work would not proceed faster? Compare apples with apples..

"On the other hand it's complete nonsense to think that someone will publish a paper before you, only because he had a better computer. If your idea is really new, you will be the first one anyway, a race against the clock wil only occur for results that are possibly not worth publishing at all."

I would say that it is nonsense to state that your idea will grant you success by itself. If your funding runs out just because you are slow, well too bad right? Time = money. Money is king of science. (ok this might not apply if you come from a university/organization with unlimited funds and/or your idea is truly exceptional in which case you might have all the support you ask for)

The maturity argument...

I guess my point was that it'll be a sad day when CFDers finally drop to the same level as today's users of the more mature simulations. Nothing can generate useless data as fast as a novice with a shiny new CFD code and a fast cluster.

There's a lot of fun to be had (if you are that way inclined) tuning and tinkering with computers. However, it's often difficult enough to get good CFD results without diluting your focus! I would say though, that you do need to savvy up on hardware if you are doing CFD. It IS a critical part of the system, and a smart choice of hardware can save a lot of time and money. Just don't get hung up on it ...

Thank you. That applies to everything in CFD. I have said nothing about tinkering around with computers and loose focus on overall CFD... A good algorithm is Very important for calculation time as well, but there is no point in trying to develop a new one each time you run a new case. You can easily loose focus on alot of things and get bogged down. So my point still stands since I get the feeling that hardware is often neglected (obviously), people just accept what big vendors provide. Everything counts and our field is called COMPUTATIONAL Fluid Dynamics.

"I would say that it is nonsense to state that your idea will grant you success by itself."

This comment is nonsense - a good piece of research stands on its own merrits. A large proportion of my fluid dynamics papers contain only a small amount of computational work and actually only a few of my papers contain numerical simulations of the full Navier-Stokes equations.

Following your logic I should stop publishing fluids papers in JFM, EJM/B, QJMAM etc which do not contain huge amounts number crunching on a supercomputer since it would be foolish of me to think that the papers were worth publishing. I have unlimited access to a supercomputer at work and I can tell you that it is very easy to run large simulations but when it comes time to write up the work it is the original idea of why you did the simulations that is important (its just nice if they run quickly).

I work and have been working alway in commercial companies, which is exaclty the main reason for using lower order methods. The example I gave is only one of the many many many that I see in everyday life.