📄 object-oriented finite element analysis.htm
字号:
<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.0 Transitional//EN">
<!-- saved from url=(0045)http://ce.ecn.purdue.edu/~archer/PhD/PhD.html -->
<HTML><HEAD><TITLE>Object-Oriented Finite Element Analysis</TITLE>
<META http-equiv=Content-Type content="text/html; charset=windows-1252">
<META content="MSHTML 6.00.2900.2180" name=GENERATOR>
<META content=C:\WINDOWS\WINWORD\NORMAL2.DOT name=Template></HEAD>
<BODY>
<P align=center><IMG src="Object-Oriented Finite Element Analysis.files/CE.htm">
<A href="http://ce.ecn.purdue.edu/cgi-bin/imagemap/CE/Maps/cebuttons.map"><IMG
isMap
src="C:\Documents and Settings\tangshibin\桌面\Object-Oriented Finite Element Analysis.files\CE(1).htm"
border=0></A> <IMG src="Object-Oriented Finite Element Analysis.files/CE.htm">
</P>Return to my <A
href="http://ce.www.ecn.purdue.edu/CE/People/FACULTY/archer.html">Home Page</A>
<P></P><BR>
<P align=center>Object-Oriented Finite Element Analysis</P>
<P align=center> </P>
<P align=center>by</P>
<P align=center>Graham Charles Archer</P>
<P align=center> </P>
<P align=center>B.A.Sc. (University of Waterloo) 1985</P>
<P align=center>M.A.Sc. (University of Waterloo) 1986</P>
<P align=center> </P>
<P align=center>A dissertation submitted in partial satisfaction of the</P>
<P align=center>requirements for the degree of</P>
<P align=center>Doctor of Philosophy</P>
<P align=center>in</P>
<P align=center>Engineering-Civil Engineering</P>
<P align=center>in the</P>
<P align=center>GRADUATE DIVISION</P>
<P align=center>of the</P>
<P align=center>UNIVERSITY of CALIFORNIA at BERKELEY</P>
<P align=center> </P>
<P align=center>Committee in charge:</P>
<P align=center> </P>
<P align=center>Professor Christopher Thewalt, Chair</P>
<P align=center>Professor Gregory Fenves</P>
<P align=center>Professor James Demmel</P>
<P align=center> </P>
<P align=center> </P>
<P align=center>1996</P>
<P align=center> </P>
<P align=center> </P>
<P align=center> </P>
<P align=center>The dissertation of Graham Charles Archer is approved:</P>
<P> </P>
<P align=center><IMG height=507
src="Object-Oriented Finite Element Analysis.files/Image158.gif" width=673></P>
<P align=center> </P>
<P align=center>University of California at Berkeley</P>
<P align=center> </P>
<P align=center>1996</P><U>
<P></P></U>
<P> </P>
<P align=center> </P>
<P align=center>Object-Oriented Finite Element Analysis</P>
<P align=center>Copyright 1996</P>
<P align=center>by</P>
<P align=center>Graham Charles Archer</P>
<P align=center> </P><B>
<P align=center>Abstract</P></B>
<P align=center> </P>
<P align=center>Object-Oriented Finite Element Analysis</P>
<P align=center> </P>
<P align=center>by</P>
<P align=center>Graham Charles Archer</P>
<P align=center>Doctor of Philosophy in Civil Engineering</P>
<P align=center>University of California at Berkeley</P>
<P align=center>Professor Christopher Thewalt, Chair</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 structural modeling and
simulation. 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. For the sake
of efficiency, the various components of the program often take advantage of
this accessibility. For example, elements, nodes, and constraints may directly
access the matrices and vectors involved in the analysis to obtain and transmit
their state information. Thus they become intimately tied to the analysis data
structures. This not only compounds the complexity of the components, by
requiring knowledge of the data structures, but writers of new analysis
procedures must be aware of all components that access the data. Modification or
extension of a portion of the code requires a high degree of knowledge of the
entire program. Solution procedures and modeling techniques become hard coded.
The resulting code is inflexible and presents a barrier to practicing engineers
and researchers.</P>
<P align=justify> </P>
<P align=justify>Recoding these systems in a new language will not remove this
inflexibility. Instead, a redesign using an object-oriented philosophy is
needed. 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 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.</P>
<P align=justify> </P>
<P align=justify>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.</P>
<P align=justify> </P>
<P align=right><IMG height=168
src="Object-Oriented Finite Element Analysis.files/Image5.gif" width=408></P>
<P align=justify> </P><B><FONT size=5>
<P align=center>Table of Contents</P></B></FONT>
<P align=center> </P>
<P align=center>List of Figures viii
<P align=justify>List of Tables xi</P>
<P align=justify>1. Introduction 1</P>
<DIR>
<DIR>
<P align=justify>1.1 Problem 1</P>
<P align=justify>1.2 Objective 3</P>
<P align=justify>1.3 Object-Oriented Philosophy as a Solution 4</P>
<P align=justify>1.4 Organization 5</P></DIR></DIR>
<P align=justify>2. Literature Review 7</P>
<DIR>
<DIR>
<P align=justify>2.1 G. R. Miller, et al. 10</P>
<P align=justify>2.2 T. Zimmermann, et al. 11</P>
<P align=justify>2.3 Jun Lu, et al. 12</P>
<P align=justify>2.4 J. W. Baugh, et al. 14</P>
<P align=justify>2.5 H. Adeli, et al. 15</P>
<P align=justify>2.6 Discussion 16</P></DIR></DIR>
<P align=justify>3. Methodologies 19</P>
<DIR>
<DIR>
<P align=justify>3.1 Design Formalisms 20</P>
<DIR>
<DIR>
<P align=justify>3.1.1 Design Intent 20</P>
<P align=justify>3.1.2 Entity Relationship Diagrams 20</P>
<P align=justify>3.1.3 Responsibility Description 21</P>
<P align=justify>3.1.4 Event Flow Diagram 22</P>
<P align=justify>3.1.5 Interface Definition Table 23</P></DIR></DIR>
<P align=justify>3.2 Implementation in C++ 24</P>
<DIR>
<DIR>
<P align=justify>3.2.1 Associations 25</P>
<P align=justify>3.2.2 Inheritance 26</P>
<P align=justify>3.2.3 Interfaces 27</P>
<P align=justify>3.2.4 Libraries 28</P>
<DIR>
<DIR>
<P align=justify>3.2.4.1 Container Classes 29</P>
<P align=justify>3.2.4.2 Numerical Object Library 30</P></DIR></DIR></DIR></DIR>
<P align=justify>3.3 Implementation Formalisms 30</P>
<DIR>
<DIR>
<P align=justify>3.3.1 C++ Interfaces 31</P>
<P align=justify>3.3.2 Demonstration Code 32</P></DIR></DIR></DIR></DIR>
<P align=justify>4. Object Model Design 35</P>
<DIR>
<DIR>
<P align=justify>4.1 Top Level Objects 38</P>
<DIR>
<DIR>
<P align=justify>4.1.1 Model 40</P>
<P align=justify>4.1.2 Map 42</P>
<P align=justify>4.1.3 Analysis 48</P></DIR></DIR>
<P align=justify>4.2 Components of the Model 52</P>
<DIR>
<DIR>
<P align=justify>4.2.1 Degree of Freedom Group (Node) 52</P>
<P align=justify>4.2.2 Element 59</P>
<P align=justify>4.2.3 Material, Action/Deformation, and Constitutive Model
65</P>
<P align=justify>4.2.4 Constraint 70</P>
<P align=justify>4.2.5 Displacement Boundary Condition 73</P>
<P align=justify>4.2.6 Load Case 75</P></DIR></DIR>
<P align=justify>4.3 Handlers 82</P>
<DIR>
<DIR>
<P align=justify>4.3.1 Constraint Handler 83</P>
<P align=justify>4.3.2 Reorder Handler 86</P>
<P align=justify>4.3.3 Matrix Handler 89</P></DIR></DIR>
<P align=justify>4.4 Utility Objects 91</P>
<DIR>
<DIR>
<P align=justify>4.4.1 Geometry 91</P>
<P align=justify>4.4.2 Numerical Objects 95</P>
<P align=justify>4.4.3 Augmented Vector and Matrix Objects
98</P></DIR></DIR></DIR></DIR>
<P align=justify>5. Behavior of High Level Classes 104</P>
<DIR>
<DIR>
<P align=justify>5.1 Element 106</P>
<DIR>
<DIR>
<P align=justify>5.1.1 Element Geometry 106</P>
<P align=justify>5.1.2 Communication of Element Properties 107</P>
<P align=justify>5.1.3 Element State 109</P>
<P align=justify>5.1.4 Action/Deformation 110</P>
<P align=justify>5.1.5 Resisting Force 111</P></DIR></DIR>
<P align=justify>5.2 Constitutive Model 111</P>
⌨️ 快捷键说明
复制代码
Ctrl + C
搜索代码
Ctrl + F
全屏模式
F11
切换主题
Ctrl + Shift + D
显示快捷键
?
增大字号
Ctrl + =
减小字号
Ctrl + -