Vous êtes sur la page 1sur 104

Mish, K.D. and Mello, J. Computer-Aided EngineeringMechanical Engineering Handbook Ed. Frank Kreith Boca Raton: CRC Press LLC, 1999

Computer-Aided

Engineering

Kyran D. Mish

California State University, Chico

Joseph Mello

Aerojet Corporation

  • 15.1 Introduction

15-1

Definition of Terms (CAD/CAM/CAE) • Overview of Computer-Aided Engineering • Goals of Computer-Aided Engineering Chapter

  • 15.2 Computer Programming and Computer

Architecture

15-3

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

  • 15.3 Computational

15-35

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

  • 15.4 Computer Intelligence

15-78

Artificial Intelligence Expert Systems in Mechanical Engineering Design Neural Network Simulations Fuzzy Logic and Other Statistical Methods

  • 15.5 Computer-Aided Design (CAD)

15-85

15.1 Introduction

Introduction Entity-Based 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 computer-aided 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 high-level understanding of these emerging engineering tools.

Definition of Terms (CAD/CAM/CAE)

First, it is necessary to define a few terms related to the integration of the computer into various aspects of engineering practice:

Computer-aided 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.

Computer-aided manufacture (CAM) is the topic concerned with the integration of the computer into the manufacturing process, including such tasks as controlling real-time production devices on the factory floor. This subject is treated in Section 13.

Computer-aided 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 computer-aided 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 computer-aided design practice.

Overview of Computer-Aided 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 artificial intelligence applications oriented toward removing the engineer from the design/analysis cycle, to “engineer in the loop” simu- lations intended to offload 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 computer-aided engineering.

Goals of Computer-Aided 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 high-level orientation is utilized. Details of computational techniques are relegated to a catalog of appropriate references, and high-level “practical” concepts are emphasized. Low-level details (such as computer performance issues) change rapidly relative to high-level concerns (such as general classi- fications of computer function, or qualitative measures of computer solution quality). Thus, concentrating on a technical overview of computer-aided engineering will permit this chapter to stay up-to-date 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

Computer-Aided 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 general-purpose 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 fields?

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 first provides the practicing mechanical engineer with an overview of the field of computer-aided 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 defini- tions) are relegated to other chapters, or to appropriate references. Thus this chapter mainly provides an overview of the broad subject of computer-aided 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- five years ago, mechanical engineers designed high-performance 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 high-performance engineering computation cost several million dollars, required custom construction, installation, and support, and could perform between 10 million and 100 million floating-point 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 definitions.

Software Engineering Overview

The modern field 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 specification, design, and implementation of computer programs. Unlike most engineering fields, 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 field are based on viewing the process of designing and implementing computer programs as analogous to designing and constructing physical objects. One of the most influential 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 configurations is a theme that runs

© 1999 by CRC Press LLC

15 -4

Section 15

throughout the history of the software engineering field. Modularity alone is not a panacea, however, in that programming effort contained within modules must be readable so as to facilitate verification, maintenance, and extension. One of the most influential 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 Man-Month (Brooks, 1975), and Philip Metzger’s Managing a Programming Project (Metzger, 1983). Brooks’ conclusions are generally considered among the most fundamental principles of the field. 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 exemplified 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 identified and proposed remedies suggested and tested. Administrative and large-scale 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 specification 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:

System Analysis
System Analysis
System Design
System Design
15 -4 Section 15 throughout the history of the software engineering field. Modularity alone is not
Programming
Programming
15 -4 Section 15 throughout the history of the software engineering field. Modularity alone is not
Testing
Testing
15 -4 Section 15 throughout the history of the software engineering field. Modularity alone is not
Delivery
Delivery
15 -4 Section 15 throughout the history of the software engineering field. Modularity alone is not

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 specifications.

System Design — the specifications 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

Computer-Aided 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 sufficiently efficient 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 difficulty 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 specified with sufficient accuracy in the first place), then the final product will be inadequate, and required changes will have to be specified before those modifications can be “percolated” back through the waterfall life cycle again. Another important difficulty with this scheme occurs because quality-control issues (e.g., testing) are delayed until the project is nearly finished. In practice, preventative quality-assurance measures work better at reducing the likelihood that errors will occur in the program. To avoid the inherent difficulties of the waterfall design, restructure this sequential design model into a spiral form that emphasizes more rapid incremental deliveries of programming function. These modified 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)

Application Application Analysis Evaluation START Preliminary Prototype Analysis Evaluation Preliminary Prototype Design Programming Application Application Design
Application
Application
Analysis
Evaluation
START
Preliminary
Prototype
Analysis
Evaluation
Preliminary
Prototype
Design
Programming
Application
Application
Design
Programming

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 first pass through the spiral) can often be constructed as a simple prototype of the desired final 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 final commercial version. This approach has a rich history in practical software development, where it is termed “throwing the first 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 final 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 computer-assisted software engineering (CASE) tools to permit substantial reuse of the prototype in the final 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 difficult 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 field of CASE tools, most current computer programming efforts are carried out by human programmers using high-level programming languages. These programming languages abstract low-level details of computer function (such as the processes of performing numerical operations or allocating computer resources), thus allowing the programmer to concentrate on high-level 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 efficiently in a procedural language).

A bstraction of D ata Abstraction of Data M ore Expressive Languages More Expressive Languages Object-Prog.
A bstraction of D ata
Abstraction of Data
M
ore Expressive Languages
More Expressive Languages
Object-Prog.
DataBase
Languages
Languages
Procedural
Languages
Assembly
Languages
A bstraction of Instruction
Abstraction of Instr uction

FIGURE 15.2.3 Language abstraction classification.

In addition, high-level 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 longer-term software development process from short-term advances in computer architecture. Perhaps the best example of how good program design and high-level 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 modifications 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

Computer-Aided 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 Classification

Computer programs consist of two primary components: data and instructions. Instructions reflect actions taken by the computer program, and are comparable to verbs in natural human languages. In a similar manner, data reflect 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 classified according to the relative importance of each of these components, and the resulting charac- terization of programming languages as “data-centered” (object-oriented) or “instruction-centered” (pro- cedural) has major ramifications toward design, implementation, and maintenance of computer software. Older programming languages (such as FORTRAN and COBOL) reflect 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 first” 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 object-oriented 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 specified, the procedures that act upon the data are defined 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 difficult 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, verifiable, extensible, and reusable code. Finally, it is important to recognize that the classification of programming languages into procedural and object-programming 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 object-programming models relegate procedures to a secondary role to data structures, much of the final effort in writing an object-oriented program still involves design, creation, and testing of the procedures (which are termed “class methods” in object-programming 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 object-oriented 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 run-time 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 top-down design . The overall effort of the program is successively decomposed into smaller logically separate subtasks, until each remaining subtask is sufficiently 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.

C om plete Task S ubtask 1 S ubtask 2 S ubtask 3 S ubtask 1a
C om plete Task
S ubtask 1
S ubtask
2
S ubtask 3
S ubtask 1a
S ubtask 1b
S ubtask 2a
S ubtask
2b
S ubtask 2c
S ubtask 3a
S ubtask 3b

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 difficult 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 “Sapir-Whorf hypothesis.” While the Sapir-Whorf 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

Computer-Aided Engineering

15 -9

observed in practice, where use of more expressive high-level 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 FORTRAN-77 standard was promulgated, FORTRAN had no way of expressing the standard logical “if-then-else” statement. The FORTRAN-77 specification 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 first and executed subsequently). Interpreted languages such as Basic are often incredibly inefficient, 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 specifically 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 difficult to use for numeric computation. Ada is a more recent language that is based on Pascal, but remedies many of Pascal’s deficiencies. 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 large-scale 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 specification was replaced in 1988 by a new ANSI standard, and this current language specification 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 (FORTRAN-90) adds user-defined extensible data structures and a more expressive instruction set to the FORTRAN-77 standard, but the FORTRAN-90 standard has so far been slow to gain acceptance in the programming community. FORTRAN-77 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 flow) 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 FORTRAN-callable 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 scientific numerical computation (e.g., IMSL) available in FORTRAN-callable 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, multiple-language integration is relatively straightforward, so high-quality FORTRAN-callable libraries can be called from C programs, and vice-versa. 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 object-programming 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

Object-programming 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 fields, 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 specific instances of the class type. Objects thus form the repre- sentative granularity found in object-oriented 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 object-programming schemes facilitate the desired goal of code reuse.

© 1999 by CRC Press LLC

Computer-Aided Engineering

15 -11

One of the most important limitations of procedural languages is abstraction. High-level 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 FORTRAN-77 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- defined data types in C using structures and typedefs, but effectively abstracting these derived data types requires considerable self-discipline on the part of the programmer. Object-oriented 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 finite-element modeling would be the class of finite-element 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 finite-element 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 predefined formats. The sum of these constraints is to require the programmer to recode substantial components of a procedural program every time a major modifi- cation is desired. In the setting of objects, the finite-element 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 predefined lists of nodes, elements, and element characteristics, an object-oriented 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 object-oriented 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 predefined formats such as floating-point arrays (for data) or predefined subroutine libraries (for instructions). Data and instruction abstraction of this form are thus useful additions to the similar (but less flexible) features available in procedural languages. If these new features constituted the only improvements available from object-programming 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 object-programming 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 finite-element mesh for a rod lying in three dimensions can be derived from a one-dimensional mesh by adding two additional coordinates at each node. An object programmer could take an existing one-dimensional 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 low-level 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 modification to the problem statement. In practice, the added details are implemented via the creation of a derived class, where the additional coordinates and the modified methods are created. When messages appropriate to the new class are sent, the derived object created from the new class will handle only the modified 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 modification to the program’s specifications are small, the resulting programming effort is generally simple. When the changes are large (such as generalizing a one-dimensional problem to a fully three-dimensional one), it is still often feasible to make only minor modifications to the program to implement the new features. One of the most important rationales for using object-programming methods arises from the desire to provide a consistent user-interface 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 user-interface 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 user-interface 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 full-featured graphics applications by writing only a few hundred or a few thousand lines of code (notably, for reading and storing data in files, 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++ user-interface layer from an existing class library around the existing procedural code, and by recycling relevant procedures as class methods in the new object-oriented 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 object-programming 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 run-time characteristics of the particular object-programming language used, but it is an important practical feature in any object- programming language.

Object-Oriented Design Principles. Because object-oriented 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

Computer-Aided Engineering

15 -13

design schemes among the various competing object-oriented design principles. For this reason (and to avoid prejudging the future), this section treats the subject of object-oriented design in less detail than procedural design methods. The fundamental tenet of object-oriented program design is that the programming objects should be chosen to model any real-world 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 specifications are least likely to vary, and thus they will require minimal modifications to the basic program design. The next step in performing an object-oriented design is to model the behaviors of the various objects identified 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 identified 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 final step in specifying an object-oriented 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 identification 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 object-programming design practice. In practice, there is no “final” step in designing object-oriented 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 specific members of a class created when an object-oriented program executes. Objects are thus specific instances of generic classes, and the process of creating objects at run time (including setting all appropriate default values etc.) is termed instantiation .

Sample Object-Oriented Languages. There are not as many successful object-oriented languages as there are procedural languages, because some languages (such as Ada and FORTRAN-90) that possess limited object-oriented features are more properly classified as procedural languages. However, ADA 95 does include excellent facilities for object-oriented programming. C++ is the most commonly used object-oriented 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 object-programming 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 “object-programming in C++”. C++ is well known as an object-programming 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 back-compatibility 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 efficient compiled language, providing the features of object-programming 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 production-quality code.

© 1999 by CRC Press LLC

15 -14

Section 15

An important recent development in object-oriented 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 World-Wide-Web, and it has a syntax very similar to C++, a pervasive object-orientation, 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 object-programming 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 efficient 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 object-oriented language with similar structure to object-oriented 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 commercial-quality C++ class libraries, including run-time 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 object-oriented 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 object-programming practices. Object Pascal is a variant of Pascal that grafts SmallTalk-like 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 sufficient support for object-oriented programming features (or a large-enough 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 object-oriented programming languages, which permit a greater degree of data abstraction, problems defined by large or complex data sets required more flexibility for modeling data than traditional procedural programming techniques allowed. To fill 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 “data-centered” 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 cross-platform 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 object-oriented languages (which permit flexible 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 object-oriented programming practice.

© 1999 by CRC Press LLC

Computer-Aided 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 specific 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 specifically defined 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 (fields 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 sufficient for this brief introduction. One important high-level definition 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 specification that permits a degree of portability for data base applications. In practice, standard SQL is sufficiently 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 SQL-based 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 non-relational data base applications.

Classification 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 sufficient capabilities for the problem. Three sample data base structures are presented below: flat-file data bases, relational data bases, and object-oriented data bases.

Flat-File Data Bases. Flat-file data bases represent the simplest conceptual model for data base struc- ture. A flat data base can be idealized as a table with a two-dimensional matrix or grid structure. The individual data base records are represented by the rows of the matrix, and each record’s component fields are represented by the columns of the matrix structure, as shown in Figure 15.2.5. Flat-file data bases are thus confined to applications where all records are structurally identical (i.e., have the same configuration of fields) 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

 
  • 250 GPa

70

GPa

 

25

 

Magnesium

 

MPa

 
  • 150 GPa

45

GPa

 

18

 

Steel

 

MPa

 
  • 400 GPa

200 GPa

 

85

FIGURE 15.2.5

Flat data base example.

The simplicity of a flat-file data base is simultaneously its greatest advantage and worst disadvantage. The main advantage of using a flat-file 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 flat-file 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 flat-file data bases is that the extreme simplicity of the flat structure simply does not reflect many important characteristics of representative data base applications. For programs requiring flexibility in data base schema, or complex relationships among individual data fields, flat-file 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 fields that may be contained in separate data files. Applications with these “relational” features are term relational data bases. Relational data base technology is a rapidly evolving field, and this family of data bases is very common in practical data base applications. Relations provide a way to generalize flat-file data base tables to include additional features, such as variation in the numbers of fields 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 fields for each material record), a flat-file 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 identification information. These parent-child relationships give relational data bases considerable flexibility in modeling diverse aggregates of data, but also add complexity to the task of storing and retrieving data in the data base. In a flat-file data base system, a simple lookup (similar to indexing into a two-dimensional array) is required to find a particular field. In a complex relational data base, which may exhibit many nested layers of parent-child relations, the task of querying may become very complex and potentially time-consuming. Because of this inherent complexity in storing and retrieving data, the topics of efficient data base organization and of query optimization are essential for careful study before any large-scale relational data base application is undertaken.

Object-Oriented Data Bases. Many of the data base schemes found in relational and flat-file 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 data-modeling capabilities with new procedural languages (such as SQL or XBase) specifically designed to manipulate data base constructs. Recently, the current proliferation of object-oriented 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 object-oriented data base systems. These object-oriented data base packages provide extremely powerful features that may ultimately make traditional SQL-based relational data base applications obsolete.

© 1999 by CRC Press LLC

Computer-Aided Engineering

15 -17

Material ID Material Name Material Type 1 Steel Isotropic 2 Wood Orthotropic Material ID MaterialProperty 1
Material ID
Material Name
Material Type
1
Steel
Isotropic
2
Wood
Orthotropic
Material ID
MaterialProperty
1
Steel Yield Strength
1
Steel Young’s Modulus
1
Steel Shear Modulus
2
Wood Tensile Strength with Grain
2
Wood Cross-Grain Compressive Strength
2
Wood Shear Strength
2
Wood Tensile Elastic Modulus
2
Wood Compressive Elastic Modulus
2
Wood Shear Modulus

FIGURE 15.2.6 Example relational data base structure.

One interesting example of object-oriented 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 object-oriented 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 low-level resources for execution support, including file services for input/output, graphical display routines, scheduling, and memory management. The software layers that provide these low-level 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 identified 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 on-line- transaction-processing schemes used in finance and commerce, where there is a similar charac- teristic of large data sets, but these large financial data models are seldom required to have all components available in memory at the same time.)

• Dependence on floating-point computation, where there are high-precision floating-point repre- sentations of numbers (i.e., numbers stored in the binary equivalent of “scientific 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

15-18

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 sufficient 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 classification scheme used to identify various operating systems in terms of the services that they provide. The most common characteristics used for these classifications 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 high-performance 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 well-behaved individuals who readily yield the floor 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 difficult 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 floor 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. Ill-behaved 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 resource-sharing 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. Low-priority 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 high-priority tasks (such as real-time 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

Computer-Aided Engineering

15-19

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 high-powered 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 identified 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 finish (which would be required in a single-threaded 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 finally gravitated to the realm of low-end 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 flavors:

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 dual-CPU 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 speed-up 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 Random-Access 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

15-20

Section 15

memory demand in a multitasking setting can be satisfied 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 wide-area networks, and also permit sharing of resources among computers. Traditional networking functions (such as sharing files 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 field 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 low-level hardware to high-level 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 field 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 classified according to criteria developed by the Department of Defense (DOD 5200.28-STD, December 1985). These DOD criteria provide for such features as secure logons (i.e., logging into a computer requires a unique user identifier and password), access control structures (which restrict access to computer resources such as files or volumes), and auditing information (which provides

© 1999 by CRC Press LLC

Computer-Aided Engineering

15-21

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 long-term 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 defined module respon- sible for managing all of the interaction between the low-level (hardware) layer of the operating system and the overlying systems services that do not need to know precise details of low-level function. The module that abstracts the low-level 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.

Classification of Representative Operating Systems

Several operating systems commonly encountered in engineering practice are classified below in accor- dance with the definitions 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 low-level 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 single-processor, single-tasking, single-threaded 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 low-overhead operating systems are commonly used in realtime applications in mechanical engineering for such tasks as process control, data acquisition, and manufacturing. In these performance-critical 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 first widely used graphical user-interface 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 first commercial 32-bit operating systems

© 1999 by CRC Press LLC

15-22

Section 15

that provided a modern interactive computing environment with features such as multitasking, multi- threading, multiprocessing, protected virtual memory management, built-in high-speed 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 64-bit 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 flexibility 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, high-level 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 object-oriented operating system that supports the client-server 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 UNIX-like graphical user interface (provided by implementing common UNIX window management functions on top of NT), and the Macintosh-like interface similar to that introduced in Windows 95 as a replacement for Windows 3.1 in mid-1995.

UNIX. The UNIX operating system was developed during the 1970s at Bell Laboratories to satisfy the need for a flexible and inexpensive operating system that would provide high-end system services (e.g., multitasking, virtual memory) on low-cost 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 built-in 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 Hewlett-Packard. 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 public-domain 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 large-scale 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 influenced by the nature of engineering computation. Vector processors, gather/scatter hardware, and coarse-grain parallel CPU architectures have been used successfully over the past few decades to increase the performance of large-scale 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

Computer-Aided Engineering

15-23

workstations. Understanding the basic principles of these advanced computer architectures is essential to gain efficient utilization of their advantages, and so the following sections present an overview of the fundamentals of this important field.

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 coarse-grained parallelism characterized by a relatively small number of independent CPUs (e.g., typically from 2 to 16 CPUs), and a fine-grained 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 floating-point numbers that are stored contiguously in memory) to be processed at very fast rates. Such pipelined execution characteristics have now become commonplace even on low-cost micro- computers. In fact, current high-performance microprocessors used in engineering workstations and high-performance 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 low-priced 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 efficient machine instruc- tions). Finally, another important form of parallelism has developed in conjunction with high-performance 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 high-priced 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 local-area networks.

Classification of Parallel Architectures

There are many schemes to characterize parallel computer architectures, including the SMP/MP classi- fication 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

15-24

Section 15

The four possible classifications 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 first 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 flexible 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 fit into this SIMD architecture, the performance obtained can be phenomenal. Many standard numerical schemes were already well organized for SIMD calculations: for example, simple two-dimensional finite-difference 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 finite- difference molecules result in highly scalable performance. More complex calculations, such as those found in modeling nonlinear problems, are generally much more difficult to implement on SIMD computers and often result in poor performance on these simplified 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 flavors 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 hardware-based 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 single-computer 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 general-purpose 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 object-oriented 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 efficient 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 significant market for computer-graphics 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

Computer-Aided Engineering

15-25

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 scientific visualization or the use of rational physical-based models in computer anima- tion, are also motivated in large part by the diverse needs or the knowledge base of the mechanical engineering field.

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 sufficient bandwidth (i.e., information-carrying 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 field have traditionally been required to study engineering graphics as a required course during their first-year 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 field of computer graphics (see Foley and VanDam, 1982, for a detailed overview). Some high-level terms commonly used in the field should be defined before more detailed exposition of this important field is attempted; the definitions given below are not intended to be all-inclusive, 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 user-interface: a metaphor for human-computer 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 field have learned to leverage the efforts of others by adhering to industry-wide standards. The code of standardization and practice in computer graphics exists on many levels, ranging from low-level coordinate choices developed as a foundation toward abstracting the rendering and display process to high-level 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 closed-form 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 time-dependent 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

15-26

Section 15

as temperature, or specific components of stress), appropriate visualization schemes include contour maps using lines or color-filled 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 field 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 Scientific 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 figure, the color contours plot gas temperatures in a model of a chemically reacting Navier-Stokes 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 time-dependent results are to be visualized, there are two standard schemes commonly used. The first approach involves treating the time-dependent behavior of the data as another spatial dimension. This approach is commonly used to graph scalar-valued 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 scalar-valued function of two variables z = z(x, t) is plotted as a three-dimensional 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 three-dimensional behavior even though it is plotted on a two-dimensional page. Using such depth cues as perspective (as well as others, including hidden-surface 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 time-dependent 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 computer-generated 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 low-end engineering workstations.

Multimedia in Mechanical Engineering Practice

Multimedia is an imprecise term whose definition 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 three-dimensional graphical input device. The former flavor of multimedia naturally draws the analogy with silent movies being replaced by those with a

© 1999 by CRC Press LLC

Computer-Aided Engineering

15-27

Computer-Aided Engineering 15 -27 FIGURE 15.2.7 Two-dimensional contour plot for stress analysis. © 199 9 by

FIGURE 15.2.7 Two-dimensional contour plot for stress analysis.

© 1999 by CRC Press LLC

stress sigma-max

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

15-28 Section 15 Max Prin Stress min -1.914E+04 max 9.563E+05 +9.8000E+05 +9.4000E+05 +9.0000E+05 +8.6000E+05 +8.2000E+05 +7.8000E+05
15-28
Section 15
Max Prin Stress
min -1.914E+04
max
9.563E+05
+9.8000E+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
FIGURE 15.2.8 Three-dimensional contour plot for stress analysis.
© 1999 by CRC Press LLC

Computer-Aided Engineering

15-29

Computer-Aided Engineering 15 -29 FIGURE 15.2.9 Three-dimensional vector field plot for torque converter simulation. FIGURE 15.2.10

FIGURE 15.2.9 Three-dimensional vector field plot for torque converter simulation.

Computer-Aided Engineering 15 -29 FIGURE 15.2.9 Three-dimensional vector field plot for torque converter simulation. FIGURE 15.2.10

FIGURE 15.2.10 Pressure contour plot with solution geometry cues.

© 1999 by CRC Press LLC

15-30

Section 15

15 -30 Section 15 FIGURE 15.2.11 Gas temperature contour plot with reactor background. u viewpoint at

FIGURE 15.2.11 Gas temperature contour plot with reactor background.

u viewpoint at Displacement History : x = 2.00000E+01 t = 1.00000E+01 z = 1.00000E+01 displacemen
u
viewpoint at
Displacement History
:
x =
2.00000E+01
t =
1.00000E+01
z =
1.00000E+01
displacemen
t
min = -1.485E-
t
02
max =
1.327E-
02
X
axial
viewpoint at:
stress
x = 2.00000E+01
min = -1.844E-
t = 1.00000E+01
01
z = 1.00000E+01
max =
1.902E-
01
displacement:
file: big.dat
min = –1.485E–02
max = 1.327E–02
step: 0.05
axial stress:
alpha: -0.3
min = –1.844E–01
max = 1.902E–01

FIGURE 15.2.12 Time-dependent data viewed as space-time surface plot.

© 1999 by CRC Press LLC

Computer-Aided Engineering

15-31

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 fields). Each of these uses is based on two empirical observations: (1) people generally find 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 efficient 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 high-quality 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 full-screen 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 high-speed storage. Storing sound requires less dramatic capacities, but even low-quality (e.g., AM-radio 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 efficient 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 efficient 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 efficient 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

15-32

Section 15

• MPEG (Motion Pictures Experts Group) CODEC. MPEG is a family of CODECs that is becoming popular for display-only animation applications. The various MPEG implementations (MPEG and MPEG-2) 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 efficiency permits very large and complex animations to be stored and played back using low-technology 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 efficiently (most animations have only small temporal differences among adjacent frames, and this time-dependent redundancy is ignored by the JPEG algorithm and carefully exploited by the MPEG family). It is expected that the near-term 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 efficient 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 time-code that numbers every frame of video. This time-code 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 time-code mechanisms include RC time-code, which is a frame-indexing scheme that is available on many consumer-grade 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 time-code infor- mation pertinent for simple synchronization of multimedia. In addition, current versions of QuickTime also provide SMPTE time-code support, in order to simplify the task of high-performance digital video editing on the Macintosh platform.

Graphical User-Interface 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 user-interfaces (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 first 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 well-designed GUI yields substantial gains in produc- tivity for most computer-assisted 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 well-written introduction relating to the widely imitated Macintosh user-interface guidelines). An intuitive program

© 1999 by CRC Press LLC

Computer-Aided Engineering

15-33

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 files, 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 first 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 workflow in a personalized manner, which allows them to seek and find the best individualized way to accomplish computer-assisted tasks. Permissiveness is one of the most difficult 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 GUI-based 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 GUI-based program provides some appropriate feedback (generally graphical) for every legitimate user-initiated 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 user-supplied input data. Responsiveness and intuition work together in the control of the program’s actions; for example, the pull-down 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 GUI-based software is a difficult process and is especially cumbersome when procedural languages are used. Modern event-driven interactive software is naturally suited to the more asynchronous message-driven architecture available with object-oriented programming models, and it is in the area of GUI-based applications that object-oriented 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 field-based input of data by the user

© 1999 by CRC Press LLC

15-34

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 fastest-growing aspects of computer graphics. Efficient 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 difficult (e.g., life-threatening) 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 artificial virtual world. While windowed virtual reality appli- cations are common (running on platforms ranging from high-performance computers with color displays to mass-market 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 insufficiently 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 fields. 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 flight simulator, where an integrated display and a movable cockpit are used to simulate the “look and feel” of flight. 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 fields (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

Computer-Aided Engineering

15.3 Computational Mechanics

15-35

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 high-technology 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 finding efficient schemes to simulate physical processes on the computer. Understanding the strengths and weaknesses of the current computational mechanics field is an important task for the practicing mechanical engineer interested in using computer-aided 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 round-off 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 semi-analytical 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 infinity to gain convergent results and are thus superficially similar to discretization schemes such as finite-element and finite-difference methods, where the number of grid points tends to infinity as the size of the grid spacing decreases.

Computational Solid, Fluid, and Thermal Problems

Before specific 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 well-understood 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 finite-element models. This family of computer simulation tech- niques is one of the most successful branches of modern computational mechanics, and practical implementations of finite-element methods represent a unified 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 stress-strain 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 strain-displacement relations of mechanics, where strains are expressed as spatial derivatives of the displacement field. Stress-strain 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 three-dimensional isotropic linear-elastic 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

15-36

Section 15

This linearity arises from the assumptions of small deformations, a linear stress-strain 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.

Definitions 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

 
  • x ,

 

y

,

z

,

xy

,

yz

,

zx

= engineering strains

 

g

  • x ,

 

g

y

,

g

z

= gravity body force components

E = Young' s Modulus

 

= Poisson' s Ratio

= Density

“Dynamic” Equilibrium Equations for a Solid

∂ ∂ ∂ xy zx u ˙˙ = x + + + g x ∂ x
xy
zx
u
˙˙ =
x
+
+
+
g
x
∂ x
y
z
xy
y
yz
˙˙
=
+
+
+
g
y
∂ xyz ∂ ∂
yz
w ˙˙ =
zx
z
+
+
+
g
x
∂ x
y
z
Compatibility Equations for a Solid
u
1
∂ u
=
=
+
x
xy
x
2
x
∂ y
1
∂ w
=
=
+
y
yz
x
2
∂ y
z
∂ w
1
∂ u
∂ w
=
=
+
z
zx
∂ z
2
∂ z
∂ x

(15.3.1)

(15.3.2)

(15.3.3)

© 1999 by CRC Press LLC

Computer-Aided Engineering

15-37

Isotropic Linear-Elastic Stress-Strain Relations

1 [ ( )] 2 ( 1 + ) = + = x x y z
1
[
(
)]
2
(
1
+
)
=
+
=
x
x
y
z
xy
xy
E
E
1
2
(
1
+
)
[
(
)]
=
+
=
y
y
z
x
yz
yz
E
E
1
)]
2
(
1
+
)
=
[
(
+
=
z
z
x
y
zx
zx
E
E

(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:

rod beam shaft
rod
beam
shaft
plate
plate
membrane
membrane

FIGURE 15.3.1 Common idealizations of solid mechanical behavior.

• Rods, with a local one-dimensional 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 two-dimensional structures loaded in the plane defined by their

geometry

• Plates, which are two-dimensional flat structures loaded by arbitrary forces and couples, including

those that excite membrane response and those that bend or twist the natural two-dimensional

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

15-38

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 fluid mechanics are exactly the same as those for solid mechanics: the mechanical

system under consideration is analyzed using appropriate equilibrium, compatibility, and stress-strain

relations. In practice, because of the inability of a fluid to resist shear, fluids are considerably more

difficult to characterize than solids, and the effective computational mechanics of fluids is therefore a

more difficult and diverse topic. Perhaps the most important difference between common models for

solid and fluid 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 flow of the fluid 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 configuration. While the Eulerian world view is more

common for analyzing fluids (primarily because tracking the individual motion of all particles of the

fluid material is generally intractable in practice), this conceptually simpler approach gives rise to many

practical computational difficulties 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 fluid response are the Navier-Stokes equations.

These equations are presented below for a three-dimensional flow field involving a Newtonian fluid (i.e.,

one readily characterized by the material parameter viscosity, which is assumed not to depend upon fluid

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 Navier-Stokes equations are nonlinear, in that products

of solution quantities occur in the convective terms on the left-hand side of the momentum conservation

equations. These nonlinearities arise because of the Eulerian reference frame used to model fluid flow,

and cause fluid mechanics problems to be generally much more difficult to solve than analogous solid

mechanics problems.

© 1999 by CRC Press LLC

Computer-Aided Engineering

15-39

Definitions 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)

2 2 2 ∂ u ∂ u ∂ u ∂ u ∂ p ∂ u ∂
2
2
2
∂ u
∂ u
u
∂ u
∂ p
u
u
u
+
u
+
+ w
=
g
+
+
+
x
2
2
2
∂ t
∂ x
y
∂ z
∂ x
x
y
z
2
2
22
∂ p
+
u
+
+ w
=
g
+
+
+
(15.3.6)
y
2
2
2
∂ t
∂ x
y
∂ z
∂ y
x
y
z
2
2
2
∂ w
∂ w
∂ w
∂ w
∂ p
w
w
w
+
u
+
+ w
=
g
+
+
+
z
2
2
2
∂ t
∂ x
∂ y
∂ z
∂ z
∂ x
∂ y
∂ z
Fluid Mass Conservation Equation
(
u
) +
(
) +
( w )
= 0
(15.3.7)
∂ x
∂ y
z
Fluid mechanical response is generally classified according to a variety of schemes, including whether

the flow is internal (confined, as in flow-through ducts) or external (confining, as in the case of modeling

flow around an airfoil in aerospace applications), and whether the internal or external flow field contains

a fluid-free surface. Free-surface flows are considerably more complex to model using computational

methods because the physical extent of the fluid 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

flow of heat through a conductor. Such problems in heat conduction, porous media flow, and other

diffusive systems can be readily modeled using standard fluid 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 fluid mechanics models.

One of the most common ways to categorize fluid mechanical behavior arises from consideration of

various dimensionless parameters defined by the constitution of the fluid and its flow regime. Represen-

tative dimensionless parameters relevant to fluid mechanics include:

• The Reynolds number, which relates the effects of fluid inertia to those of fluid viscosity forces

and which naturally arises in a broad range of fluid problems

• The Mach number, which measures the ratio of fluid speed to the speed of sound in the fluid:

this parameter is important in compressible flow problems

• The Peclet number, which quantifies the relative effects of fluid transport due to advection and

dispersion and is used in fluid mass transport modeling

© 1999 by CRC Press LLC

15-40

Section 15

• The Taylor number, which is used to predict instabilities present in various fluid flow regimes

and may be encountered when dealing with the computational ramifications of fluid instability

Unlike solid mechanics, there is no body of computational expertise that provides a generic model

for computational approximation of the full range of fluid response. In practice, computational schemes

are chosen according to particular aspects of fluid behavior (such as the various classifications and

dimensionless parameters given), which substantially limits the range of applicability of any particular

computational solution scheme. Many fluid models are solved using finite-element 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 fluids

exhibit a bewildering array of diversified material responses. Because of the difficulty in modeling many

fluid constitutive parameters, many fluid models are analyzed using gross constitutive models that often

neglect complicating material behavior (one common example of this case is the case of inviscid flow

models, where neglecting the presence of fluid viscosity results in tremendous simplification of the

resulting computational approximation). When fluid material response is important, as in the example

of modeling transition from laminar to turbulent fluid behavior, the requisite constitutive equations for

the fluid become appropriately more complex. While there is not yet a completely unified model for

fluid constitutive behavior, each individual subdiscipline of computational fluid mechanics utilizes fluid

material models that provide reasonable accuracy for fluid response within the range of the particular

problems studied.

Electromagnetics problems are commonly solved by practicing mechanical engineers using techniques

originally utilized for computational fluid dynamics. It is feasible to recast much of the computational

technology developed for fluids into the setting of electromagnetics problems, because many electro-

magnetic simulations are qualititatively similar to fluid response. For example, potential flow simulation

techniques are readily adapted to the potential formulations of electrostatics and magnetostatics. Alter-

natively, the full range of fluid response exhibited by the Navier-Stokes equations, which includes

transient inertial and dissipative effects, is qualitatively similar to large-scale transient problems involving

coupled magnetic and electrical fields. Mechanical engineers interested in performing electromagnetic

simulations will commonly find that expertise in fluid 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

best-known cases of the mathematical setting known as “scalar potential field” theory. In this case, the

scalar potential is the temperature field, and the heat flow 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 flows downhill, or opposite the direction of the

temperature gradient. The governing mathematical relations for transient conductive heat transfer in a

three-dimensional 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 right-hand side of this relation must

be generalized to include spatial derivatives of the conductivity term.

© 1999 by CRC Press LLC

Computer-Aided Engineering

15-41

Definitions 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 fluid 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, fluid, and electromagnetic systems.

Convective thermal problems are considerably more difficult to model by computer because they involve

transport of heat by a moving fluid, and thus may suffer from the same difficulties inherent in modeling

transient fluid response.

Biomechanics

Biomechanics is an increasingly important component of mechanics (see Section 20.3) Computational

simulation of biomechanical systems is difficult because many biomechanical problems straddle the

boundary between solid and fluid 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 finite-element 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 difficult, they are often encountered in professional

practice. The practicing engineer interested in performing accurate computational modeling of complex

biomechanical systems should insure that appropriate verification 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 difficulties in modeling these important but often intractable mechanical systems.

Coupled Solid/Fluid/Thermal Field Analyses

Many “real-world” problems encountered in mechanical engineering practice defy simple categorization

into solid, fluid, or otherwise. These practical problems often include combinations of classes of response,

and the efficient 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 first, and

which components can be considered of secondary relevance during the decoupled solution

process?

© 1999 by CRC Press LLC

15-42

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

identified 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 field can be calculated

independently of the state of stress. Furthermore, an additional simplification 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

simplification is that the coupled problem could be solved as a series of uncoupled transient problems.

At each time in the solution history, the temperature field 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 simplified decoupled problems are satisfied, 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 flutter instabilities in aircraft structures (where the coupled external flow 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 flow 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., force-like 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. Well-posed problems can be characterized as

© 1999 by CRC Press LLC

Computer-Aided Engineering

15-43

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 finite-element models is the verification 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 well-posed physical problems whose analogous mathematical existence is estab-

lished by appropriate mechanics theorems. For example, any linear-elastic 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 rigid-body 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 refined), 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 rigid-body

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

rigid-body 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 field. Problems such as incom-

pressible elasticity (where the volume of the mechanical body is invariant under deformation), incom-

pressible flow (where the conservation of mass implies a “continuity” constraint on the velocity field),

or electromagnetic field applications (where the magnetic field must be divergence-free) all possess

constraints that can lead to serious solvability difficulties 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 rigid-body motion. On the other

hand, if the entire boundary of the incompressible body is subject to a constrained displacement field,

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 satisfied (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 difficulty 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

15-44

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. Verification 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. High-quality 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 verification 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 refinement 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 time-dependent 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 time-dependent

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 finite-difference operators (and their finite-element

relatives used for time-dependent 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 difficult 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 finding convergent approximations is often replaced by that of searching for schemes

that are simultaneously consistent and stable.

© 1999 by CRC Press LLC

Computer-Aided Engineering

15-45

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 large-scale

engineering computation because their computational realizations exhibit prohibitively large growth

rates. For example, many recursive schemes, such as Cramer’s rule for finding 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 lower-order 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

  • 10 100

1,000

3,628,800

  • 20 10 18

400

8,000

2.433 ×

  • 50 2,500

125,000

3.041 × 10 64

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 higher-order 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.

Finite-Element Approximations in Mechanical Engineering

Finite-element models are among the most efficient, general, and accurate computational approximation

methods available in engineering. Many of the attractive characteristics of finite-element computational

models arise from a seemingly unlikely source: instead of representing the mathematical statement of

the underlying mechanics as systems of differential equations, finite-element models are motivated by

considering instead equivalent integral formulations, e.g., the basic equations of equilibrium, compati-

bility, and stress-strain can be replaced by equivalent integral energy formulations such as the Principle

© 1999 by CRC Press LLC

15-46

Section 15

of Virtual Work or the Theorem of Minimum Potential Energy. These latter integral principles form the

basis for finite-element 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 well-known example

of this equivalence. Once identified, 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 sufficient to express the range of

intractable differential behavior. However, the integral formulation requires only marginal modifications

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 finite-element models also provides other important features. One

important aspect of finite-element models is their computational efficiency; another is that strong and

general convergence proofs can be cited for large classes of finite-element 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 unified computational framework that includes many other practical

schemes (such as finite-difference models) as special cases of a general integral theory of computational

mechanics. Therefore, careful study of the mathematical underpinnings of finite-element modeling also

provides considerable insight into such diverse alternative computational schemes as finite-difference

models and boundary-element methods.

Overview of Finite-Element Models

Finite-element 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 well-established general results, and it is straight-

forward to develop generic finite-element computer models from these fundamental integral mechanics

formulations. Since many problems in other branches of mechanics (such as Stokes Flow in fluid

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, finite-

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 finite-element approximation.

The most common application of finite-element models is in computational solid mechanics. In this

area, finite-element models can be made arbitrarily accurate for a wide range of practical problems.

Standard stress analysis problems involving moderate deformations of well-characterized materials (such

as metals) are generally easy to solve using finite-element technology, and static or time-dependent

simulations of these mechanical systems are routinely performed in everyday mechanical engineering

practice. More complex problems (such as computational fluid mechanics, coupled problems, or elec-

tromagnetic simulations) can readily be solved using finite-element techniques, though the accuracy of

the solution in these areas is often limited, not by the finite-element technology available, but by

difficulties in determining accurate characterizations for the materials used. For example, in many

biomechanical problems, the model for simulating the stress-strain 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 finite-element 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 finite-element modeling in engineering practice. Some of

these problems arise from inherent difficulties in developing generic finite-element computer programs,

© 1999 by CRC Press LLC

Computer-Aided Engineering

15-47

while others arise from the same generality that makes finite-element models so attractive as computa-

tional approximations. Examples of the former include computer programs that do not contain completely

robust modern finite-element models for plates and shells, while examples of the latter include finite-

element applications that incorporate the latest computational technology but are so difficult to use that

inaccuracies result from gross errors in preparing input data. Finally, many practical limitations of finite-

element modeling are due to theoretical difficulties inherent in the mathematical formulations of mechan-

ics, and these last pathologies are the most difficult to remove (as well as being problematic for any

computational scheme and not therefore particular to finite-element techniques).

Classification of Finite-Element Models

There are many classifications possible in computational mechanics, and so choosing an appropriate

classification scheme for any general method such as finite-element modeling is necessarily an ambiguous

task. The most common classification scheme for categorizing finite-element models is based on con-

sideration of the physical meaning of the finite-element solution, and a simplified version of this scheme

can be described by the following list:

• If kinematical solution unknowns (such as displacement or velocity) are determined first, then

the model is termed a displacement-based finite-element model.

• If statical finite-element solution parameters are the primary unknowns determined during the

computational solution process, then the model is termed a stress-based finite-element model.

• If a combination of kinematical and statical solution unknowns are determined simultaneously,

then the computational scheme is called a mixed finite-element model.

Displacement-based finite-element models are the most common schemes used at present, and most

commercial-quality finite-element applications contain extensive element libraries consisting primarily

of displacement-based families. In a displacement-based model, the analyst creates a finite-element 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 flow problems). Once the displacements

have been determined, the unknowns in the secondary solution (such as stress and strain) are derived

from the finite-element displacement field by using appropriate compatibility and stress-strain relations.

Some common two-dimensional finite elements used for displacement-based formulations are catalogued

in Figure 15.3.2. The elements shown are successfully used for common problems in stress analysis,

simple fluid flow, and thermal analyses, and their generalization to three-dimensional problems is

straightforward and computationally efficient.

Three Node Six Node Ten Node Linear Triangle Quadratic Triangle Cubic Triangle
Three Node
Six Node
Ten Node
Linear Triangle
Quadratic Triangle
Cubic Triangle
Computer-Aided Engineering 15 -47 while others arise from the same generality that makes finite-element models so

Four Node Bilinear Lagrange Quadrilateral

Computer-Aided Engineering 15 -47 while others arise from the same generality that makes finite-element models so

Eight Node Biquadratic Serendipity Quadrilateral

Computer-Aided Engineering 15 -47 while others arise from the same generality that makes finite-element models so

Nine Node Biquadratic Lagrange Quadrilateral

FIGURE 15.3.2 Common two-dimensional finite elements.

© 1999 by CRC Press LLC

15-48

Section 15

Stress-based finite-element schemes are much more rare than displacement models, although stress-

based finite 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 finite-element 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-

ment-based finite-element programs.

Mixed finite-element schemes commonly arise in problems involving constraints, such as electromag-

netics, incompressible deformation or flow, 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 field 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 finite-element computer programs that have already been tested and verified 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 finite-element

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 finite-element 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 finite-element approximation permits a more general study of convergence than

do competing differential frameworks utilized in finite-difference and finite-volume models).

Finite-element formulations can also be classified into two particular flavors of development: Rayleigh-

Ritz and Galerkin. Rayleigh-Ritz finite-element models are developed by applying theorems of minimum

potential energy (or some similar integral extremization measure). Galerkin models arise from so-called

weak statements of boundary-value problems and are simultaneously more complicated to derive and

substantially more general in scope. For problems (such as standard linear stress-analysis problems)

where both minimum and equivalent weak statements of the problem exist, the resulting Rayleigh-Ritz

and Galerkin finite-element models will yield identical results. For problems where no extremization

principle exists (such as high-Reynolds number fluid flow), Galerkin finite-element models (and their

relatives) can still be used in practice.

Computational Characteristics of Finite-Element Models

Finite-element models are widely used in mechanical engineering precisely because of their computa-

tional efficiency. A brief enumeration of the computational characteristics of finite-element models

highlights many reasons why they form such an effective family of computational approximation

techniques.

• Finite-element models tend to result in computational algorithms that are readily understood,

easily implemented, and exhibit well-known computational advantages. For example, finite-

element equation sets tend to be sparse (i.e., to have a relatively small percentage of nonzero

terms in the coefficient matrix, with these nonzero entries in a well-defined pattern that can be

utilized to achieve efficient 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

Computer-Aided Engineering

15-49

• Finite-element 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, finite-element 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 finite-difference and finite-volume meth-

ods. In contrast to these latter discretization schemes, finite-element 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 finite-element 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 finite-element program performance with little additional

effort required by either users or programmers.

• Finite-element results are defined everywhere in the problem domain, and these results include

derived parameters such as stress and strain. Because these solution components are defined

everywhere, it is very easy to apply additional computer technology (such as integrated graphical

postprocessors) to verify and interpret the results of the finite-element analysis. It is commonly

(and incorrectly!) believed that all numerical methods provide computational solutions only at a

finite number of points in the domain, but this observation is erroneous in the case of finite-

element models. The global definition of the finite-element solution is of considerable utility

toward the important goal of evaluating the convergence of finite-element models. In addition,

the derived secondary solution parameters are also convergent, so that the optimal accuracy

characteristics of finite-element 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 finite-difference and finite-volume schemes.

• It is relatively easy to guarantee the convergence of common finite-element solution schemes,

and this characteristic, when combined with the mathematical optimality of the finite-element

solution, facilitates trust in the computed finite-element results. The convergence properties of

finite-element 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 finite-difference schemes) that would

otherwise be competitive with finite-element models in terms of computational effort.

• For some problems, including those involving substantial convective nonlinearities due to high-

speed fluid flow, the optimality characteristics of standard finite-element models can no longer

be guaranteed, and an alternative integral convergence formulation must be sought. In the setting

of finite-element models for flow, 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 flow 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 finite-

element models is an attractive alternative to analogous (but generally more complex) convergence

results used in finite-difference modeling for fluid problems.

In simple terms, finite-element models are very attractive candidates for computational approximation

efforts. Under very general conditions, they can be demonstrated to be extremely accurate, computa-

tionally efficient, and amenable to improvements in computer hardware and software technology. Because

© 1999 by CRC Press LLC

15-50

Section 15

of these computational advantages, finite-element models have become popular in virtually all branches

of computational mechanics.

Advantages and Disadvantages of Finite-Element Models

Like all computer approximation schemes, finite-element modeling has characteristic advantages and

disadvantages, and the effective use of finite-element technology requires at least an introductory

understanding of each. Besides the computational advantages of efficiency and optimality presented

above, most finite-element schemes include other practical advantages. Foremost among the advantages

are the characteristics of generality of function and flexibility of modeling. The primary disadvantages

occur when naive finite-element implementations are applied to mathematically ill-behaved problems.

Finite-element 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 commercial-quality finite-element

programs permit the analysis of static and time-dependent problems in solid mechanics, fluid 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 finite-element 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 finite-element 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 finite-element 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 verification tools (such as integrated graphical

pre- and postprocessors) whenever possible. Virtually all high-quality commercial finite-element 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 finite-element modeling:

the most common pathologies arise from analyses incorporating mixed finite-element models. Guaran-

teeing the convergence of mixed finite-element models is a much more difficult mathematical problem

than the analogous proof of convergence for displacement-based models, and it is possible to get

unreliable results from naive use of mixed finite-element models. While most modern commercial finite-

element programs will largely guard against the possibility of constructing inherently poor finite-element

approximations, there are older or less robust finite-element applications available that do not incorporate

completely dependable finite-element technologies. Therefore, it is important to identify potential prob-

lem areas for finite-element modeling. The most common sources of difficulty are presented below.

Incompressible Problems. Problems where volume is preserved commonly occur in mechanical engi-

neering practice, but errors arising from inaccurate finite-element modeling techniques are often readily

identified and corrected. Incompressible solid elastic materials include rubber and solid propellants, and

models for inelastic response of metals also require incompressible or near-incompressible 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 finite-element mesh locks in these test examples,

then either different elements or a different finite-element 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 finite-element 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

Computer-Aided Engineering

15-51

Load Incompressible Material
Load
Incompressible
Material

Test Problem

fixed

fixed

Load fixed
Load
fixed
Load fixed fixed fixed fixed fixed
Load
fixed
fixed
fixed
fixed
fixed

Quadrilateral Test Meshes

Load fixed (can flip diagonal) fixed fixed
Load
fixed
(can flip
diagonal)
fixed
fixed
Load fixed fixed fixed fixed fixed Triangle Test Meshes
Load
fixed
fixed
fixed
fixed
fixed
Triangle Test Meshes
Load fixed fixed fixed fixed fixed
Load
fixed
fixed
fixed
fixed
fixed

FIGURE 15.3.3 Test problem suite for incompressibility.

Computer-Aided Engineering 15 -51 Load Incompressible Material Test Problem fixed fixed Load fixed Load fixed fixed
Displacement
Displacement
Computer-Aided Engineering 15 -51 Load Incompressible Material Test Problem fixed fixed Load fixed Load fixed fixed
Pressure
Pressure

FIGURE 15.3.4 Incompressible elasticity finite elements.

textbooks on finite-element 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

finite-element 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, one-dimensional beam elements

or two-dimensional 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 finite-element mesh, with attendant

underprediction of the displacement field. 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 field 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 finite-element packages

are used. It may be important when the finite-element application is a local or unsupported product, and

© 1999 by CRC Press LLC

15-52

Section 15

Load Test Problem Load Load Load One-Dimensional Frame Element Two-Dimensional Plane Stress Element Three-Dimensional Elasticity Element
Load
Test Problem
Load
Load
Load
One-Dimensional
Frame Element
Two-Dimensional
Plane Stress Element
Three-Dimensional
Elasticity Element

FIGURE 15.3.5 Single-element flexure 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 simplified problems that can be solved analytically using engineering

beam theory analogies or closed-form plate models. One simple test case for naive finite-element 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 finite-element model (or applica-

tion) should be sought.

Lack of Curvature Deformation in Low-Order Elements. Low-order linear, bilinear, and trilinear ele-

ments (such as four-node bilinear quadrilaterals used in plane stress and plane strain applications) are

commonly utilized in finite-element packages because they are easy to implement and because many

software tools exist for creating two- and three-dimensional meshes for such low-order elements. Unfor-

tunately, there are common circumstances when these low-order elements give inaccurate and unconser-

vative results. One such example is shown in Figure 15.3.5. Many simple finite-element packages will

provide accurate answers for the one-dimensional problem, but will substantially underpredict the two-

and three-dimensional displacements. Unlike the mesh-locking pathology encountered in incompressible

cases, the underprediction of displacements from low-order elasticity elements eventually disappears as

more elements are used when the mesh is refined. It is easy to remedy this problem in general by choosing

appropriate continuum elements, and many commercial codes provide appropriate low-order elements

automatically. Problems due to poorly implemented low-order elements are best avoided by solving

simple one-element models first 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 finite-element package!) or take pains to insure that the mesh is appropriately refined.

It is important to recognize that many of the problems that arise when using finite-element models

for these more difficult cases are not completely due to the particular finite-element 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 Finite-Element Software

It is easy to avoid most errors in finite-element analysis, by first 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 “warm-up” 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 final member of the

series (namely, the complex problem to be modeled accurately) is obtained. The simpler members of

the suite of problems generally involve simplifications in geometry, in material response, and in scale

of deformation. For example, if a complicated problem involving large-deformation behavior of an

inelastic material is to be analyzed, simpler problems using small-deformation theories, elastic material

© 1999 by CRC Press LLC

Computer-Aided Engineering

15-53

models, and simplified problem geometry should be solved and carefully verified. 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 finite-element packages

are to be evaluated. Most commercial finite-element packages are specifically oriented toward different

engineering markets, and their respective feature sets depend upon the needs of those particular engi-

neering disciplines. When evaluating commercial finite-element software for potential purchase, a wide

selection of representative problems should be analyzed and verified, 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 finite-element 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 finite-element software.

Finite-Difference Approximations in Mechanics

Finite-difference models include many of the first successful examples of large-scale computer simulation

for mechanical engineering systems. Finite-difference modeling techniques were originally developed

for human calculation efforts, and the history of finite-difference calculations is considerably longer than

the history of finite-element modeling. Once automatic computation devices replaced humans for low-

level computing tasks, many of the existing finite-difference schemes were automated, and these simple

numerical techniques opened up much of engineering analysis to computer simulation methods. Over

time, improved finite-difference approximations (including ones that would be prohibitively difficult for

human calculation) resulted, and the range of problems solvable by finite-difference models became

more diverse.

Throughout the 1970s and 1980s, a natural division developed between finite-difference and finite-

element models in computational mechanics. Finite-difference models were utilized primarily for a wide

variety of flow problems, and finite-element approximations were used for modeling the mechanical

response of solids. While many finite-element approximations were proposed for fluid problems such

as the Navier-Stokes equations, in practice these first-generation finite-element models generally per-

formed poorly relative to more advanced finite-difference schemes. The poor performance of naive finite-

element models relative to carefully optimized finite-difference approximations was widely (but incor-

rectly) accepted in the mechanical engineering profession as evidence that fluid problems were best

solved by finite-difference methods, even as finite-element technology gained near-exclusive use in such

fields as stress analysis.

In fact, the problems associated with early-generation finite-element models in fluids were due

primarily to rampant overgeneralization of insight gained in solid mechanics instead of any inherent

limitations of finite-element technology applied to fluid mechanics problems. Similar problems developed

in the early stages of finite-difference modeling; for example, one of the first finite-difference 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 finite-element technology on the relatively more complicated models for fluid behavior, and

there has been an explosion of interest in using finite-element approximations to replace finite-difference

schemes in a variety of fluid mechanics settings. While finite-difference methods (and especially carefully

optimized applications found in certain difficult and narrow specialties in fluid modeling) continue to

be widely used in fluid mechanics and electromagnetic simulations, the range of mechanics problems

thought to be resistant to finite-element solution approaches is rapidly diminishing.

Finally, a word regarding nomenclature is warranted. Originally, finite-difference models were devel-

oped using regular grids of equally spaced points, with the solution approximation computed at the

© 1999 by CRC Press LLC

15-54

Section 15

vertices of this structured lattice. As increasingly complicated problems were solved with finite-difference

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, finite-difference modeling was generalized to include various averaged

(i.e., integrated) schemes that augmented classical vertex-oriented finite-difference methods to include

cell-centered 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 finite-volume schemes, which are a general family of integrated finite-difference

approximations that preserve the relative simplicity of finite-difference equations, while casting the

underlying theory in a form more amenable to modeling complicated problems. Finite-volume methods

are discussed in a later section of this chapter, but the general characteristics given below apply to the

entire finite-difference/finite volume family of approximate solution techniques. Because of the wide-

spread application of these integral generalizations of classical vertex-based finite-difference schemes,

it has become commonplace to use the term “finite-difference methods” collectively to include all the

members of this computational family, including vertex-centered schemes, cell-averaged methods, and

finite-volume approximations.

Overview of Finite-Difference Models

Finite-difference 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 finite-element modeling instead of finite-difference approximation) is probably more

useful in computational practice, but it is definitely 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 first, 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 finite-difference schemes

is essentially inexhaustible.

The computational component of finite-difference 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 finite-difference grid,

and the collection of individual grid points used to approximate the differential operator is called (among

other terms) the finite-difference molecule. Sample finite-difference 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 finite-difference 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 finite-difference solution. This regular spacing of points provides simulta-

neously the greatest incentive and the biggest constraint toward practical use of finite-difference methods.

Performing finite-difference 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 fixed grid structure that is difficult to adapt to nonregular domains without sacrificing 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 flexibility. Unfortunately, these requisite coordinate

© 1999 by CRC Press LLC

Computer-Aided Engineering

15-55

Laplacian Molecule Laplacian Molecule Biharmonic Molecule Quadratic Convergence Quartic Convergence Quadratic Convergence
Laplacian Molecule
Laplacian Molecule
Biharmonic Molecule
Quadratic Convergence
Quartic Convergence
Quadratic Convergence

FIGURE 15.3.6 Sample finite-difference molecules.

transformations may be difficult to determine for sufficiently complicated problem geometries. This

limitation should be contrasted with the geometric flexibility inherent in analogous finite-element models,

where optimal rates of convergence are readily realized even in the presence of irregular or unstructured

finite-element meshes.

A geometric motivation for the improved performance of regularly spaced finite-difference 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 centered-difference 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 centered-difference estimate.

(Note that it is also possible to define a backward-difference slope estimate by considering the secant

line passing through the function at the points x and (x h). In problems involving spatial derivatives,

this backward-difference estimate has numerical properties that are generally indistinguishable from the

forward-difference approximation, but in the setting of time-dependent derivatives, there are considerable

differences between forward- and backward-difference schemes.)

f(x+h) f(x) f(x–h) x–h x x+h
f(x+h)
f(x)
f(x–h)
x–h
x
x+h

Forward

Centered

Tangent

f(x+h) – f(x) h f(x+h) – f(x–h) Centered 2h df Tangent f'(x) = dx
f(x+h) – f(x)
h
f(x+h) – f(x–h)
Centered
2h
df
Tangent
f'(x) =
dx

Forward

Computer-Aided Engineering 15 -55 Laplacian Molecule Laplacian Molecule Biharmonic Molecule Quadratic Convergence Quartic Convergence Quadratic Convergence

FIGURE 15.3.7 Finite-difference formulas and geometry.

It is apparent from the figure that the centered-difference 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 centered-difference 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 finite-difference practice: centered-difference 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 finite-difference methods is the use of Taylor Series expansions), it is

particularly instructive to perform some computational experimentation regarding this optimality of

centered-difference models.

© 1999 by CRC Press LLC

15-56

Section 15

Consider the following simple FORTRAN program:

15 -56 Section 15 Consider the following simple FORTRAN program: This program evaluates forward difference estimates

This program evaluates forward difference estimates for the derivative of the exponential function at

the point x = 0. The program is easily modified to provide a centered-difference 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 centered-difference results are graphed for two different precisions

of FORTRAN REAL declarations (32-bit, which represents a lower limit of quality on floating-point

numeric representation, and 80-bit, which represents a high-quality floating-point 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 log-log

plots. In this region, the difference estimates are converging to the exact value of tangent slope,

as might be expected given the definition of the derivative as the limit of a secant.

• In these linear regions, the centered-difference error decreases with a slope of two, while the

forward-difference error decreases with unit slope. This implies that the forward-difference

approximation has a linear rate of convergence, while the centered-difference estimate is con-

verging quadratically.

• The size of these convergent regions depends upon the precision used for floating-point calcula-

tions. Extended-precision formats (such as 80-bit 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 underflows (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 floating-point 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 centered-difference formula converges much more rapidly than the forward-differ-

© 1999 by CRC Press LLC

Computer-Aided Engineering

15-57

0 32-bit reals -2 Forward-Difference -4 Convergence Region: -6 Slope = 1 80-bit -8 reals -10
0
32-bit
reals
-2
Forward-Difference
-4
Convergence Region:
-6
Slope = 1
80-bit
-8
reals
-10
-20
-10
0
Log[h]
(Base 10)
Log [h]
(Base
Log |error|
Log|error|
(Base
(Base 10)
10)

10)

0 32-bit reals Centered-Difference -5 Convergence Region: 80-bit reals Slope = 2 -10 -15 -20 -10
0
32-bit
reals
Centered-Difference
-5
Convergence Region:
80-bit
reals
Slope = 2
-10
-15
-20
-10
0
Log[h]
(Base 10)
Log [h]
(Base
Log |error|
Log|error|
(Base
(Base 10)
10)

10)

FIGURE 15.3.8 Results of finite-difference 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 round-off and

truncation errors in the calculation of the derivative estimate).

Classification of Finite-Difference Models

As in the case of finite-element models, there are many alternative classifications available for catego-

rizing finite-difference approximations. The first relevant classification is a geometric one, based on

whether the finite-difference grid is structured (i.e., possesses a regularly spaced lattice structure) or

unstructured. In order to maintain optimal convergence rates, finite-difference 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 low-order linear finite-element mesh (on the

left of the figure) and a corresponding finite-difference/finite volume scheme (on the right). In order to

capture the effect of boundary curvature, the structured finite-difference/finite-volume 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 fluid and electromagnetic applications), this imposition of structure on what is

© 1999 by CRC Press LLC

15-58

Section 15

Finite-Element Subdomain
Finite-Element Subdomain
Finite-Difference/Volume Subdomain
Finite-Difference/Volume Subdomain

FIGURE 15.3.9 Finite-difference modeling of irregular geometry.

really an unstructured physical problem can seriously compromise the quality of the resulting compu-

tational approximation. Finite-element 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 higher-order finite-

element approximations (e.g., locally quadratic or cubic interpolants) to approximate the boundary

curvature shown in the figure to an essentially exact degree.

Another classification scheme can be based upon whether the difference formulas used are forward,

backward, or centered. This classification is especially appropriate for finite-difference time-stepping

methods used to solve initial-value problems in engineering and science. In this time-dependent setting,

there is a coalescence of finite-element and finite-difference approaches, and the classification presented

below permits one unified terminology to be used for both topics. Each class of difference estimate leads

to time-marching discretization schemes that have distinctly different characteristics.

Forward difference schemes are commonly used to produce time-stepping methods that are very

efficient in terms of computational effort and memory demand. The important class of explicit time-

stepping algorithms arises largely from using forward-difference approaches: explicit schemes are defined

as those requiring no equation solution effort to advance the solution to the next time step (e.g., where

the coefficient matrix to be solved is diagonal). The primary disadvantage of forward-difference 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 trade-off between reduced

computational effort at each step, and the attendant requirement of a small time step. Explicit schemes

based on forward-difference 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 three-dimensional models), explicit schemes are often

used exclusively because of their relatively small demand for memory.

Backward difference schemes are commonly used in time-stepping applications where stability of the

solution is especially important. In particular, backward-difference schemes generally provide numerical

dissipation of high-frequency 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 long-period vibrations of the entire structure as

well as short-period response of individual structural components. One of the characteristics of discret-

ization methods, in general, is that they tend to predict low-frequency behavior very accurately, while

high-frequency response is predicted with considerably less accuracy. Since the high-frequency response

is therefore often inaccurate (or spurious), there is a strong incentive to attenuate its effects, and choosing

backward-difference temporal schemes is a good way to achieve this end. Backward-difference formu-

lations generally require solution of a system of equations to advance the solution across a time step,

and hence they are termed implicit time-stepping methods.

Centered-difference approximations are generally chosen in order to gain optimal convergence rates

for time-stepping methods, and centered schemes are thus one of the most common choices for model