Early NASA “Dream Computer Program” Still Optimizes Designs

NASA Technology

At the top of the food chain, an apex predator hunts without fear of being hunted. That’s why MSC Software Corporation branded its latest software line MSC Apex and dubbed the original, 2014 release “Arctic Wolf,” confident the computer-aided engineering program would soon, like its namesake, dominate the landscape.

Computer-aided engineering uses software to model, test, and analyze structures and parts before they’re ever built. It’s a tool that has come to be embraced by industries from aeronautics and auto manufacturing to farm machinery and medical equipment.

NASA, always trying to stay atop the engineering curve, quickly became an Apex customer and found its nomenclature to be justified.

“With Apex, what normally can take you days or weeks can be done in a couple of hours,” says Scott Taylor, a senior mechanical engineer at NASA’s Marshall Space Flight Center. Taylor uses the software to analyze the Agency’s next-generation rocket, the Space Launch System. “It is just stunning, and I’ve been here at NASA as a contractor since ’89. I’ve used all of the packages. This is just simply something else.”

But a lot of the computer coding that enables Apex, as well as a number of other related programs, was first found in the product of a long-ago partnership between Newport Beach, California-based MSC and NASA: NASTRAN.

Half a century after its creation, NASTRAN remains at the cutting edge of its field, both in the internal workings of programs like Apex and as an industry standard in its own right. To this day it is one of NASA’s most widely used software programs, and its influence has changed the design process for a number of industries.

NASTRAN owes its existence perhaps first and foremost to Thomas G. Butler, who, as an engineer at Goddard Space Flight Center in the 1960s, championed the creation of a general-purpose finite element analysis (FEA) program.

FEA is a now-common computerized numerical method for modeling structures and predicting how they will react to outside forces such as pressure, vibration, and temperature.

But back then, the field was in its infancy, and when Butler hired Reg Mitchell, then an engineering student at George Washington University, as a summer engineering aide in 1964, “I had to go to the library to find out what finite elements were,” Mitchell recalls.

Butler had previously worked at the Baltimore division of the Martin Company, which developed an early, basic finite element modeling program, Mitchell explains. “He arranged to have a copy brought down to Goddard, and I was to try to figure out how to use it that summer.”

Meanwhile, Butler recruited supporters from the various NASA field centers and several Department of Defense agencies, and a committee was formed with him at the head. “These fellows all got together and came up with their dream computer program, all the things it should do—a lot of which weren’t doable in 1964, but they described what they wanted, not necessarily what they had,” Mitchell says.

Following a competitive process, a team of three companies—Computer Sciences Corporation (CSC), the Martin Company, and MSC—was selected to build this dream program. Richard MacNeal and others from MSC, better known then as the MacNeal-Schwendler Corporation, handled the theoretical mathematics behind the software’s design, while CSC created much of the architecture and programming, and Martin produced the structure-plotting capability, Mitchell says.

He describes the basic idea of the program as “a virtual Tinkertoy set.”

A model was defined using coordinates for grid points, connected by virtual plates, beams, rods, and other finite element building blocks that were assigned the properties of various materials. “Then the computer takes all this description of geometry and the material the elements are made of and builds a huge matrix equation set that describes this theoretical model.” Hypothetical loads of pressure or vibration, for example, are applied, and the software figures out how these loads move through the model.

Engineers built the program as a series of functional modules. “NASTRAN was one of the first programs that was highly modular in its approach, which is probably why it’s still around now, all these years later,” Mitchell says.

While NASA had an obvious interest in predicting the behavior of aeronautic and space vehicles, NASTRAN was always intended to work just as well for any other structure, he says. “NASTRAN was to be a general-purpose structural analyzer. It didn’t matter what you were analyzing. It hasn’t mattered to this day.”

This flexibility earned the program wide appeal, and its extensive documentation also eased its adoption by industry, says Mitchell, who was the chief reviewer for the programming manual. He describes it as “about two phone books thick.” In addition, a user’s manual and a theoretical manual were also created.

“Butler was big on documentation, not only on how to use the software but also how to fix it, how to add to it—all this was extensively documented, much better than the average program in the late 1960s,” he says.

NASTRAN was first demonstrated to modest fanfare in a Goddard auditorium in May of 1967, and the program was fully functional a year later.

Technology Transfer

In the early 1970s, NASA released NASTRAN to the public through its Computer Software Management and Information Center (COSMIC) at the University of Georgia, which managed the Agency’s public software programs at the time, offering them at low prices.

MSC and other companies soon began marketing their own versions of the program.

“As soon as we started distributing it, industry saw a good thing and pounced right on it, with the automobile companies being the biggest pouncers,” Mitchell says. “Using NASTRAN in the process that’s now called virtual product design, you can do a lot of trial-and-error in your structures on the computer instead of going out and building stuff and driving it around the track. It significantly shortened the development time for their automobiles.”

The automotive industry has remained the biggest user, but companies and Government agencies have used NASTRAN to design everything from steam turbines to tractors, floppy disks to computer printers, oil platforms to buildings, and manufacturing equipment to roller coasters, as well as ships, submarines, planes, helicopters, and space shuttles (Spinoff 1976-1982, 1986, 1988, 1990, 1991, 1998). The program has been used for such disparate purposes as earthquake analysis and predicting thermal activity in poultry houses and plant nurseries.

Meanwhile, NASTRAN has grown from about 300,000 lines of code to nearly a million as it has been refined and new modules have been added. The Space Agency remains a regular user.

“If you’re going to qualify anything for flight, especially manned flight, NASTRAN is the software that’s been relied on,” Taylor says. “For us, it’s a daily experience, running NASTRAN.”

Benefits

NASTRAN’s code has turned up in other software—Apex is one of several MSC programs that incorporate it, for example—and its successes, both in the marketplace and in the design lab, inspired the widespread adoption and further refinement of FEA software. Such software has since become an everyday engineering tool that has decreased the time and cost of design, raised engineering standards, and led to better understandings of the behavior of materials and systems.

“NASTRAN is used by most aerospace and automotive manufacturers out there,” says Hugues Jeancolas, senior product manager at MSC, noting that it was important for the company to build its latest software on the NASTRAN foundation that customers have come to trust for its accuracy and reliability. “Apex is reusing all the same NASTRAN element and material formulations that have proven themselves over the past decades and will continue to give our users the same level of accuracy.”

The difference is that, as MSC’s next-generation computer-aided engineering platform, Apex integrates NASTRAN’s solver capabilities with a modern, easy-to-use graphical user interface. The platform now has six releases and is quickly gaining a hold on the market.

Until now, computer-aided engineering’s complexity has restricted its use to a small group of experts who usually use it to run simulations late in the design process, says Jeancolas. As a result, much of the insight gained from simulation is not leveraged to the extent it could be. “MSC’s new platform intends to enable non-experts to harness the power of simulation earlier in the design cycle by delivering a seamless integration of both modeling and simulation tools,” Jeancolas says.

Even in other modern software, he says, converting computer-aided design models into simplified, FEA-ready models is extremely time-consuming. A majority of the engineers MSC surveyed before creating Apex said they spent more than a third of their time preparing models. For example, the necessary process of breaking up models into a mesh of tiny elements is long, tedious, and error-prone. “Sixty-seven percent of FEA experts we interviewed need two to four solver runs to obtain a converged solution,” Jeancolas says.

Apex eliminates much of that manual work. Meshes regenerate automatically as the engineer makes changes to the geometry, and the program continually checks to see that all elements of a model are viable, color-coding those that have problems like a lack of part connectivity or a possible over-constraint. “Our integration eliminates this incremental, iterative process, where you pass entire datasets from a pre-processor to the solver, and try, try, try until you get it right,” says Jeancolas. “Solver checks are now fully synchronous with modeling.”

Another evolution in Apex comes from its parts-based architecture. A designer often optimizes a model by running multiple simulations with only slight modifications to a single part. Apex speeds up this process by storing and reusing the mathematical representation of the parts that have not been modified, while traditional software requires all parts to be processed at every solver execution. “This gives users the opportunity to incrementally build, validate, and execute simulations,” says Jeancolas. “After the complete assembly is built, small changes are fast to execute.“

Finally, Apex’s capabilities for processing the results of simulations are also intimately integrated with its solver. This integration has been most fully realized in the latest release, Fossa, where users can now artificially shift vibration frequencies, add damping, or recompute a structure‘s frequency response, skipping many steps of traditional finite element programs.

In the end, Jeancolas says, a model and simulation can be completed in as little as one-tenth the time it would take with other FEA software.

Taylor says he’s seen the evidence himself, recalling one project that took an expert the better part of a month. “We got ahold of it with Apex, and I promise you, we were able to do in a morning what took him a month,” he reports.

The integration of an intuitive new user interface with time-tested solver methods not only offers major productivity gains for FEA experts but also makes this previously esoteric technology accessible to any engineer, says Jeancolas. He says Apex represents the next step in a process MSC began decades ago when it first repackaged NASTRAN—“commercializing extremely complex technology and putting it in the hands of everybody.”

The new software also reflects the intentions of the committee that dreamed up NASTRAN at Goddard, wanting to leverage the latest computing power to design better structures faster and more economically.

Given the reach this early software has had across years and industries, Mitchell says, “If Tom Butler were still alive, he would say his vision has been fulfilled. He envisioned it as a general-purpose program that could be used for anything, anywhere.”