Mish, K.D. and Mello, J. “ComputerAided Engineering” Mechanical Engineering Handbook Ed. Frank Kreith Boca Raton: CRC Press LLC, 1999
c
1999 by CRC Press LLC
Kyran D. Mish
California State University, Chico
Joseph Mello
Aerojet Corporation

151 
Deﬁnition of Terms (CAD/CAM/CAE) • Overview of ComputerAided Engineering • Goals of ComputerAided Engineering Chapter 



Architecture 
153 
Software Engineering Overview • Computer Languages • Data Base Systems • Operating System Characteristics • Parallel Computation • Computer Graphics and Visualization

1535 
Computational Solid, Fluid, and Thermal Problems • Mathematical Characteristics of Field Problems • Finite Element Approximations in Mechanical Engineering • Finite Difference Approximations in Mechanics • Alternative Numerical Schemes for Mechanics Problems • Time Dependent and Nonlinear Computational Mechanics • Standard Packages Criteria • Selection of Software — Benchmarking 


1578 
Artiﬁcial Intelligence • Expert Systems in Mechanical Engineering Design • Neural Network Simulations • Fuzzy Logic and Other Statistical Methods 


1585 
15.1 Introduction
Introduction • EntityBased CAD Systems • Solid or Feature Based CAD Systems • Computer Aided Manufacturing (CAM)
The revolution in computer technology that has taken place over the last few decades has changed the face of all engineering disciplines. Fortunately, computers appropriate for solving complex mechanical engineering problems have evolved from complicated, rare, and expensive mainframes or supercomputers of yesterday to simple, common, and inexpensive desktop microcomputers widely available today. During this period, the application of improved computer technology has revolutionized the profession of mechanical engineering and enabled practicing engineers to solve problems routinely that a few decades ago would have resisted any available solution technique. However, many engineers possess only a limited grasp of important topics such as computational mechanics, computer science, and advanced computeraided design principles. Thus, this chapter the present fundamentals of these computational
© 1999 by CRC Press LLC
15 1
15 2
Section 15
topics, in order to assist the practicing mechanical engineer in maintaining an appropriate highlevel understanding of these emerging engineering tools.
Deﬁnition of Terms (CAD/CAM/CAE)
First, it is necessary to deﬁne a few terms related to the integration of the computer into various aspects of engineering practice:
• Computeraided engineering (CAE) is a broadly inclusive term that includes application of the computer for general tasks encountered in mechanical engineering, including analysis, design, and production.
• Computeraided manufacture (CAM) is the topic concerned with the integration of the computer into the manufacturing process, including such tasks as controlling realtime production devices on the factory ﬂoor. This subject is treated in Section 13.
• Computeraided design (CAD) is a general term outlining areas where computer technology is used to speed up or eliminate efforts by engineers within the design/analysis cycle. This topic is also covered in Section 11.
The acronym CAD is also used as an abbreviation for computeraided drafting. Since drafting is a key component of the mechanical engineering design process, this more narrow meaning will be integrated into the general notion of computeraided design practice.
Overview of ComputerAided Engineering
There are many important components of integrating the computer into mechanical engineering. In the past few decades, integrating the computer into mechanical engineering practice was largely a matter of generating input data for computational analyses and subsequent examination of the output in order to verify the results and to examine the response of the computer model. Today there are a wide variety of integration schemes used in engineering practice, ranging from artiﬁcial intelligence applications oriented toward removing the engineer from the design/analysis cycle, to “engineer in the loop” simu lations intended to ofﬂoad to the computer the quantitative tedium of design and analysis in order to permit the engineer to concentrate instead on qualitative issues of professional judgment. In the near future, these existing computer integration techniques will be combined with virtual reality technology and improved models for human/computer interaction. In order to use these new developments, engineers must be appropriately schooled in the fundamental tenets of modern computeraided engineering.
Goals of ComputerAided Engineering Chapter
This chapter is designed to aid practicing mechanical engineers in understanding the scope of applications of computer technology to their profession. To avoid premature obsolescence of the material presented here, a highlevel orientation is utilized. Details of computational techniques are relegated to a catalog of appropriate references, and highlevel “practical” concepts are emphasized. Lowlevel details (such as computer performance issues) change rapidly relative to highlevel concerns (such as general classi ﬁcations of computer function, or qualitative measures of computer solution quality). Thus, concentrating on a technical overview of computeraided engineering will permit this chapter to stay uptodate over the long term. In addition, this approach provides the practicing mechanical engineer with the funda mental principles required to accommodate the relentless pace of change that characterizes the world of modern computation. In addition to providing engineers with basic principles of computer science, computational mechanics, computer intelligence, and examples of the application of CAD/CAM principles, this chapter also provides insight into such simple but commonly neglected issues as:
© 1999 by CRC Press LLC
ComputerAided Engineering
15 3
• What are the best ways to identify and judge computer applications for integration and use in a practical engineering setting?
• What common pitfalls can be encountered using generalpurpose CAE software, and how can these problems be avoided?
• What are the most important characteristics of engineering computation, and how do engineering computer problems differ from computational methods used in other ﬁelds?
The development of material in this chapter is oriented toward presenting the practical how of effectively using engineering software as opposed to the mathematical why of identifying the cause of pathological computer results. This chapter therefore ﬁrst provides the practicing mechanical engineer with an overview of the ﬁeld of computeraided engineering, and then presents that material in a manner less likely to become obsolete due to the rapid pace of change in this important engineering discipline. Finally, in order to avoid overlap with other chapters, many details (for example, mathematical deﬁni tions) are relegated to other chapters, or to appropriate references. Thus this chapter mainly provides an overview of the broad subject of computeraided engineering, leaving the individual component subjects to other chapters or to outside references.
15.2 Computer Programming and Computer Architecture
Few other aspects of engineering practice change as rapidly as the use of the computer. Fifty years ago, mechanical engineers analyzed and designed automobiles that are not radically different from the automobiles of today, but practicing engineers of that era had no means of electronic calculation. Twenty ﬁve years ago, mechanical engineers designed highperformance aircraft and space vehicles that are similar to those currently under development, but the computers of that more recent era had less power than a typical microprocessor available today in an automobile’s braking system. Ten years ago, an advanced supercomputer appropriate for highperformance engineering computation cost several million dollars, required custom construction, installation, and support, and could perform between 10 million and 100 million ﬂoatingpoint operations per second. Today, one can buy such computational power for a few thousand dollars at a retail electronics store. Given this background of astonishing change in the performance, size, and cost of computers, it is clear that the applications of computers to the practice of mechanical engineering can be expected to advance at an equally breathtaking rate. This section presents fundamental principles from the viewpoint of what can be expected between today and the beginning of the next century. The emphasis is on basic principles and fundamental deﬁnitions.
Software Engineering Overview
The modern ﬁeld of software engineering is an outgrowth of what used to be called computer program ming. Like many other engineering disciplines, software engineering gains much of its knowledge base from the study of failures in the speciﬁcation, design, and implementation of computer programs. Unlike most engineering ﬁelds, however, the accepted codes of practice for software engineering are not yet universally adhered to and many preventable (and expensive) software failures still occur.
History of the Software Engineering Discipline
Software engineering is barely two decades old. Early efforts in this ﬁeld are based on viewing the process of designing and implementing computer programs as analogous to designing and constructing physical objects. One of the most inﬂuential works demonstrating this “manufacturing tool” approach to the conceptualization of software is Software Tools (Kernighan and Plauger, 1976). In this view, large software projects are decomposed into reusable individual components in the same manner that complex machinery can be broken up into smaller reusable parts. The notion that computer programs could be constructed from components that can then be reused in new conﬁgurations is a theme that runs
© 1999 by CRC Press LLC
15 4
Section 15
throughout the history of the software engineering ﬁeld. Modularity alone is not a panacea, however, in that programming effort contained within modules must be readable so as to facilitate veriﬁcation, maintenance, and extension. One of the most inﬂuential references on creating readable and reliable code is The Elements of Programming Style (Kernighan and Plauger, 1978). Emphasizing a modular and reusable approach to software components represents one of the primary threads of software engineering, and another important related thread arises in parallel to the idea of “manufacture” of software as an administrative process. After the failure of several large software projects in the 1960s and 1970s, early practitioners of software engineering observed that many of these software failures resulted from poor management of the software development process. Chronicles of typical failures and the lessons to be learned are detailed in Fred Brooks’ The Mythical ManMonth (Brooks, 1975), and Philip Metzger’s Managing a Programming Project (Metzger, 1983). Brooks’ conclusions are generally considered among the most fundamental principles of the ﬁeld. For example, his observation that adding manpower to a late software project makes it later is generally accorded the status of an axiom, and is widely termed “Brooks’s law.” More recent efforts in software management have concen trated on constructive solutions to past failures, as exempliﬁed by Watts Humphrey’s Managing the Software Process (Humphrey, 1989). Understanding of the local (poor design) and global (poor management) causes of software failure has led to the modern study of software engineering. Obstacles to modularization and reuse of software tools were identiﬁed and proposed remedies suggested and tested. Administrative and largescale archi tectural failures have been documented, digested, and their appropriate solutions published. The result is a substantial body of knowledge concerning such important topics as speciﬁcation and design of computer programs, implementation details (such as choice of programming language), and usability of software (e.g., how the human user relates to the computer program). This collection of knowledge forms the basis for the modern practice of software engineering (see Yourdon, 1982).
Standard Models for Program Design and Implementation
A simple conceptual model of a program design and implementation methodology is presented by Yourdon (1993). This model is termed the “waterfall model” because its associated schematic overview bears a resemblance to a waterfall. The fundamental steps in the waterfall model (see Figure 15.2.1) proceed consecutively as follows:
FIGURE 15.2.1 Waterfall model for software development.
• System Analysis — the requirements of the software system are analyzed and enumerated as a set of program speciﬁcations.
• System Design — the speciﬁcations are translated into precise details of implementation, including decomposition of the software system into relevant modules, and the implementation details required within this modular structure.
© 1999 by CRC Press LLC
ComputerAided Engineering
15 5
• Programming — the proposed design is implemented in a computer programming language (or collection of languages) according to the structure imposed in the system design phase.
• Testing — the resulting computer program is tested to insure that no errors (“bugs”) are present, and that it is sufﬁciently efﬁcient in terms of speed, required resources (e.g., physical memory), and usability.
• Delivery — the completed program is delivered to the customer.
This approach for software development works well for the small tasks, but for larger mechanical engineering projects there are many problems with this model. Probably the most important difﬁculty is that large projects may take years of development effort, and the customer is forced to wait nearly until the end of the project before any results are seen. If the project’s needs change during the implementation period (or more commonly, if those needs were not speciﬁed with sufﬁcient accuracy in the ﬁrst place), then the ﬁnal product will be inadequate, and required changes will have to be speciﬁed before those modiﬁcations can be “percolated” back through the waterfall life cycle again. Another important difﬁculty with this scheme occurs because qualitycontrol issues (e.g., testing) are delayed until the project is nearly ﬁnished. In practice, preventative qualityassurance measures work better at reducing the likelihood that errors will occur in the program. To avoid the inherent difﬁculties of the waterfall design, restructure this sequential design model into a spiral form that emphasizes more rapid incremental deliveries of programming function. These modiﬁed techniques are termed “incremental” or “spiral” development schemes (see Figure 15.2.2). The emphasis on quick delivery of incremental programming function permits seeing results sooner and, if necessary, making changes.
END (or
next spiral)
FIGURE 15.2.2 Spiral model for software development.
One important interpretation of the spiral development model is that the initial implementation of the program (i.e., the ﬁrst pass through the spiral) can often be constructed as a simple prototype of the desired ﬁnal application. This prototype is often implemented with limited function, in order to simplify the initial development process, so that little or no code developed in the prototypical implementation ends up being reused in the ﬁnal commercial version. This approach has a rich history in practical software development, where it is termed “throwing the ﬁrst one away” (after a similarly titled chapter in Brooks, [1975]). This widely used scheme uses the prototype only for purposes of demonstration, education (i.e., to learn the location of potential development pitfalls), and marketing. Once the prototype has been constructed and approved, design and implementation strategies more similar to the traditional waterfall approach are used for commercial implementation. An obvious argument against spiral development models that incorporate a disposable prototype is that the cost of development is paid twice: once for the prototype and once again for the ﬁnal imple mentation. Current remedies for this inherent problem include “rapid application development” (RAD)
© 1999 by CRC Press LLC
15 6
Section 15
methods, which emphasize the use of computerassisted software engineering (CASE) tools to permit substantial reuse of the prototype in the ﬁnal version. With this approach, the programmer uses specially designed computer applications that build the programs out of existing components from a software library. Program components that are especially mundane or difﬁcult to implement (such as those commonly associated with managing a program’s graphical user interface) often represent excellent candidates for automation using RAD or CASE tools. This area of software design and implementation will undoubtedly become even more important in the future, as the ability of computer programs to create other computer applications improves with time.
Computer Languages
Regardless of what future developments occur in the ﬁeld of CASE tools, most current computer programming efforts are carried out by human programmers using highlevel programming languages. These programming languages abstract lowlevel details of computer function (such as the processes of performing numerical operations or allocating computer resources), thus allowing the programmer to concentrate on highlevel concepts appropriate for software design and implementation. Figure 15.2.3 diagrams the various interrelationships among abstractions of data, abstraction of instructions, and combinations of abstracted data and instructions. In general, more expressive languages are to be found along the diagonal line, but there are many instances in which increased abstraction is not necessarily a primary goal (for instance, performing fast matrix operations, which can often be done efﬁciently in a procedural language).
FIGURE 15.2.3 Language abstraction classiﬁcation.
In addition, highlevel programming languages provide a means for making computer programs portable , in that they may be moved from one type of computer to another with relative ease. The combination of portability of computer languages and adherence to standard principles of software design enables programmers to produce applications that run on a wide variety of computer hardware platforms. In addition, programs that are designed to be portable across different computers available today are generally easy to migrate to new computers of tomorrow, which insulates the longerterm software development process from shortterm advances in computer architecture. Perhaps the best example of how good program design and highlevel language adherence work together to provide longevity for computer software is the UNIX operating system. This common operating system was designed and implemented in the 1970s using the C programming language, and runs with only minor modiﬁcations on virtually every computer available today. This operating system and its associated suite of software tools provide an excellent demonstration of how good software
© 1999 by CRC Press LLC
ComputerAided Engineering
15 7
design, when implemented in a portable programming language, can result in a software product that exhibits a lifespan much greater than that associated with particular hardware platform.
Computer Language Classiﬁcation
Computer programs consist of two primary components: data and instructions. Instructions reﬂect actions taken by the computer program, and are comparable to verbs in natural human languages. In a similar manner, data reﬂect the objects acted on by computer instructions, in analogy with nouns in natural languages. Just as one would not attempt to construct sentences with only nouns or verbs, both data and instructions are necessary components of computer programs. However, programming languages are classiﬁed according to the relative importance of each of these components, and the resulting charac terization of programming languages as “datacentered” (objectoriented) or “instructioncentered” (pro cedural) has major ramiﬁcations toward design, implementation, and maintenance of computer software. Older programming languages (such as FORTRAN and COBOL) reﬂect a preeminent role for instruc tions. Languages that abstract the instruction component of programs permit the programmer to recur sively decompose the overall computational task into logically separate subtasks. This successive decomposition of overall function into component subtasks highlights the role of the individual task as an encapsulated set of programming instructions. These encapsulated individual tasks are termed “pro cedures” (e.g., the SUBROUTINE structure in FORTRAN), and this “instruction ﬁrst” approach to program design and construction is thus termed procedural programming . In procedural programming, the emphasis on decomposition of function obscures the important fact that the data component of the program is inherited from the procedural design, which places the data in a secondary role. A more recent alternative model for programming involves elevating the data component of the program to a more preeminent position. This newer approach is collectively termed object programming, or objectoriented programming. Where procedural models abstract programming function via encap sulation of instructions into subroutines, object programming models bind the procedures to the data on which they operate. The design of the program is initially oriented toward modeling the natural data of the system in terms of its behaviors, and once this data component has been speciﬁed, the procedures that act upon the data are deﬁned in terms of their functional operations on these preeminent data structures. Object programming models have been very successful in the important task of the creation of reusable code, and are thus valuable for settings (like implementation of a graphical user interface, where consistency among applications is desired) where there is a natural need for considerable code reuse. The choice of language in computer programming is difﬁcult because proponents of various languages and programming models favoring particular approaches often castigate those who advocate otherwise. Fortunately, there are few other branches of engineering that are so heavily politicized. It is important to look beyond the dogmatic issues surrounding language choice toward the important pragmatic goals of creating readable, veriﬁable, extensible, and reusable code. Finally, it is important to recognize that the classiﬁcation of programming languages into procedural and objectprogramming models is not precise. Regardless of whether data or instructions are given relative precedence, computer programs need both, and successful software design demands that the requirements of each component be investigated carefully. Although objectprogramming models relegate procedures to a secondary role to data structures, much of the ﬁnal effort in writing an objectoriented program still involves design, creation, and testing of the procedures (which are termed “class methods” in objectprogramming models) that act upon the data. Similarly, it is possible to gain many object programming advantages while using strictly procedural languages. In fact, some of the most successful languages utilized in current practice (e.g., the C++ programming language) are completely suitable for use as either procedural or objectoriented programming languages.
Procedural Programming Models
The most commonly used procedural programming languages in current use include Ada, C, FORTRAN, Basic, and Pascal. These procedural programming languages are characterized by a natural modular
© 1999 by CRC Press LLC
15 8
Section 15
structure based on programming function, which results in similar design methods being used for each. Since procedural languages are primarily oriented toward encapsulating programming function, each language has a rich set of control structures (e.g., looping, logical testing, etc.) that permits an appropriate level of control over the execution of the various procedural functions. Beyond this natural similarity, most procedural languages exhibit vast differences based on the expressiveness of the language, the range and extensibility of native data types, the facilities available for implementing modularity in the component procedures, and the runtime execution characteristics of the language.
Design Principles for Procedural Programming Models. The fundamental design principle for proce dural programming is based on the concept of “divide and conquer,” and is termed functional decom position or topdown design . The overall effort of the program is successively decomposed into smaller logically separate subtasks, until each remaining subtask is sufﬁciently limited in scope so as to admit implementation within a procedure of appropriately small size. The overall process is diagrammed in Figure 15.2.4.
FIGURE 15.2.4 Sample functional decomposition.
The basic motivation behind functional decomposition is that the human mind is incapable of under standing an entire large computer program unless it is effectively abstracted into smaller “black boxes,” each of which is simple enough so that its complete implementation can be grasped by the programmer. The issue of exactly how large an individual procedure can be before it becomes too large to understand is not an easy question to answer, but rules of thumb range from around ten up to a few hundred lines of executable statements. While it is generally accepted that extremely long procedures (more than a few hundred lines) have been empirically shown to be difﬁcult to comprehend, there is still a lively debate in the software engineering community about how short procedures can become before an increased error rate (e.g., average number of errors per line of code) becomes apparent. Although procedural programming languages possess the common characteristic of encapsulating programming function into separate granular modules, there are few similarities beyond this basic architectural resemblance. The various procedural languages often exhibit substantial differences in expressiveness, in the inhibition of practices associated with common language errors, and in the run time characteristics of the resulting computer program. Expressiveness represents the range of features permitted by the language that can be used by the programmer to implement the particular programming design. There is considerable evidence from the study of linguistics to support the notion that the more expressive the language, the wider the range of thoughts that can be entertained using this language. This important postulate is termed the “SapirWhorf hypothesis.” While the SapirWhorf hypothesis is considered controversial in the setting of natural human languages, in the vastly simpler setting of programming languages, this phenomenon has been commonly
© 1999 by CRC Press LLC
ComputerAided Engineering
15 9
observed in practice, where use of more expressive highlevel languages has been correlated with overall programmer productivity. Expressiveness in a computer language generally consists of permitting more natural control structures for guiding the execution of the program, as well as permitting a wide range of data representations appropriate for natural abstraction of data.
Sample Procedural Programming Languages. Some procedural languages (including FORTRAN and Basic) permit only a limited set of control structures for looping, branching, and logical testing. For instance, before the FORTRAN77 standard was promulgated, FORTRAN had no way of expressing the standard logical “ifthenelse” statement. The FORTRAN77 speciﬁcation still does not permit standard nondeterministic looping structures, such as “do while” and “repeat until”. The standard Basic language suffers from similar limitations and is further impeded by the fact that most implementations of Basic are interpreted (each line of code is sequentially translated and then executed) instead of compiled (where the entire program’s code is translated ﬁrst and executed subsequently). Interpreted languages such as Basic are often incredibly inefﬁcient, especially on problems that involve substantial looping, as the overhead of retranslating each line of code cannot be amortized in the same manner available to compiled languages. Finally, because Basic is limited in its expressiveness, many imple mentations of Basic extend the language to permit a greater range of statements or data types. While language extension facilitates programmer expression, it generally compromises portability, as different nonstandard dialects of the extended language generally develop on different computer platforms. The extreme case is illustrated by Microsoft’s Visual Basic language, which is completely tied to Microsoft applications and operating systems software (and thus inherently nonportable), but so useful in its extensions to the original Basic language that it has become the de facto scripting language for Microsoft applications and operating systems. Ada and Pascal are very expressive languages, permitting a rich set of control structures and a simple extension of the set of permitted data types. In addition, Ada and some Pascal dialects force the programmer to implement certain forms of data modularity that are speciﬁcally designed to aid in the implementation of procedural programs. In a similar vein, standard Pascal is so strongly typed that it forces the programmer to avoid certain common practices (such as misrepresenting the type of a data structure passed to a procedure, which is a widespread and useful practice in FORTRAN) that are associated with common errors in program implementation. In theory, Pascal’s strict approach to repre senting data structures and its rich set of control structures ought to make it an attractive language for engineering programming. In practice, its lack of features for arithmetic calculation and its strict rules on data representation make it fairly difﬁcult to use for numeric computation. Ada is a more recent language that is based on Pascal, but remedies many of Pascal’s deﬁciencies. Ada is a popular language in mechanical engineering applications, as it is mandated for use on many Department of Defense programming projects. C and FORTRAN are among the most common procedural languages used in largescale mechanical engineering software applications. Both are weakly typed compiled languages with a rich set of available mathematical operations. C permits a considerable range of expressive control structures and extensible data structures. In addition, C is extremely portable and generally compiles and runs quickly, as the language’s features are closely tuned to the instruction sets of modern microprocessors used in current generations of computers. The original C language speciﬁcation was replaced in 1988 by a new ANSI standard, and this current language speciﬁcation adds some features (such as type checking on arguments passed to procedures, a facility that aids greatly in preventing common programming errors) that resemble those found in Pascal, but do not seem to compromise the overall utility of the original C language standard. FORTRAN’s current implementation (FORTRAN90) adds userdeﬁned extensible data structures and a more expressive instruction set to the FORTRAN77 standard, but the FORTRAN90 standard has so far been slow to gain acceptance in the programming community. FORTRAN77 compilers are still common, and the problems associated with this version of the language (e.g., minimal resources for abstracting data, limited control structures for expressing program ﬂow) still compromise the archi
© 1999 by CRC Press LLC
15 10
Section 15
tecture of FORTRAN programs. However, FORTRAN retains a rich set of intrinsic numeric operations, so it is still a good choice for its original goal of “Formula Translation” (where the language derives its name). In addition, FORTRAN programs often execute very rapidly relative to other procedural lan guages, so for programs that emphasize rapid mathematical performance, FORTRAN is still a good language choice. Finally, many FORTRANcallable libraries of mathematical operations commonly encountered in engineering applications are available, and this ability to leverage existing procedural libraries makes FORTRAN an excellent choice for many mechanical engineering applications.
Advantages and Disadvantages of Procedural Programming. Procedural programming has inherent advantages and disadvantages. One of the most important advantages of some procedural languages (notably FORTRAN) is the existence of many complete libraries of procedures for solving complex tasks. For example, there are many standard libraries for linear algebra (e.g., LINPACK, EISPACK, LAPACK) or general scientiﬁc numerical computation (e.g., IMSL) available in FORTRANcallable form. Reuse of modules from these existing libraries permits programmers to reduce development costs substantially for a wide variety of engineering applications. Under most current portable operating systems, multiplelanguage integration is relatively straightforward, so highquality FORTRANcallable libraries can be called from C programs, and viceversa. The development of standard procedural libraries is largely responsible for the present proliferation of useful computer applications in mechanical engi neering. Another important advantage of procedural languages is that many important computational tasks (such as translating mathematical models into analogous computer codes) are naturally converted from the underlying mathematical algorithm (which is generally a sequence of instructions, and hence ame nable to encapsulation within a procedure) into an associated modular procedure. As long as the data used within a program do not become unduly complex, procedural languages permit easy implementation of many of the standard methods used in engineering analysis and design. Perhaps the biggest disadvantage of procedural models is that they are harder to reuse than competitive objectprogramming models. These obstacles to code reuse arise from the fact that data are modeled in procedural programming as an afterthought to the simulation of instructions. In order to reuse procedures between two different programs, the programmer must force the representation of data to be identical across the different computer applications. In procedural programming, the goal of code reuse requires standardization of data structures across different computer programs, regardless of whether or not such standardization is natural (or even desired) by those disparate computer programs. Object programming models are an attractive alternative to procedural programming schemes in large part because these newer programming methods successfully avoid such unwarranted data standardization.
Object Programming Models
Objectprogramming models place modeling of data structures in a more preeminent position, and then bind to the data structures the procedures that manipulate the data. This relegation of procedures (which are termed “methods” in object programming) to a more secondary role facilitates a degree of code reuse substantially better than is feasible with conventional procedural programming languages. Object programming languages employ aggregate data types (consisting of various data ﬁelds, as well as the associated methods that manipulate the data) that are termed classes , and these classes serve as templates for creation of objects that represent speciﬁc instances of the class type. Objects thus form the repre sentative granularity found in objectoriented programming models, and interactions among objects during program execution are represented by messages that are passed among the various objects present. Each message sent by one object to another tells the receiving object what to do, and the details of exactly how the receiving object accomplishes the associated task are generally private to the class. This latter issue of privacy regarding implementation details of object methods leads to an independence among objects that is one of the main reasons that objectprogramming schemes facilitate the desired goal of code reuse.
© 1999 by CRC Press LLC
ComputerAided Engineering
15 11
One of the most important limitations of procedural languages is abstraction. Highlevel languages such as FORTRAN or C permit considerable abstraction of instructions, especially when compared to the machine and assembly languages they are designed to supplant. Unfortunately, these languages do not support similar levels of abstraction of data. For example, although FORTRAN77 supports several different numeric types (e.g., INTEGER, REAL, DOUBLE PRECISION), the only derived types avail able for extending these simple numeric representations are given by vectors and multidimensional arrays. Unless the data of a problem are easily represented in one of these tabular forms, they cannot be easily abstracted in FORTRAN. To some extent, experienced programmers can create new user deﬁned data types in C using structures and typedefs, but effectively abstracting these derived data types requires considerable selfdiscipline on the part of the programmer. Objectoriented programming languages avoid these pitfalls of procedural languages by using classes as templates for abstraction of both instructions and data. By binding the instructions and the data for classes together, the programmer can abstract both components of a programming model simultaneously, and this increased level of abstraction results in a radically new programming model. For instance, a natural class for ﬁniteelement modeling would be the class of ﬁniteelement mesh objects. A mesh object (which could easily be composed internally of node and element objects) makes it possible for the object programmer to hide all the details of mesh representation from the rest of the program. A procedural programming model would require standardization of the mesh to consist of (for example):
•
A list of nodes, each associated with individual nodal coordinates given in 1D, 2D, or 3D (depending on the geometry of the model used)
• A list of elements, each with a given number of associated nodes • A list of element characteristics, such as material properties or applied loads
In this representation, each procedure that manipulates any of the mesh data must know all of the details of how these data have been standardized. In particular, each routine must know whether a 1D, 2D, or 3D ﬁniteelement analysis is being performed, and pertinent details of the analysis (e.g., is the problem being modeled thermal conduction or mechanical deformation?) are also spread throughout the code by the standardization of data into predeﬁned formats. The sum of these constraints is to require the programmer to recode substantial components of a procedural program every time a major modiﬁ cation is desired. In the setting of objects, the ﬁniteelement mesh object would store its particular geometric imple mentation internally, so that the rest of the program would be insulated from the effects of changes in that representation. Rather than calling a procedure to generate a mesh by passing predeﬁned lists of nodes, elements, and element characteristics, an objectoriented approach to mesh generation would employ sending a message such as “discretize yourself” to the mesh object. This object would then create its internal representation of the mesh (perhaps using default values created by earlier messages) and store this information privately. Alternatively, the objectoriented program might later send a “solve yourself” message to the mesh object and then a “report your results in tabular form” message for generating output. In each case, the rest of the program has no need to know the particular details of how the mesh object is generating, storing, or calculating results. Only the internal procedures local to the class (i.e., the class methods) generally need to know this private data, which are used locally to implement the functions that act on the class. This hiding of internal function within an object is termed encapsulation , and object programming models permit simultaneous encapsulation of both data and instructions via appropriate abstraction. In this setting, encapsulation permits the programmer to concentrate on creating data and procedures naturally, instead of forcing either component into predeﬁned formats such as ﬂoatingpoint arrays (for data) or predeﬁned subroutine libraries (for instructions). Data and instruction abstraction of this form are thus useful additions to the similar (but less ﬂexible) features available in procedural languages. If these new features constituted the only improvements available from objectprogramming models, then
© 1999 by CRC Press LLC
15 12
Section 15
they would offer only slight advantages over traditional procedural programming. There are many other advantages present in objectprogramming models. The most important advantages of object programming occur because of the existence of class hierarchies . These hierarchies permit new objects to be created from others by concentrating only on the differences between the object’s behaviors. For instance, a ﬁniteelement mesh for a rod lying in three dimensions can be derived from a onedimensional mesh by adding two additional coordinates at each node. An object programmer could take an existing onedimensional mesh class and derive a three dimensional version using only very simple steps:
• Adding internal (private) representation for the additional coordinate data
• Overriding the existing discretization method to generate the remaining coordinates when the “discretize yourself” message is sent
• Overriding some lowlevel calculations in class methods pertinent to performing local element calculations using the new coordinate representation
Note that all of these steps are private to the mesh object, so that no other part of the program needs to be changed to implement this major modiﬁcation to the problem statement. In practice, the added details are implemented via the creation of a derived class, where the additional coordinates and the modiﬁed methods are created. When messages appropriate to the new class are sent, the derived object created from the new class will handle only the modiﬁed data and instructions, and the parent object (the original mesh object) will take care of the rest of the processing. This characteristic of object programming models is termed inheritance , as the individual derived (“child”) objects inherit their behavior from the parent class. When the changes required by the modiﬁcation to the program’s speciﬁcations are small, the resulting programming effort is generally simple. When the changes are large (such as generalizing a onedimensional problem to a fully threedimensional one), it is still often feasible to make only minor modiﬁcations to the program to implement the new features. One of the most important rationales for using objectprogramming methods arises from the desire to provide a consistent userinterface across diverse programs. Existing standardized graphical interface models (such as the Motif interface available on OSF/UNIX, or the Microsoft Windows interface used on Windows and Windows NT) place a premium on a consistent “look and feel” across different applications. Since managing the userinterface commonly constitutes much of the programming effort required to implement interactive engineering applications, it is advantageous to consolidate all of the code required to implement the standard graphical userinterface into a class library and allow the programmer to derive new objects pertinent to the application at hand. One such class library is the Microsoft Foundation Classes, which implement the Windows interface via a class hierarchy requiring around a hundred thousand lines of existing C++ source code. Program mers using class libraries such as these can often generate fullfeatured graphics applications by writing only a few hundred or a few thousand lines of code (notably, for reading and storing data in ﬁles, for drawing content into windows, and for relevant calculations). In fact, it is relatively easy to graft graphical user interfaces onto existing procedural programs (such as old FORTRAN applications) by wrapping a C++ userinterface layer from an existing class library around the existing procedural code, and by recycling relevant procedures as class methods in the new objectoriented setting. This “interface wrapper” approach to recycling old procedural programs is one of many standard techniques used in reengineering of existing legacy applications (Barton and Nackman, 1994). One other important characteristic of many objectprogramming languages is polymorphism . Poly morphism (Latin for “many forms”) refers to the ability of a single message to spawn different behaviors in various objects. The precise meaning of polymorphism depends upon the runtime characteristics of the particular objectprogramming language used, but it is an important practical feature in any object programming language.
ObjectOriented Design Principles. Because objectoriented programming is a relatively new discipline of software engineering (when compared to procedural programming), one cannot yet identify the best
© 1999 by CRC Press LLC
ComputerAided Engineering
15 13
design schemes among the various competing objectoriented design principles. For this reason (and to avoid prejudging the future), this section treats the subject of objectoriented design in less detail than procedural design methods. The fundamental tenet of objectoriented program design is that the programming objects should be chosen to model any realworld objects present in the system to be analyzed and simulated. For example, in a thermal analysis of a microprocessor, one might identify such natural physical objects as “heat sink,” “thermocouple,” and “fan.” In general, the nature of the physical objects in a mechanical system is stable over long periods of time, so they make natural candidates for programming objects, as their speciﬁcations are least likely to vary, and thus they will require minimal modiﬁcations to the basic program design. The next step in performing an objectoriented design is to model the behaviors of the various objects identiﬁed within the system. For example, a fan object can “turn on” and “turn off”, or might vary in intensity over a normalized range of values (e.g., 0.0 = off, 1.0 = high speed), and this behavior will form the basis for the messaging protocols used to inform objects which behaviors they should exhibit. At the same time, any relevant data appropriate to the object (in this case, fan speed, power consumption, requisite operating voltage) should be identiﬁed and catalogued. Here, these individual items of data will represent the private data of the fan class, and the behaviors of this class will be used to design class methods. The ﬁnal step in specifying an objectoriented design is to examine the various objects for interrela tionships that can be exploited in a class hierarchy. In this setting, “heat sink” and “fan” could be considered to be derived from a larger class of “cooling devices” (although in this trivial example, this aggregation is probably unnecessary). Careful identiﬁcation of hierarchical relationships among the candidate objects will generally result in an arrangement of classes that will permit considerable code reuse through inheritance, and this is one of the primary goals of objectprogramming design practice. In practice, there is no “ﬁnal” step in designing objectoriented programs, as the design process is necessarily more complex and iterative than procedural programming models. In addition, the object oriented designer must take more care than given here in differentiating the role of classes (which are the static templates for construction of objects) from objects themselves, which are the dynamic real ization of speciﬁc members of a class created when an objectoriented program executes. Objects are thus speciﬁc instances of generic classes, and the process of creating objects at run time (including setting all appropriate default values etc.) is termed instantiation .
Sample ObjectOriented Languages. There are not as many successful objectoriented languages as there are procedural languages, because some languages (such as Ada and FORTRAN90) that possess limited objectoriented features are more properly classiﬁed as procedural languages. However, ADA 95 does include excellent facilities for objectoriented programming. C++ is the most commonly used objectoriented language and was primarily developed at Bell Labs in the same pragmatic vein as its close procedural relative, C. In theory, the C++ language includes both procedural and objectprogramming models, and thus C++ can be used for either type of programming. In practice, the procedural features on C++ are nearly indistinguishable from those of ANSI C, and hence the phrase “programming in C++” is generally taken to mean “objectprogramming in C++”. C++ is well known as an objectprogramming language that is not particularly elegant, but that is very popular because of its intimate relation with the C procedural programming language (C++ is a superset of ANSI C) and because of its extensive features. The design goal of maintaining backcompatibility with ANSI C has led to shortcomings in the C++ language implementation, but none of these shortcomings has seriously compromised its popularity. C++ is an efﬁcient compiled language, providing the features of objectprogramming models without undue loss of performance relative to straight procedural C, and C++ is relatively easy to learn, especially for knowledgeable C programmers. It supports extensive inheritance, polymorphism, and a variety of pragmatic features (such as templates and structured excep tion handling) that are very useful in the implementation of productionquality code.
© 1999 by CRC Press LLC
15 14
Section 15
An important recent development in objectoriented design is the Java programming language: the popularity of this new language is closely tied to the explosion of interest in the Internet. Java is widely used to provide interactive content on the WorldWideWeb, and it has a syntax very similar to C++, a pervasive objectorientation, and provides portable elements for constructing graphical user interfaces. Java programs can be deployed using interpreted forms over the web (utilizing a “Java Virtual Machine” on the client platform), or by a more conventional (though less portable) compilation on the target computer. SmallTalk is one of the oldest and most successful objectprogramming languages available, and was designed at the Xerox Corporation’s Palo Alto Research Center (also responsible for the design of modern graphical user interfaces). SmallTalk supports both inheritance (in a more limited form than C++) and polymorphism, and is noted as a highly productive programming environment that is particularly ame nable to rapid application development and construction of prototypes. SmallTalk is not a compiled language, and while this characteristic aids during the program implementation process, it generally leads to computer programs that are substantially less efﬁcient than those implemented in C++. SmallTalk is generally used in highly portable programming environments that possess a rich library of classes, so that it is very easy to use SmallTalk to assemble portable graphical interactive programs from existing object components. Eiffel is a newer objectoriented language with similar structure to objectoriented variants of the Pascal procedural programming language. Eiffel is similar in overall function to C++ but is considerably more elegant, as Eiffel does not carry the baggage of backward compatibility with ANSI C. Eiffel has many important features that are commonly implemented in commercialquality C++ class libraries, including runtime checking for corruption of objects, which is a tremendous aid during the program debugging process. Even with its elegant features, however, Eiffel has not gained the level of acceptance of C++. There are other objectoriented programming languages that are worth mentioning. The procedural language Ada provides some support for objects, but neither inheritance or polymorphism. FORTRAN 90 is similarly limited in its support for objectprogramming practices. Object Pascal is a variant of Pascal that grafts SmallTalklike object orientation onto the Pascal procedural language, and several successful implementations of Object Pascal exist (in particular, the Apple Macintosh microcomputer used Object Pascal calling conventions, and this language was used for most commercial Macintosh application development for many years). For now, none of these languages provides sufﬁcient support for objectoriented programming features (or a largeenough user community) to provide serious com petition for C++, SmallTalk, Eiffel, or Java.
Data Base Systems
In procedural programming practice, modeling data are relegated to an inferior role relative to modeling instructions. Before the advent of objectoriented programming languages, which permit a greater degree of data abstraction, problems deﬁned by large or complex data sets required more ﬂexibility for modeling data than traditional procedural programming techniques allowed. To ﬁll this void, specialized data base management systems were developed, and a separate discipline of computer programming (data base management) arose around the practical issues of “datacentered” programming practice. The study of data base management evolved its own terminology and code of application design, and suffered through many of the same problems (such as language standardization to provide crossplatform portability) that had plagued early efforts in procedural programming. The data base management subdiscipline of software engineering is still fundamentally important, but the widespread adoption of objectoriented languages (which permit ﬂexible modeling of data in a more portable manner than that provided by proprietary data base management systems) has led to many of the concepts of data base management becoming incorporated into the framework of objectoriented programming practice.
© 1999 by CRC Press LLC
ComputerAided Engineering
15 15
Technical Overview of Data base Management
Many important engineering software applications are naturally represented as data base applications. Data base applications are generally developed within specialized custom programming environments speciﬁc to a particular commercial data base manager, and are usually programmed in a proprietary (and often nonportable) data base language. Regardless of these issues, data base programming is a particular form of computer programming, and so the relevant topics of software engineering, including procedural and object models, portability, reliability, etc., apply equally well to data base programming. Because many of these principles have already been presented in considerable detail, the following sections on design and programming issues for data base systems are kept relatively concise. Data base applications are very similar to conventional programming applications, but one of the most important differences is in the terminology used. Data base applications have developed a nomenclature speciﬁcally deﬁned to dealing with structured and unstructured data, and this terminology must be addressed. Some of the most appropriate terms are enumerated below.
• Table: a logical organized collection of related data
• Record: a collection of data that is associated with a single item (records are generally represented as rows in tabular data base applications)
• Field: an individual item of data in a record (ﬁelds are generally represented as columns in a tabular data base)
• Schema: the structure of the data base (schema generally is taken to mean the structure and organization of the tables in a tabular data base)
• Query: a structured question regarding the data stored in the data base (queries are the mechanism for retrieving desired data from the data base system)
There are many other relevant terms for data base management, but these are sufﬁcient for this brief introduction. One important highlevel deﬁnition used in data base management is Structured Query Language , or SQL. SQL is a standard language for creating and modifying data bases, retrieving information from data bases, and adding information to data bases. In theory, SQL provides an ANSI standard relational data base language speciﬁcation that permits a degree of portability for data base applications. In practice, standard SQL is sufﬁciently limited in function so that it is commonly extended via proprietary addition of language features (this situation is similar to that of the Basic procedural language, which suffers from many incompatible dialects). The practical effect of these nonstandard extensions is to compromise the portability of some SQLbased data base systems, and additional standardization schemes are presently under development in the data base management industry. One such scheme is Microsoft’s Open data base Connectivity (ODBC) programming interface, which provides portable data base services for relational and nonrelational data base applications.
Classiﬁcation of Data Base Systems
There are many different types of data base systems in common use. One of the most important initial steps in designing and implementing a data base application is to identify the relevant characteristics of the data in order to choose the most appropriate type of data base for development. Depending upon the structure of the data to be modeled, the data base application developer can select the simplest scheme that provides sufﬁcient capabilities for the problem. Three sample data base structures are presented below: ﬂatﬁle data bases, relational data bases, and objectoriented data bases.
FlatFile Data Bases. Flatﬁle data bases represent the simplest conceptual model for data base struc ture. A ﬂat data base can be idealized as a table with a twodimensional matrix or grid structure. The individual data base records are represented by the rows of the matrix, and each record’s component ﬁelds are represented by the columns of the matrix structure, as shown in Figure 15.2.5. Flatﬁle data bases are thus conﬁned to applications where all records are structurally identical (i.e., have the same conﬁguration of ﬁelds) and where the underlying matrix structure naturally represents the data component of the application.
© 1999 by CRC Press LLC
15 16
Section 15
Record 1:
Material 1
Record 2:
Material 2
Record 3:
Material 3
Field 1: 
Field 2: 
Field 3: 
Field 4: 

Name 
Yield Strength 
Young’s Modulus 
Shear Modulus 

Aluminum 
MPa 
70 GPa 
25 

Magnesium 
MPa 
45 GPa 
18 

Steel 
MPa 
200 GPa 
85 
FIGURE 15.2.5
Flat data base example.
The simplicity of a ﬂatﬁle data base is simultaneously its greatest advantage and worst disadvantage. The main advantage of using a ﬂatﬁle data base structure is that querying the data base is extremely simple and fast, and the resulting data base is easy to design, implement, and port between particular data base applications. In practice, spreadsheet applications are often used for constructing ﬂatﬁle data bases, because these packages already implement the requisite tabular structure and include a rich variety of control structures for manipulating the data. The biggest disadvantage of ﬂatﬁle data bases is that the extreme simplicity of the ﬂat structure simply does not reﬂect many important characteristics of representative data base applications. For programs requiring ﬂexibility in data base schema, or complex relationships among individual data ﬁelds, ﬂatﬁle data bases are simply a poor choice, and more complex data base models should be used.
Relational Data Bases. In practice, data base applications often require modeling relationships among various ﬁelds that may be contained in separate data ﬁles. Applications with these “relational” features are term relational data bases. Relational data base technology is a rapidly evolving ﬁeld, and this family of data bases is very common in practical data base applications. Relations provide a way to generalize ﬂatﬁle data base tables to include additional features, such as variation in the numbers of ﬁelds among different records. A schematic of a simple relational data base schema is shown in Figure 15.2.6. Here a data base of material properties is represented by related tables. Note that because of the disparity in number of material constants (i.e., differing numbers of ﬁelds for each material record), a ﬂatﬁle data base would not be suitable for this data base storage scheme. The material properties tables (containing the lists of material properties) are related to their parent table, which contains overall identiﬁcation information. These parentchild relationships give relational data bases considerable ﬂexibility in modeling diverse aggregates of data, but also add complexity to the task of storing and retrieving data in the data base. In a ﬂatﬁle data base system, a simple lookup (similar to indexing into a twodimensional array) is required to ﬁnd a particular ﬁeld. In a complex relational data base, which may exhibit many nested layers of parentchild relations, the task of querying may become very complex and potentially timeconsuming. Because of this inherent complexity in storing and retrieving data, the topics of efﬁcient data base organization and of query optimization are essential for careful study before any largescale relational data base application is undertaken.
ObjectOriented Data Bases. Many of the data base schemes found in relational and ﬂatﬁle data base systems arose because of the inability to model data effectively in older procedural programming languages like FORTRAN. Commercial relational data base managers combined powerful datamodeling capabilities with new procedural languages (such as SQL or XBase) speciﬁcally designed to manipulate data base constructs. Recently, the current proliferation of objectoriented programming languages, with their innate ability to abstract data as effectively as possible with dedicated data base management systems, has led to the development of objectoriented data base systems. These objectoriented data base packages provide extremely powerful features that may ultimately make traditional SQLbased relational data base applications obsolete.
© 1999 by CRC Press LLC
ComputerAided Engineering
15 17
FIGURE 15.2.6 Example relational data base structure.
One interesting example of objectoriented data base technology is the integration of data base technology into a C++ framework. The Microsoft Foundation Class library for C++ provides numerous features formerly requiring custom data base programming that are implemented as C++ class library members. For example, there are extensible data base classes that provide direct support for common data base functions, and there are ODBC (Open Data Base Connectivity, the extension of SQL to generic data base environments) classes allowing the C++ program to access existing relational data bases developed with specialized data base management systems. Given the extensibility of C++ class libraries, this objectoriented approach makes it feasible to gain all of the advantages of proprietary relational data base applications, while preserving the numerous features of working in a standard portable programming language.
Operating System Characteristics
Computer programs depend on lowlevel resources for execution support, including ﬁle services for input/output, graphical display routines, scheduling, and memory management. The software layers that provide these lowlevel services are collectively termed the computer’s operating system . Operating systems thus insulate individual programs from the details of the hardware platform where they are executed, and choosing the right operating system can be a critical decision in engineering practice. Engineering computation is generally identiﬁed by three fundamental characteristics:
• Large demand for memory, where extremely large data sets (generally on the order of megabytes or gigabytes) are used, and where all components of these demanded memory resources must be accessible simultaneously (This demand for memory can be contrasted with standard online transactionprocessing schemes used in ﬁnance and commerce, where there is a similar charac teristic of large data sets, but these large ﬁnancial data models are seldom required to have all components available in memory at the same time.)
• Dependence on ﬂoatingpoint computation, where there are highprecision ﬂoatingpoint repre sentations of numbers (i.e., numbers stored in the binary equivalent of “scientiﬁc notation”, where storage is divided among sign, mantissa, and exponent, requiring more extensive storage than that required for characters or integer data types)
© 1999 by CRC Press LLC
1518
Section 15
• Extensive use of graphics in input and display, as graphics is generally characterized as an engineer’s “second language,” because only the human visual sense has sufﬁcient bandwidth to process the vast amounts of data generally present in engineering computation
While many of these characteristics may be found in other computational settings, the simultaneous presence of all three is a hallmark of computation in science and engineering. Identifying and selecting an operating system that provides appropriate support for these characteristics is thus a fundamentally important problem in the effective development and use of engineering software.
Technical Overview of Operating Systems
A simple and effective way to gain an overview of operating systems theory is to review the classiﬁcation scheme used to identify various operating systems in terms of the services that they provide. The most common characteristics used for these classiﬁcations are enumerated below.
Multitasking. Humans are capable of performing multiple tasks simultaneously, and this characteristic is desirable in a computer operating system as well. Although an individual computer CPU can only process the instructions of one application at a time, it is possible with highperformance CPUs to manage the execution of separate programs concurrently by allocating processing time to each application in sequence. This sequential processing of different applications makes the computer appear to be executing more than one software application at a time. When an operating system is capable of managing the performance of concurrent tasks, it is termed a multitasking operating system. Many early operating systems (such as MS/DOS) could only execute a single task at a time and were hence termed single tasking systems. While it is possible to load and store several programs in memory at one time and let the user switch between these programs (a technique sometimes termed context switching that is commonly used in MS/DOS applications), the lack of any coherent strategy for allocating resources among the competing programs limits the practical utility of this simple tasking scheme. A simple generalization of context switching is known as cooperative multitasking, and this simple tasking scheme works remarkably well in some settings (in fact, this method is the basis for the popular Microsoft Windows 3.x and Apple Macintosh 7.x operating systems). In a cooperative multitasking setting, the allocation of computer resources is distributed among the competing programs: the individual programs are responsible for giving up resources when they are no longer needed. A comparison to human experience is a meeting attended by wellbehaved individuals who readily yield the ﬂoor whenever another speaker desires to contribute. Just as this scheme for managing human interaction depends on the number of individuals present (obviously, the more people in the meeting, the more difﬁcult the task of distributed management of interaction) as well as on the level of courtesy demonstrated by the individual speakers (e.g., there is no simple means for making a discourteous speaker yield the ﬂoor when someone else wants to speak), the successful use of cooperative multitasking schemes is completely dependent on the number and behavior of the individual software applications that are being managed. Illbehaved programs (such as a communications application that allocates communications hardware when executed, but refuses to release it when not needed) compromise the effectiveness of cooperative multitasking schemes and may render this simple resourcesharing model completely unusable in many cases. The obvious solution to managing a meeting of humans is to appoint a chair who is responsible for allocating the prioritized resources of the meeting: the chair decides who will speak and for how long, depending upon scheduling information such as the meeting’s agenda. The computer equivalent of this approach is termed preemptive multitasking and is a very successful model for managing the allocation of computer resources. Operating systems that use a preemptive multitasking model make use of a scheduler subsystem that allocates computer resources (such as CPU time) according to a priority system. Lowpriority applications (such as a clock accessory, which can update its display every minute or so without causing serious problems) are generally given appropriately rare access to system resources, while highpriority tasks (such as realtime data acquisition applications used in manufacturing, which cannot tolerate long intervals without access to the operating system’s services) are given higher priority.
© 1999 by CRC Press LLC
ComputerAided Engineering
1519
Of course, the scheduler itself is a software system and generally runs at the highest level of priority available. Preemptive multitasking operating systems are natural candidates for engineering software, as the intense memory and hardware resources associated with engineering computation require appropriately highpowered operating system support. Virtually all large engineering computers of the present era (e.g., workstations, mainframes, and supercomputers) run operating systems that provide preemptive multitasking, and many microcomputers are now available with similar operating system support.
Multithreading. In the setting of multitasking, the term “task” has some inherent imprecision, and this ambiguity leads to various models for allocation of computer resources among and within applications. In the simplest setting, a task can be identiﬁed as an individual software application, so that a multitasking operating system allocates resources sequentially among individual applications. In a more general context, however, individual programs may possess internal granularity in the form of subprocesses that may execute in parallel within an application. These subprocesses are termed “threads,” and operating systems that support multiple threads of internal program execution are termed multithreaded operating systems. Examples of multiple threads of execution include programs that support internally concurrent oper ations such as printing documents while other work is in progress (where a separate thread is spawned to handle the printing process), displaying graphical results while performing other calculations (where a separate thread can be used to paint the screen as data are read or calculated), or generating reports from within a data base application while other queries are performed. In general, multithreading of individual subtasks within an application will be advantageous whenever spawned threads represent components of the application that are complicated enough so that waiting for them to ﬁnish (which would be required in a singlethreaded environment) will adversely affect the response of the program.
Multiprocessing. One of the most important advantages of separating a program into multiple threads is that this decomposition of programming function permits individual threads to be shared among different processors. Computers with multiple CPUs have been common platforms for performing high end engineering computation for over a decade (e.g., multiprocessor supercomputer architectures, such as the Cray X/MP and Cray Y/MP models introduced in the 1980s), but the availability of multiple processing units within a single computer has ﬁnally gravitated to the realm of lowend microcomputers. The ability of an operating system to support concurrent execution of different program threads on different processors is termed multiprocessing. Multiprocessing occurs in two fundamental ﬂavors:
• Symmetric multiprocessing (SMP), where each individual CPU is capable of executing any process, including threads originating within applications or within operating system services
• Asymmetric multiprocessing (ASMP), where different processors are relegated to different tasks, such as running applications or running operating systems services
Asymmetrical processing is commonly implemented using a dualCPU architecture involving a mas ter/slave relation between the processing units. The master CPU performs the application and some system services, while the slave CPU is relegated to pure system tasks (such as printing, waiting for slow input/output devices, etc.). Asymmetric multiprocessing architectures provide some speedup of individual programs, but this increased performance is often limited to reducing the wait time required for some system services. Symmetric multiprocessing can produce substantial gains in program execution speed, as long as individual threads do not contend for resources. The ability of a program (or an operating system) to take advantage of multiple CPU resources is termed scalability, and scalable operating systems are well positioned to take advantage of current improvements in available multipro cessing hardware platforms.
Virtual Memory. Providing the extensive memory resources required for most engineering software can be an expensive undertaking. Dynamic RandomAccess Memory (DRAM) is too expensive to maintain an appropriate supply for every program used in a multitasking environment. In practice, much of the
© 1999 by CRC Press LLC
1520
Section 15
memory demand in a multitasking setting can be satisﬁed by caching some of the blocks of data ostensibly
stored in main memory to a fast disk storage subsystem. These blocks of data can be reloaded to main memory only when they are absolutely required, and this practice of paging memory to and from the disk is termed virtual memory management. In most common implementations of virtual memory, the paging scheme provides a level of independence of memory addressing between processes that is carefully implemented so that one process cannot corrupt the memory of another. Such schemes that implement memory protection to prevent interapplication memory corruption are termed protected virtual memory management.
Depending on demand for physical memory, virtual memory schemes may be a great help or a hindrance. While there are sophisticated paging algorithms available that are designed to prevent writing needed to memory to disk, in practice, if there are enough different applications competing for memory, the relative disparity in speed of memory vs. disk subsystems may lead to very sluggish performance for applications whose memory resources have been written to the disk subsystem. In addition, multi processing architectures place further constraints on virtual memory performance in order to avoid corruption of memory by different threads running on different CPUs. Modern virtual memory manage ment is an active area of research in computer science, but one empirical rule is still true: perhaps the best way to improve the performance of any virtual memory operating system is to add physical (“real”) memory!
Networking and Security. One of the most fundamental shifts in computing over the last decade has been the transition from disconnected individual computers to a distributed computing model character ized by networked workstations that support various remote processing models. Most modern operating systems support standard networking protocols that allow easy integration of different computers into local and widearea networks, and also permit sharing of resources among computers. Traditional networking functions (such as sharing ﬁles between different computers on the same network) have been augmented to encompass remote computing services, including sharing applications between networked computers (which represents a generalization of symmetric multiprocessing architectures from a single computer to a disparate network of connected computers). Because of the tremendous pace of changes in the ﬁeld of computer networking, one of the most important features of any network operating system involves adherence to standard networking protocols. Networking standards provide a portable implementation of networking function that effectively abstracts network operations, allowing existing networking applications to survive current and future changes in networking hardware and software. The most common current networking model is one promulgated by the International Standards Organization and termed the Open Systems Interconnect (OSI) reference model. The OSI model uses layers (ranging from lowlevel hardware to highlevel application connec tions) to idealize networking function. Adherence to the OSI model permits operating systems to become insulated from improvements in networking hardware and software, and thus preserves operating system investment in the face of rapid technological improvements in the ﬁeld of computer networking. Once an individual computer is connected to a network, a whole host of security issues arise pertaining to accessibility of data across the network. Secure operating systems must satisfy both internal (local to an individual computer) and global (remote access across a network) constraints to ensure that sensitive data can be protected from users who have no right to access it. Since many mechanical engineering applications involve the use of military secrets, adherence to appropriate security models is an essential component of choosing an operating system for individual and networked computers. There are many aspects to securing computer resources, including some (such as protected virtual memory schemes) that satisfy other relevant computer needs. In the setting of computer security, operating systems are classiﬁed according to criteria developed by the Department of Defense (DOD 5200.28STD, December 1985). These DOD criteria provide for such features as secure logons (i.e., logging into a computer requires a unique user identiﬁer and password), access control structures (which restrict access to computer resources such as ﬁles or volumes), and auditing information (which provides
© 1999 by CRC Press LLC
ComputerAided Engineering
1521
automated record keeping of security resources so as to help prevent and detect unauthorized attempts at gaining access to secure computer resources).
Portability. Some operating systems (for example, MS/DOS, written in Intel 8080 assembly language) are inextricably tied to the characteristics of a particular hardware platform. Given the rapid pace of development in CPU hardware, tying an operating system to a particular family of processors potentially limits the longterm utility of that operating system. Since operating systems are computer software systems, there is no real obstacle to designing and implementing them in accordance with standard practice in software engineering, and in particular, they can be made portable by writing them in high level languages whenever possible. A portable operating system generally abstracts the particular characteristics of the underlying hard ware platform by relegating all knowledge of these characteristics to a carefully deﬁned module respon sible for managing all of the interaction between the lowlevel (hardware) layer of the operating system and the overlying systems services that do not need to know precise details of lowlevel function. The module that abstracts the lowlevel hardware layer is generally termed a hardware abstraction layer (HAL), and the presence of a HAL permits an operating system to be ported to various processors with relative ease. Perhaps the most common portable operating systems are UNIX and Windows NT. Both of these operating systems are commonly used in engineering applications, operate on a wide variety of different CPUs, and are almost entirely written in the procedural C language.
Classiﬁcation of Representative Operating Systems
Several operating systems commonly encountered in engineering practice are classiﬁed below in accor dance with the deﬁnitions presented above. Note that some of these operating systems are presently disappearing from use, some are new systems incorporating the latest advances in operating system design, and some are in the middle of a potentially long life span.
MS/DOS and Windows 3.x. The MS/DOS (Microsoft Disk Operating System) operating system was introduced in the 1980s as a lowlevel controlling system for the IBM PC and compatibles. Its architecture is closely tailored to that of the Intel 8080 microprocessor, which has been both an advantage (leading to widespread use) and disadvantage (relying on the 8080’s arcane memory addressing scheme has prevented MS/DOS from realizing effective virtual memory schemes appropriate for engineering com putation). MS/DOS is a singleprocessor, singletasking, singlethreaded operating system with no native support for virtual memory, networking, or security. Despite these serious shortcomings, MS/DOS has found wide acceptance, primarily because the operating system is so simple that it can be circumvented to provide new and desirable functions. In particular, the simplicity of MS/DOS provides an operating system with little overhead relative to more complex multitasking environments: such lowoverhead operating systems are commonly used in realtime applications in mechanical engineering for such tasks as process control, data acquisition, and manufacturing. In these performancecritical environments, the increased overhead of more complex operating systems is often unwarranted, unnecessary, or counter productive. Microsoft Windows is an excellent example of how MS/DOS can be patched and extended to provide useful features that were not originally provided. Windows 3.0 and 3.1 provided the ﬁrst widely used graphical userinterface for computers using the Intel 80 × 86 processor family, and the Windows subsystem layers, which run on top of MS/DOS, also provided for some limited forms of cooperative multitasking and virtual memory for MS/DOS users. The combination of MS/DOS and Windows 3.1 was an outstanding marketing success. An estimated 40 million computers eventually ran this combination worldwide. Although this operating system had some serious limitations for many engineering applica tions, it is widely used in the mechanical engineering community.
VAX/VMS. Another successful nonportable operating system that has found wide use in engineering is VAX/VMS, developed by Dave Cutler at Digital Equipment Corporation (DEC) for the VAX family of minicomputers. VMS (Virtual Memory System) was one of the ﬁrst commercial 32bit operating systems
© 1999 by CRC Press LLC
1522
Section 15
that provided a modern interactive computing environment with features such as multitasking, multi threading, multiprocessing, protected virtual memory management, builtin highspeed networking, and robust security. VMS is closely tied to the characteristics of the DEC VAX microprocessor, which has limited its use beyond that platform (in fact, DEC has created a software emulator for its current family of 64bit workstations that allows them to run VMS without the actual VAX microprocessor hardware). But the VMS architecture and feature set is widely imitated in many popular newer operating systems, and the ﬂexibility of this operating system was one of the main reasons that DEC VAXs became very popular platforms for midrange engineering computation during the 1980s.
Windows NT. Windows NT is a scalable, portable, multitasking, multithreaded operating system that supports OSI network models, highlevel DOD security, and protected virtual memory. The primary architect of Windows NT is Dave Cutler (the architect of VAX/VMS), and there are many architectural similarities between these two systems. Windows NT is an objectoriented operating system that supports the clientserver operating system topology, and is presently supported on a wide range of high performance microprocessors commonly used in engineering applications. Windows NT provides a Windows 3.1 subsystem that runs existing Windows 3.1 applications within a more robust and crash proof computational environment, but NT also provides other user interfaces, including a console interface for textual applications ported from mainframes and MS/DOS, a UNIXlike graphical user interface (provided by implementing common UNIX window management functions on top of NT), and the Macintoshlike interface similar to that introduced in Windows 95 as a replacement for Windows 3.1 in mid1995.
UNIX. The UNIX operating system was developed during the 1970s at Bell Laboratories to satisfy the need for a ﬂexible and inexpensive operating system that would provide highend system services (e.g., multitasking, virtual memory) on lowcost computers. Since its initial inception, the UNIX operating system has evolved to become one of the most successful operating environments in history. UNIX provides preemptive multitasking, multithreading (threads are termed “lightweight processes” in most implementations of UNIX), multiprocessing, scalability, protected virtual memory management, and builtin networking. Although there are a variety of competing UNIX implementations, substantial standardization of the UNIX operating system has occurred under the auspices of the Open Software Foundation (OSF), a consortium of computer companies that includes IBM, DEC, and HewlettPackard. OSF UNIX is based on IBM’s AIX UNIX implementation and represents one of the most advanced operating systems available today. Another important emerging standard for UNIX is the publicdomain version termed Linux: this UNIX variation runs on a wide range of computers, is freely distributed, and has an incredibly diverse feature set, thanks to the legions of programmers around the world who have dedicated their skills to its development, extension, and support. Various versions of UNIX run on virtually every type of computer available, ranging from inexpensive microcomputers through engineer ing workstations to expensive supercomputers. The ability of the UNIX system to evolve and retain a dominant market position over two decades is a concrete testimonial to the advantages of strict adherence to the principles of software engineering, because nearly all aspects of the UNIX operating system have been designed and implemented according to these principles. In fact, much of the history of software engineering is inextricably bound up with the history of the UNIX operating system.
Parallel Computation
The use of multiple processors and specialized hardware to speed up largescale calculations has a rich history in engineering computation. Many early mainframe computers of the 1970s and most supercom puters of the 1980s used specialized hardware whose design was inﬂuenced by the nature of engineering computation. Vector processors, gather/scatter hardware, and coarsegrain parallel CPU architectures have been used successfully over the past few decades to increase the performance of largescale computers used in engineering computation. Currently, most of the hardware advances of these past large computers have migrated to the desktop, where they are readily available on microcomputers and
© 1999 by CRC Press LLC
ComputerAided Engineering
1523
workstations. Understanding the basic principles of these advanced computer architectures is essential to gain efﬁcient utilization of their advantages, and so the following sections present an overview of the fundamentals of this important ﬁeld.
Technical Overview of Parallel and Vectorized Computation
Parallelism in computer hardware can occur on many levels. The most obvious example was addressed in the setting of operating system services, where scalability over multiple CPUs was presented as a means for a computer’s operating system to utilize additional CPU resources. Parallelism achieved by adding additional CPUs to a computer commonly occurs in two variations: a coarsegrained parallelism characterized by a relatively small number of independent CPUs (e.g., typically from 2 to 16 CPUs), and a ﬁnegrained parallelism commonly implemented with substantial numbers of CPUs (typically, from a minimum of around 64 up to many thousands). The former is termed symmetric multiprocessing, or SMP, and the latter is referred to as massively parallel (MP) computing. Each is frequently encountered in practical engineering computation, although SMP is much more common due to its lower cost and relative simplicity. It is also possible for parallelization to occur within an individual CPU. On specialized mainframes with attached vector processors (and within the CPUs of most supercomputers), various different machine instructions can be pipelined so that more than one instruction occurs in parallel in a particular arithmetic unit. The practical effect of this internal parallelization in instruction execution is that many common arithmetic operations (such as the multiplication of a vector by a scalar) can be performed by carefully arranging the pipelined calculations to permit impressive performance relative to the computational effort required on a nonpipelined CPU. One of these forms of internal parallelism within the CPU (or attached processor) is termed vectorization, as it permits vector operations (i.e., those associated with a list, or vector, of ﬂoatingpoint numbers that are stored contiguously in memory) to be processed at very fast rates. Such pipelined execution characteristics have now become commonplace even on lowcost micro computers. In fact, current highperformance microprocessors used in engineering workstations and highperformance microcomputers generally have multiple independent arithmetic units that can operate in parallel. Such internally redundant designs are called superscalar architectures and allow the CPU to execute more than one instruction per clock cycle. The cumulative effect of such multiple independent pipelined arithmetic units operating in parallel within an individual CPU is that current microprocessors exhibit astonishing performance on typical engineering problems when compared to large (and expensive) central computers of the 1980s. Engineering problems that required dedicated vector processors in the 1980s are commonly executed faster on lowpriced microcomputers today. In addition to current hardware eclipsing older vector processors in performance levels, modern computer language compilers are now commonly tuned to particular microprocessor characteristics in order to provide the same sort of computational performance formerly associated with specialized vectorizing compilers (i.e., compilers that could recognize common vector operations and generate appropriately efﬁcient machine instruc tions). Finally, another important form of parallelism has developed in conjunction with highperformance networking schemes. Distributed computing applications are commonly designed to parallelize calcula tions by dividing up individual threads of execution among disparate computers connected via a high speed network. While this sort of distributed computing was sometime encountered in the 1980s on highpriced computers (such as DEC VAX clusters, which transparently balanced computational loads over a collection of networked minicomputers), similar distributed computing schemes are now becoming commonplace on microcomputers and workstations connected over localarea networks.
Classiﬁcation of Parallel Architectures
There are many schemes to characterize parallel computer architectures, including the SMP/MP classi ﬁcation given above. Since computer programs consist of instructions and data, it is possible to further classify parallelization schemes by considering the redundancy (or lack thereof) in these components.
© 1999 by CRC Press LLC
1524
Section 15
The four possible classiﬁcations are single instruction/single data (SISD); single instruction/multiple data (SIMD); multiple instruction/single data (MISD); and multiple instruction/multiple data (MIMD). Of these four, the ﬁrst pertains to nonparallel computation (such as a standard computer with a single processor). The others include representations of practical schemes for MP (massively parallel) com puting, SMP (symmetric multiprocessing) computation, and networked distributed computing. SIMD computers are particularly simple representatives of massively parallel systems. In order to run at maximum speed, each CPU in a SIMD architecture has to execute the same instructions as its neighbors (here “neighbors” is a ﬂexible term that represents various topological arrangements among small groups of processors). The result is a massively parallel computer where individual processors act in unison:
every instruction is executed by many processors, each with its own local data. If the underlying algorithm used can be constrained to ﬁt into this SIMD architecture, the performance obtained can be phenomenal. Many standard numerical schemes were already well organized for SIMD calculations: for example, simple twodimensional ﬁnitedifference calculations for heat conduction involve replacing the value at a node with the average of the node’s four neighbors in a north/west/south/east pattern. This simple calculation is relatively easy to implement on a SIMD computer, and so calculations such as these ﬁnite difference molecules result in highly scalable performance. More complex calculations, such as those found in modeling nonlinear problems, are generally much more difﬁcult to implement on SIMD computers and often result in poor performance on these simpliﬁed computer architectures. MISD computers are commonplace today, both in the form of supercomputers and in SMP desktop workstations. In each case, a small set of individual processors shares memory (single data), and each processor operates more or less independently of the others (multiple instructions). This form of paral lelism has been aided by operating systems (such as current ﬂavors of UNIX and Windows NT) that support multithreading, allowing the programmer (or the operating system) to distribute threads among the various processors in a typical SMP environment. Given appropriate programmer and operating system support, MISD computers can be highly scalable, so that adding additional processors results in associated decreases in execution time. There are substantial obstacles of increased performance in a MISD environment, including the important issue of contention by different threads for common resources. An example of resource contention occurs when two different processors attempt to access a shared memory address simultaneously: some form of signaling and locking mechanism must be provided to insure that more than one processor cannot simultaneously modify memory. Currently, many vendors offer hardwarebased support for resolving contention (and related bottlenecks) in symmetric multipro cessing, and standards are currently evolving in this important area of support. Probably the most common MIMD example of current interest is in distributed computing performed on networked computers. Since each computer has its own local data and instruction stream (MIMD), this approach combines many of the best features of singlecomputer implementations of both symmetric multiprocessing and massively parallel architectures. While networks of computers have been used for over a decade in solving many easily parallelized applications (such as classical mathematical problems arising in number theory), using such distributed computer networks to perform generalpurpose engi neering computations is a more recent development. MIMD networked computation requires a host of instruction synchronization and data replication issues to be resolved (these are the network equivalent of the resource contention problems of SMP architectures), but substantial progress is underway in addressing these bottlenecks to distributed computing. The use of objectoriented models for distributed computing, which permit hiding many of the details of the distribution process via appropriate process abstraction, appears to be an especially important avenue toward the efﬁcient use of distributed networked computing.
Computer Graphics and Visualization
Mechanical engineering is one of the most important sources of applications in computer graphics, and mechanical engineers form a signiﬁcant market for computergraphics software. Many of the most important developments in the history of computer graphics, such as the development of spline models
© 1999 by CRC Press LLC
ComputerAided Engineering
1525
for realistic surface representations, were originally motivated by the particular needs of the mechanical engineering profession. Current topics of importance to researchers in computer graphics, such as the applications of scientiﬁc visualization or the use of rational physicalbased models in computer anima tion, are also motivated in large part by the diverse needs or the knowledge base of the mechanical engineering ﬁeld.
Technical Overview of Computer Graphics
The fundamental motivation for computer graphics and visualization arises from the adage that “a picture is worth a thousand words.” The human visual sense is the only sensory apparatus with sufﬁcient bandwidth (i.e., informationcarrying capacity) to permit rapid evaluation of the large data sets charac teristically associated with problems in science and engineering. Mechanical engineers have historically been aware of the importance of using graphics, and college students in this ﬁeld have traditionally been required to study engineering graphics as a required course during their ﬁrstyear programs of study. The commonly cited observation that “graphics is an engineer’s second language” is pertinent today, especially in light of the importance of television and other visual arts during the formative years of younger engineers. There is a rich nomenclature associated with the ﬁeld of computer graphics (see Foley and VanDam, 1982, for a detailed overview). Some highlevel terms commonly used in the ﬁeld should be deﬁned before more detailed exposition of this important ﬁeld is attempted; the deﬁnitions given below are not intended to be allinclusive, but instead to be concise enough to permit further review of this topic.
• Visualization: the study of applying computer graphics toward the goal of displaying collections of data in a relevant and informative manner
• Rendering: converting a mathematical model of a scene geometry (or a collection of data values) into a visually meaningful image on the computer
• Virtual reality: technology permitting simultaneous display and control of graphical simulations so that the user interprets the display as the existence of an alternative reality
• Multimedia: the integration of senses besides the visual sense into a computer application or simulation
• Graphical userinterface: a metaphor for humancomputer interaction using standardized graphical mechanisms for control, input, and output
One of the main reasons that rapid progress has occurred in computer graphics is that practitioners in the ﬁeld have learned to leverage the efforts of others by adhering to industrywide standards. The code of standardization and practice in computer graphics exists on many levels, ranging from lowlevel coordinate choices developed as a foundation toward abstracting the rendering and display process to highlevel format standardizations required for the portable use of multimedia content. The breadth of standardization in computer graphics is beyond the scope of this handbook, but relevant information can be found in the publications of the ACM/SIGGRAPH. This organization is the primary instrument of dissemination and standardization efforts in the computer graphics industry.
Visualization Methods in Mechanical Engineering
The fundamental problem of visualization in science and engineering is the conversion of raw data into an informative visual display. The data may arise from a closedform mathematical representation, or it may be obtained as an organized collection of data presented in tabular or related formats. The most important initial step in engineering visualization is the recognition of the domain (i.e., the set of input values) and range (i.e., the set of output values) of the data to be represented, so that an appropriate visual display can be synthesized. For example, if the range of the data includes a temporal component, then a timedependent display scheme such as an animation is often warranted. If the domain is a physical region in space (such as a mechanical object being analyzed), then a common visualization scheme consists of mapping that region onto the display surface as a background for visual results. The details of the particular display choice depend upon the range of the output data: for display of scalars (such
© 1999 by CRC Press LLC
1526
Section 15
as temperature, or speciﬁc components of stress), appropriate visualization schemes include contour maps using lines or colorﬁlled contours, as shown in Figure 15.2.7 (in two dimensions) and in Figure 15.2.8 (in three dimensions, for the same general stress analysis problem). When rendering three dimensional results as in Figure 15.2.8, it is necessary to provide for removal of hidden surfaces from the display. For display of vectors, the use of arrows aligned with the local vector ﬁeld is a common means for displaying this more complex type of range: an example is shown in Figure 15.2.9. In order to aid in the understanding of complicated visualizations, it is often useful to provide visual cues to aid the viewer in understanding the display presented. In Figure 15.2.10, a contour plot of pressure within a heater fan is shown (at high Reynolds’ number), with an inset picture showing the geometry of the fan used in the computational simulation. The combination of virtual display (the pressure contours) and physical display (the fan assembly) aids the viewer in understanding the model geometry and solution response. (Figures 15.2.9 and 15.2.10 are included courtesy of Advanced Scientiﬁc Computing Corporation of El Dorado Hills, CA.) Another useful approach to provide contextual cues to aid in understanding a complex visualization is to overlay the graphical image on top of a physical setting associated with the simulation. For example, geographical simulations (such as models of contaminant transport used for air pollution modeling) can be overlayed on a map of the geographical area under study: viewers will instantly grasp the problem domain in terms of landmarks such as rivers, roads, mountains, and other obvious visual cues. An alternative approach is shown in Figure 15.2.11, where a visualization of a complex reactor simulation is overlayed on a picture of the reactor itself. In this ﬁgure, the color contours plot gas temperatures in a model of a chemically reacting NavierStokes simulation used for modeling vapor deposition processes occurring in semiconductor manufacture. (The simulation and visualization were both performed at Sandia National Laboratories in Livermore, CA.) When timedependent results are to be visualized, there are two standard schemes commonly used. The ﬁrst approach involves treating the timedependent behavior of the data as another spatial dimension. This approach is commonly used to graph scalarvalued functions of time t as y = y(t), with the function’s variation plotted on the vertical axis and the time on the horizontal axis. It can also be used to draw more complex functions such as the one shown in Figure 15.2.12, where a scalarvalued function of two variables z = z(x, t) is plotted as a threedimensional surface (in this example, the axial displacement of a bar as a wave moves along its length). Note that the surface is drawn in perspective to aid in the perception of threedimensional behavior even though it is plotted on a twodimensional page. Using such depth cues as perspective (as well as others, including hiddensurface removal and shading and realistic illumination models) to aid in realistic display of computer images is the essence of the rendering process. The other standard approach for visualizing timedependent data is to treat the temporal variation of the data in a natural form by animating the history of the display. Standard animation techniques were formerly beyond the range of cost and effort for most engineering purposes, as computergenerated animation workstations of the 1980s typically cost over $100,000 and required considerable dedicated expertise for operation. Currently, microcomputers have become excellent platforms for animation and visualization, and appropriate computer programs (known as nonlinear digital video editing software) for generating and composing animations from engineering simulations have become popular on inex pensive microcomputers and lowend engineering workstations.
Multimedia in Mechanical Engineering Practice
Multimedia is an imprecise term whose deﬁnition has evolved over the recent past as the performance of computers has improved substantially. Formerly, multimedia was taken to mean integration of different types of display (such as a textual computer used to control a graphical device for display of archived images). The current context of the term includes multiple senses, such as the integration of video and sound, or the control of a visual display by a tactile threedimensional graphical input device. The former ﬂavor of multimedia naturally draws the analogy with silent movies being replaced by those with a
© 1999 by CRC Press LLC
ComputerAided Engineering
1527
FIGURE 15.2.7 Twodimensional contour plot for stress analysis.
© 1999 by CRC Press LLC
stress sigmamax 

min 1.960E+04 

max 
8.949E+05 
+9.4000E+05 

+9.0000E+05 

+8.6000E+05 

+8.2000E+05 

+7.8000E+05 

+7.4000E+05 

+7.0000E+05 

+6.6000E+05 

+6.2000E+05 

+5.8000E+05 

+5.4000E+05 

+5.0000E+05 

+4.6000E+05 

+4.2000E+05 

+3.8000E+05 

+3.4000E+05 

+3.0000E+05 

+2.6000E+05 

+2.2000E+05 

+1.8000E+05 

+1.4000E+05 

+1.0000E+05 

+6.0000E+04 

+2.0000E+04 

2.0000E+04 

6.0000E+04 
ComputerAided Engineering
1529
FIGURE 15.2.9 Threedimensional vector ﬁeld plot for torque converter simulation.
FIGURE 15.2.10 Pressure contour plot with solution geometry cues.
© 1999 by CRC Press LLC
1530
Section 15
FIGURE 15.2.11 Gas temperature contour plot with reactor background.
FIGURE 15.2.12 Timedependent data viewed as spacetime surface plot.
© 1999 by CRC Press LLC
ComputerAided Engineering
1531
sound track: that technological development revolutionized the movie industry in a manner similar to the predicted impact of multimedia on computing practice. The latter example is widely used in virtual reality applications. Multimedia is presently used in education, training, marketing, and dissemination efforts in the engineering profession (see Keyes [1994] for a detailed exposition of the application of multimedia to all of these ﬁelds). Each of these uses is based on two empirical observations: (1) people generally ﬁnd multimedia presentation of data more interesting, and this increased interest level translates into better retention of data presented; and (2) good use of visualization principles in multimedia presentation provides a better audience understanding of the material presented. The promise of simultaneous increased understanding and improved retention is a strong motivation for using multimedia in the presentation of information. There are considerable technical issues to address in efﬁcient use of multimedia technology. The most important technical problem is the sheer volume of stored data required to make animations, which are a mainstay of multimedia presentations. A single highquality color computer workstation image (e.g., one frame of an animation that would typically be displayed at 24 to 30 frames per second to convey the sense of continuous motion) requires from approximately 1 to 4 million bytes of storage. Generating fullscreen animations therefore requires anywhere from a few dozen to over a hundred megabytes of data to be processed and displayed every second. Such video bandwidths are rare on computers, and even if they were available, the demand for storage would soon outstrip available supply, as each 10 sec of video potentially requires up to a gigabyte of highspeed storage. Storing sound requires less dramatic capacities, but even lowquality (e.g., AMradio quality) audio storage requires substantial storage for long durations of audio. The practical way to overcome these technical limitations to storage and display bandwidth is to develop efﬁcient ways to compress visual and aural redundancies out of the data stream on storage, and then decompress the archived data for editing or display. Such COmpression/DECompression schemes (termed CODECs) are generally used to support multimedia applications ranging from digital animation preparation on microcomputers to video teleconferencing applications. Common CODECs are tailored for individual applications and auxiliary technology (for example, playing video from a CD/ROM device generally requires high compression ratios in order to accommodate the relatively poor data transfer rates obtained with CD/ROM technology), and their performance is measured in terms of compression ratio, which is the ratio of uncompressed image size to compressed image size. Various CODECs in common use include:
• JPEG (Joint Photographic Experts Group) CODEC. JPEG is a CODEC originally developed for efﬁcient storage of individual images, such as photographic libraries. JPEG is a lossy algorithm (i.e., some information may be lost during compression), but JPEG is so carefully tuned to human perceptual characteristics that it is feasible to achieve compression ratios on the order of 10:1 or more without being able to detect any losses, even after repeated recompressions. Higher com pression ratios (on the order of 100:1) can be achieved, but these more efﬁcient rates may introduce visible artifacts of the compression process. JPEG is generally only feasible for animation appli cations through the use of specialized hardware, but the same hardware can be used for both compression and decompression tasks. JPEG is a very commonly used CODEC in animation applications, as the required hardware is relatively inexpensive, the performance (e.g., speed, image quality) is acceptable, and the algorithm is easy to implement within animation applications (e.g., digital video editing software).
© 1999 by CRC Press LLC
1532
Section 15
• MPEG (Motion Pictures Experts Group) CODEC. MPEG is a family of CODECs that is becoming popular for displayonly animation applications. The various MPEG implementations (MPEG and MPEG2) require prodigious amounts of computational effort for the compression step, so they are not presently feasible for inexpensive video capture applications. MPEG CODECs routinely provide compression ratios approaching 100:1 with relatively little degradation of image quality. This compression efﬁciency permits very large and complex animations to be stored and played back using lowtechnology devices such as CD/ROMs. The fundamental difference between MPEG and JPEG schemes is that with JPEG,each video frame is compressed indepen dently of all the other frames, where MPEG uses adjoining frame information by concentrating on the differences between frames to compress the overall animation more efﬁciently (most animations have only small temporal differences among adjacent frames, and this timedependent redundancy is ignored by the JPEG algorithm and carefully exploited by the MPEG family). It is expected that the nearterm will see many inexpensive implementations of MPEG CODECs for microcomputers, and many proposed video storage standards (e.g., new videodisc technology designed to replace existing VHS video playback devices) rely on MPEG compression schemes for efﬁcient storage of movies on CD/ROMs.
Another important technical issue arising in multimedia applications is the synchronization of time dependent data streams. For example, multimedia applications using both video and sound must guar antee synchronization of these two data streams in order to maintain audience interest. Probably the most important synchronization method is that provided by the Society of Motion Picture and Television Engineers (SMPTE). SMPTE synchronization depends on a timecode that numbers every frame of video. This timecode information can be used to synchronize audio information to the video source; in fact, this is exactly how commercial movie soundtracks are synchronized with the motion picture. Other timecode mechanisms include RC timecode, which is a frameindexing scheme that is available on many consumergrade video products, including camcorders, video recorders, and video editing equip ment. RC provides the same sort of synchronization as SMPTE, but with fewer features and at a reduced cost. Standard microcomputer multimedia programming interfaces generally provide synchronization mechanisms for simultaneous audio and video display. Both Microsoft’s Video for Windows system software (used under Windows and Windows NT operating systems) and Apple’s QuickTime software (available for Macintoshes, Windows, Windows NT, and UNIX workstations) provide timecode infor mation pertinent for simple synchronization of multimedia. In addition, current versions of QuickTime also provide SMPTE timecode support, in order to simplify the task of highperformance digital video editing on the Macintosh platform.
Graphical UserInterface Design and Implementation
The marriage of human perceptual principles from applied psychology with the technology of interactive computer graphics resulted in the development of graphical userinterfaces (GUIs). GUIs have since evolved into one of the most revolutionary ideas in the history of computing. The basic idea behind a GUI is that visualization can be used to provide a powerful abstraction for the interaction between human and computer, and that basing that graphical abstraction on principles of human perception and ergo nomics will result in increased user productivity. Most of the early work on development of GUIs occurred at the Xerox Palo Alto Research Center in California, and the fundamental ideas developed there were ﬁrst implemented in a consumer setting when Apple Computer released the Macintosh in 1984. Since then, virtually every major vendor of computer has adopted a GUI similar in appearance to that of the Macintosh, and it is clear that using a welldesigned GUI yields substantial gains in produc tivity for most computerassisted tasks. The fundamental rules for implementing a GUI within a computer program are simple: the program’s interface must be intuitive, consistent, permissive, and responsive (see Apple [1985] for a wellwritten introduction relating to the widely imitated Macintosh userinterface guidelines). An intuitive program
© 1999 by CRC Press LLC
ComputerAided Engineering
1533
interface is easy to understand and responds naturally to a user’s actions. Implementing an intuitive interface is a similar task to good industrial design, where principles of cognitive ergonomics are used to insure that controls of manufactured products (such as household appliances) are appropriately easy to use. The classic example of an appliance with an intuitive user interface is a toaster (in fact, one of the design goals of the Macintosh development process was to design a computer that would be as easy to use as a toaster), as the controls are naturally placed and behave intuitively. Intuition in computer applications thus implies natural composition, arrangement, and performance of graphical controls, such as buttons to be pressed for execution of commands. The role of consistency is essential to the goal of improving the productivity of computer users. Until the widespread use of GUIs, most application programs used individual and unique schemes for such mundane tasks as saving ﬁles, printing documents, or quitting the program. Unfortunately, there was little standardization of commands for performing these common functions, so the user was faced with a substantial learning curve for each program encountered. With the advent of consistent graphical user interfaces, the effort of learning most standard commands needs to be learned only once; all other applications will use the same mechanism for performing these common functions. The cost of training is thus primarily amortized over the ﬁrst program learned, and the resulting productivity gains are often substantial. While the goal of complete consistency between applications (and especially between different types of GUI) has not yet been realized, there has been considerable progress toward this ultimate goal. Permissiveness places the user in control of the computer, instead of the opposite situation, which was routinely encountered in older textual interfaces. The user should decide what actions to do and when to do them, subject only to the feasibility of those actions. Permissiveness allows users to structure their workﬂow in a personalized manner, which allows them to seek and ﬁnd the best individualized way to accomplish computerassisted tasks. Permissiveness is one of the most difﬁcult attributes for a computer programmer to implement, as it requires enabling and testing a myriad of different execution pathways in order to guarantee that all feasible approaches to using the computer program have been insured to work reliably. The quality control processes of permissive GUIbased programs are often automated (using software that generates random input processes to simulate a variety of user actions) in order to test unexpected command sequences. Responsiveness is another essential element of ensuring that the user feels in control of the software. In this sense, a responsive GUIbased program provides some appropriate feedback (generally graphical) for every legitimate userinitiated action. This feedback may be as simple as a “beep” when an improper command is issued, or as complicated as rendering a complex picture in response to usersupplied input data. Responsiveness and intuition work together in the control of the program’s actions; for example, the pulldown menu command procedures of most current GUI programs permits the user to see clearly (typically, via highlighting of the currently selected menu item) which of a series of intuitive commands are about to be initiated. Writing good GUIbased software is a difﬁcult process and is especially cumbersome when procedural languages are used. Modern eventdriven interactive software is naturally suited to the more asynchronous messagedriven architecture available with objectoriented programming models, and it is in the area of GUIbased applications that objectoriented languages have begun to corner the development market. Since managing the GUI requires so much programmer effort (and because the goal of consistency requires that all such code behave in a similar manner), there is a considerable incentive to reuse code as much as possible in this task. The use of class libraries designed for implementing a standard GUI model is a highly effective way to develop and maintain graphical interactive computer programs, and this use is one of the most common applications of class libraries in software engineering. There are many standard GUI elements, including:
• Menus for permitting the user to initiate commands and exert program control • Dialogs for ﬁeldbased input of data by the user
© 1999 by CRC Press LLC
1534
Section 15
• Windows for graphical display (output) of program data • Controls (such as buttons or scroll bars) for auxiliary control of the program
Virtual Reality Applications in Engineering
Virtual reality is one of fastestgrowing aspects of computer graphics. Efﬁcient and realistic virtual reality applications require incredible amounts of computational effort, so advances in this area have been limited in the past, but the increased computational performance available with current CPUs (and with better support for multiprocessing and parallelization of effort) has made virtual reality solutions feasible for many engineering problems. The primary motivation for virtual reality is the same one as for computer graphics: using the body’s senses (and especially the sense of sight) is a very productive way to gain insight into large amounts of data or for simulating difﬁcult (e.g., lifethreatening) situations. There are two common technological approaches to virtual reality: windowed virtual reality applica tions, in which the view into the virtual world is represented by a conventional planar graphical computer display, and immersive virtual reality which requires specialized hardware (such as display headsets) to convey a sense of being immersed in the artiﬁcial virtual world. While windowed virtual reality appli cations are common (running on platforms ranging from highperformance computers with color displays to massmarket dedicated computer game machines designed for use with television sets), immersive virtual reality applications are still fairly expensive and rare. In addition, there is considerable anecdotal evidence that attempting to perform immersive virtual reality with equipment insufﬁciently powerful to update the display instantaneously (i.e., within the interval of around 1/30 sec associated with the persistence of vision) may induce nausea and disorientation in many users. There are many important types of virtual reality applications in use in engineering and related ﬁelds. Walkthrough (or perambulatory) virtual reality programs permit the user to move around in the virtual world, where either easily recognizable images (such as architectural renderings of virtual construction) or completely virtual images (such as visualization displays involving surface plots, color contours, streamline realizations, and other standard visualization schemes updated in realtime) are encountered and manipulated. Walkthrough virtual reality applications are typically used to gain new perspective on simulations or proposed constructions. The primary control ceded to the user is the power to move through the virtual world, and perhaps to modify the type of display encountered. Synthetic experience is another important component of the application of virtual reality. The classic example of this form of virtual reality application is a ﬂight simulator, where an integrated display and a movable cockpit are used to simulate the “look and feel” of ﬂight. Synthetic experience applications permit the user to manipulate the virtual world in exactly the same manner as the real world, and these programs are used for education, training, and professional practice. The basic motivation for this class of virtual reality applications is to permit the user to practice and learn techniques that would be otherwise too expensive or too dangerous to perform by “real” methods as opposed to virtual practice. This approach has been used extensively in military applications (e.g., battle simulators) and is gaining wide use in medicine and other professional ﬁelds (e.g., virtual surgery, where surgeons can practice surgical tech niques on the computer or even perform real surgery from a remote “virtual” location).
© 1999 by CRC Press LLC
ComputerAided Engineering
15.3 Computational Mechanics
1535
Computational mechanics is the art and science of simulating mechanics problems on the computer. The rapid development of computational mechanics is an important component of the foundation of the today’s hightechnology world. Current developments in aerospace, automotive, thermal, biomedical, and electromagnetic engineering applications are in large part due to the success of computational mechanics researchers in ﬁnding efﬁcient schemes to simulate physical processes on the computer. Understanding the strengths and weaknesses of the current computational mechanics ﬁeld is an important task for the practicing mechanical engineer interested in using computeraided engineering methods. Computational approximations for mechanics problems are generally constructed by discretizing the domain of the problem (i.e., the underlying mechanical system) into smaller components. Ideally, in the limit as the size of each of these individual discretized components becomes negligibly small, the computational approximation obtained becomes exact. In practice, there is a lower limit on how small a discretization can be used, as roundoff error (caused by truncation of numerical representations used on computers) and requisite computational effort eventually conspire to produce inaccurate or excessively expensive results. Other alternative approximation schemes, including semianalytical methods such as truncated Fourier series representations, are also commonly used to provide numerical solutions for engineering problems. These nondiscretized methods require letting the number of solution functions (such as the trigonometric functions used in Fourier series) approach inﬁnity to gain convergent results and are thus superﬁcially similar to discretization schemes such as ﬁniteelement and ﬁnitedifference methods, where the number of grid points tends to inﬁnity as the size of the grid spacing decreases.
Computational Solid, Fluid, and Thermal Problems
Before speciﬁc computational approximation schemes are presented, it is enlightening to enumerate the wide variety of problems encountered in mechanical engineering practice. In many cases, each individual subdiscipline of mechanics (e.g., solid mechanics) uses different modeling techniques to obtain compu tational approximations, so that reviewing the various branches of mechanics also serves to foreshadow the spectrum of numerical schemes used in the different branches of computational mechanics.
Solid Mechanics
Solid mechanics is one of oldest and most wellunderstood branches of mechanics, and its associated computational schemes are similarly well established. The most common application of solid mechanics is stress analysis, where the mechanical deformation of a body is studied to determine its induced state of stress and strain. The study of stress analysis formerly included considerable emphasis on construction and instrumentation of physical models using strain gauges and photoelastic coatings, but modern computational schemes for modeling deformation of solids have rendered these traditional laboratory techniques nearly extinct. The most currently popular stress analysis methods are those based on computational approximations using ﬁniteelement models. This family of computer simulation tech niques is one of the most successful branches of modern computational mechanics, and practical implementations of ﬁniteelement methods represent a uniﬁed computational model for nearly the entire range of solid mechanical response. Solids are modeled by appealing to three classes of mathematical relationships: equilibrium, compat ibility, and stressstrain laws. Equilibrium statements represent mathematical expressions of conservation laws and are generally expressed in terms of the conservation of linear and angular momentum. Com patibility conditions include the kinematical straindisplacement relations of mechanics, where strains are expressed as spatial derivatives of the displacement ﬁeld. Stressstrain laws are also termed consti tutive relations, because they idealize the constitution of the material in order to relate the interplay of stresses and strains in a deformed body. The fundamental mathematical relations for the dynamic response of a threedimensional isotropic linearelastic solid body are given below — note that these equations are linear, in that they involve no products of the solutions components of displacement, stress, or strain.
© 1999 by CRC Press LLC
1536
Section 15
This linearity arises from the assumptions of small deformations, a linear stressstrain law, and the fact
that the reference frame for these equations is attached to the solid body. The linear nature of these
relations makes them relatively easy to solve for a wide range of problems, and this simplicity of analysis
is an important reason why stress analyses based on these relations is such an important part of
computational mechanics.
Deﬁnitions for Solid Mechanics Equations
u 
, 
, 
w 
= 
x , y , z components of displacement 

˙˙, ˙˙ u 
, 
˙˙ w 
= 
x , y , z components of acceleration 

x 
, 
y 
, 
z 
, 
xy 
, 
yz 
, 
zx 
= stress components 


y 
, 
z 
, 
xy 
, 
yz 
, 
zx 
= engineering strains 

g 

g 
y 
, 
g 
z 
= gravity body force components 
E = Young' s Modulus
= Poisson' s Ratio 

= Density 
“Dynamic” Equilibrium Equations for a Solid
(15.3.1)
(15.3.2)
(15.3.3)
© 1999 by CRC Press LLC
ComputerAided Engineering
1537
Isotropic LinearElastic StressStrain Relations
(15.3.4)
Solids are commonly distinguished from liquids by the ability of solids to maintain their shape without
restraint due to enclosing containers. Because of this particular form of mechanical strength, solids
provide many simple structural approximations that naturally arise as degenerations of full three
dimensional solid mechanical response. These idealizations of solid mechanical behavior are diagrammed
in Figure 15.3.1 and include:
FIGURE 15.3.1 Common idealizations of solid mechanical behavior.
• Rods, with a local onedimensional geometry and applied loads directed along the natural axis
of the rod (rods are also termed spars or struts)
• Beams, which are similar to rods except that beams permit loads to be applied in directions
perpendicular to the natural axis
• Shafts, which are also similar to rods, except that they are loaded by torques directed along their
natural axis in addition to forces applied in that axial direction
• Membranes, which are locally twodimensional structures loaded in the plane deﬁned by their
geometry
• Plates, which are twodimensional ﬂat structures loaded by arbitrary forces and couples, including
those that excite membrane response and those that bend or twist the natural twodimensional
reference surface of the plate
• Shells, which are generalizations of plates to include curvature of the reference surface in three
dimensions
© 1999 by CRC Press LLC
1538
Section 15
Theories of computational solid mechanics are often categorized by reference to the particular struc
tural idealization being studied. In particular, computational theories for beams, plates, and shells are
similar because each is characterized by bending deformation, in which the primary mechanical response
may occur at right angles to the natural geometric reference frame for the structure. Problems that include
substantial bending deformation often require considerable care in computational modeling in order to
avoid inaccurate results.
Another very important aspect of solid mechanics involves nonlinear material and geometric response.
Nonlinear material behavior is commonly encountered in computational inelasticity, where the plastic,
viscous, or nonlinear elastic response of a solid material must be modeled. In many materials (such as
most metals) this inelastic behavior in realized after considerable elastic response, and hence it may
often be neglected. In other materials (such as rubber or its relatives commonly used in aerospace
applications), the nonlinear material properties must be addressed throughout the range of computational
simulation. Furthermore, many of the idealizations presented earlier (such as rods and membranes)
possess nonlinear geometric behavior that may dominate the mechanical response. One important
example of this form of geometric nonlinearity is the buckling of a rod subjected to axial compressive
stresses.
Fluid Mechanics
The basic principles of ﬂuid mechanics are exactly the same as those for solid mechanics: the mechanical
system under consideration is analyzed using appropriate equilibrium, compatibility, and stressstrain
relations. In practice, because of the inability of a ﬂuid to resist shear, ﬂuids are considerably more
difﬁcult to characterize than solids, and the effective computational mechanics of ﬂuids is therefore a
more difﬁcult and diverse topic. Perhaps the most important difference between common models for
solid and ﬂuid mechanics is that the base reference frame for the solution process is generally different.
For solids, most analyses proceed by modeling the deformation relative to a reference frame attached
to the material body being deformed. Fluids are generally modeled instead by attaching the problem’s
reference frame to a region in space and analyzing the ﬂow of the ﬂuid as it is transported through this
geometric reference frame. The latter scheme is termed an Eulerian formulation of the reference frame,
and the former is called a Lagrangian reference conﬁguration. While the Eulerian world view is more
common for analyzing ﬂuids (primarily because tracking the individual motion of all particles of the
ﬂuid material is generally intractable in practice), this conceptually simpler approach gives rise to many
practical computational difﬁculties because the underlying conservation principles are most readily posed
in a reference frame attached to the material.
One of the most important mathematical models of ﬂuid response are the NavierStokes equations.
These equations are presented below for a threedimensional ﬂow ﬁeld involving a Newtonian ﬂuid (i.e.,
one readily characterized by the material parameter viscosity, which is assumed not to depend upon ﬂuid
stress) and an incompressible formulation (see Panton, 1984 or White, 1979). It is worth noting that
even in the case of these simplifying assumptions, which correspond to those given above for the
mathematical formulation of solid mechanics, the NavierStokes equations are nonlinear, in that products
of solution quantities occur in the convective terms on the lefthand side of the momentum conservation
equations. These nonlinearities arise because of the Eulerian reference frame used to model ﬂuid ﬂow,
and cause ﬂuid mechanics problems to be generally much more difﬁcult to solve than analogous solid
mechanics problems.
© 1999 by CRC Press LLC
ComputerAided Engineering
1539
Deﬁnitions for Fluid Conservation Equations
u 
, 
, 
w 
= 
, 
, 

p = pressure field 

g 
x 
, 
g 
y 
, 
g 
z 

= density 

= viscosity 
x y z components of velocity
= gravity body force components
Fluid Momentum Conservation Equations
(15.3.5)
the ﬂow is internal (conﬁned, as in ﬂowthrough ducts) or external (conﬁning, as in the case of modeling
ﬂow around an airfoil in aerospace applications), and whether the internal or external ﬂow ﬁeld contains
a ﬂuidfree surface. Freesurface ﬂows are considerably more complex to model using computational
methods because the physical extent of the ﬂuid material (and hence of the problem’s geometric domain)
is unknown a priori, and therefore determining the geometry of the mechanical problem must be
considered as an essential part of the problem solution process.
One important facet of mechanical engineering practice involves diffusion phenomena, such as the
ﬂow of heat through a conductor. Such problems in heat conduction, porous media ﬂow, and other
diffusive systems can be readily modeled using standard ﬂuid mechanical models appropriate for
diffusion and dispersion. In addition, problems involving combined advection and diffusion (such as
mass transport problems encountered in environmental engineering or in manufacturing) are readily
modeled using techniques similar to related ﬂuid mechanics models.
One of the most common ways to categorize ﬂuid mechanical behavior arises from consideration of
various dimensionless parameters deﬁned by the constitution of the ﬂuid and its ﬂow regime. Represen
tative dimensionless parameters relevant to ﬂuid mechanics include:
• The Reynolds number, which relates the effects of ﬂuid inertia to those of ﬂuid viscosity forces
and which naturally arises in a broad range of ﬂuid problems
• The Mach number, which measures the ratio of ﬂuid speed to the speed of sound in the ﬂuid:
this parameter is important in compressible ﬂow problems
• The Peclet number, which quantiﬁes the relative effects of ﬂuid transport due to advection and
dispersion and is used in ﬂuid mass transport modeling
© 1999 by CRC Press LLC
1540
Section 15
• The Taylor number, which is used to predict instabilities present in various ﬂuid ﬂow regimes
and may be encountered when dealing with the computational ramiﬁcations of ﬂuid instability
Unlike solid mechanics, there is no body of computational expertise that provides a generic model
for computational approximation of the full range of ﬂuid response. In practice, computational schemes
are chosen according to particular aspects of ﬂuid behavior (such as the various classiﬁcations and
dimensionless parameters given), which substantially limits the range of applicability of any particular
computational solution scheme. Many ﬂuid models are solved using ﬁniteelement models, as in solid
mechanics, but others have largely resisted characterization by such general computational schemes.
Fluid material models are generally more complex than those found in solid mechanics, as ﬂuids
exhibit a bewildering array of diversiﬁed material responses. Because of the difﬁculty in modeling many
ﬂuid constitutive parameters, many ﬂuid models are analyzed using gross constitutive models that often
neglect complicating material behavior (one common example of this case is the case of inviscid ﬂow
models, where neglecting the presence of ﬂuid viscosity results in tremendous simpliﬁcation of the
resulting computational approximation). When ﬂuid material response is important, as in the example
of modeling transition from laminar to turbulent ﬂuid behavior, the requisite constitutive equations for
the ﬂuid become appropriately more complex. While there is not yet a completely uniﬁed model for
ﬂuid constitutive behavior, each individual subdiscipline of computational ﬂuid mechanics utilizes ﬂuid
material models that provide reasonable accuracy for ﬂuid response within the range of the particular
problems studied.
Electromagnetics problems are commonly solved by practicing mechanical engineers using techniques
originally utilized for computational ﬂuid dynamics. It is feasible to recast much of the computational
technology developed for ﬂuids into the setting of electromagnetics problems, because many electro
magnetic simulations are qualititatively similar to ﬂuid response. For example, potential ﬂow simulation
techniques are readily adapted to the potential formulations of electrostatics and magnetostatics. Alter
natively, the full range of ﬂuid response exhibited by the NavierStokes equations, which includes
transient inertial and dissipative effects, is qualitatively similar to largescale transient problems involving
coupled magnetic and electrical ﬁelds. Mechanical engineers interested in performing electromagnetic
simulations will commonly ﬁnd that expertise in ﬂuid computer modeling provides an excellent under
standing of methods appropriate for solving electromagnetic problems.
Thermal Analysis
The determination of the static or transient temperature distribution in a physical medium is one of the
bestknown cases of the mathematical setting known as “scalar potential ﬁeld” theory. In this case, the
scalar potential is the temperature ﬁeld, and the heat ﬂow in the physical domain occurs in a direction
governed by the product of a constitutive tensor known as the thermal conductivity and the gradient of
the temperature distribution. In simple terms, heat ﬂows downhill, or opposite the direction of the
temperature gradient. The governing mathematical relations for transient conductive heat transfer in a
threedimensional solid are given below (see Kreith and Bohn, 1993). Note that this form of the energy
conservation law will not apply if the conductivity varies with position, as is common in many mechanical
engineering applications: in this case, the second derivatives on the righthand side of this relation must
be generalized to include spatial derivatives of the conductivity term.
© 1999 by CRC Press LLC
ComputerAided Engineering
1541
Deﬁnitions for Thermal Equation
T = temperature field
k = thermal conductivity
s = distributed heat sources
= density
c = specific heat
Heat Energy Conservation Equation
∂ T 
∂ 
2 T 
∂ 
2 
T 
∂ 
2 
T 

c 
k 
+ 
+ 
+ 
s 

∂ t 
= 
∂ x 
2 
∂ y 
2 
∂ z 
2 
(15.3.8)
(15.3.9)
Conductive thermal problems are relatively straightforward to solve, which leads to the incorporation
of thermal effects in many commercial solid and ﬂuid mechanics analysis programs. The mathematical
quality of these thermal analyses is that they are diffusive phenomena, in that they exhibit smooth solution
behavior and that there are few localization effects either in space or time that cause serious computational
problems such as those commonly found in transient analyses in solid, ﬂuid, and electromagnetic systems.
Convective thermal problems are considerably more difﬁcult to model by computer because they involve
transport of heat by a moving ﬂuid, and thus may suffer from the same difﬁculties inherent in modeling
transient ﬂuid response.
Biomechanics
Biomechanics is an increasingly important component of mechanics (see Section 20.3) Computational
simulation of biomechanical systems is difﬁcult because many biomechanical problems straddle the
boundary between solid and ﬂuid mechanics and the mechanical properties of many organic components
are diverse. For example, the computational modeling of head trauma, which is of considerable interest
in automotive engineering applications, is complicated by the fact that the brain is a semisolid porous
mechanical system, and its motion and deformation are further constrained by the solid enclosure of the
skull. While rational ﬁniteelement mechanical modeling of head trauma has been underway for over
two decades (Shugar, 1994), the problem still resists accurate computational simulation.
Even though biomechanical problems are inherently difﬁcult, they are often encountered in professional
practice. The practicing engineer interested in performing accurate computational modeling of complex
biomechanical systems should insure that appropriate veriﬁcation measures (such as computer visualiza
tion of model geometry and results) are undertaken in order to minimize the potential for errors caused
by the overwhelming difﬁculties in modeling these important but often intractable mechanical systems.
Coupled Solid/Fluid/Thermal Field Analyses
Many “realworld” problems encountered in mechanical engineering practice defy simple categorization
into solid, ﬂuid, or otherwise. These practical problems often include combinations of classes of response,
and the efﬁcient solution of such coupled problems requires careful investigation of the individual
components of the combined problem. There are several important questions that must be addressed
when solving a coupled mechanical problem:
• Is it necessary to solve for all components of the solution response simultaneously (i.e., can the
problem components be decoupled)?
• If the solution processes can be decoupled, which aspects of the solution must be found ﬁrst, and
which components can be considered of secondary relevance during the decoupled solution
process?
© 1999 by CRC Press LLC
1542
Section 15
• Are there any mathematical pathologies present in the coupled problem that may compromise
the accuracy of the computed solution?
In general, fully coupled solution schemes (in which all components of the solution are found at the
same time) will be more accurate over the entire range of solution response and will also require more
computational effort. Under some circumstances, one or more components of the solution can be
identiﬁed as of relatively minor importance (either because of their relative magnitude or their insignif
icant rate of change with time), and then the solution process can be decoupled in order to simplify the
resulting calculations. For example, in many problems involving the coupled mechanical/thermal
response of a material, it is common practice to assume that the temperature ﬁeld can be calculated
independently of the state of stress. Furthermore, an additional simpliﬁcation can be obtained by
assuming that the mechanical deformation of the system does not affect the temperature distribution
substantially. The analysis of a mechanical system during relatively slow changes in ambient temperature
(such as the diurnal variations of temperature encountered outdoors between night and daytime direct
sunlight) could be modeled with reasonable accuracy using these assumptions, and the net result of this
simpliﬁcation is that the coupled problem could be solved as a series of uncoupled transient problems.
At each time in the solution history, the temperature ﬁeld would be computed, and this temperature
distribution would then be used to compute the mechanical deformation at the same time. As long as
the underlying assumptions leading to these simpliﬁed decoupled problems are satisﬁed, this uncoupled
approach works well in practice.
In many problems, it is not possible to decouple the component problems, and all aspects of the
solution must be determined simultaneously. Some important examples occur in aerospace applications,
including the modeling of ﬂutter instabilities in aircraft structures (where the coupled external ﬂow and
solid mechanics problems are considered concurrently) and the ablation of rocket engine components
(where the modeling of combustion, heat transfer, thermal pyrolysis, mechanical deformation, and porous
media ﬂow effects all must be considered simultaneously).
In many coupled problems, there are mathematical solution pathologies present that may corrupt the
accuracy of the computer solution. In particular, whenever the solution process involves determination
of coupled kinematical solution components (i.e., geometric unknowns such as velocities and displace
ments) and statical solution parameters (i.e., forcelike quantities such as pressure), then the mathematical
setting for guaranteeing accuracy of the computer approximation may become considerably more com
plex. Coupled problems involving both statical and kinematical solution components are termed mixed
problems, and practicing engineers who must model mixed problems ought to familiarize themselves
with an outline of the potential pathologies that can be exhibited by naive application of mixed compu
tational technologies. While a complete characterization of these problems is far beyond the scope of
this brief introduction to coupled problems, some hint of the underlying theory and practice is presented
in the following sections.
Mathematical Characteristics of Field Problems
Effective computational solution of the problems encountered in mechanical engineering requires at least
an introductory knowledge of the underlying mathematics. Without a fundamental understanding of such
relevant issues as solvability (the study of the conditions required for a solution to exist), convergence
(measuring whether the computed solution is accurate), and complexity (quantifying the effort required
to construct a computational solution), the practicing engineer may spend considerable time and resources
constructing computational approximations that bear little or no resemblance to the desired “exact”
answers. The material presented below is intended to provide an overview of the relevant mathematical
content required to evaluate the quality of a computer approximation.
Solvability Conditions for Computational Approximations
Before any physical problem is modeled using a computational approximation, it is essential to ensure
that the underlying mathematical model is well posed. Wellposed problems can be characterized as
© 1999 by CRC Press LLC
ComputerAided Engineering
1543
those where a solution exists and where that solution is unique. While solvability concerns (i.e., those
relating to whether a mathematical problem can be solved) such as mathematical existence and unique
ness are often considered as mere niceties by practicing engineers, in fact these properties are important
aspects of constructing a numerical solution. It is imperative for engineers using numerical approximation
schemes to understand that the computer programs generally used are deterministic: they will construct
a numerical solution to the problem and will generate results, regardless of whether the physical solution
actually exists. One of the most important components of the practical use of computational approxi
mations such as ﬁniteelement models is the veriﬁcation that the solution obtained actually provides a
reasonable representation of the physical reality. There are a number of important problems that arise
in mechanical engineering practice that are not well posed, and it is important for the engineer to
recognize symptoms of this sort of mathematical pathology.
Existence of a solution is often guaranteed by the underlying physics of the problem. Most practical
stress analyses model wellposed physical problems whose analogous mathematical existence is estab
lished by appropriate mechanics theorems. For example, any linearelastic stress analysis of a compress
ible solid body can be shown to possess at least one solution. Furthermore, if the elastic body is
constrained to prevent rigidbody translations and rotations, those same theorems insure that the solution
is unique. As long as the engineer uses appropriately convergent computational models (i.e., ones that
can be shown to be capable of getting arbitrarily close to exact results in the limit as the discretization
is reﬁned), then the unique solution constructed on the computer will represent an appropriate approx
imation to the unique physical problem being modeled. Analogous existence and uniqueness theorems
can be found for a wide variety of problems commonly encountered in mechanical engineering practice.
There are many instances in which the physical problem is not well posed. One important example
is when a stress analysis is performed on a problem that is not constrained to prevent rigidbody
translations and/or rotations. In this case (which commonly arises during the modeling of vehicles and
aircraft) the computational solution obtained will generally represent the “exact” static solution super
imposed onto a large rigid body displacement. Depending upon the precision of the computer used
(among other details), the computed stresses and strains may be accurate, or they may be contaminated
due to truncation errors resulting from the static displacements being overwhelmed by the computed
rigidbody motion that is superimposed upon the desired static solution. Proper attention to detail during
the modeling process, such as constraining the solution to prevent unwanted rigid body displacement,
will generally prevent this class of solvability pathologies from occurring.
Other more complex solvability concerns commonly arise in mechanical engineering problems where
there is an underlying constraint applied to components of the solution ﬁeld. Problems such as incom
pressible elasticity (where the volume of the mechanical body is invariant under deformation), incom
pressible ﬂow (where the conservation of mass implies a “continuity” constraint on the velocity ﬁeld),
or electromagnetic ﬁeld applications (where the magnetic ﬁeld must be divergencefree) all possess
constraints that can lead to serious solvability difﬁculties during the computational approximation
process. In incompressible elasticity (the other mentioned cases admit similar resolutions), two particular
pathologies present themselves: if there are no prescribed displacement constraints on the problem, then
a solution will exist, but it will not be unique. In this case, the resulting computational approximation
will exhibit rigid body motion, and the underlying stress analysis may or may not be accurate, depending
upon the precision of the computer and the magnitude of the computed rigidbody motion. On the other
hand, if the entire boundary of the incompressible body is subject to a constrained displacement ﬁeld,
then either the overall prescribed displacement of the boundary will satisfy a global incompressibility
condition (in which case the solution will exist, the computed displacements will be unique, but the
associated stresses may be suspect), or the global incompressibility condition is not satisﬁed (in which
case there is no feasible solution to the underlying physical problem, so the computed solution will be
completely spurious and should be ignored).
Because of the difﬁculty in ascertaining a priori whether solvability considerations are germane to
the physical problem being modeled, alternative schemes are often desirable for verifying that the
computed solution actually represents a reasonable approximation to the physical problem being mod
© 1999 by CRC Press LLC
1544
Section 15
eled. One particularly useful computational scheme for verifying solution quality involves the application
of computer graphics and visualization to display solution behavior (e.g., stresses and strains) for
interactive interpretation of the results by the engineer. Veriﬁcation of input and output via graphical
means involves the development and use of graphical pre and postprocessors (respectively) designed
to permit interactive review of the solution behavior. Highquality interactive pre and postprocessors
for use with a particular computational mechanics application are very desirable characteristics and
should be given due consideration during the selection of CAE software for use in mechanical engineering
practice. When nonlinear problems (with their accompanying solvability pathologies) are encountered,
use of interactive graphics for solution veriﬁcation is often required to insure the reliability of the
computed nonlinear solution.
Convergence, Stability, and Consistency
In any numerical method, the primary issue that must be addressed is that of convergence. A convergent
method is one that guarantees that a reﬁnement of the discretization will produce generally more accurate
results. Ultimately, as the discretization mesh size decreases, the exact solution can be approximated to
an arbitrarily small tolerance; as the size of the discretization measure decreases, the answers should
converge to the correct solution. A second criterion is that of accuracy, which is related to that of
convergence. Where convergence addresses the question “does the error go to zero as the discretization
step size decreases?,” accuracy is concerned with “at any particular size step, how close is the approx
imation to the solution?,” and with “at what rate does the error go to zero with step size?.” A convergent
method in which the error tends to zero as the square of the step size (a quadratic convergence rate)
will eventually become more accurate than another scheme in which the error and step size decrease at
the same rate (a linear convergence rate).
Concern especially relevant to timedependent simulations is that of stability: a stable method is one
that guarantees that errors introduced at one step cannot grow with successive steps. If a method is
unstable, even when the errors introduced at each step are small, they can increase exponentially with
time, thus overwhelming the solution. In a stable method this cannot occur, although stability alone does
not imply anything about the size of solution errors that may be introduced at each step, or whether
errors from different times can grow by accumulation. Many numerical methods for timedependent
approximation are only conditionally stable, implying that stability is guaranteed only when the step
size is smaller than some critical time scale dictated by the data of the physical problem and by the
discretization (in mechanics problems, this time scale is often related to the shortest period of vibration
for the structure). Some idea of this critical time scale must be known a priori for a conditionally stable
method to behave in a robust manner. For this reason, the use of unconditionally stable methods is often
preferred, since these methods are stable regardless of the step size (although the actual size of the errors
introduced at each step may still be large).
Another important issue in numerical approximations for differential equations is consistency. A
consistent discrete approximation is one that approaches the underlying continuous operator as the size
of the discretization tends to zero. All standard ﬁnitedifference operators (and their ﬁniteelement
relatives used for timedependent approximations) are consistent, because as the size h of the discreti
zation parameter tends to zero, the appropriate derivative is recovered. Inconsistent discretization schemes
are rarely (if ever) encountered in practice.
The convergence and stability characteristics of a numerical method are not independent: they are
related by the Lax Equivalence Theorem, which is alternatively termed “The Fundamental Theorem of
Numerical Analysis.” In simple terms, the Lax Equivalence Theorem states that convergence (which is
the desired property, but one which is often difﬁcult to demonstrate directly) is equivalent to the
combination of consistency and stability. Because consistency and stability are relatively easy to deter
mine, the task of ﬁnding convergent approximations is often replaced by that of searching for schemes
that are simultaneously consistent and stable.
© 1999 by CRC Press LLC
ComputerAided Engineering
1545
Computational Complexity
Computational complexity is another important characteristic of a numerical scheme. The complexity
of an algorithm is measured in terms of the asymptotic rate of growth of computational effort required
to perform the algorithm. For example, standard schemes (such as factorization or Gauss Elimination)
for solving a full linear system of equations with N rows and columns require computational effort that
grows as the cube of N; these algorithms thus possess a cubic rate of growth of effort. (Note that standard
schemes such as Gauss Elimination also involve terms that grow as the square of N, or linearly with N:
as N becomes asymptotically large, these latter terms diminish in size relative to the cube of N, so the
algorithm is characterized by the cubic term which ultimately dominates the growth of effort.) Many
(or most) standard numerical schemes exhibit some form of polynomial computational complexity, and
for large problems, selecting the algorithm with the lowest polynomial exponent (i.e., the slowest
asymptotic rate of growth) is generally a good idea.
Many common algorithms encountered in engineering handbooks are not suitable for largescale
engineering computation because their computational realizations exhibit prohibitively large growth
rates. For example, many recursive schemes, such as Cramer’s rule for ﬁnding the solution of a linear
system of equations via recursive evaluation of various matrix determinants, exhibit rates of growth that
are larger than any polynomial measure. Cramer’s rule possesses a factorial rate of growth of compu
tational effort (i.e., the effort grows as N!), and thus should be avoided completely for N larger than
ten. When faced with implementing or using a computational scheme such as this, the practical engineer
should consult appropriate references in order to determine whether alternative simpler algorithms are
available — in the case of Cramer’s rule, it is easy to solve a linear system (or evaluate a determinant)
using algorithms that grow cubically, and for large N, there is a vast difference in effort between these
latter schemes and a naive implementation of Cramer’s rule, as shown in the Table 15.3.1 (note that the
values of N presented in the table are extremely small by the standards of typical computational
approximations, and hence the relative gain in using lowerorder complexity schemes is even more
important than the results in the table might indicate).
TABLE 15.3.1 Polynomial and Factorial Growth Rates
N 
N ^{2} 
N ^{3} 
N! 

2 
4 
8 
2 

5 
25 
125 
120 


1,000 
3,628,800 

400 8,000 2.433 × 


125,000 
3.041 × 10 ^{6}^{4} 
In general, the choice of algorithms for computational simulation of mechanics problems should be
restricted to methods that are both convergent and at least conditionally stable. In addition, it should be
clear that an unconditionally stable method, especially if it has a higherorder convergence rate, is to be
desired. Finally, one normally prefers those methods that exhibit the slowest asymptotic rate of growth
of computational effort, especially when large problems are to be solved.
FiniteElement Approximations in Mechanical Engineering
Finiteelement models are among the most efﬁcient, general, and accurate computational approximation
methods available in engineering. Many of the attractive characteristics of ﬁniteelement computational
models arise from a seemingly unlikely source: instead of representing the mathematical statement of
the underlying mechanics as systems of differential equations, ﬁniteelement models are motivated by
considering instead equivalent integral formulations, e.g., the basic equations of equilibrium, compati
bility, and stressstrain can be replaced by equivalent integral energy formulations such as the Principle
© 1999 by CRC Press LLC
1546
Section 15
of Virtual Work or the Theorem of Minimum Potential Energy. These latter integral principles form the
basis for ﬁniteelement computational approximations.
For example, the differential equations for equilibrium of a solid body can be replaced by an integral
formulation: the principle of virtual work of elementary mechanics is one particular wellknown example
of this equivalence. Once identiﬁed, the equivalent integral formulation is considerably simpler than the
differential form, and this simplicity is even more apparent when mechanics problems are generalized
to include such practical effects as point loads, arbitrary geometric constraints, and heterogeneous or
anisotropic material properties. Under these more interesting conditions (i.e., in situations that are likely
to arise in mechanical engineering practice), the differential equations of mechanics become nearly
impossible to write, as the standard calculus symbolism is barely sufﬁcient to express the range of
intractable differential behavior. However, the integral formulation requires only marginal modiﬁcations
under these more general conditions, and this simpler integral approach also leads to appropriate elegant
and general computational approximation schemes.
In addition to providing a simpler means to express the fundamental mathematical relations of
mechanics, the integral foundation of ﬁniteelement models also provides other important features. One
important aspect of ﬁniteelement models is their computational efﬁciency; another is that strong and
general convergence proofs can be cited for large classes of ﬁniteelement models, obviating the need
for application of the more complicated Lax Equivalence Theorem to prove convergence and estimate
accuracy. Perhaps the most important theoretical characteristic of these integral calculus models is that
their general formulation provides a uniﬁed computational framework that includes many other practical
schemes (such as ﬁnitedifference models) as special cases of a general integral theory of computational
mechanics. Therefore, careful study of the mathematical underpinnings of ﬁniteelement modeling also
provides considerable insight into such diverse alternative computational schemes as ﬁnitedifference
models and boundaryelement methods.
Overview of FiniteElement Models
Finiteelement models are most commonly utilized in computational solid mechanics, where they have
been used successfully on a very general range of practical problems. Integral formulations for solid
mechanics (such as the Principle of Virtual Work) are wellestablished general results, and it is straight
forward to develop generic ﬁniteelement computer models from these fundamental integral mechanics
formulations. Since many problems in other branches of mechanics (such as Stokes Flow in ﬂuid
mechanics, which is a direct mathematical analog of the solid mechanical problem of deformation of
an incompressible elastic medium) are closely related to standard problems of solid mechanics, ﬁnite
element models are rapidly gaining favor in many other branches of mechanics as well. In general, any
physical problem that can be expressed in terms of integral energy formulations is a natural candidate
for ﬁniteelement approximation.
The most common application of ﬁniteelement models is in computational solid mechanics. In this
area, ﬁniteelement models can be made arbitrarily accurate for a wide range of practical problems.
Standard stress analysis problems involving moderate deformations of wellcharacterized materials (such
as metals) are generally easy to solve using ﬁniteelement technology, and static or timedependent
simulations of these mechanical systems are routinely performed in everyday mechanical engineering
practice. More complex problems (such as computational ﬂuid mechanics, coupled problems, or elec
tromagnetic simulations) can readily be solved using ﬁniteelement techniques, though the accuracy of
the solution in these areas is often limited, not by the ﬁniteelement technology available, but by
difﬁculties in determining accurate characterizations for the materials used. For example, in many
biomechanical problems, the model for simulating the stressstrain response of the biological material
may contain uncertainties on the order of many percent; in cases such as these, it is not the quality of
the ﬁniteelement application that limits the accuracy of the solution, but instead the inherent uncertainty
in dealing with realistic biological materials.
There are still many practical limitations to ﬁniteelement modeling in engineering practice. Some of
these problems arise from inherent difﬁculties in developing generic ﬁniteelement computer programs,
© 1999 by CRC Press LLC
ComputerAided Engineering
1547
while others arise from the same generality that makes ﬁniteelement models so attractive as computa
tional approximations. Examples of the former include computer programs that do not contain completely
robust modern ﬁniteelement models for plates and shells, while examples of the latter include ﬁnite
element applications that incorporate the latest computational technology but are so difﬁcult to use that
inaccuracies result from gross errors in preparing input data. Finally, many practical limitations of ﬁnite
element modeling are due to theoretical difﬁculties inherent in the mathematical formulations of mechan
ics, and these last pathologies are the most difﬁcult to remove (as well as being problematic for any
computational scheme and not therefore particular to ﬁniteelement techniques).
Classiﬁcation of FiniteElement Models
There are many classiﬁcations possible in computational mechanics, and so choosing an appropriate
classiﬁcation scheme for any general method such as ﬁniteelement modeling is necessarily an ambiguous
task. The most common classiﬁcation scheme for categorizing ﬁniteelement models is based on con
sideration of the physical meaning of the ﬁniteelement solution, and a simpliﬁed version of this scheme
can be described by the following list:
• If kinematical solution unknowns (such as displacement or velocity) are determined ﬁrst, then
the model is termed a displacementbased ﬁniteelement model.
• If statical ﬁniteelement solution parameters are the primary unknowns determined during the
computational solution process, then the model is termed a stressbased ﬁniteelement model.
• If a combination of kinematical and statical solution unknowns are determined simultaneously,
then the computational scheme is called a mixed ﬁniteelement model.
Displacementbased ﬁniteelement models are the most common schemes used at present, and most
commercialquality ﬁniteelement applications contain extensive element libraries consisting primarily
of displacementbased families. In a displacementbased model, the analyst creates a ﬁniteelement mesh
by subdividing the region of interest into nodes and elements, and the program calculates the solution
in terms of nodal displacements (or velocities, in the case of ﬂow problems). Once the displacements
have been determined, the unknowns in the secondary solution (such as stress and strain) are derived
from the ﬁniteelement displacement ﬁeld by using appropriate compatibility and stressstrain relations.
Some common twodimensional ﬁnite elements used for displacementbased formulations are catalogued
in Figure 15.3.2. The elements shown are successfully used for common problems in stress analysis,
simple ﬂuid ﬂow, and thermal analyses, and their generalization to threedimensional problems is
straightforward and computationally efﬁcient.
Four Node Bilinear Lagrange Quadrilateral
Eight Node Biquadratic Serendipity Quadrilateral
Nine Node Biquadratic Lagrange Quadrilateral
FIGURE 15.3.2 Common twodimensional ﬁnite elements.
© 1999 by CRC Press LLC
1548
Section 15
Stressbased ﬁniteelement schemes are much more rare than displacement models, although stress
based ﬁnite elements have some attractive theoretical qualities (such as more direct calculation of stresses
and strains, which are the most important currency in practical stress analysis). Many practical stress
based ﬁniteelement methods are recast into a form involving determination of nodal approximations
for displacement, so that these alternative formulations can be easily integrated into existing displace
mentbased ﬁniteelement programs.
Mixed ﬁniteelement schemes commonly arise in problems involving constraints, such as electromag
netics, incompressible deformation or ﬂow, and (in some cases) solid mechanics problems characterized
by substantial bending deformation. When using a mixed computational scheme, considerable care must
be taken to insure that the resulting approximation is convergent: these subtle mathematical solvability
conditions are best approached by a practicing engineer by insuring that the program used automatically
applies appropriate consistency conditions (which are commonly presented in the literature for each
given ﬁeld of practice). In short, the best ways to insure that reasonable results are obtained from mixed
models are to:
• Know which problems commonly result in mixed formulations.
• Use ﬁniteelement computer programs that have already been tested and veriﬁed for use on the
class of problems of interest.
• Take advantage of auxiliary software (such as graphical visualization applications) to verify the
input and output data for all problems.
Note that the potential convergence problems that haunt some mixed formulations in ﬁniteelement
modeling are generally caused by the underlying mathematical model used to represent the engineering
system. In these cases, any computational method used may exhibit solution pathologies, and, in fact,
the ﬁniteelement model (while still containing the pathology) is often the best approach for identifying
and rectifying the underlying mathematical problem (this result follows from the fact that the integral
framework underlying ﬁniteelement approximation permits a more general study of convergence than
do competing differential frameworks utilized in ﬁnitedifference and ﬁnitevolume models).
Finiteelement formulations can also be classiﬁed into two particular ﬂavors of development: Rayleigh
Ritz and Galerkin. RayleighRitz ﬁniteelement models are developed by applying theorems of minimum
potential energy (or some similar integral extremization measure). Galerkin models arise from socalled
weak statements of boundaryvalue problems and are simultaneously more complicated to derive and
substantially more general in scope. For problems (such as standard linear stressanalysis problems)
where both minimum and equivalent weak statements of the problem exist, the resulting RayleighRitz
and Galerkin ﬁniteelement models will yield identical results. For problems where no extremization
principle exists (such as highReynolds number ﬂuid ﬂow), Galerkin ﬁniteelement models (and their
relatives) can still be used in practice.
Computational Characteristics of FiniteElement Models
Finiteelement models are widely used in mechanical engineering precisely because of their computa
tional efﬁciency. A brief enumeration of the computational characteristics of ﬁniteelement models
highlights many reasons why they form such an effective family of computational approximation
techniques.
• Finiteelement models tend to result in computational algorithms that are readily understood,
easily implemented, and exhibit wellknown computational advantages. For example, ﬁnite
element equation sets tend to be sparse (i.e., to have a relatively small percentage of nonzero
terms in the coefﬁcient matrix, with these nonzero entries in a welldeﬁned pattern that can be
utilized to achieve efﬁcient computational implementation of required matrix operations) and
preserve physical characteristics (such as symmetry and structural stability) that are readily
exploited by common matrix algebra schemes.
© 1999 by CRC Press LLC
ComputerAided Engineering
1549
• Finiteelement models are readily shown to possess optimal accuracy characteristics for a sub
stantial portion of problems commonly encountered in engineering practice. For example, for
most classes of practical stress analysis, ﬁniteelement solution schemes can be shown to yield
the most accurate results (measured in terms of minimizing the energy of the error) of any standard
numerical approximation scheme, including competing ﬁnitedifference and ﬁnitevolume meth
ods. In contrast to these latter discretization schemes, ﬁniteelement optimal convergence rates
are preserved even in the important case of irregular or unstructured meshes. The practical effect
of this optimality is that there is often little or no incentive to use any other technique for solution
of many computational mechanics problems encountered in the mechanical engineering profes
sion.
• Many ﬁniteelement calculations are inherently scalable, in that they can be readily implemented
in a manner amenable to parallel computer architectures. The practical result of this scalability
property is that current advances in multiprocessor computer architectures are easily leveraged
to gain substantial improvements in ﬁniteelement program performance with little additional
effort required by either users or programmers.
• Finiteelement results are deﬁned everywhere in the problem domain, and these results include
derived parameters such as stress and strain. Because these solution components are deﬁned
everywhere, it is very easy to apply additional computer technology (such as integrated graphical
postprocessors) to verify and interpret the results of the ﬁniteelement analysis. It is commonly
(and incorrectly!) believed that all numerical methods provide computational solutions only at a
ﬁnite number of points in the domain, but this observation is erroneous in the case of ﬁnite
element models. The global deﬁnition of the ﬁniteelement solution is of considerable utility
toward the important goal of evaluating the convergence of ﬁniteelement models. In addition,
the derived secondary solution parameters are also convergent, so that the optimal accuracy
characteristics of ﬁniteelement models generally apply to both primary (e.g., displacement) and
secondary (e.g., stress) solution unknowns. This latter advantage is much harder to prove for
many competing numerical methods such as ﬁnitedifference and ﬁnitevolume schemes.
• It is relatively easy to guarantee the convergence of common ﬁniteelement solution schemes,
and this characteristic, when combined with the mathematical optimality of the ﬁniteelement
solution, facilitates trust in the computed ﬁniteelement results. The convergence properties of
ﬁniteelement models are cast in an integral (as opposed to a differential) form, which results in
their applicability toward a wide spectrum of engineering problems that contain mathematical
pathologies (such as heterogeneous materials, point loads, and complex boundary conditions) that
compromise the convergence statements for models (such as ﬁnitedifference schemes) that would
otherwise be competitive with ﬁniteelement models in terms of computational effort.
• For some problems, including those involving substantial convective nonlinearities due to high
speed ﬂuid ﬂow, the optimality characteristics of standard ﬁniteelement models can no longer
be guaranteed, and an alternative integral convergence formulation must be sought. In the setting
of ﬁniteelement models for ﬂow, this convergence framework is termed weak convergence. It is
important to understand that “weak” in this sense is not a pejorative term, but instead refers to
the topological structure of the solution space for these ﬂow problems. In fact, weak formulations
for problems in science and engineering are useful representations for many practical cases; for
example, in the study of statics, the principle of virtual work is a weak formulation of the equations
of equilibrium of a rigid body. The weak integral convergence framework for Galerkin ﬁnite
element models is an attractive alternative to analogous (but generally more complex) convergence
results used in ﬁnitedifference modeling for ﬂuid problems.
In simple terms, ﬁniteelement models are very attractive candidates for computational approximation
efforts. Under very general conditions, they can be demonstrated to be extremely accurate, computa
tionally efﬁcient, and amenable to improvements in computer hardware and software technology. Because
© 1999 by CRC Press LLC
1550
Section 15
of these computational advantages, ﬁniteelement models have become popular in virtually all branches
of computational mechanics.
Advantages and Disadvantages of FiniteElement Models
Like all computer approximation schemes, ﬁniteelement modeling has characteristic advantages and
disadvantages, and the effective use of ﬁniteelement technology requires at least an introductory
understanding of each. Besides the computational advantages of efﬁciency and optimality presented
above, most ﬁniteelement schemes include other practical advantages. Foremost among the advantages
are the characteristics of generality of function and ﬂexibility of modeling. The primary disadvantages
occur when naive ﬁniteelement implementations are applied to mathematically illbehaved problems.
Finiteelement models can be cast into general computer applications that permit a tremendous variety
of problems to be solved within the scope of a single program. Some commercialquality ﬁniteelement
programs permit the analysis of static and timedependent problems in solid mechanics, ﬂuid mechanics,
and heat conduction within one monolithic computer application. In contrast, alternative computer
analysis techniques often place substantial constraints on the range of problems that can be solved, and
these limitations require the practicing engineer to be familiar with a variety of different software
packages instead of an inclusive general analysis application.
Most ﬁniteelement packages are very permissive in the modeling of complexities that regularly occur
in engineering practice. These complicating factors include material discontinuities (which are common
in composite applications), material anisotropies (implementing more general material response within
typical ﬁniteelement applications is generally a simple programming task) and complex boundary
conditions (such as combinations of traction and displacement on boundaries not readily aligned with
the coordinate directions). Because most commercial ﬁniteelement applications have very general
features, a common source of analysis errors arises from gross mistakes in creating input data (such as
specifying a different material model or an incorrect boundary condition). One of the easiest ways to
identify gross modeling errors is to make use of solution veriﬁcation tools (such as integrated graphical
pre and postprocessors) whenever possible. Virtually all highquality commercial ﬁniteelement pack
ages incorporate integrated visualization tools, and utilizing these tools to verify input data and output
results is always a good idea.
There are also more complicated problems that can arise in the course of ﬁniteelement modeling:
the most common pathologies arise from analyses incorporating mixed ﬁniteelement models. Guaran
teeing the convergence of mixed ﬁniteelement models is a much more difﬁcult mathematical problem
than the analogous proof of convergence for displacementbased models, and it is possible to get
unreliable results from naive use of mixed ﬁniteelement models. While most modern commercial ﬁnite
element programs will largely guard against the possibility of constructing inherently poor ﬁniteelement
approximations, there are older or less robust ﬁniteelement applications available that do not incorporate
completely dependable ﬁniteelement technologies. Therefore, it is important to identify potential prob
lem areas for ﬁniteelement modeling. The most common sources of difﬁculty are presented below.
Incompressible Problems. Problems where volume is preserved commonly occur in mechanical engi
neering practice, but errors arising from inaccurate ﬁniteelement modeling techniques are often readily
identiﬁed and corrected. Incompressible solid elastic materials include rubber and solid propellants, and
models for inelastic response of metals also require incompressible or nearincompressible plastic
behavior. The most common artifact of poor modeling of incompressibility is known as mesh locking,
and this aptly named phenomenon is characterized by grossly underestimated displacements. The easiest
way to test for potential incompressibility problems is to solve a suite of simple case studies using small
numbers of elements, as shown in Figure 15.3.3. If the ﬁniteelement mesh locks in these test examples,
then either different elements or a different ﬁniteelement application should be considered, as adding
more elements to the mesh does not generally improve the results in this case. It is easy to accommodate
incompressibility in the setting of standard ﬁniteelement libraries. Figure 15.3.4 shows several two
dimensional elements that are accurate when used in an incompressible elasticity setting. Modern
© 1999 by CRC Press LLC
ComputerAided Engineering
1551
Test Problem
fixed
fixed
Quadrilateral Test Meshes
FIGURE 15.3.3 Test problem suite for incompressibility.
FIGURE 15.3.4 Incompressible elasticity ﬁnite elements.
textbooks on ﬁniteelement theory (e.g., Hughes, 1987 or Zienkiewicz, 1991) generally provide guide
lines on choice of element for incompressible problems, and the user’s manuals for many commercial
ﬁniteelement packages offer similar preventative advice.
Bending Deformation.
Problems involving beams, plates, and shells may exhibit solution pathologies
similar to those found in incompressible elasticity. In these problems, onedimensional beam elements
or twodimensional plate elements are loaded in directions normal to the element’s reference surface,
and naive coding practices for these cases may result in locking of the ﬁniteelement mesh, with attendant
underprediction of the displacement ﬁeld. Depending upon the characteristics of the particular element
and the stability of the geometric boundary constraints, mesh locking errors may instead be replaced by
wildly unstable solution response, with the displacement ﬁeld oscillating uncontrollably over adjacent
elements. In practice, it is very easy to avoid both of these pathologies by incorporating simple additional
programming effort, so this problem is rarely encountered when commercial ﬁniteelement packages
are used. It may be important when the ﬁniteelement application is a local or unsupported product, and
© 1999 by CRC Press LLC
1552
Section 15
FIGURE 15.3.5 Singleelement ﬂexure test problems.
in these cases, appropriate care should be taken to verify the solution. If graphical solution visualization
tools are available, they should be used in these cases. If such tools are not available, then the computed
results should be compared to simpliﬁed problems that can be solved analytically using engineering
beam theory analogies or closedform plate models. One simple test case for naive ﬁniteelement coding
practices is shown below (see Hughes, 1987); if this simple (but marginally stable) structure is analyzed
and gives excessively large or oscillating displacements, then a better ﬁniteelement model (or applica
tion) should be sought.
Lack of Curvature Deformation in LowOrder Elements. Loworder linear, bilinear, and trilinear ele
ments (such as fournode bilinear quadrilaterals used in plane stress and plane strain applications) are
commonly utilized in ﬁniteelement packages because they are easy to implement and because many
software tools exist for creating two and threedimensional meshes for such loworder elements. Unfor
tunately, there are common circumstances when these loworder elements give inaccurate and unconser
vative results. One such example is shown in Figure 15.3.5. Many simple ﬁniteelement packages will
provide accurate answers for the onedimensional problem, but will substantially underpredict the two
and threedimensional displacements. Unlike the meshlocking pathology encountered in incompressible
cases, the underprediction of displacements from loworder elasticity elements eventually disappears as
more elements are used when the mesh is reﬁned. It is easy to remedy this problem in general by choosing
appropriate continuum elements, and many commercial codes provide appropriate loworder elements
automatically. Problems due to poorly implemented loworder elements are best avoided by solving
simple oneelement models ﬁrst to determine whether the particular element to be used exhibits these
errors, and if this is found to be the case, the analyst can either choose a different type of element (or a
better ﬁniteelement package!) or take pains to insure that the mesh is appropriately reﬁned.
It is important to recognize that many of the problems that arise when using ﬁniteelement models
for these more difﬁcult cases are not completely due to the particular ﬁniteelement model used, but
may arise from pathologies in the underlying mathematical problem statement. In these cases, any
computational approximation scheme may be susceptible to errors, and so care should be used in
evaluating any computational results.
Test Problem Suites for FiniteElement Software
It is easy to avoid most errors in ﬁniteelement analysis, by ﬁrst insuring that no mathematical pathologies
are present in the problem or in the elements to be utilized and then by guarding against gross modeling
errors in preparation of the input data. The best way to guard against both forms of errors is to use a
suite of simpler problems as a “warmup” to the more complex problems that must be solved. The
general idea here is to solve a series of problems of increasing complexity until the ﬁnal member of the
series (namely, the complex problem to be modeled accurately) is obtained. The simpler members of
the suite of problems generally involve simpliﬁcations in geometry, in material response, and in scale
of deformation. For example, if a complicated problem involving largedeformation behavior of an
inelastic material is to be analyzed, simpler problems using smalldeformation theories, elastic material
© 1999 by CRC Press LLC
ComputerAided Engineering
1553
models, and simpliﬁed problem geometry should be solved and carefully veriﬁed. These simpler problems
can then be used to verify the response of the complex problem, and this approach is of considerable
help in avoiding spectacular engineering blunders.
Another role of a problem suite arises when different competing commercial ﬁniteelement packages
are to be evaluated. Most commercial ﬁniteelement packages are speciﬁcally oriented toward different
engineering markets, and their respective feature sets depend upon the needs of those particular engi
neering disciplines. When evaluating commercial ﬁniteelement software for potential purchase, a wide
selection of representative problems should be analyzed and veriﬁed, and two excellent sources of test
problems are the pathological examples of the last section (which will provide insight into the overall
quality of the commercial ﬁniteelement application) and any suite of test cases used to verify more
complex problems with a competitive program (which will provide information on how well the proposed
application provides support for the particular class of problem encountered in local practice). Problems
encountered with either type of test problems should be appropriately investigated before purchase of
new ﬁniteelement software.
FiniteDifference Approximations in Mechanics
Finitedifference models include many of the ﬁrst successful examples of largescale computer simulation
for mechanical engineering systems. Finitedifference modeling techniques were originally developed
for human calculation efforts, and the history of ﬁnitedifference calculations is considerably longer than
the history of ﬁniteelement modeling. Once automatic computation devices replaced humans for low
level computing tasks, many of the existing ﬁnitedifference schemes were automated, and these simple
numerical techniques opened up much of engineering analysis to computer simulation methods. Over
time, improved ﬁnitedifference approximations (including ones that would be prohibitively difﬁcult for
human calculation) resulted, and the range of problems solvable by ﬁnitedifference models became
more diverse.
Throughout the 1970s and 1980s, a natural division developed between ﬁnitedifference and ﬁnite
element models in computational mechanics. Finitedifference models were utilized primarily for a wide
variety of ﬂow problems, and ﬁniteelement approximations were used for modeling the mechanical
response of solids. While many ﬁniteelement approximations were proposed for ﬂuid problems such
as the NavierStokes equations, in practice these ﬁrstgeneration ﬁniteelement models generally per
formed poorly relative to more advanced ﬁnitedifference schemes. The poor performance of naive ﬁnite
element models relative to carefully optimized ﬁnitedifference approximations was widely (but incor
rectly) accepted in the mechanical engineering profession as evidence that ﬂuid problems were best
solved by ﬁnitedifference methods, even as ﬁniteelement technology gained nearexclusive use in such
ﬁelds as stress analysis.
In fact, the problems associated with earlygeneration ﬁniteelement models in ﬂuids were due
primarily to rampant overgeneralization of insight gained in solid mechanics instead of any inherent
limitations of ﬁniteelement technology applied to ﬂuid mechanics problems. Similar problems developed
in the early stages of ﬁnitedifference modeling; for example, one of the ﬁrst ﬁnitedifference references
published by Richardson used theoretically attractive but practically worthless difference schemes and
resulted in a completely unusable algorithm (see Richardson, 1910 or Ames, 1977 for details of this
interesting historical development). During the 1980s and 1990s, a better understanding emerged of how
to utilize ﬁniteelement technology on the relatively more complicated models for ﬂuid behavior, and
there has been an explosion of interest in using ﬁniteelement approximations to replace ﬁnitedifference
schemes in a variety of ﬂuid mechanics settings. While ﬁnitedifference methods (and especially carefully
optimized applications found in certain difﬁcult and narrow specialties in ﬂuid modeling) continue to
be widely used in ﬂuid mechanics and electromagnetic simulations, the range of mechanics problems
thought to be resistant to ﬁniteelement solution approaches is rapidly diminishing.
Finally, a word regarding nomenclature is warranted. Originally, ﬁnitedifference models were devel
oped using regular grids of equally spaced points, with the solution approximation computed at the
© 1999 by CRC Press LLC
1554
Section 15
vertices of this structured lattice. As increasingly complicated problems were solved with ﬁnitedifference
technology, it became desirable to be able to model more complex problems involving variable material
properties, singular data (such as point sources), and irregular geometries. In order to permit these more
general problems to be solved, ﬁnitedifference modeling was generalized to include various averaged
(i.e., integrated) schemes that augmented classical vertexoriented ﬁnitedifference methods to include
cellcentered schemes where appropriate integral averaging of the underlying differential equation is
utilized to permit modeling discontinuous or singular data. Ultimately, these various improvements led
to the development of ﬁnitevolume schemes, which are a general family of integrated ﬁnitedifference
approximations that preserve the relative simplicity of ﬁnitedifference equations, while casting the
underlying theory in a form more amenable to modeling complicated problems. Finitevolume methods
are discussed in a later section of this chapter, but the general characteristics given below apply to the
entire ﬁnitedifference/ﬁnite volume family of approximate solution techniques. Because of the wide
spread application of these integral generalizations of classical vertexbased ﬁnitedifference schemes,
it has become commonplace to use the term “ﬁnitedifference methods” collectively to include all the
members of this computational family, including vertexcentered schemes, cellaveraged methods, and
ﬁnitevolume approximations.
Overview of FiniteDifference Models
Finitedifference methods arise from the combination of two components:
• Differential equations of mathematical physics
• Replacement of differential operators with discrete difference approximations
Differential statements of the equations of mathematical physics are well known, as most of engi
neering and physics instruction is provided in this form. For example, the familiar relation “
f
= m
a
”
is a vector differential equation relating the components of the applied force to the differential temporal
rate of change of momentum. The analogous integral statement of this fundamental relation (which is
used to motivate ﬁniteelement modeling instead of ﬁnitedifference approximation) is probably more
useful in computational practice, but it is deﬁnitely less well known than its differential brethren. Similar
instances occur in every branch of mechanics, as the differential equations for engineering analysis are
generally introduced ﬁrst, with their equivalent integral statement presented later, or not at all. Because
of this widespread knowledge of the differential form of standard equations for modeling physical
systems, the supply of differential equations that can be converted to analogous ﬁnitedifference schemes
is essentially inexhaustible.
The computational component of ﬁnitedifference modeling arises from the replacement of the con
tinuous differential operators with approximations based on discrete difference relations. The gridwork
of points where the discrete difference approximation is calculated is termed the ﬁnitedifference grid,
and the collection of individual grid points used to approximate the differential operator is called (among
other terms) the ﬁnitedifference molecule. Sample ﬁnitedifference molecules for common differential
operators are diagrammed in Figure 15.3.6. One of the most obvious characteristics of the molecules
represented in Figure 15.3.6 is that the discrete set of points where the ﬁnitedifference approximation
is computed is very structured, with each grid point occurring in a regularly spaced rectangular lattice
of solution values.
The fundamental reason for this regular spacing has to do with necessary conditions for optimal
convergence rates for the ﬁnitedifference solution. This regular spacing of points provides simulta
neously the greatest incentive and the biggest constraint toward practical use of ﬁnitedifference methods.
Performing ﬁnitedifference calculations on a regular grid provides desirable fast convergence rates on
one hand, but the regularity in the placement of solution sampling points often forces the analyst into
a ﬁxed grid structure that is difﬁcult to adapt to nonregular domains without sacriﬁcing optimal rates of
convergence. For some problems, it is possible to perform coordinate transformations of the entire
physical (i.e., problem) domain onto a regularized computational domain in order to gain simultaneous
high convergence rate and geometric modeling ﬂexibility. Unfortunately, these requisite coordinate
© 1999 by CRC Press LLC
ComputerAided Engineering
1555
FIGURE 15.3.6 Sample ﬁnitedifference molecules.
transformations may be difﬁcult to determine for sufﬁciently complicated problem geometries. This
limitation should be contrasted with the geometric ﬂexibility inherent in analogous ﬁniteelement models,
where optimal rates of convergence are readily realized even in the presence of irregular or unstructured
ﬁniteelement meshes.
A geometric motivation for the improved performance of regularly spaced ﬁnitedifference molecules
can be seen in Figure 15.3.7. Here a representative function has been drawn, along with its tangent
derivative and two estimates of the derivative’s slope given by standard secant formulas from elementary
calculus. In particular, the forward and centereddifference approximations for the slope of the tangent
line can be visualized by passing lines through the points [x, f(x)] and [x + h, f(x + h)] for the forward
difference approximation, and [x – h, f(x – h)] and [x + h, f(x + h)] for the centereddifference estimate.
(Note that it is also possible to deﬁne a backwarddifference slope estimate by considering the secant
line passing through the function at the points x and (x – h). In problems involving spatial derivatives,
this backwarddifference estimate has numerical properties that are generally indistinguishable from the
forwarddifference approximation, but in the setting of timedependent derivatives, there are considerable
differences between forward and backwarddifference schemes.)
Centered
FIGURE 15.3.7 Finitedifference formulas and geometry.
It is apparent from the ﬁgure that the centereddifference approximation for the slope is substantially
better than that obtained from the forward difference. While it may appear from this particular example
that the improved quality of the centereddifference estimate is due to the particular shape of the function
used in this case, in fact these results are very general and represent a common observation encountered
in ﬁnitedifference practice: centereddifference formula are generally optimal in providing the highest
rate of convergence relative to the number of points required to evaluate the difference approximation.
While this observation can be motivated from a variety of viewpoints (the most common example for
purpose of development of ﬁnitedifference methods is the use of Taylor Series expansions), it is
particularly instructive to perform some computational experimentation regarding this optimality of
centereddifference models.
© 1999 by CRC Press LLC
1556
Section 15
Consider the following simple FORTRAN program:
This program evaluates forward difference estimates for the derivative of the exponential function at
the point x = 0. The program is easily modiﬁed to provide a centereddifference approximation by adding
an evaluation of exp(x – h). The results of running these two computational experiments are diagrammed
in Figure 15.3.8, where forward and centereddifference results are graphed for two different precisions
of FORTRAN REAL declarations (32bit, which represents a lower limit of quality on ﬂoatingpoint
numeric representation, and 80bit, which represents a highquality ﬂoatingpoint format). Important
features presented in these two graphs are
• In each graph there is a region at the right where the error in replacing the differential operator
with a difference approximation decreases with a characteristic linear behavior on the loglog
plots. In this region, the difference estimates are converging to the exact value of tangent slope,
as might be expected given the deﬁnition of the derivative as the limit of a secant.
• In these linear regions, the centereddifference error decreases with a slope of two, while the
forwarddifference error decreases with unit slope. This implies that the forwarddifference
approximation has a linear rate of convergence, while the centereddifference estimate is con
verging quadratically.
• The size of these convergent regions depends upon the precision used for ﬂoatingpoint calcula
tions. Extendedprecision formats (such as 80bit reals) provide both a larger region of conver
gence and improved accuracy (obtained by being able to use smaller values of the step size h).
• To the left (smaller values of the step size h) of these linear regions, the convergent behavior of
each estimate breaks down: upon passing through the minimum of each curve (which represents
the most accurate estimate that can be obtained for a given precision by using these difference
molecules), the effect of decreasing step size is not to decrease the error, but instead to ultimately
degrade the approximation quality.
• Eventually, the denominator of each difference formula underﬂows (vanishes due to truncation
error) as the values of f(x), f(x + h), and f(x – h) become indistinguishable in terms of their
respective ﬂoatingpoint representations. This implies that the estimate of the slope is computed
as zero, and thus the error eventually tends to unity, which each curve approaches at the left edge
[recall that exp(0) = 1].
This numerical experiment clearly shows the interplay of convergence rate, numerical precision, and
truncation error. The centereddifference formula converges much more rapidly than the forwarddiffer
© 1999 by CRC Press LLC
ComputerAided Engineering
1557
10)
10)
FIGURE 15.3.8 Results of ﬁnitedifference numerical experiment.
ence formula, and there exists an optimal step size for the various difference calculations where increasing
the step size results in larger errors (in agreement with the rate of convergence of the approximation),
and where decreasing the step size results in increased errors (due to the effects of roundoff and
truncation errors in the calculation of the derivative estimate).
Classiﬁcation of FiniteDifference Models
As in the case of ﬁniteelement models, there are many alternative classiﬁcations available for catego
rizing ﬁnitedifference approximations. The ﬁrst relevant classiﬁcation is a geometric one, based on
whether the ﬁnitedifference grid is structured (i.e., possesses a regularly spaced lattice structure) or
unstructured. In order to maintain optimal convergence rates, ﬁnitedifference models must use regular
spacings of grid points. This regularity is easy to maintain when the problem geometry is simple, but
if the natural geometry is complicated, then the regularity of the difference grid will be compromised,
with the potential for an attendant loss of convergence rate. In cases of irregular geometry, unstructured
meshes are used, and if optimal convergence rates are to be realized, then a coordinate mapping from
the actual problem geometry to a regularized computational domain must be constructed.
The problem with using structured grids on irregular or curved domains is diagrammed in Figure
15.3.9. Here a curved boundary is approximated using a loworder linear ﬁniteelement mesh (on the
left of the ﬁgure) and a corresponding ﬁnitedifference/ﬁnite volume scheme (on the right). In order to
capture the effect of boundary curvature, the structured ﬁnitedifference/ﬁnitevolume representation
must approximate the boundary as a stepped pattern of rectangular subdomains. If the curvature is
substantial, or if there is a considerable effect of regularizing the boundary on the physical model (a
common situation in ﬂuid and electromagnetic applications), this imposition of structure on what is
© 1999 by CRC Press LLC
1558
Section 15
FIGURE 15.3.9 Finitedifference modeling of irregular geometry.
really an unstructured physical problem can seriously compromise the quality of the resulting compu
tational approximation. Finiteelement models, in which the presence of unstructured geometries does
not substantially affect the solution quality, are thus more natural candidates for problems involving
irregular boundaries or poorly structured problem domains. In fact, it is easy using higherorder ﬁnite
element approximations (e.g., locally quadratic or cubic interpolants) to approximate the boundary
curvature shown in the ﬁgure to an essentially exact degree.
Another classiﬁcation scheme can be based upon whether the difference formulas used are forward,
backward, or centered. This classiﬁcation is especially appropriate for ﬁnitedifference timestepping
methods used to solve initialvalue problems in engineering and science. In this timedependent setting,
there is a coalescence of ﬁniteelement and ﬁnitedifference approaches, and the classiﬁcation presented
below permits one uniﬁed terminology to be used for both topics. Each class of difference estimate leads
to timemarching discretization schemes that have distinctly different characteristics.
Forward difference schemes are commonly used to produce timestepping methods that are very
efﬁcient in terms of computational effort and memory demand. The important class of explicit time
stepping algorithms arises largely from using forwarddifference approaches: explicit schemes are deﬁned
as those requiring no equation solution effort to advance the solution to the next time step (e.g., where
the coefﬁcient matrix to be solved is diagonal). The primary disadvantage of forwarddifference time
stepping is that these methods are generally only conditionally stable, so that they will converge only
if the time step is relatively small. The use of explicit schemes thus involves a tradeoff between reduced
computational effort at each step, and the attendant requirement of a small time step. Explicit schemes
based on forwarddifference estimates for temporal derivatives are usually selected when the increased
number of steps required is overshadowed by the decrease in the amount of effort required at each step.
In some very large problems (such as complex threedimensional models), explicit schemes are often
used exclusively because of their relatively small demand for memory.
Backward difference schemes are commonly used in timestepping applications where stability of the
solution is especially important. In particular, backwarddifference schemes generally provide numerical
dissipation of highfrequency response, and this characteristic is often desirable in engineering practice.
Many transient problems exhibit a wide range of natural time scales; for example, structural dynamics
problems in aerospace engineering commonly include longperiod vibrations of the entire structure as
well as shortperiod response of individual structural components. One of the characteristics of discret
ization methods, in general, is that they tend to predict lowfrequency behavior very accurately, while
highfrequency response is predicted with considerably less accuracy. Since the highfrequency response
is therefore often inaccurate (or spurious), there is a strong incentive to attenuate its effects, and choosing
backwarddifference temporal schemes is a good way to achieve this end. Backwarddifference formu
lations generally require solution of a system of equations to advance the solution across a time step,
and hence they are termed implicit timestepping methods.
Centereddifference approximations are generally chosen in order to gain optimal convergence rates
for timestepping methods, and centered schemes are thus one of the most common choices for model