Today’s interview is with Dr. Ralph Noack, a senior Research Associate in the Computational Methods Development Department at the Applied Research Laboratory of The Pennsylvania State University.  Ralph and I were coworkers for about three years in the early 1990s and it’s nice to get caught up with what he’s working on now.

Chawner: What do you see are the biggest challenges facing CFD in the next three years?

Noack: One of the biggest challenges is the software complexity of today’s and tomorrow’s CFD simulation technology. CFD solution technology has matured significantly and is being routinely applied to increasingly complex and large problems.

A big focus for the present and future is multi-disciplinary problems in analysis and design. This requires coupling different solution and simulation technologies and is not a simple task. The goal in many cases is to provide a flexible capability and as I like to say, “Flexibility leads to complexity.” Good software development technology and practices are required to develop such complex and flexible simulation technology and most CFD developers do not have the software development background to produce the software quality that is required. Some development teams, like the NASA Langley team developing FUN3D, have integrated modern software practices to assist in producing good quality, complex software.

Chawner: Can you be more specific about what you mean when you say “modern software practices?”  I get the impression you’re thinking about something more than having the source code in CVS.  Are you talking about Agile?

Noack: There’s a wide range of “modern software practices” that helps improve the quality and cost of software. It would be great if we all could use Agile, pair programming, and other well-defined software development practices. But for most small organizations, that’s not usually practical.

The first step is some sort of source code management (SCM) system like CVS. We use git and it’s a huge benefit. The ability to go back in time to see the changes you made, to pull a previous version and test with it are obvious capabilities that help identify what changed and what went wrong. I find it very useful, even while editing code: I just deleted a section and need to see a portion of the code I deleted. With an SCM tool like git, I can see what the diffs are between what I’m working on and what I had.

Another conceptually simple and extremely valuable practice is regression testing. We’ve developed our own testing driver and it runs every night at the minimum. Running one or more tests while you’re doing the development will ensure that the code still works for other inputs. It takes time and discipline to add the test cases to the suite, but is well worth it.

You may not be able to do pair programming in which  more than one person knows each part of the code, but having a “truck factor” of greater than one (how many people have to be run over by a truck  to wipe out all knowledge of the code?) has obvious benefits in long term code maintenance. Another benefit is the ability to bounce ideas off someone else, resulting in improved code and user interface quality.

Chawner: What are you working on now to which you’re applying these practices?

Noack: I’m still working on Suggar++, which is used to determine the domain connectivity information for a system of overset grids.

Chawner: You say “still” like it’s just taking a long time to finish, but I know it’s more than that.  What are some of the issues that take so much time when developing a tool like Suggar++?

Noack: One of my favorite phrases is “If you think it is simple, you just haven’t worked on it.”  Overset grids are conceptually simple: grids overlap, so find donor cells and interpolate. One of the strengths of the overset grid method is the flexibility that it gives the user, which brings up another of my phrases: “flexibility leads to complexity. “ If you restrict the flexibility to only unstructured tetrahedral meshes, for example, that all are watertight, life can be easy for the developer. But the end user is always asking for more. It is non-trivial to be able to robustly handle everything the user throws at you, with automation to minimize user inputs, especially for structured grids with overlapping surfaces. Additionally, the user wants it to be very fast.  SUGGAR and Suggar++ both are designed to handle nearly any grid type, so we have lots of flexibility. Another aspect is that in many cases the user would like to tweak the resulting overlap, sometimes for aesthetics and sometimes for valid flow solver concerns. Trying to give all users what they want is an ongoing task.

Chawner: How did you come to be a developer of software for overset grids?

Noack: I have a fairly eclectic background that has provided me with lots of different opportunities. I earned a B.S. and M.S. in aerospace engineering from Texas A&M University in 1979 and 1981, respectively.  I then worked on hypersonic re-entry vehicle CFD for Sandia National Laboratories in Albuquerque, NM, for about 5 years.

I left Sandia to pursue a Ph.D. in aerospace engineering at the University of Texas at Arlington and earned my Ph.D. in 1991. From 1989 until 1985, I worked for MDA Engineering, a small business started by my Ph.D. adviser, Dale Anderson, doing SBIR contracts with the U.S. Air Force. The topics ranged from computational electromagnetics, which funded my Ph.D. research, unstructured mesh generation and flow solution, and simulation of fluid structure interactions.

From there, I went to Eglin Air Force Base for about five years and worked on the Beggar flow solver, which started my career in the overset grid community. This led me to a position within the DoD HPC program as an on-site lead for CFD at the Army Research Laboratory. The initial focus of the position was to develop an overset capability and as a result, I wrote two pieces of software. The first, DiRTlib, is a solver neutral library that simplifies adding an overset capability to non-overset flow solvers. DiRTlib is used in a number of different flow solvers covering a wide range of solution technologies, including structured and unstructured grids, node- and/or cell-centered formulations and many different flow physics. An overset grid assembly code that could provide the domain connectivity for these different solvers did not exist at the time, so I also developed the SUGGAR code.

From there, I joined the Applied Research Laboratory at Penn State and have been developing a significantly improved version of SUGGAR, which is called Suggar++.

Chawner: I know DiRTlib is very popular.  If people  want to add overset capability to their flow solvers, how do they go about getting a copy of DiRTlib?

Noack: I’m still the distribution and support point. They can email me at rwn10@psu.edu.

Chawner: Who or what inspired you to get started in your career?

Noack: Like many aerospace majors, as a kid I dreamed of flying airplanes. In ninth grade, I gave up that dream because my vision is so bad and decided that if I couldn’t fly them, I’d design them. I never got into the design part, but found that software development satisfied my creativity needs.

Chawner: What advice do you have for young people entering the field today?

Noack: Find something to do that you love and internally motivates you. Then, find a place that will provide you the freedom to innovate and apply that motivation. If you do the job just for money, you’ll never be happy with the job. I also think that young people don’t read enough books.  There are lots of inspiring and extraordinary books out there. Some books that I highly recommend are “Drive” by Pink, “Outliers” by Gladwell, and “The Last Lecture” by Pausch.

Chawner: I agree that reading good books can really help educate, enlighten and entertain.  But I thought Gladwell’s Blink was horrible – like Oprah with a doctorate.  Should I give him another chance?

Noack: I think one problem with some books that I’ve read is that they stretch a short pamphlet into a book by being repetitively redundant. I think Blink and Tipping Point fall into that category.  I did like “Outliers,” so I would recommend it, especially for the young people, who I hope would be impacted by some of the concepts.

Chawner: Coincidentally, my son has “Outliers” as a summer reading assignment. Also, do you have any preference for dead-tree books or e-books?  I personally don’t own an e-reader.

Noack: There are advantages to both formats. I hate the way e-books are priced and restricted. With a hardcopy, you can lend it as many times as you want, you can sell it, give it away, etc. The e-books are horribly restricted. Plus, I think they are priced way too high for the restricted rights. In many cases, you can get a discounted hard copy for less than the e-book. I almost avoid e-books based upon principles. The e-book readers are much more convenient in size and volume. I have a little stand for my e-book reader on my exercise bike and the e-book reader works great. It’s a pain to try to hold down the pager of a thick paper back without using your hands.  One bad downside to my e-book reader is that pictures/images are small, not scalable, so you miss some content. The main reason I have my e-book reader is that it supports the EPUB format, which my library supports for lending. So, I can download a book to read and not have to travel to the physical library.

Chawner: Remind us how you know Pointwise.

Noack: I go back to when Pointwise was just a gleam in the eye. I was the first employee at MDA Engineering and then you and John Steinbrenner left General Dynamics to work at MDA on the NASA contract that lead to Gridgen Version 8. It’s amazing to see how Pointwise has grown over the years, starting with a couple of guys with a vision and empty retirement accounts!

Chawner: John and I are as amazed as everyone else.

Chawner: Would you share with us your favorite tools and resources that help you get your job done?

Noack: The Symposium on Overset Composite Grids and Solution Technology is held every two years and is a small but very focused community of developers and end users of overset grid technology. The various AIAA meetings are always useful and I am a member of the AIAA Meshing, Visualization and Computational Environments technical committee. Because I’m more of a software developer, my main tools are Emacs, g++, and gdb. Technical resources beyond the symposium and AIAA papers are mostly books and web sites on programming, especially C++, as that is what Suggar++ is written in.

Chawner: I will not say anything about Emacs. I will not say anything about Emacs.  I will not say anything about Emacs.  Actually, my son (a computer science major) is an Emacs user, so he fell far from this vim tree.

Noack:  Not to start any flame wars but… vi is perfectly acceptable for the two-finger typists.  It’s good to hear your son is more enlightened!

Chawner: If we were to come visit you, where’s a good place to go out for dinner?

Noack: State College, PA, is pretty small but has three microbrew restaurants. The largest is Otto’s Pub and Brewery, the Elk Creek Café Aleworks is a bit out of town but has good beer and food, and finally the Gamble Mill Tavern recently added a microbrewery. All of them have good food and good beer, with each having a unique atmosphere.

Chawner: I think you’re being a little modest.  I hear you brew your own beer that’s quite good.

Noack: Well, you asked about good places to go out for dinner and I wouldn’t call my cooking good. I like the beer I brew, but it’s getting harder to find the time to brew the next batch. It’s great that there is so much variety in brewing again. The number of brewers in the U.S. is almost back to what it was before Prohibition and that’s all because of the craft brew industry.

Chawner: Thanks for your time, Ralph.  A pleasure as always.