Grad school CFD work, programming requirements

Starting CFD work? When I started, I'd had essentially a freshman-level Fortran programming course, an elective on some interesting subjects in supercomputer programming (but not much on fundamentals), and what I'd picked up in working through four years of classes on other things. Which is, I gather, about where you are currently.

So, there you have an existence proof; here I am, a number of years later, finishing up a Ph.D. in CFD, and I seem to have turned out ok.

That said, I don't think I'd completely recommend it -- there's a lot that I wish I'd known earlier. For instance, object-oriented programming. I only learned C++ last year by teaching myself, and have only recently started to have a good handle on the conceptual side of object-oriented programming. There's a lot of stuff like that, too -- theoretical ideas about how to structure programs and so forth that have been developed in the last 30 years, and a freshman programming course probably teaches nearly none of it. I think it would be well worth your while to take a course from your CS department in something along those lines, just to get a sense of what's out there in the world, so that you know to go track down the details when you find a place it would be useful.

Also, if you end up starting with an existing CFD code and modifying it -- which I highly recommend; I can say from experience that writing your own is way too much work in the long run -- you'll probably end up working on something that's written in either C++ or Fortran. I'd suggest doing at least a little playing around with both of those, so that you know what they look like and what they can do. (And by Fortran I mean Fortran 95, not Fortran 77 -- the language has had quite a lot of useful stuff added since the early days, and Fortran 77 contains nearly none of the features that are why someone would want to use the language today.)

(For that matter, there's a lot to be said for just reading the language newsgroups for one or two languages you're interested in; you gain a lot of experience from other people's mistakes rather than having to make your own, and learn about a lot of the concepts of the language too.)

There's a lot that I learned by doing, too. My first summer as a grad student I spent learning the hard way why one should always write programs in small, independently-testable chunks -- I got done with my program at the end of the summer, and it wouldn't run right, and there was no way to figure out where to start fixing it. My programming style has improved notably over the years; I look at my older code and realize that I could have done things much more sensibly. But I think those are things that one's sort of expected to learn over the course of a graduate program involving working with large programs, as there's not really any way to learn them from anything other than practice.

I should probably add that Fortran 77 was the primary code for all four large computational (3 of them CFD) that I have worked on in my graduate school and professional career. Learning F77 is easy, too, so don't just ignore it because the language is 30 years old and bites the dung monkey.

A lot of useful solvers and packages are written in C and F77, only now are we seeing some of these converted to C++ and F90/95.

I would have to say that CFD work uses the simplest set of programming skills. You'll have a much harder time picking up on all of the formulations (what you learn in class) than you will the practice of programming (which you'll learn out of class, as you go).

I had 1 credit hour of C and 4 of Fortran before I started CFD, and I've picked up everything that I needed to know, programming-wise, by writing code and reading mauals.

If you already have written GUI codes, and have a good grasp of OO, then you're ahead of me when I started. Concentrate on the math instead.

OO

was OO programming pretty rare in past CFD? has it changed much today? i'm wondering whether it'd be beneficial to brush up on my C or C++.

Re: OO

OO was pretty rare in general in the past, especially so in the area of computational physics. Research CFD codes made the switch to OO-like architecture earlier (as researchers got younger), but big commercial codes held on to non-OO code longer, and (both) still use it in many cases.

In general, you'd be better off learning C++ than C, if only for the OO-nature of it; but the two are close enough that you'll be learning/reviewing them at the same time, anyways. Chances are that you're work will involve maintaining or extending an existing project instead of starting a new one, and you'll be constrained to the language that they used (pray it isn't Fortran).

I may not have stated this clearly before: concentrate on learning the methods, algorithms, and data structures of CFD/computational physics, because learning a programming language is always the easy part.

Re: OO

s/you're/your/g

Re: OO

a vi user, excellent :). thanks for the tips, i'll be sure to focus on the physics rather than the coding. from my experience with both, physics definitely seems to be more troublesome.

I use mostly Fortran, Perl, and Numerical Python. I've never taken a class and I came in when very basic knowledge (HA! pun, all I knew was Basic and a bit of VB).

However, I use this all for numerical weather prediction, which is more like applied Computational Fluid Dynamics.

thanks

extremely helpful replies from all, thanks.