Axel Rohde is the founder and owner of MicroCFD. His virtual wind tunnel software, capable of solving unsteady 2D and axis-symmetric compressible flows on a fine Cartesian mesh, has served academia, government and industry for over a decade. He has a doctorate degree (Ph.D.) in aerospace engineering from the Florida Institute of Technology and 10 years of teaching and research experience at Embry-Riddle Aeronautical University (ERAU).
What do you see as the biggest challenges facing CFD in the next three years?
Axel: I would say the advent of GPGPUs (general purpose graphics processing units) has brought huge opportunities and huge challenges to the CFD industry. Some of the latest GPUs have over 1500 parallel processors that can be used for general purpose computing. How do you efficiently harness this kind of computational power? The CFD companies who embrace this new technology now will likely be the winners in five to 10 years.
John: They certainly can be very powerful and a lot of people are exploiting them for spectacular results. We did a study a year ago that yielded some impressive results for one algorithm in Pointwise (36x speed-up at best), but those results came at a considerable cost in terms of programming and maintainability. Have you had better results?
Axel: The GPU implementation of my flow solver routine was relatively straightforward. To parallelize the code, I only had to modify my loop statements to incorporate threads. The biggest question was how to divide these threads into blocks and grids so it would efficiently run on the GPU, and I solved that one by trial and error. There is still room for further improvement by employing a memory model of my flow vector array that is better suited for the GPU pipeline, but I am satisfied with the execution speed so far.
So how does this fit with what you’re currently working on?
Axel: After nearly 10 years at Embry-Riddle, I decided to leave the university last summer to pursue MicroCFD full time. Two months ago, I released an update of my virtual wind tunnel software, which now runs on multi-core CPUs and NVIDIA GPUs. My benchmark tests have demonstrated that a GPU with only 96 cores (which I bought for $68) can solve 2D and axis-symmetric compressible flows at a resolution of 1 million cells in five to 10 minutes. I am planning to have a 3D version ready in 2014, which will instantly mesh STL input files and run at resolutions of 30+ million cells within a few hours.
John: I’ll ask the obvious question. How will you differentiate your solver from all the other solvers – commercial, open source, academic, and proprietary – in the market today? What type of user or application is best suited for MicroCFD?
Axel: I would classify MicroCFD as a “brute force” solver that can yield uniformly accurate flow results throughout its computational domain in a relatively short time. With every pixel of the wind tunnel display representing a single fluid or solid cell, it is a true “what-you-see-is-what-you-get” CFD application; and that makes it somewhat unique. The uniform Cartesian mesh inside the tunnel allows a quick and simple setup of any 2D or axis-symmetric configuration with a few mouse-clicks, as long as the (x,y) coordinates of the input geometries are defined. The 3D version currently under development will be equally easy to work with, even for the most inexperienced user. So I am targeting a very broad audience with little or no CFD background and limited budget, who want to run low-cost aerodynamic simulations.
John: How does your solver handle the boundaries – cut cells or stair-stepping? Also, will you offer boundary layer resolution through some sort of extruded grid? I ask because I recently blogged about Cartesian methods based on something Mentor Graphics had written.
Axel: The prototype version had stair-stepping boundaries, which worked well for blunt bodies but gave terrible results for slender bodies like airfoils. So I looked into cut cell methods and eventually developed my own, somewhat simpler than what you see published in the literature, but it works very well. What bewilders many CFD experts is how an Euler solver can yield flow separation in the absence of shocks or sharp corners, and that is really the result of my cut cell algorithm combined with the numerical viscosity present in the solver. I also have a basic boundary layer “model” which can further enhance flow separation in wake regions. To answer your second question, no, I do not plan to offer an extruded grid for boundary layer resolution.
How did you get to be where you are today?
Axel: I spent 12 years on my higher education. All my degrees (B.S., M.S., Ph.D.) are in aerospace engineering, and I also hold a private pilot license with instrument rating and high performance aircraft endorsement. I was very fortunate to have my parents fully support me during those years. As an international student from Germany, I was not allowed to seek employment until I finished my Ph.D. ERAU subsequently sponsored my immigration, and I am very grateful for that.
The MicroCFD virtual wind tunnel was first developed in 1995 when I started my Ph.D. program. Originally, it was mostly a hobby of mine, but I decided to create a website for it in 1999 and started selling it in 2001 under its current trademark (its original name was MicroTunnel).
While teaching at ERAU, MicroCFD turned out to be a very useful tool in many of my aerospace engineering courses. I also used a slightly modified version during a consulting job for Berkeley Lab to simulate the flow inside their prototype gas spectrometer. Other commercial CFD software had difficulty resolving the many shocks present inside this device and could not capture unsteady shocks.
Who or what inspired you to get started in your career?
Axel: At age 14 I invested my then life savings in a Commodore 64 computer and quickly got hooked writing programs in Basic and Assembly. The programming skills I acquired back then helped me throughout my engineering career. To give you an example, the disc image on my website’s main page was drawn with a vanishing point algorithm that I had first developed on the C64 and which I recycled many years later while working on my dissertation.
After witnessing the space shuttle’s inaugural flight on my first trip to Florida in 1981, my decision to become an aerospace engineer was pretty much made. And since I had always excelled in math and science, it was a natural choice. While in graduate school, I chose CFD as my focus area, so I could further apply and develop my programming skills. And it was fun!
John: It’s not surprising when I talk to CFD people that they cite early programming experiences as an important part of their career path. (I did my first programming in Basic on a Wang 3300 that used punched tape as a storage medium. I still have a couple of those tapes in a box somewhere). But it raises an interesting issue that comes up every once in a while with respect to engineers in general. Do you think programming (e.g. C, Fortran and not Matlab or Excel) should be an integral part of the engineering undergraduate curriculum?
Axel: Most definitely! Far too much emphasis is placed on obtaining closed form analytical solutions in undergraduate engineering courses. The majority of problems cannot even be solved that way. The curriculum would be better served, if students were introduced to the basics of numerical analysis in their first year. During my tenure at ERAU, I assigned homework that required numerical integration of ordinary differential equations in nearly every course, including statics and dynamics. Even the most complex shear and bending moment diagram can be elegantly solved by integrating the basic equations in Excel using finite differences. At one point I was known as the “Visual Basic Professor”, although I encouraged students to use any programming language they felt comfortable with to do their assignments. I was happy if they could use Matlab or Excel.
John: I was actually thinking more along the lines of higher performing languages like Fortran or C. Programming in Matlab or Excel seems too much like a skill whereas learning to write, compile, run and debug using Fortran might develop more of an appreciation for the overall programming process. It would serve the same purpose as requiring a guy like me to take structures and mechanics of materials when I was clearly interested in fluids. I still developed an appreciation for the subject.
Axel: During my first year at ERAU, I was very surprised to find out how programming was becoming a lost art among aerospace engineers. The majority of students had little or no appreciation for it, some complained about my small programming assignments, and others did not bother with it at all. Although they were required to take an introductory course in C during their first semester, many students never developed a taste for programming. Maybe C is not the best first language to learn.
What advice do you have for young people entering the field today?
Axel: Allow yourself enough time in college to absorb all the material. Many students rush through the program and never take time to connect the dots between different courses. When entering the job market, make sure you pick an employer where you can fully apply your existing skills while learning new ones. And if you ever feel like your career has reached a stagnation point, don’t be afraid to move on to another job where you can continue to grow professionally. Without continuous learning, it is easy to become obsolete in today’s world.
John: Tell me exactly what you mean by allowing enough time. Many students take more than four years to complete a degree now.
Axel: As an academic advisor, I saw many students trying to overload themselves during the last year, and especially the last semester, in an effort to finish up in exactly four years. This usually resulted in a drop of their grades or a later withdrawal from a course, for which they had to come back in the summer. Students would be better served, in my opinion, if the undergraduate engineering programs were laid out for five years, with some courses taught over two semesters instead of one. I also think that the humanity courses are an unnecessary distraction. There is ample opportunity to emphasize proper writing through the many engineering project reports. I always graded reports for spelling, grammar, and formatting, and I made it worth at least 10 percent of the grade.
How do you know Pointwise?
Axel: I first remember Pointwise from running banner ads on CFD-Online, where I used to be a frequent contributor around the turn of the millennium; I also recall reading full-page ads for Gridgen in the monthly AIAA magazine Aerospace America. The Pointwise logo and Gridgen name struck me as excellent choices for branding its meshing software, and that is what people remember, even if they never had the opportunity to use the software. I always associated Pointwise with the major players in the CFD world.
And of course, I know John Dreese who recently joined Pointwise. John and I first met about 10 years ago at Embry Riddle, while he was visiting our university to promote his famous DesignFOIL software. Our aerospace engineering department subsequently bought a multi-user perpetual license, which turned out to be a great asset for our senior design courses. Over the years, John and I frequently compared notes on how to better promote our CFD businesses.
John: I should point out that this is the first interview for the blog that I’ve done with a person I’ve never met. I really need to do more of these.
Can you share with us your favorite tools and resources that help you get your job done?
Axel: For my daily tasks, I use Microsoft Office, Adobe Acrobat, Windows Mail, and Skype. For my software development, I use Microsoft Visual Basic, Visual C++ and MASM. Visual Basic is great for GUI (graphical user interface) development, and I only use Visual C++ and MASM when speed is critical, like the flow solver routine. Since 2001, the MicroCFD flow solver had been written in Assembly language and was linked to the main program as a DLL.
The latest virtual wind tunnel release offers three processor choices: single core CPU, multi core CPU, and CUDA core GPU. Multi-core programming in Assembly turned out to be cumbersome, and I decided to switch to Visual C++, which supports both OpenMP and CUDA. My single core CPU solver got a boost with the SSE2 processor extensions; it is now written in C++ and runs slightly faster than the original Assembly coded solver, which did not utilize SSE or SSE2.
I would say my biggest resource is the Internet. If I am stuck on a problem and need a quick answer, I can usually find it through Google and Wikipedia. To further my knowledge, I occasionally read books and publications. Last year I read the “green book” by Kirk & Hwu on “Programming Massively Parallel Processors” which got me started on CUDA. Currently, I am reading the “OpenGL Programming Guide” by Shreiner et alii, colloquially known as the “red book”. For CFD and other aerospace related research, I frequently browse the AIAA online library.
John: Did I hear that correctly? You wrote MicroCFD in Assembly? I have to ask why.
Axel: In a typical CFD application, 1 percent of the code does 99 percent of the work. So if you can optimize that 1 percent code, usually a small subroutine that gets called iteratively thousands of times during a single flow simulation, you can end up with a significant speedup. The original Visual Basic flow solver, with all the compiler switches set to optimize for speed, ran 6 times slower than its Assembly coded DLL replacement. Over the past decade, compilers have tremendously improved, but even my latest Visual C++ code, running on a single processor with SSE disabled, takes up to 40 percent longer than its Assembly counterpart. When programming in Assembly, you notice hardware limitations that you would never become aware of in a high level language. By rearranging your code and memory model to optimally work within those limitations, you can sometimes achieve great time savings. Writing a numerically intensive subroutine in Assembly is not as daunting of a task as it might sound.
If we were to come visit you, where’s a good place to go out for dinner?
Axel: The only two restaurants we had on north Hutchinson Island were part of a hotel which got destroyed in the 2004 hurricanes and was subsequently demolished. So we would have to drive a bit up or down the coast. About 20 minutes to the north is Tangos II in Vero Beach; or if we wanted to take a 30 minute scenic drive south along the Indian River, we would go to the 11 Maple Street in Jensen Beach. Both restaurants offer contemporary American cuisine and are two of my favorites.
John: After checking out the menu for both places, I’m not only thinking about a trip to Florida, but I’m fairly certain I know a place in Fort Worth you’d like should you come to visit.
Thanks for sharing this with me.
Axel: I certainly look forward to meeting you some day, and thank you for the opportunity of this interview.