Sunday, August 28, 2011

Undergraduate CFD Education

CFD has become an indispensable design tool in many industries, especially in aerospace, automobile, micro-electronics, mechanical and chemical industries. The yearly worldwide revenue in CFD software is estimated to be in the hundreds of millions of dollars. In many industries, undergraduate students with CFD skills are highly sought after.

Iowa State University has been a pioneer in CFD research and education for over 4 decades. One of the most popular CFD text books was written by ISU faculty (Tannehill, Anderson and Pletcher). ISU's aerospace engineering education has always a strong emphasis on CFD fundamentals and computer programming. A basic CFD course has been taught as a senior elective for many decades, and has been a very popular one.

There is another paradigm in CFD education, maybe to reduce the cost at the undergraduate level. In this paradigm, students are taught how to use a particular commercial CFD software. The course is then centered around one CFD tool. The students learn "push button" CFD without having to learn how to program any computer languages. This paradigm has even been adopted by some PhD programs. In fact, I was told by a friend in the industry that he interviewed a PhD in CFD, who does not know what the Navier-Stokes equations are!   

I would like to know whether our way of teaching CFD is out of dated. Do leave a comment if you have an opinion. In addition, do you have a preference on which language should be taught, Fortran, c, C++, ...?


  1. I don't have the knowledge to say what can be considered "outdated" in a curriculum, but I've certainly benefited greatly from strong undergrad programming experience and picking up CFD away from the "push button" approach.

    I spoke with a government research scientist that was passionately opposed to that push towards universities training engineering students in commercial software (CAE/FEA/CFD) at the cost of learning the fundamentals behind them. He insisted it's industry's job to "train" (i.e. teach to use a particular software they desire) and a university's job to "educate," and I have to agree. It seems myopic for a school to act as trainer in whatever commercial software is in favor at the time. A CFD practitioner that's never written code seems like a wind tunnel experimentalist that doesn't know how his DAQ works -- not to be trusted. The Tannehill text states that well.

    Regarding language preference, I think it's important to know at least one compiled language (Fortran/C/C++) and one scripting (Matlab/Python.) C++ certainly has a learning curve, but it's certainly easier for a C++ programmer to pick up Fortran quickly to deal with legacy code than the other way around. Anyway, the jump from learning to program to nothing at all is far more severe than a choice of languages. Learning good software engineering in any language tends to carry over.

  2. I don't think the teaching is outdated. I guess the needs of the industry has downgraded quite a bit over the last several years. There are BIG CFD companies that have existed for quite sometime and then there are many small ones that have come up recently. The small companies usually don't want to invest in new codes. These days many advanced free CFD codes are available and the small companies basically want to do consulting and regardless of what qualifications they seek from job applicants, most of the time it means using a push-button technology on the free software. As far as the big players are concerned, they usually have two departments - applications and development. Applications people do consulting most of the time again using push-button technology and when they have to explain the results to the clients it's basically FD that one needs and not CFD. For the development group, there is not a lot of solvers development going on. Mostly it involves coding new applications (front-end, GUI) which runs the already existing solvers in the background. Hence again apart from the people involved in solver development, most of the CFD developers generally just need coding knowledge.

  3. Thanks for all the comments. In fact, there are a few more on my linkedin web page. I am encouraged by these comments that CFD fundamentals still have a place even in undergraduate CFD education!

  4. This comment has been removed by the author.

  5. Sadly enough I do believe that the way we teach CFD is quickly becoming outdated and probably for all the wrong reasons too. The reason being is the nature of CFD codes themselves. CFD codes, while powerful, have accuracy problems. And those accuracy problems aren't exactly deterministic. A lot of it comes from the type and size of the mesh (course versus fine) and the type of solver (pressure vs density). And there's a dozen different ways you can mix those two qualities together resulting in a dozen different answers that can be interpreted as 'right'.

    I'll be honest when I first heard about CFD I was excited that there was a program that can solve the Navier Stokes equation (or approximate it close enough that the error was negligible) in less than an hour. When I started to immerse myself in the art I realized that nothing could be farther from the truth. CFD solutions range from as little as 10 minutes to as much as half a day (and more from what I've heard). Add that to the fact that predicting drag still remains an elusive art to the CFD professionals in the world and you've got a result that you look at in askance. I then came to realize that CFD wasn't the mechanic of flow simulation that was going to fix everything and tell me hard numbers on everything. Instead CFD is like the patient psychologist. It's there to help you glean information on the flow, take back what you learn, put it into your panel codes (which are more crude but much faster) and then go to wind tunnel to verify your answers. With that said why get a specialist (who you pay alot) to give you answers that you are going to be skeptical of anyway. Why not get the guy who knows how to push the right button (who you pay alot less) and give you answers your going to be skeptical of anyway! Is this right? Probably not but I get the feeling that the industry is slowing going in that direction anyway so we might as well adapt to changing landscape. If it's any consolidation, I think the transition is similar to that of the drafting board to the CAD program. Everybody uses the later. You'll be lucky to find anyone under the age of 25 who knows the former.

    However I believe strongly that any engineer who all he knows how to do is to push a button and isn't ashamed of himself shouldn't call himself an engineer.

  6. As a computer engineering grad student at ISU, I would love to see a CFD software engineering course. With multicore CPUs, MPI, and GPUs there are a lot of open research problems.

  7. Very nice idea! We actually do research on clusters of CPUs and GPUs. I would be happy to co-teach such a course with a software engineering faculty.

  8. A great post with out doubt. The information shared is of top quality which has to get appreciated at all levels. Well done keep up the good work.


  9. I'm teaching an undergrad CFD course now. While students do use a commercial solver as a part of a term project, they are taught enough of the fundamentals to become knowledgeable users. They do get their hands dirty programming simple routines for solving elliptic heat equation with a variety of point/line methods, TDMA, etc, wave equations with a handful of methods, and solving simple 1D problems using FV by hand. The response I've received is that by blending the fundamentals with the use of commercial CFD, they are better able to make deliberate, informed decisions in setting up simulations in the commercial solver, and also have a better understanding of how to assess the veracity of the results.

    That said, I'm finding that the comfort level in programming among 4th-year undergrads seems to be slowly decreasing. I can't comment as to why that seems to be.

    1. I really like your mix of cfd fundamentals with the use of commercial codes. Obviously the emphasis will depend on the programming skills of the students. Personally, I always feel some fundamental cfd knowledge always makes the user a better practitioner.

  10. This comment has been removed by a blog administrator.

  11. Hi everyone,
    I am a 2013 mechanical engineering graduate and I too was given a little exposure to CFD and programming in the last year of my engineering. It all started with the colourful images that soaked me in during my 2nd year of engineering.
    I learned that push button approach doesn't take engineering graduates anywhere. It involves a lot of in depth knowledge of calculus, numerical methods, knowledge of programming language and fundamentals. I remember I used to get some results during many of the simulations I ran with the commercial CFD packages and was very sad over not being able to quantify and reason them.
    Thanks to my professor in the final year of my engineering whose guidance actually helped me understand the principles and what it takes to be a CFD engineer.

    Today I was searching for a relevant post and here I found very similar and was very delighted to read them all. I hope everything goes smooth ahead in the coming days.