Origins of NASTRAN

In the early 1960s, structures researchers from the various NASA Centers were gathering annually at Headquarters in Washington, DC, to exchange ideas and coordinate their efforts. They began to realize that many organizations—NASA Centers and industry—were independently developing computer programs to solve similar types of structural prob­lems. There were several drawbacks to this situation. Effort was being duplicated needlessly. There was no compatibility of input and out­put formats, or consistency of naming conventions. The programs

were only as versatile as the developers cared to make them; the inher­ent versatility of the finite element method was not being exploited. More benefit might be achieved by pooling resources and developing a truly general-purpose program. Thomas G. Butler of the Goddard Space Flight Center (GSFC), wholed the team that developed NASTRAN between 1965 and 1970, recalled in 1982:

NASA’s Office of Advanced Research and Technology (OART) under Dr. Raymond Bisplinghoff sponsored a considerable amount of research in the area of flight structures through its operating centers. Representatives from the centers who man­aged research in structures convened annually to exchange ideas. I was one of the representatives from Goddard Space Flight Center at the meeting in January 1964. . . . Center after center described research programs to improve analysis of structures. Shells of different kinds were logical for NASA to analyze at the time because rockets are shell-like. Each research concentrated on a different aspect of shells. Some were closed with discontinuous boundaries. Other shells had cutouts. Others were noncircular. Others were partial spans of less than 360°. This all seemed quite worthwhile if the prod­ucts of the research resulted in exact closed-form solutions. However, all of them were geared toward making some sim­plifying assumption that made it possible to write a computer program to give numerical solutions for their behavior. . . .

Each of these computer programs required data organization different from every other. . . . Each was intended for explor­ing localized conditions rather than complete shell-like struc­tures, such as a whole rocket. My reaction to these programs was that. . . technology was currently available to give engi­neering solutions to not just localized shells but to whole, highly varied structures. The method was finite elements.[806]

Doug Michel led the meetings at NASA Headquarters. Butler, Harry Runyan of Langley Research Center, and probably others proposed that NASA develop its own finite element program, if a suitable one could

not be found already existing. "The group thought this was a good idea, and Doug followed up with forming the Ad Hoc Group for Structural Analysis, which was headed by Tom Butler of Goddard,” recalled C. Thomas Modlin, Jr., who was one of the representatives from what is now Johnson Space Center.[807] The committee included representatives from all of the NASA Centers that had any significant activity in struc­tural analysis methods at the time, plus an adjunct member from the U. S. Air Force at Wright-Patterson Air Force Base, as listed in the accom­panying table.[808]

CENTER	REPRESENTATIVE(S)
Ames	Richard M. Beam and Perry P. Polentz
Flight Research (now Dryden)	Richard J. Rosecrans
Goddard	Thomas G. Butler (Chair) and Peter A. Smidinger
Jet Propulsion Laboratory	Marshall E. Alper and Robert M. Bamford
Langley	Herbert J. Cunningham
Lewis	William C. Scott and James D. McAleese
Manned Spacecraft (now Johnson)	C. Thomas Modlin, Jr., and William W. Renegar
Marshall	Robert L. McComas
Wright-Patterson AFB	James Johnson (adjunct member)

After visiting several aerospace companies, all of whom were "extremely cooperative and candid,” and reviewing the existing meth­ods, the committee recommended to Headquarters that NASA spon­sor the development of its own finite element program "to update the analytical capability of the whole aerospace community. The program should incorporate the best of the state of the arts, which were cur­rently splintered.”[809]

The effort was launched, under the management of Butler at the Goddard Space Flight Center, to define and implement the General Purpose Structural Analysis program. Requirements were collected from the information brought from the various Centers, from the industry vis­its, and from a conference on "Matrix Methods in Structural Mechanics”

held at Wright-Patterson Air Force Base.[810] Key requirements included the following:[811]

• General-purpose. The system must allow different analysis types—static, transient, thermal, etc.—to be per­formed on the same structural model without alteration.

• Problem size. At least 2,000 degrees of freedom for static and dynamic analyses alike. (Prior state of the art was approximately 100 d. o.f. for dynamic mode analysis and 100 to 600 d. o.f. for static analysis.)

• Modular. Parts of the program could be changed with­out disrupting other parts.

• Open-ended. New types of elements, new analysis mod­ules, and new formats could be added.

• Maintainable and capable of being updated.

• Machine-independent. Capable of operating on IBM 360,

CDC 6000 Series, and UNIVAC 1108 (the only 3 commer­cially available computers capable of performing such analysis at the time), and future generations of computers.

After an initial design phase, the implementation contract was awarded to a team led by Computer Sciences Corporation (CSC), with MacNeal Schwendler Corporation and Martin Baltimore as subcontrac­tors. Coding began in July 1966. Dr. Paul R. Peabody was the principal architect of the overall system design. Dr. Richard H. MacNeal (MacNeal Schwendler) designed the solution structure, taking each type of solu­tion from physics, to math, to programming, assisted by David Harting. Keith Redner was the implementation team lead and head program­mer, assisted by Steven D. Wall and Richard S. Pyle. Frank J. Douglas coded the element routines and wrote the programmer’s manual. Caleb W. McCormick was the author of the user’s manual and supervised NASTRAN installation and training. Other members of the development team included Stanley Kaufman (Martin Baltimore), Thomas L. Clark,

David B. Hall, Carl Hennrich, and Howard Dielmann. The project staff at Goddard included Richard D. McConnell, William R. Case, James B. Mason, William L. Cook, and Edward F. Puccinelli.[812]

NASTRAN embodied many technically advanced features that are beyond the scope of this paper (and, admittedly, beyond the scope of this author’s understanding), which provided the inherent capability to handle large problems accurately and efficiently. It was referred to as a "system” rather than just a program by its developers, and for good reasons. It had its own internal control language, called Digital Matrix Abstraction Programming (DMAP), which gave flexibility in the use of its different modules. There were 151,000 FORTRAN statements, equating to more than 1 million machine language statements. Twelve prepack­aged "rigid formats” permitted multiple types of analysis on the same structural model, including statics, steady-state frequency response, transient response, etc.[813]

The initial development of NASTRAN was not without setbacks and delays, and at introduction it did not have all of the intended capabili­ties. But the team stayed focused on the essentials, choosing which fea­tures to defer until later and which characteristics absolutely had to be maintained to keep NASTRAN true to its intent.[814] According to Butler: "One thing that must be mentioned about the project, that is remark­able, pertains to the spirit that infused it everywhere. Every man thought that he was the key man on the whole project. As it turned out, every man was key because for the whole to mesh no effort was inconsequen­tial. The marvelous thing was that every man felt it inside. There was a feeling of destiny on the project.”[815]

That the developers adhered to the original principles to make NASTRAN modular, open-ended, and general-purpose—with com­mon formats and interfaces among its different routines—proved to be more important in the long term than how many elements and analysis

capabilities were available at introduction. Preserving the intended architecture ensured that the details could be filled in later.