Object-oriented finite element analysis

Over the last 30 years, the finite element method has gained wide acceptance as a general purpose tool for structural modeling and simulation. Typical finite element programs consist of several hundred thousand lines of procedural code, usually written in FORTRAN. Modification or extension of a portion of the code requires a high degree of knowledge of the entire program.Recoding these systems in a new language will not remove this inflexibility. Instead, a redesign using an object-oriented philosophy is needed.The application of object-oriented design to the finite element method has several advantages. The primary advantage is that it encourages the developer to abstract out the essential immutable qualities of the components of the finite element method. This abstraction forms the definition of objects that become the building blocks of the software. The class definitions encapsulate both the data and operations on the data, and provide an enforceable interface by which other components of the software may communicate with the object. Once specified, the object interfaces are frozen. It is possible to extend the interface later without affecting other code, but it should be noted that modifying the existing elements of an interface would require changes throughout the rest of the program wherever the interface was used. The internal class details that are needed to provide the desired interface are invisible to the rest of the program and, therefore, these implementation details may be modified without affecting other code. Thus, the design forms a stable base that can be extended with minimum effort to suit a new task. Due to the encapsulation enforcement inherent in object-oriented languages, new code will work seamlessly with old code. In fact old code may call new code.The system design and a prototype implementation for the finite element method is presented. The design describes the abstraction for each class and specifies the interface for the abstraction. The implementation of a class, and the interaction between objects must conform to the interface definition. Furthermore, recognizing that most finite element development involves the addition of elements, new solution strategies, or new matrix storage schemes, special care was taken to make these interfaces as flexible as possible. The flexibility is provided by an object that is responsible for automatically and efficiently transforming between coordinate systems to relieve element and solution writers from this task. Elements authors are free to work in any convenient coordinate system rather than requiring them to use the degrees-of-freedom described by the modeler. Similarly, the writers of new solution strategies need not deal with any model specific details or transformations, but rather are presented only with the equations to be solved. The transformation from element coordinate systems to final equations, including the effects of constraints and equation reordering, is transparently handled without element or solution writer intervention. This separation of tasks also allows analysis objects to use any matrix storage scheme that is convenient for that particular method. (Abstract shortened by UMI.)...