By John Steinbrenner, Ph.D.
Vice President, Research and Development
Two previous The Connector articles written this year by John Chawner and Rick Matus chronicled the 30-year development of Gridgen and Pointwise. In part three of this trilogy, I will present my (perhaps redundant) recollection of events, including the evolution of our code development processes.
GRIDGEN2D development began in 1984 at General Dynamics Fort Worth Division (GDFW) within the newly formed computational fluid dynamics (CFD) group. Originally a text-driven interactive code with primitive display capabilities on DEC VT240 and Tektronix 4010 terminals, GRIDGEN2D was ported in 1987 to the first Silicon Graphics Iris 2400 Workstation purchased by GDFW. Later, under contract to the U.S. Air Force, the GRIDGEN system was expanded into five codes, four of which were graphically based. GRIDBLOCK was used to draw block boundaries (connectors), GRIDBOUND was used to set interblock connections and flow boundary conditions, and GRIDGEN2D (the least sophisticated from a GUI-standpoint) was used to create the surface meshes which served as block boundaries. The fourth code, GRIDGEN3D, generated volume grids, and the fifth, GRIDVUE, was used to examine these volume grids. GRIDBLOCK and GRIDBOUND (combined into a single GRIDBLOCK in a later version), which were almost single-handedly developed by Chris Fouts (an engineering specialist here at Pointwise), were quite sophisticated graphical codes for their time. In fact, GRIDGEN2D and GRIDGEN3D's functions were eventually ported to GRIDBLOCK to become the Gridgen interface still in use today. (A 1988 video of the Gridgen codes may be found on Pointwise's CFD Meshing YouTube channel.)
GRIDGEN was one of the first interactive mesh generators to market, and so initial acceptance was generally, but not universally, positive. Doubters included one summer intern at GDFW (since all CFD careers at the time seemed to start with making meshes) who asked, “Do we have to use this?”
The release of GRIDGEN predated worldwide adoption of Microsoft Windows products, and we were not forward-thinking enough, I suppose, to adopt Microsoft's GUI conventions. For their part, Microsoft seemed equally unaware of our effort. Perhaps Mr. Gates will address this one day in the “Life Regrets” chapter of his autobiography. Consequently, what was innovative in the late 1980s degraded from simply quirky to highly non-standard in the 1990s, eventually falling to deal-breaker for some customers in the 2000s, particularly engineers schooled solely in software adopting modern UI conventions. As one potential customer said not too long ago, Gridgen's GUI looks like it was developed in the '60s. Groovy.
When the U.S. Air Force contracts were completed in 1991 resulting in GRIDGEN V6, Chris Fouts had already moved on to work for Silicon Graphics, and John Chawner and I moved to MDA Engineering to continue work on GRIDGEN under support from NASA Langley and NASA Ames. The two of us developed code, authored user manuals, provided phone support, taught user classes, and did the occasional trade show, usually at the AIAA Reno Meeting in a hidden corner of the SGI booth. It was a busy, tiring and exciting period that led us to the conclusion that we needed help on a lot of fronts.
And so, a little more than 10 years after Gridgen was started, Pointwise was incorporated. The first order of business for us was to partner with Rick Matus to run the sales, marketing and support departments. Soon afterward we had a mini-Pointwise skeleton crew in place, covering all the important bases - Erick Gantt providing support, Nick Wyman developing code, and Heather McCoy running the office. As you know, all three are still with Pointwise. Nick is the director of Applied Research, Heather is the manager of Sales and Marketing Programs, and Erick is an engineering specialist in Technical Support.
For the next several years Gridgen development continued (with Chris Fouts back on the team), with new meshing features shoe-horned into an over-constrained and limited Gridgen GUI and architecture. Unstructured surface and volume meshing, extruded quad, prism and hex meshing, solid modeling, and multi-grid elliptic solvers all were added among other things.
Fast-forwarding to 2014 and with the fact that the latest version of Gridgen (V15.18) was released more than two years ago, it's probably safe to conclude that comparatively little future effort will be dedicated to expanding our former flagship product's technical capabilities to match Pointwise's ever-growing feature set. Thus, a question that has kept me awake on many nights for the past 10 years is finally resolved. The answer is no, I will not devote my entire career to a single piece of software. In some ways, however, it is just semantics, because most of the grid generation techniques existing in Pointwise are based on (improvements to) methods incorporated in Gridgen over the past 25+ years.
The early development of Pointwise the product (which began more than 12 years ago) followed a set of general user experience guidelines designed to preserve a broad, loyal set of existing customers, while allowing for significant expansion for future directions. We used the Volkswagen Beetle analogy, where the second generation is clearly superior to the original, but retains an immediate familiar feel that longtime customers would feel drawn to explore. This is the primary reason why we elected to stick with some unfortunate terminology (think connector, domain, database), and to refer to some methods by the author's names (Thomas and Middlecoff) rather than by a more descriptive title. The decision was not born of self-importance, expecting new users to acclimate to our conventions, but of respect for our existing customers.
Perhaps the major difference in development practices between Gridgen and Pointwise (beside the programming languages, C to C++) is the formality and stringency with which new features are added in Pointwise. With Gridgen, the scope, implementation details and GUI design of a new feature were the responsibility of the developer assigned to the task. Of course, the general goal was a design consistent in layout, terminology and look and feel with the rest of the code, but often inconsistencies were reconciled along the way or even after the first release. In Pointwise, new feature implementation does not begin until a requirements document (written by a non-developer) is prepared that explains how the code should be expected to behave. These ideas are fortified via use-cases, test cases and GUI mockups. The requirements document is then passed to the Pointwise Advisory Team for a period of review and comment. This select team consists of partners and customers who provide regular feedback on Pointwise development activity. Next, a developer prepares a specification document that outlines code implementation details, expected issues, and an hour estimate to complete the work. Finally, proposed enhancements to the GUI are vetted and modified by a GUI design team. This structured approach allows the implementation to follow a more predictable timetable, usually circumventing the need for rewrites after the first release.
Rigor in coding has also increased markedly in Pointwise. New developers are directed to an internal software style guide, and adherence to the recommended style is actively policed. Gone is the Gridgen routine of looking at code and knowing immediately who the primary developer is (my C code looked remarkably like Fortran - go figure). All members of the development team are subject to periodic code reviews, a practice that benefits all present in the review, and other progressive techniques such as pair programming are also used with some frequency.
Although there is no typical developer at Pointwise, there have been periodic emphases in skill-sets over the years. In the early days of Gridgen, most developers were engineers with keen interests in mesh generation who could also code (in Fortran). In the early days of Pointwise (as features were rapidly being migrated from Gridgen to Pointwise), new developers tended to be computer scientists with significant software skills and a passing knowledge of mesh generation. Now that Pointwise has been in the public for more than eight years, we have a team with collectively more than 120 years of mesh generation experience, and more than 150 years experience in professional coding. The result is a strong team that is blurring the distinction among coders - the grid folks' coding skills are bolstered by strong guidelines and reviews, and the computer scientists are beginning to foray into new mesh generation techniques, guided by the old-guard mesh developers.
As might be expected, the code itself has changed dramatically in 20 years. Whereas Gridgen's C code base consists of approximately 700,000 lines divided among 300 .c and .h files, Pointwise's C++ code base is more than twice as large, divided into 10 times as many files. Despite the growth in code size, Pointwise is easier to maintain and extend, due in large part to the software architecture and use of container class libraries for memory maintenance.
Release of Pointwise V17 in 2012 was a long-awaited milestone in our company history because it marked the functional equivalency between Gridgen and Pointwise. While this milestone provided a natural Gridgen-to-Pointwise transition for experienced users, we still today have strong advocates for each code. Gridgen may now be effectively on autopilot, but we continue to offer and support it fully, and we are mindful of the long-term relationships it has fostered.
Pointwise development, on the other hand, is in full stride, and meshing tools such as the advancing front tri surface mesher, the plugin CAE library, the floating boundary capability in the block solver, and T-Rex cell combination into hexes are but a few of the features unique to Pointwise. Some features found in Gridgen have been implemented in Pointwise in a superior manner. Examples include automatic domain and block formation, native CAD import, solid modeling, CAE export, and overset mesh tools (coming in V17.3).
Pointwise is poised for continued innovative and reliable mesh generation, both from a code base as well as a personnel standpoint. I would like to thank our users for 20 years of support of our product as well for providing years of valuable advice and suggestions to Pointwise's future direction.
Join us to celebrate the past 20 years and hear our plans for the next 20 at the Pointwise User Group Meeting 2014 to be held 29-30 October in Anaheim, California. The Call for Papers is open for those of you who wish to share your work and registration is open for those who look forward to learning more about CFD and mesh generation.