📄 object-oriented finite element analysis.htm
字号:
<P align=justify> </P>
<P align=justify> </P>
<P align=justify> </P>
<P align=justify> </P>
<P align=justify>Over the last 30 years, the finite element method has gained
wide acceptance as a general purpose tool for the modeling and simulation of
physical systems. It has become a crucial analytical technique in such diverse
fields as structural mechanics, fluid mechanics, electro-magnetics, and many
others. As finite element techniques evolve, the existing software systems must
be modified. Therefore, finite element analysis programs must be flexible.</P>
<P align=justify> </P>
<P align=justify> </P><B><FONT size=4>
<P>1.1 Problem</P></B></FONT>
<P align=justify>Typical finite element programs consist of several hundred
thousand lines of procedural code, usually written in FORTRAN. The codes contain
many complex data structures, which are accessed throughout the program. This
global decreases the flexibility of the system. It is difficult to modify the
existing codes and to extend the codes to adapt them for new uses, models, and
solution procedures. The inflexibility is demonstrated in several ways: 1) a
high degree of knowledge of the entire program is required to work on even a
minor portion of the code; 2) reuse of code is difficult; 3) a small change in
the data structures can ripple throughout the system; 4) the numerous
interdependencies between the components of the design are hidden and difficult
to establish; 5) the integrity of the data structures is not assured.</P>
<P align=justify> </P>
<P align=justify>For the sake of efficiency, the various components of the
program often directly access the program's data structures. For example,
elements, nodes, and constraints may need to access the matrices and vectors
involved in the analysis to obtain and transmit their state information. This
compounds the complexity of the components, by requiring knowledge of the
program's data structures. Modification or extension to a component requires not
only knowledge of the component at hand, but also a high degree of knowledge of
the entire program.</P>
<P align=justify> </P>
<P align=justify>The components of the system become intimately tied to the
program's data structures. Access to the data structures occurs throughout the
component, and easily becomes inseparable from the component's function. Since
the layout of the data structures is unique to each program, the possibility of
the reuse of the code in other systems is greatly diminished. Also, code from
other programs is difficult to adapt for use within the system.</P>
<P align=justify> </P>
<P align=justify>Since the data structures are globally accessible, a small
change in the data structures can have a ripple effect throughout the program.
All portions of the code that access the affected data structures must be
updated. As a result, the layout of the data structures tend to become fixed
regardless of how appropriate they remain as the code evolves.</P>
<P align=justify> </P>
<P align=justify>The components of the system become dependent on each other via
their common access to the data structures. Little control can be placed on the
access. As a result, these interdependencies are numerous. More importantly,
they are implicit. One component can be completely unaware of another's reliance
on the same data structure. Thus, when modification or extension to a component
occurs, it is difficult to assure that all affected portions of the code are
adjusted accordingly.</P>
<P align=justify> </P>
<P align=justify>Access to the program's data structures is usually described by
an interface. The interface may merely consist of a document describing the
layout of the data, or may get as involved as a memory management tool that
shields the data from the component routines. In either case, it is up the each
programmer to honor the interface. The best laid plans are easily subverted for
the sake of efficiency and ease of implementation.</P>
<P align=justify> </P>
<P align=justify> </P><B><FONT size=4>
<P>1.2 Objective</P></B></FONT>
<P align=justify>Current finite element analysis software is inflexible and
presents a barrier to practicing engineers and researchers. Recoding these
systems in a new language will not remove this inflexibility. Instead, a
redesign is needed. The objective of this dissertation is to provide a new
architecture for finite element analysis software which results in an
implementation that is manageable, extendible, and easily modified. The design
will provide the Civil Engineering profession with a flexible tool that can be
adapted to meet future requirements.</P>
<P align=justify> </P>
<P align=justify> </P><B><FONT size=4>
<P>1.3 Object-Oriented Philosophy as a Solution</P></B></FONT>
<P align=justify>The application of object-oriented design has proven to be very
beneficial to the development of flexible programs. The basis of object-oriented
design is abstraction. The object-oriented philosophy abstracts out the
essential immutable qualities of the components of the finite element method.
This abstraction forms a stable definition of objects in which the relationships
between the objects are explicitly defined. The implicit reliance on another
component's data does not occur. Thus, the design can be extended with minimal
effort.</P>
<P align=justify> </P>
<P align=justify>The object-oriented paradigm provides four fundamental concepts
[33, 9]; <I>objects</I>, <I>classes</I>, <I>inheritance</I>, and
<I>polymorphism</I>. Software is organized into <I>objects</I> that store both
its data and operators on the data. This permits developers to abstract out the
essential properties of an <I>object</I>; those that will be used by other
<I>objects</I>. This abstraction allows the details of the implementation of the
<I>object</I> to be hidden, and thus easily modified. <I>Objects</I> are
instances described by a <I>class</I> definition. <I>Classes</I> are related by
<I>inheritance</I>. A subclass inherits behavior through the attributes and
operators of the superclass. <I>Polymorphism</I> allows the same operation to
behave differently in different <I>classes</I> and thus allows <I>objects</I> of
one <I>class</I> to be used in place of those of another related
<I>class</I>.</P>
<P align=justify> </P>
<P align=justify>The premise of this research is that the previously outlined
problems with current finite element programs can be eliminated by
object-oriented design. The abstraction of the data into objects limits the
knowledge of the system required to work on the code to only the object of
interest and the services other objects provide to the object of interest.
Encapsulating the data and operations together isolates the classes and promotes
the reuse of code. Code reuse is further enhanced by placing attributes common
to several subclasses into the superclass, which is implemented once for all.
Changes to a class affect only the class in question. There is no ripple effect.
Interdependencies between the classes are explicitly laid out in the class
interfaces. The number of dependencies are minimized and easily determined.
Object-oriented languages enforce the encapsulation of the classes. The
integrity of the data structures is assured by the language.</P>
<P align=justify> </P>
<P align=justify> </P><B><FONT size=4>
<P>1.4 Organization</P></B></FONT>
<P align=justify>The layout of this dissertation is described below.</P>
<P align=justify> </P>
<DIR>
<DIR><B>
<P align=justify>Chapter 2: Literature Review - </B>provides a survey of the
current literature regarding object-oriented finite element analysis design and
programming.</P>
<P align=justify> </P><B>
<P align=justify>Chapter 3: Methodologies - </B>presents various methodologies
that were used to design, implement, and document the object-oriented finite
element analysis system.</P><B>
<P align=justify> </P>
<P align=justify>Chapter 4: Object Model Design - </B>provides a top-down,
system level description of the object model design. The primary focus of the
chapter is the description of abstractions for each class. The descriptions are
given in terms of: the design intent, which describes how the class fits into
the system; an entity-relationship diagram, which shows how the class is
associated with other classes; a responsibility description, which details the
external and internal responsibilities of the class; an event flow diagram,
which outlines the flow of information for the class; and the class interface
definition table, which precisely defines the methods the class provides to the
system.</P><B>
<P align=justify> </P>
<P align=justify>Chapter 5: Behavior of High Level Classes - </B>describes the
behavior of several important high level objects in the system design. The
chapter provides insight into the implementation, without focusing on the
details. The objects described are the Element, the Constitutive Model, the
Constraint Handler, the Map, and the Analysis.</P><B>
<P align=justify> </P>
<P align=justify>Chapter 6: Extensions and Examples - </B>contains extensions to
the basic finite element analysis system described in the previous chapters, and
examples that demonstrate the use of the system. The extensions demonstrate that
the design is extendible. The examples include: a two-dimensional beam element
with hinges at the ends; a type of substructuring using the element interface;
several analysis types, including a nonlinear dynamic solution scheme using
Newton-Raphson iteration; and an example of the use of the program.</P><B>
<P align=justify> </P>
<P align=justify>Chapter 7: Conclusions and Future Work - </B>summarizes the
research. Both the significant findings and the direction of future research are
discussed.</P><B>
<P align=justify> </P>
<P align=justify>Appendix: C++ Class Interfaces - </B>presents the public
portions of the class interfaces in the implementation.</P><B>
<P align=justify> </P></B>
<P align=justify> </P></DIR></DIR>
<P></P>
<P align=justify> </P>
<P align=justify> </P><B><FONT size=5>
<P align=center>2. Literature Review</P></B></FONT>
<P align=justify> </P>
<P align=justify> </P>
<P align=justify> </P>
<P align=justify> </P>
<P align=justify> </P>
<P align=justify> </P>
<P align=justify> </P>
<P align=justify> </P>
<P align=justify>The application of object-oriented design has only come to the
structural engineering community in the last several years. Several researchers
began work in the late eighties, leading to publication in the nineties. In
1990, Fenves [17] described the advantages of object-oriented programming for
the development of engineering software. Namely, that its data abstraction
technique leads to flexible, modular programs with substantial code reuse. </P>
<P align=justify> </P>
<P align=justify>One of the first detailed applications of the object-oriented
paradigm to finite element analysis was published in 1990 by Forde, <I>et
al.</I> [19]. The authors abstracted out the essential components of the finite
element method (elements, nodes, materials, boundary conditions, and loads) into
a class structure used by most subsequent authors. Also presented was a
hierarchy of numerical objects to aid in the analysis. Other authors [18, 24,
29, 30] increased the general awareness of the advantages of object-oriented
finite element analysis over traditional FORTRAN based approaches.</P>
<P align=justify> </P>
<P align=justify>Some researchers have concentrated on the development of
numerical objects. Scholz [34] gives many detailed programming examples for full
vector and matrix classes. Zeglinski, <I>et al.</I> [40] provide a more complete
linear algebra library including full, sparse, banded, and triangular matrix
types. Also included is a good description of the semantics of operators in C++.
Lu, <I>et al.</I> [22] present a C++ numerical class library with additional
matrix types such as a profile matrix. They report efficiency comparable to a C
implementation. Lu, <I>et al.</I> weakly argue against using the standard
FORTRAN library LAPACK [2] by noting that "[LAPACK does] not embody the
principles of encapsulation and data abstraction". Dongarra, <I>et al.</I> [13]
present an object-oriented (C++) version of LAPACK named LAPACK++. It includes
full, symmetric, and banded matrix types, and, according to the authors, the
library can be extended to include other types. They report speed and efficiency
competitive with native FORTRAN codes.</P>
<P align=justify> </P>
<P align=justify>Rihaczek, <I>et al.</I> [31] present a short paper showing some
abstractions for a heat transfer type problem. An interesting component of their
design is the Assemblage class which coordinates the interaction between the
model and the analysis. It contains the topological buildup, the constraints,
and the loads. Chudoba, <I>et al.</I> [8] present a similar type of Connector
class, to exchange data between elements and the analysis. The concept of an
object responsible for the mapping between the model and the analysis is echoed
by Lu, <I>et al.</I> [22, 7, 35].</P>
<P align=justify> </P>
<P align=justify>One of the most complete treatments of material class, the
modeling of the constitutive relationships, is presented by Zahlten, <I>et
al.</I> [39, 20]. A particular material object is an assemblage of a yield
surface object, a hardening rule object, a flow rule object, and an algorithm to
solve the initial value problem. The material object itself tracks the state of
strain and directs the calculation of stress.</P>
<P align=justify> </P>
<P align=justify>The focus of this dissertation is the development of a complete
finite element system architecture. The remainder of this chapter presents five
such systems that exist in the literature. Each architecture is evaluated with
respect to the following significant criteria:</P>
<DIR>
<DIR>
<P align=justify><FONT face=Symbol>⌨️ 快捷键说明
复制代码
Ctrl + C
搜索代码
Ctrl + F
全屏模式
F11
切换主题
Ctrl + Shift + D
显示快捷键
?
增大字号
Ctrl + =
减小字号
Ctrl + -