Computer-aided engineering.pdf

15-5

C o m p u t e r -A i d ed E n g i n eer i n g

• 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 Analysis

Application Evaluation

START Preliminary Analysis

Preliminary Design

Application Design

Prototype Evaluation

Prototype Programming

Application 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 implementation. Current remedies for this inherent problem include “rapid application development” (RAD)

© 1999 by CRC Press LLC

15-6

Secti on 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 ata Abstraction ofD Data

M oreMore Expres sive Languages Expressive Languages

DataBase Languages

Assembly Languages

Object-Prog. Languages

Procedural Languages

A bs traction ofIns tion Abstraction oftruc Instruction 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



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 characterization of programming languages as “data-centered” (object-oriented) or “instruction-centered” (procedural) has major ramifications toward design, implementation, and maintenance of computer software. Older programming languages (such as FORTRAN and COBOL) reflect a preeminent role for instructions. Languages that abstract the instruction component of programs permit the programmer to recursively 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 “procedures” (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 encapsulation 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 objectprogramming 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


15-8

Secti on 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 procedural 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

Subtask 1

Subtask 1a

Subtask 1b

Subtask 2

Subtask 2a

Subtask 2b

Subtask 3

Subtask 2c

Subtask 3a

Subtask 3b

FIGURE 15.2.4 Sample functional decomposition.

The basic motivation behind functional decomposition is that the human mind is incapable of understanding 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 runtime 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



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 implementations 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 representing 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-


15-10

Secti on 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 languages, 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 engineering. 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 amenable 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 representative 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.



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 available 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 userdefined 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 modification is desired. In the setting of objects, the finite-element mesh object would store its particular geometric implementation 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


15-12

Secti on 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 threedimensional 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 objectprogramming 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. Programmers 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. Polymorphism (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 objectprogramming 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


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 interrelationships 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 objectoriented 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 realization 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 exception handling) that are very useful in the implementation of production-quality code.


15-14

Secti on 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 amenable 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. FORTRAN90 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 competition 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.



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

Secti on 15

Field 1: Name

Field 2: Yield Strength

Field 3: Young’s Modulus

Field 4: Shear Modulus

Record 1: Material 1

Aluminum

250 MPa

70 GPa

25 GPa


Magnesium

150 MPa

45 GPa

18 GPa


Steel

400 MPa

200 GPa

85 GPa

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. 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 r elationships 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.

Relational Data Bases.

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.


15-17


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-linetransaction-processing schemes used in finance and commerce, where there is a similar characteristic 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 representations 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)


15-18

Secti on 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 singletasking 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.


C o m p u t e r -A i d ed E n gi n eer i n g

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 operations 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 highend 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 master/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 multiprocessing 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


15-20

Secti on 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, multiprocessing 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 management 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 characterized 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 connections) 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



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 highlevel languages whenever possible. A portable operating system generally abstracts the particular characteristics of the underlying hardware platform by relegating all knowledge of these characteristics to a carefully defined module responsible 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 accordance 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 computation). 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 counterproductive. 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 applications, 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


15-22

Secti on 15

that provided a modern interactive computing environment with features such as multitasking, multithreading, 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 highperformance 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 crashproof 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 engineering 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 supercomputers 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



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 microcomputers. 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 instructions). Finally, another important form of parallelism has developed in conjunction with high-performance networking schemes. Distributed computing applications are commonly designed to parallelize calculations by dividing up individual threads of execution among disparate computers connected via a highspeed 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 classification 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.


15-24

Secti on 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) computing, 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 finitedifference 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 parallelism 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 multiprocessing, 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 engineering 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



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 animation, 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 characteristically 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

Secti on 15

as temperature, or specific components of stress), appropriate visualization schemes include c ontour 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 threedimensional 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 inexpensive 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


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

C o m p u t e r -A i d e d E n g i n e e r i n g

FIGURE 15.2.7 Two-dimensional contour plot for stress analysis.

1 5 2 7


Max Prin Stress min

-1.914E+04

max

9.563E+05

1 5 2 8

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


S e c t i o n 1 5

Max Prin Stress min

-1.914E+04

max

9.563E+05

1 5 2 8

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



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

15-29

S e c t i o n 1 5


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

FIGURE 15.2.10 Pressure contour plot with solution geometry cues.


15-29

15-30

Secti on 15

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 t min = -1.485Et

02 max =

1.327E-

02

X

viewpoint axial at: stress x = 2.00000E+01 min = -1.844Et = 1.00000E+01 01 z = 1.00000E+01 max =

1.902E-

01

file: big.dat step: 0.05 alpha: -0.3

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


displacement: min = –1.485E–02 max = 1.327E–02 axial stress: min = –1.844E–01 max = 1.902E–01


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 compression 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 applications 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).


15-32

Secti on 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 independently 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 timedependent data streams. For example, multimedia applications using both video and sound must guarantee 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 equipment. 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 information 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 ergonomics 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 productivity 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



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


15-34

Secti on 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 applications, 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 applications 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 r elated 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 techniques on the computer or even perform real surgery from a remote “virtual” location).



15-35

15.3 Computational Mechanics 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 co nvergent 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 computational 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 techniques 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, compatibility, 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. Compatibility 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 constitutive 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.


15-36

Secti on 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

˙˙, w ˙˙, ν ˙˙ u

= 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

(15.3.1)

E = Young' s Modulus

ν = Poisson' s Ratio ρ = Density “Dynamic” Equilibrium Equations for a Solid

ρu˙˙ =

∂σ x ∂τ xy ∂τ zx + + + ρg x ∂ x ∂y ∂z

ρν˙˙ =

∂τ xy ∂σ y ∂τ yz + + + ρg y ∂ x ∂y ∂z

ρw˙˙ =

∂τ zx ∂τ yz ∂σ z + + + ρg x ∂ x ∂y ∂z

(15.3.2)

Compatibility Equations for a Solid


ε x =

∂u ∂ x

1  ∂ν ∂u  γ xy =  +  2  ∂x ∂ y 

ε y =

∂ν ∂ x

1  ∂w ∂ν  γ yz =  +  2  ∂ y ∂z 

ε z =

∂w ∂ z

1 ∂u ∂w  γ zx =   +  2  ∂ z ∂ x 

(15.3.3)

15-37


Isotropic Linear-Elastic Stress-Strain Relations 1

ε x =

[σ E

ε y =

1

[σ E

ε z =

1 E

x

− ν(σ y + σ z )]

γ xy =

y

− ν(σ z + σ x )]

γ yz =

[σ z − ν(σ x + σ y )]

γ zx =

2(1 + ν) E

2(1 + ν) E

2(1 + ν) E

τ xy τ yz

(15.3.4)

τ zx

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 threedimensional solid mechanical response. These idealizations of solid mechanical behavior are diagrammed in Figure 15.3.1 and include: rod

beam

shaft

plate

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

Secti on 15

Theories of computational solid mechanics are often categorized by reference to the particular structural 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 f or 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.


15-39


Definitions for Fluid Conservation Equations u, ν, w

= x, y, z components of velocity

p = pressure field g x , g y , g z

= gravity body force components

(15.3.5)

ρ = density µ = viscosity Fluid Momentum Conservation Equations

 ∂u ∂u ∂u  ∂ 2 u ∂ 2 u ∂ 2 u  u  p ∂ ∂ ρ + u + ν + w  = ρg x − + µ 2 + 2 + 2  ∂ y ∂ z  ∂ x  ∂ x ∂ y ∂ z   ∂t ∂ x  ∂ν ∂ν ∂ν ∂ν  ∂ p  ∂ 2 ν ∂ 2 ν ∂ 2 ν  ρ + u + ν + w  = ρg y − + µ 2 + 2 + 2  ∂y ∂ z  ∂ y  ∂x ∂y ∂ z   ∂t ∂ x

(15.3.6)

 ∂w ∂w ∂w ∂w  ∂ p  ∂ 2 w ∂ 2 w ∂ 2 w  ρ + u + ν + w  = ρg z − + µ 2 + 2 + 2  ∂ x ∂ y ∂ z  ∂ z  ∂ x ∂ y ∂ z   ∂t Fluid Mass Conservation Equation

∂ u ∂ ∂ (ρ ) + (ρν) + (ρw) = 0 ∂ x ∂ y ∂z

(15.3.7)

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


15-40

Secti on 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 electromagnetic simulations are qualititatively similar to fluid response. For example, potential flow simulation techniques are readily adapted to the potential formulations of electrostatics and magnetostatics. Alternatively, 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 understanding 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.


15-41


Definitions for Thermal Equation T = temperature field k = thermal conductivity s

= distributed heat sources

(15.3.8)

ρ = density c

= specific heat

Heat Energy Conservation Equation

ρc

 ∂ 2 T ∂ 2 T ∂ 2 T  ∂T = −k  2 + 2 + 2  + s ∂t  ∂ x ∂ y ∂ z 

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

Secti on 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 insignificant 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 displacements) 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 complex. 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 computational 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


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 uniqueness 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 approximations 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 established by appropriate mechanics theorems. For example, any linear-elastic stress analysis of a compressible 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 approximation 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 superimposed 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 incompressible elasticity (where the volume of the mechanical body is invariant under deformation), incompressible 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

Secti on 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 approximation 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 discretization 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 determine, the task of finding convergent approximations is often replaced by that of searching for schemes that are simultaneously consistent and stable.


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 computational 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

N2

N3

N!

2 5 10 20 50

4 25 100 400 2,500

8 125 1,000 8,000 125,000

2 120 3,628,800 2.433 × 1018 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, compatibility, and stress-strain can be replaced by equivalent integral energy formulations such as the Principle


15-46

Secti on 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 straightforward 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, finiteelement 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 electromagnetic 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,


15-47


while others arise from the same generality that makes finite-element models so attractive as computational 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 finiteelement 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 finiteelement modeling are due to theoretical difficulties inherent in the mathematical formulations of mechanics, 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 consideration 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 Linear Triangle

Four Node Bilinear Lagrange Quadrilateral

Six Node Quadratic Triangle

Ten Node Cubic Triangle

Eight Node Biquadratic Serendipity Quadrilateral

Nine Node Biquadratic Lagrange Quadrilateral

FIGURE 15.3.2 Common two-dimensional finite elements.


15-48

Secti on 15

Stress-based finite-element schemes are much more rare than displacement models, although stressbased 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 stressbased 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 displacement-based finite-element programs. Mixed finite-element schemes commonly arise in problems involving constraints, such as electromagnetics, 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: RayleighRitz 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 computational 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, finiteelement 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.



15-49

• Finite-element models are readily shown to possess optimal accuracy characteristics for a substantial 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 methods. 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 profession. • 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 finiteelement 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 highspeed 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 finiteelement 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, computationally efficient, and amenable to improvements in computer hardware and software technology. Because


15-50

Secti on 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 packages 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. Guaranteeing 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 finiteelement 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 problem 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 twodimensional elements that are accurate when used in an incompressible elasticity setting. Modern


15-51


Load

Load

Load

fixed

fixed

Incompressible Material

fixed

fixed

fixed

Test Problem

fixed

fixed

Quadrilateral Test Meshes

Load

Load

fixed

fixed

Load

fixed

fixed

fixed

fixed

(can flip diagonal) fixed

fixed

fixed

fixed

fixed

fixed

fixed

fixed

Triangle Test Meshes FIGURE 15.3.3 Test problem suite for incompressibility.

Displacement

Pressure

FIGURE 15.3.4 Incompressible elasticity finite elements.

textbooks on finite-element theory (e.g., Hughes, 1987 or Zienkiewicz, 1991) generally provide guidelines 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

Secti on 15

Load

Test Problem

Load

Load

One-Dimensional Frame Element

Two-Dimensional Plane Stress Element

Load

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 application) 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. Unfortunately, there are common circumstances when these low-order elements give inaccurate and unconservative 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 twoand 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


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 engineering 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 lowlevel 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 finiteelement 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 performed poorly relative to more advanced finite-difference schemes. The poor performance of naive finiteelement models relative to carefully optimized finite-difference approximations was widely (but incorrectly) 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 developed using regular grids of equally spaced points, with the solution approximation computed at the


15-54

Secti on 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 widespread 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 engineering 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 continuous 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 simultaneously 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

15-55


Laplacian Molecule Quadratic Convergence

Laplacian Molecule Quartic Convergence

Biharmonic Molecule 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 forwarddifference 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.)

Forward Centered Tangent f(x+h)

f(x–h)

Forward

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

f(x)

2h

Tangent x–h

x

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

x+h

f'(x) = df dx

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.


15-56

Secti on 15

Consider the following simple FORTRAN program:

This program evaluates forward difference estimates for the derivative of the exponential function at the point x = 0. The program is easily 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 converging quadratically. • The size of these convergent regions depends upon the precision used for floating-point calculations. Extended-precision formats (such as 80-bit reals) provide both a larger region of convergence 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-


15-57


) 0 1 e s a e B s ( a B ( | r | r o r o r r r e e| | g g o o L L

) 0 1 e s a B e ( s

0

32-bit reals

-2

Forward-Difference -4

Convergence Region: Slope = 1

-6 -8 ) 0

80-bit reals

1 -10 -20

-10

Log[h] Log [h] (Base 10) 0

0

(Base 10)

32-bit reals Centered-Difference

a -5 B | ( r o | r r r o r -10 e r | e g | o g ) o L 0 L 1 -15

Convergence Region: Slope = 2

80-bit reals

-20

-10

Log[h] Log [h] (Base 10)

(Base 10)

0

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 categorizing 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


15-58

Secti on 15

Finite-Element 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 computational 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 finiteelement 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 timestepping 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 timestepping 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 discretization 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 formulations 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 modeling



15-59

transient response. In practice, centered-difference schemes are a mixed blessing. They generally require equation solution to advance across a time step, so they are implicit schemes which require more computational effort and increased demand for memory. They also usually provide a higher convergence rate, so that larger steps can be taken without sacrificing accuracy. In problems where the time-dependent solution is expected to be “well behaved,” such as transient heat conduction or similar diffusion problems, centered-difference methods are an excellent choice, especially if there are no spatial pathologies (such as material discontinuities or singular initial conditions) present. In problems where time-dependent response is more problematic (such as nonlinear dynamics of mechanical systems) many centereddifference schemes often give poor results, due to their general inability to attenuate spurious highfrequency discretization effects. There are a number of generalizations of centered-difference timestepping schemes that have recently been developed to provide optimal accuracy while damping spurious high-frequency response, and these specialized schemes should be considered when complicated dynamic simulations are inevitable (see, for example, the relevant material in Hughes, 1987).

Computational Characteristics of Finite-Difference Models Finite-difference methods possess many computational similarities to finite-element models, and so their computational characteristics are in large part similar. Both families of approximations generally result in sparse equation sets to be solved, but finite-difference models are less likely to preserve any symmetry of the governing differential equations in the form of matrix symmetry. In addition, many finite-difference molecules (such as those used to represent derivatives of order higher than two) result in equation sets that are not well conditioned and may give poor results when implemented in a low-precision, floatingpoint environment (such as some inexpensive microcomputers working in single precision). Convergence rates for many families of finite-difference models can be established using appropriate Taylor series expansions of the solution function. These convergence estimates thus require the conditions under which existence of a Taylor expansion can be guaranteed, and may be compromised when the exact solution of the problem violates these existence conditions. In such cases, the precise rate of convergence of the finite-difference model is more difficult to estimate exactly, though numerical experiments on simple test problems can often be used to obtain estimates of the actual convergence rate. The most common examples of conditions where an appropriate Taylor series expansion may not exist include problems involving interfaces joining dissimilar materials, and singular problem data such as point loads or localized sources. In each of these cases, the exact solution of the underlying differential equation may not possess sufficient continuous derivatives to warrant a Taylor series expansion, and so the rate of convergence may be compromised from that obtained on better-behaved data. For many standard finite-difference schemes, this compromised accuracy is commonly localized around the region possessing the singular or discontinuous data, and outside this disturbed region, better accuracy is obtained. Estimating the extent of contamination of optimal accuracy is a task greatly facilitated by the use of integrated graphics applications for visualizing and verifying solution behavior. It is worthwhile to contrast this latter potential convergence problem with the analogous finite-element case. Finite-element convergence proofs are generally cast in terms of least-squared error norms (such as the energy norm used for solid mechanics and diffusive flow problems) or weak convergence error measures. Each of these convergence settings is cast in an integral form, so few (if any) constraints upon the existence or continuity of the solution’s derivatives are required. The end result of the dependence on integral convergence measures in finite-element modeling is that a substantially more robust mathematical framework exists for guaranteeing optimal convergence of finite-element models.

Advantages and Disadvantages of Finite-Difference Models Finite-difference schemes possess many important computational advantages. Chief among these is the fact that finite-difference models are very easy to implement for a wide variety of problems, because much of the work of developing a finite-difference application consists merely of converting each derivative encountered in the mathematical statement of the problem to an appropriate difference estimate.


15-60

Secti on 15

Because there are so many well-understood differential equations available in engineering and science, the scope of finite-difference modeling is appropriately broad. Finite-difference models are also relatively simple to implement in software. Unlike finite-element models, which possess a bewildering generality that often complicates the task of software development, most finite-difference schemes are sufficiently limited in scope so that the task of computational implementation is less general and therefore considerably simpler. Because these models are easy to motivate and to implement, there is a vast body of existing finite-difference programs that can readily be applied to an equally wide range of problems in mechanical engineering. As long as the problems to be solved fit into the framework of finite-difference modeling, there is a strong incentive to use difference models in mechanical engineering practice. The primary disadvantages of finite-difference modeling arise from engineering problems that do not fit neatly into the restrictive nature of finite-difference modeling. Real-world phenomena such as material dissimilarities, complex geometries, unusual boundary conditions, and point sources often compromise the utility of finite-difference approximations, and these complicating factors commonly arise in professional practice. Differential formulations of physical problems are inherently restrictive, as the conditions under which derivatives exist are considerably more stringent than those relating to integrability. The end result of relying on differential statements of physical problems is that finite-difference schemes are generally easier to implement on simple problems than are finite-element models, but that for more complex problems, this relative simplicity advantage disappears. There are other disadvantages of finite-difference models including some important issues in verifying solution results. Since finite-difference models generally only calculate the primary solution parameters at a discrete lattice of sampling points, determining a global representation for the solution over the regions between these lattice points is not necessarily an easy task. If the grid used is sufficiently regular, a finite-element mesh topology can be synthesized and use made of existing finite-element postprocessing applications. If the grid is irregular, then automated schemes to triangulate discrete data points may be required before postprocessing applications can be used. Another serious disadvantage of restricting the domain of the solution to a lattice of discrete points is that determination of secondary parameters (such as heat flux in thermal analyses or stress and strain in mechanical problems) becomes unnecessarily complicated. In a finite-element model, determination of secondary derived parameters is simplified by two properties: first, the solution is defined globally over the entire domain, which permits solution derivatives to be evaluated easily and accurately; and second, the convergence of the solution is generally cast into a mathematical framework (such as the so-called “energy norm”) that guarantees not only convergence of the primary solution unknowns, but of the derived secondary solution parameters as well. In many finite-difference applications, neither of these important finite-element advantages are easily realized. Finally, another problem for general application of finite-difference models is in the implementation of boundary conditions. As long as the primary solution unknown is specified on the boundary (and the boundary is easily represented in terms of the finite-difference grid), then implementation of boundary conditions is relatively simple in theory. However, if derivative boundary conditions are required, or if the boundary itself is not readily represented by a finite-difference grid, then various “tricks” may be required to coerce the problem into a form amenable for finite-difference modeling (a particular example of a clever fix is the construction of phantom nodes located outside the problem domain specifically for the purpose of implementing derivative boundary conditions). Competing finite-element models generally permit trivial implementation of a wide spectrum of common boundary conditions. The implementation of derivative boundary conditions in a simple finite-difference model (in this case, heat conduction, where the temperature function is denoted by u) is diagrammed in Figure 15.3.10. Here it is desired to implement an insulated boundary along a vertical section of the finite-difference grid, where x = constant , and hence the normal derivative is easily evaluated. In order to make the normal derivative vanish, which represents the condition of an insulated boundary, it is necessary either to utilize a reduced control volume (shown in gray in the figure) or to implement a fictitious solution


15-61


column column j+2 j+2 y r a

x d n

y

u o b

column column j+1 j+1 d e t al u s ni

node (i,j ) phantom node (i-1,j )

column column j j nodal control volume

j- j–1 column column 1

row i row i

row i+1 row i+1

row i+2 row i+2

FIGURE 15.3.10 Finite-difference derivative boundary condition implementation.

node outside the problem domain (labeled as a phantom node in the figure). To simplify the resulting equations, it will be assumed that there is no heat generation taking place. A brief overview of each implementation strategy will be presented below in order to highlight the general methods used in practice. It should be noted that implementing derivative boundary conditions on inclined or curved boundary segments is much more difficult than the case for this simple example. In addition, it is worthwhile to reiterate that derivative boundary conditions are common in engineering practice, as constraints such as insulated boundaries, specified sources, or stress-free surfaces are accurately modeled using derivative boundary conditions. Finally, it should be emphasized that implementing derivative boundary conditions is a generally trivial task when using finite-element approximations, a fact which lends considerable practical advantage to finite-element analysis methods. Implementation of the derivative condition at node ( i, j) in the figure is most easily developed using

the rectangular control volume shown. If the steady-state conservation of heat energy is considered over this subdomain, then the heat flowing through the top, bottom, and right sides of the control volume must be balanced by heat generation within the volume and by flow through the boundary, and these last two terms are taken to be zero by assumptions of no internal heat generation and of an insulated boundary, respectively. The appropriate mathematical relation for heat conservation over the control volume is given by

∂u ∆ x ∂u ∆ x ∂u − k − k ∆ y right = 0 bottom ∂ y 2 face ∂ y 2 top ∂ x edge face

k

where k is the thermal conductivity of the material. This partial differential relationship among the heat flows can easily be converted to a discrete set of difference relations by substituting appropriate difference formulas for the partial derivatives, and letting uij denote the temperature computed at node (i,j). The result of this substitution is given by uij k

− uij −1 ∆ x uij +1 − uij ∆ x ui +1, j − uij − k − ∆ y = 0 ∆ y 2 ∆ y 2 ∆ x

This single equation can be used to augment the standard difference equations for the nodes not located on the boundary, in order to embed the desired derivative boundary conditions into the complete finitedifference thermal model. For each node located on the insulated boundary (e.g., nodes [i, j – 1], [i, j], [i, j + 1], and [i, j + 2] in the figure), an appropriate difference relationship is synthesized and incorporated © 1999 by CRC Press LLC

15-62

Secti on 15

into the set of difference equations governing the complete problem. Details of this procedure for the case of heat conduction can be found in Kreith and Bohn (1993). For more complex problems, appropriate derivations must be carried out to determine the correct form of the boundary relations for the finitedifference/finite-volume model. In practice, the first two difference terms above are often combined to yield a more accurate centereddifference approximation for the solution. In this case, the third term, which captures the insulated boundary condition specification, can be seen to represent a backward-difference approximation for the boundary flux. Since such two-point backward difference schemes have been shown earlier in this chapter to possess less desirable convergence characteristics than centered-difference formulas, it is often advantageous to convert the insulated boundary derivative condition to a more optimal centered-difference form. One scheme for gaining a centered-difference derivative formula at node ( i, j) can be developed by introducing the phantom node shown in the figure as node ( i – 1, j). A fictitious (in the sense that the node does not lie within the actual problem domain) thermal solution can be constructed at this node and utilized to gain a centered-difference relationship for the derivative boundary condition that may be more consistent with the relations used elsewhere in the finite-difference approximation. The details of this form of boundary condition implementation can be found in Ames (1977) or any other advanced text on finite-difference numerical analysis. It is sufficient to note here that the analyst is often confronted with the choice of a feasible but lessthan-optimal implementation (such as the control volume approach taken above), or a more accurate but appropriately more computationally complicated scheme for implementing a boundary derivative. Since finite-element models do not exhibit any of these difficulties in boundary-condition implementation, it is often much easier to utilize finite-element software for problems involving derivative boundary conditions.

Test Problem Suite for Finite-Difference Software Evaluation Before purchasing or using a new finite-difference program, appropriate evaluation measures should be contemplated to insure that the proposed application is capable of solving the particular problems encountered in mechanical engineering practice. As in the case of evaluation of finite-element software, any known solution pathologies can be modeled using the new program in order to determine the quality of the solution scheme. Many of the same mathematical pathologies presented for finite-element evaluation (such as mixed problems arising from incompressible flow constraints) can occur in finitedifference models, so these standard tests may also be appropriate in the finite-difference setting. In addition, any problems commonly encountered in professional practice should be solved with the new code in order to verify that the proposed application is both easy to use and reliable. Integrated graphical pre- and postprocessors are also important for use with finite-difference programs. Preprocessors that can plot both structured and unstructured finite-element grids are especially valuable, as verification of the coordinate transformations required to map complex physical domains to a regularized coordinate system may necessitate plotting of the finite-element grid in both its irregular physical setting and its regularized transformed computational setting. Postprocessors that automatically determine appropriate secondary solution parameters from the difference solution lattice are especially attractive, as they provide additional solution intepretation functions while minimizing the extra work required on the part of the engineer to construct the desired derived solution function. If computational simulations of advection-dominated problems are to be generated, it is imperative to insure that the proposed application provides robust algorithms for handling the nonlinear effects of convective acceleration terms. Older computational technology (such as simple upwinding schemes used to more accurately model advective effects in fluid dynamics) often results in poorer solution quality than can be obtained from codes utilizing newer schemes from computational fluid dynamics. Comparing results from various computer programs is a good way to determine which programs implement the best means to capture nonlinear effects. In addition, if the application being evaluated is noncommercial (e.g., public domain codes commonly distributed by academic researchers or special-purpose applications developed within an engineering organization), these comparisons will help to determine whether the



15-63

application is capable of robust modeling of the engineering problems encountered in normal professional practice.

Alternative Numerical Schemes for Mechanics Problems Finite-element and finite-difference approximations are the most common computational schemes used in mechanics, but the practice of computational mechanics is not restricted to these two discretization approaches. There are a variety of alternative methods available for solving many important problems in mechanical engineering. Some of these alternatives are closely related to finite-element and finitedifference models. Others have little in common with these general discretization schemes. A representative sampling of these alternative approaches is presented in the following sections.

Boundary-Element Models Boundary elements are a novel generalization of finite-element technology to permit better computational modeling of many problems where finite-element methods are unduly complex or expensive (see Brebbia and Dominguez, 1989). In simple terms, boundary elements involve recasting the integral principles that lead to finite-element models into a more advantageous form that only requires discretizations to be constructed on the boundary of the body (hence the term “boundary element”), instead of over the entire solution domain. For many problems involving complicated boundaries, such as infinite domains or multiply connected three-dimensional shapes, boundary element technology is an attractive alternative to finite-element modeling. In addition, because many existing computer-aided drafting applications already idealize shapes in terms of enclosing boundary representations, boundary-element approaches are natural candidates for integration with automated drafting and design technologies. Boundary-element schemes are not without disadvantages, however. The recasting of the integral formulation from the original domain to the boundary of the problem is not a trivial task, and this conversion substantially complicates the process of developing new boundary-element technology. One of the most important factors limiting the applicability of finite-element models is the formulation of an integral principle for a mechanical problem that is equivalent to a more standard differential problem statement. The conversion of this integral statement into a form amenable to boundary element approximation is yet another laborious task that must be performed, and each of these difficult mathematical problems represents potential errors when implemented in the setting of developing general-purpose analysis software. Many of the potentially attractive capabilities of boundary-element technology, such as the goal of accurate modeling of singular solution behavior (e.g., stress concentrations) that commonly occur on the boundaries of the domain, have not yet been completely realized in existing boundaryelement software. However, it is clear that boundary-element models are promising candidates for future computational approximation schemes. At present, boundary-element codes are most commonly found in research applications, as there is not yet a full range of commercial quality boundary element programs available for widespread use by practicing engineers. While the boundary-element method has a promising future, other advances in finite-element technology (such as robust automated mesh generation schemes that synthesize internal element information from a simple boundary representation) may compromise the demand for the considerable theoretical advantages of boundary element models. It is already feasible to combine features of finite-element and boundary-element technology in the same code, so the future of boundary element techniques may lie in integration with (instead of “replacement of”) finite-element applications.

Finite-Volume Schemes Finite-volume methods are hybrid computational schemes that have been developed to ameliorate some of the problems of finite-difference models. In simple terms, finite-volume models represent integrated finite-difference approximations, where the underlying differential equation is integrated over individual control volumes in order to obtain recurrence relations among discrete solution values. These recurrence formulas are strikingly similar to standard finite-difference approximations, but this integrated approach possesses some clear advantages over related finite-difference technology: © 1999 by CRC Press LLC

15-64

Secti on 15

• Because the equations are integrated over control volumes, finite-volume schemes are better able to model material discontinuities, which may cause serious problems in standard finite-difference models. • The integration process permits rational modeling of point sources, which are commonly implemented in an ad hoc manner in finite-difference schemes. • The integration process permits more flexibility in modeling unusual geometries, as the individual integration volumes can be adjusted locally to provide such important effects as curved boundaries. While these are important generalizations for finite-difference theory, in practice they do not realize many of the advantages available with finite-element models. Finite-volume schemes still require substantial regularity in the construction of the solution grid, or the construction of appropriate coordinate transformations to map the problem domain to a simpler computational setting. The integration process provides no relevant aid in the construction of secondary solution parameters such as stresses and strains. Finite-element topology must still be synthesized to enable use of appropriate solution visualization schemes, and this synthesis may be difficult when complex unstructured grids are utilized for the finitevolume model. Therefore, finite-volume schemes are most likely to be found competing with existing finite-difference models in areas where the underlying differential statements of the problem are well established, but where increased modeling flexibility is required. Finally, the convergence setting for finite-volume methods is similar to that of finite-difference models, and the various integral convergence measures available for proving finite-element convergence are not so readily applied to finite-volume approximations. Thus finite-volume models provide a way to generalize finite-difference approximations to more realistic problem settings, but their limited utilization of integral principles does not provide a unified integral framework of the quality found in finite-element modeling applications.

Semi-Analytical Schemes Many problems in mechanical engineering still admit solutions based on computational implementation of analytical (i.e., nonnumeric) techniques originally used for hand computation using closed-form solutions. This approach of approximating reality by simplifying the model to the point where it admits a closed-form solution (as opposed to the standard computational approach of putting a complicated model on the computer and using numerical approximations based on finite-element or finite-difference relations) has a rich history in engineering and science, and it includes such classical techniques as Fourier Series expansions for heat conduction problems, representation by orthogonal polynomials, and other eigenfunction expansion schemes. The advent of high-performance computers has had two effects on semi-analytic schemes such as Fourier Series approximation. First, modern computers are capable of performing the trigonometric evaluations required by Fourier Series representations very rapidly, so that these eigenfunction expansion schemes are now computationally feasible to implement. On the other hand, the application of modern computers to competitive approximation schemes (such as finite-element or finite-difference models for heat conduction applications formerly solved using closed-form Fourier Series techniques) has obviated the need to consider using semi-analytical schemes, as their more general computational approximation competition are now capable of solving more complicated problems with similar amounts of computational effort. While some applications of semi-analytical techniques can still be found, these computational implementations tend to be localized into special-purpose noncommercial codes. These classical schemes are still useful tools for such niche uses as verification of more complex computational models, but there is little likelihood that these older closed-form schemes will one day become more important relative to modern computational approaches.



15-65

Nondeterministic Computational Models All of the computational models presented so far are completely deterministic: the computer program constructs one solution for every set of input data, and the output is completely determined by the values of the input data set (except, of course, for some differences that may be encountered when using a different computer or changing to a different precision for floating-point computation on the same computer). In some problems, the input data can be characterized with sufficient precision so that these deterministic models are sufficient for analysis. In other problems, however, the input data are not known precisely, but are instead given only in a probabilistic sense. In these latter cases, it is more reasonable not to speak of the precise values that define the solution (such as the nodal displacements of a finiteelement model), but instead to consider the problem of determining the probabilistic distribution of these solution components. This nondeterministic approach to finding computational solutions in a probabilistic sense is termed stochastic modeling. Stochastic modeling of mechanical engineering systems is still an emerging field, though related engineering disciplines have seen substantial developments in this area. For example, in the modeling of structural systems subjected to earthquake loads (a field of civil/structural engineering very similar to structural dynamics applications found in mechanical engineering practice), nondeterministic models are commonly used to represent the fact that the precise excitation of an earthquake is never known a priori. Engineers concerned with the reliability of structures subjected to earthquake loads often resort to stochastic modeling techniques to estimate the probabilistic distribution of forces in a structure in order to design the individual component structural members. One area of considerable interest is in developing stochastic finite-element models that will permit using much of the existing knowledge base of deterministic finite-element models toward more general nondeterministic computations that can address directly the probabilistic distribution of finite-element response. One of the main constraints to the practical use of such schemes is that large computational models (e.g., ones with substantial numbers of displacement components) generate stochastic approximations that are computationally intractable because of the immense computational expense required to generate and solve the resulting stochastic equation set. At present, only relatively small problems are commonly solved via stochastic models, but this situation is reminiscent of early developments in computational implementation of finite-element and finite-difference schemes. As computer performance continues to improve, so will the practical utility of stochastic models in engineering.

Time-Dependent and Nonlinear Computational Mechanics Many important problems in mechanical engineering are neither static nor linear-elastic. Mechanical systems undergoing dynamic response or materials deformed past their elastic limit require fundamentally different solution methods than do simpler static or elastic cases. In practice, static and elastic models are often used for initial analysis purposes, and depending upon the analysis results or the solution accuracy required, more complex time-dependent or nonlinear models may be subsequently analyzed. In cases that warrant these more accurate and difficult analysis methods, it is generally a good idea to perform simple static linear analyses first, in order to gain physical intuition into the more difficult problem, and to remove gross modeling errors (such as inconsistent discretizations) before more complex and expensive analyses are performed.

Practical Overview of Time-Dependent and Nonlinear Problems While it may seem unusual to lump nonlinear and time-dependent problems into a single framework, in practice there are many common features in implementing these two disparate solution approaches. In each case, the more complex problem is solved by looping over a sequence of equivalent pseudostatic or quasilinear computational problems in order to approximate time-dependence or nonlinear behavior. In the case of time-dependent problems, the looping amounts to stepping the solution over a discretization of the time domain; in the nonlinear case, the looping represents an iteration scheme used to trade in a complex nonlinear problem for a series of simpler linear ones. In many problems, the response is both


15-66

Secti on 15

time-dependent and nonlinear, and then nested looping schemes are generally utilized, requiring internal iterations to solve each nonlinear step composed within a larger time-marching scheme used to advance through the temporal domain of the problem. Time-dependent problems in computational mechanics are generally solved by discretization of the problem’s history into a set of distinct times, and the time-dependent analysis is carried out by stepping the solution between these discrete times. At each step, the temporal variation of the solution is combined with discrete estimates for the temporal derivatives inherent in the problem, and these composed approximations are utilized to transform the advancement across the time step into a computational form that resembles a traditional static problem. In this manner, the sequential nature of the time-dependent problem is transformed into a series of equivalent pseudostatic problems. Nolinear problems are inherently difficult to solve, as they are commonly ill posed. Nonlinearities are generally accompanied by problems of nonuniqueness (recall that two lines intersect in at most one point, but two curves may intersect at many), and this nonunique character of the solution leads to considerable concerns as to which (if any) of the solutions represents the “real” (feasible) physical state of the problem. In addition, there is little general theory underlying nonlinear solution techniques, and so concrete guarantees that a nonlinear iteration process will converge to a desired solution are generally difficult to obtain.

Test Problems for Time-Dependent Program Evaluation The most important issues relevant for effective solution of time-dependent problems have already been presented and are reiterated here in a high-level setting. In particular, issues of stability and convergence are especially relevant to practical time-stepping schemes, and insuring that the computed solution history is free from unstable artifacts or inaccurate components is the most important aspect of the practical use of time-stepping algorithms. The basic trade-off in time-dependent solution processes is between the desire to minimize the number of time steps required for a particular solution history and the need to minimize the amount of computational effort required to construct the solution at each individual time step. Ideally, it would be possible to achieve both goals simultaneously, but this desirable state is seldom reached in practice. In general, increasing the length of the time step involves performing more work at each step, while minimizing the effort at each individual step is accompanied by a substantial increase in the number of steps required to construct the entire solution history. Understanding the interplay of these two desirable goals constitutes much of the practice of solving time-dependent problems. Since many commercial programs that support time-dependent analysis methods provide some form of automated selection of the time step, it is imperative for the analyst to have some idea of the trade-offs involved in the use of these various time-stepping approaches. Implicit schemes, such as those based upon centered- or backward-difference schemes for approximating temporal derivatives, generally permit taking larger time steps than do explicit schemes, which are often based upon forward-difference approximations. Implicit schemes also require that sets of simultaneous equations be solved to advance the solution across a time step, where explicit schemes require little or no effort of this kind. Therefore, implicit schemes permit fewer steps to be taken with more work per step, where explicit approaches permit rapid advancement of the solution across an attendant larger set of time steps. In general, implicit schemes tend to be more stable than explicit schemes: most practical implicit schemes are unconditionally stable, in that their stability properties do not depend upon the time-step size. Explicit schemes tend to be conditionally stable, with a maximum step size given by a so-called Courant condition : step sizes larger than the critical threshold will result in solution oscillations that can easily dwarf the desired solution response. Centered-difference schemes for time-dependent solution, such as the Crank-Nicolson method used to solve time-dependent heat conduction problems (Ames, 1977) or the Newmark algorithm used to solve structural dynamics problems (Hughes, 1987), are attractive numerical approaches because they possess optimal (quadratic) convergence rates for their time-dependent accuracy behavior. Unfortunately, these optimal error properties are commonly associated with an inability to damp spurious oscillations



15-67

that are generally present in discrete computational models. The problem is less important in heat conduction and other dispersive problems, as the spurious oscillations are generally damped over time. In dynamics applications, however, these oscillations can eventually grow and contaminate the solution, and this effect is especially pronounced in the important nonlinear time-dependent case. For this reason, various schemes have been proposed to generalize the more naive centered-difference approach to permit new schemes that damp unwanted high-frequency artifacts but preserve optimal convergence properties (for example, the Hilber-Hughes-Taylor method is a simple extension of Newmark’s algorithm, but removes virtually all of the oscillation problems encountered with the latter scheme). One of the best ways to determine whether the solution accuracy is being eroded by stability or accuracy concerns is to utilize appropriate visualization programs wherever possible. Undesirable or spurious artifacts are readily observed on many graphical displays of solution history, and such solution visualization schemes should be used whenever possible.

Classification of Nonlinear Mechanical Response Many important problems in computational mechanics are nonlinear. Typical examples include: • Nonlinear materials, where the material parameters (for example, the material compliances) depend upon the displacements • Nonlinear geometry, where large deformations require consideration of deformed geometry in the strain-displacement relations, or where Eulerian coordinate formulations are used (as in fluid mechanics problems, where convection introduces strong nonlinearities into otherwise well-posed problems) • Nonlinear boundary conditions, where the value or type of the boundary condition depends upon the solution of the problem The different types of nonlinearities often lead to disparate solution qualititative behavior. For example, many material nonlinearities (such as the yielding of metals due to plastic deformation) tend to produce nonlinear problems that are reasonably well posed, in that they are relatively simple to solve and tend not to have serious problems with nonuniqueness of the solution or convergence of the nonlinear solution scheme. Alternatively, many geometrically nonlinear problems (such as high Reynolds’ number flow, or arbitrarily large deformations of materials) are considerably more difficult to solve effectively, owing to the presence of alternative (but infeasible) solutions and strong nonlinear effects.

General Overview of Nonlinear Solution Schemes It is possible to have problems where material and geometric nonlinearities are present simultaneously, and this situation is made commonplace by the fact that inelastic material nonlinearities are often accompanied by plastic flow, which may lead to large deformations that necessitate the use of nonlinear strain-displacement relations. Therefore, it is appropriate to consider solution schemes for nonlinear problems that do not depend upon the particular source of the nonlinearity. There are many ways to solve nonlinear problems — it often seems like there are too many schemes, reflecting the important fact that there is little general theory for solving nonlinear problems . Even though there are a wide variety of approaches that can be used to motivate nonlinear solution schemes, one basic fact emerges from all of them: nonlinear problems are generally solved using an iteration scheme. The most common nonlinear iteration schemes are based on Newton’s method , which provides a relatively simple way to convert an intractable nonlinear equation solution process into a sequence of linear solution processes. The ultimate goal is that this sequence of linear solutions will tend to a fixed solution, and that this solution will solve the underlying nonlinear problem. Thus, Newton’s method is based upon a linearization of the nonlinear problem, and it is an especially effective approach in practice because the sequence of linear solutions will often converge quadratically to the nonlinear solution (recall that quadratic rates of convergence are especially attractive, as these schemes cause the error to go to zero rapidly once a good approximation is found). © 1999 by CRC Press LLC

15-68

Secti on 15

Newton’s Finally, a warning on nomenclature ought to be mentioned. Some authors reserve the term Newton’s method for for the iteration scheme resulting from the minimization of a nonquadratic functional such as those that govern many nonlinear problems in solid mechanics. These authors refer to the analogous technique of solving a nonlinear system of equations (which often may not result from a functional extremization problem, as in the case of the Navier-Stokes equations) as Newton-Raphson iteration.

Test Problems for Nonlinear Program Evaluation Just as there is little general theory for solving nonlinear problems, there is little general practice that can be cited to aid the engineer contemplating effective estimation of nonlinear response. Some basic principles based on empirical observations can be given, however, and adherence to these ad hoc guidelines will aid the practicing engineer working in this interesting but difficult field. The most important observation is that it is unusual to be able to solve a complicated nonlinear problem unless one can also solve a simpler version with the intractable nonlinearities removed. This leads to the concept of “sneaking up on” a nonlinear solution by first performing a sequence of problems of increasing modeling complexity and (hopefully) increasing accuracy. For example, in order to find gross modeling errors (such as incorrect discretizations or geometric inconsistencies), it is sufficient to generate a discretization mesh for the problem, but to use a simpler linear model for approximating material or geometric nonlinearities. Once the gross modeling errors have been removed from these simpler (and computationally less expensive) expensive) analyses, more accurate material or geometric models can be constructed from the simpler input data. The results of the simplified analyses may often then be reused to verify the overall mechanical response of the final nonlinear solution. Another important way to verify nonlinear solution behavior occurs in the setting of time-dependent problems, where the nonlinearities evolve over time from an initial linear state. Most time-dependent algorithms are obtained by trading in a complicated historical problem for a sequence of quasistatic solutions, and at each time step, a standard finite-element or finite-difference quasistatic problem is to be solved (this is especially true when implicit time-stepping schemes are used). In this setting, it is desirable to be able to use large time steps so that the entire solution history can be obtained with as little effort as is possible. However, in many problems (most notably, nonlinear stress analyses), the effect of the nonlinearities on each individual quasistatic problems decreases with the size of the time smaller, the time-dependent component of the solution process process becomes more step. As the time step gets smaller, expensive, but each nonlinear iteration scheme generally becomes easier to solve . Therefore, when solving nonlinear time-dependent time-dependent processes, it is important to balance the desire to minimize the number of time steps taken with the goal of more rapid convergence of the nonlinear iterations required at each solution step. Finally, Finally, the use of integrated graphics postprocessing to verify solution behavior is incredibly important in the setting of solving nonlinear problems. The problems of nonuniqueness, localization of response, and solution instabilities are commonly encountered in nonlinear analysis settings, and the use of solution visualization techniques (combined with a good sense of engineering judgment and physical intuition) greatly simplifies the task of dealing with these otherwise intractable difficulties.

Standa Standard rd Packag ckages C riteri riteria a Poor computer acquisition policies can result in spectacular losses for a variety of public and private organizations. Many of these failures arose because empirical concepts developed in the computer industry were not given proper consideration. Guidelines for acquisition of computer hardware and software are outlined below.

Functional Specifications Regardless of whether an application is to be purchased off the shelf or developed for custom use, the process of acquiring computer software begins with a functional specification specification of the role r ole of the software. The end result of this process is termed a “functional requirements document”, and it is a high-level nontechnical enumeration of the goals (“functions”) that the software package is designed to meet. The © 1999 by CRC Press LLC

C o m p u t e r -A -A i d ed E n gi gi n eer i n g

15-69

language used in a functional specification is normally reasonably devoid of any references to specific technological issues. For instance, if the purchase of an application to aid in document preparation at the “XYZ Engineering” company is contemplated, the functional requirements might include such phrases as “be able to import existing documents for future modification” and “provide support for various printers and other output devices normally used at XYZ Engineering.” A good functional specification would not be characterized by “XYZ Engineering should purchase the MicroWizard DocuStuff Version 9.4 software to run on a new WhizBang 9000 Supercomputer:” precise specifications of hardware and software are normally not relevant in a functional specification unless they are used only to indicate the need for back compatibility with existing computer systems. A functional specification should provide a view of the needs of the organization that are to be satisfied. By stating these needs in broad terms, the functional specification admits the widest possible range of hardware and software solutions. Since computer technology changes rapidly, it is essential to keep technical details from creeping into the functional requirements, as these technical requirements may cause useful alternative measures to be overlooked. When the procurement process is for a government agency (where the lead time between identifying the need and purchasing the software or hardware may be a year or more), it is imperative to insulate the statement of need from technical details that may change rapidly over the course of the acquisition process, and functional specifications are an excellent approach toward this important goal.

Technical Specifications The next step in the computer materials acquisition process is the translation of the functional requirements to a technical specification. This step is generally performed immediately before bids are sought, so that the most current technical information will be available for review. All of the relevant technical data that was carefully excluded from the functional specification belong in the technical specification, but care should still be taken to avoid unwarranted detail. It is especially important to avoid placing technical information that is inaccurate into the technical specification, specification, or else the resulting procurement process may be compromised.

Evaluation and Testing Once the technical specification has been finalized, it is either sent to vendors for bidding (in the case of large purchases, where the work of matching specific models and manufacturers of computers can be offloaded to the vendor) or handled internally (for small purchases), where local expertise is used to match the technical requirements with a range of computer models. One important component of the evaluation process for software procurement is regression testing, where existing data sets are migrated to the new application (or computer), analyzed, and output results compared. This process • Aids in evaluating evaluating whether whether the application application is easy to use • Provides verification verification of the the software application’ application’ss capabilities and accuracy accuracy • Gives estimates of performance performance for the the new new application application Regression testing of computational mechanics software is greatly aided by the use of integrated visualization tools. Comparing the outputs of complex simulations from two different codes (or even two different revisions of the same code) can be an incredibly tedious process, but the use of graphical display tools provides considerable help toward accurate implementation of the regression testing process.

Overvi vervie ew of Comp Computer uter Mode odels for for Me Mechanical Engi Enginee neering ring Practi Practice ce The following outline classifies families of computational models in terms of common mechanical engineering problem characteristics. It emphasizes general “rules of thumb”. Although there are instances in which the recommendations below are not optimal, the outline below represents a good starting point for picking the right computational tool for a given task.


15-70

Secti on 15

• Simplicity: Finite-difference models are among the simplest computer models, as they can be derived and implemented directly from the governing diffferential equation whenever the differential form of the boundary-value problem is known. If it is desired to develop, implement, and test a computer model in a hurry, and the problem is well defined in terms of differential equations, finite-difference schemes are a very powerful simulation tool. • Generality: Finite-element models are the most general computational schemes available for mechanical engineers. The mathematical framework of finite-element theory makes it easy to solve coupled problems, as well as problems with discontinuous and singular data. When the underlying problem is intractable in terms of its complexity or material constitution, then finiteelement models are generally the first choice for solution. • Data definition: Depending upon how the data are defined, one computer model may be better than others. If all of the data defining the problem domain are given in terms of surfaces (such as would be obtained from some surface-based CAD solid modeling applications), then boundary element technology may be a good choice if the underlying boundary element package can handle the problem encountered. Alternatively, a finite-element package that automatically generates internal element definition definition from the surface data would be a good choice for such surface-defined modeling. If the data are specified naturally on an unstructured grid, then finite-element finite-element schemes generally are easier to attempt than are finite-difference and finite-volume models. Availability: It is generally a lot easier to use a commercial program to solve a complex mechanical • Availability mechanical engineering problem than it is to develop the requisite modeling capabilities locally. Therefore, one of the most important starting points for solving complex problems is to become aware of the range of existing applications available. The next section provides an outline guide to a wide spectrum of commercial and public-domain computer-aided engineering tools.

Sample Mechanical Engineering Applications The following tables (Tables 15.3.2, 15.3.3, 15.3.4, 15.3.5, and 15.3.6) represent a sampling of available softwar typical mechanical engineering applications. The tables include software for the following tasks: • Computat Computationa ionall solid mechanics mechanics and structural structural analysis analysis • Computat Computationa ionall fluid fluid mechanics mechanics • Computat Computationa ionall electro electromagn magnetics etics • Computat Computationa ionall thermal thermal analysis analysis • Utility software for mechanical mechanical optimization optimization and design These tables only represent a sampling of the state of the software market at the time of publication of this handbook. Since the world of computation and software development proceeds at a rapid pace, it is a good idea to check the current literature (and the addresses listed) to gain a better idea of up-todate information. Finally, there are several abbreviations given in the tables that are enumerated below: • FE — finite-ele finite-element ment applicat application ion • FD — finite finite-dif -differen ference ce applicat application ion • FV — finite-vo finite-volume lume applicati application on • BE — boundaryboundary-elem element ent appli applicati cation on • AN — analytical analytical or semi-ana semi-analyti lytical cal applicat application ion • OPT — design design optimization optimization utility (often (often listed with preferred computational computational model) model)

Selection of Software — Benchmarking Benchmarks are software applications that are used to compare the performance of various computers, or of various operating environments on the same computer. While benchmarks provide a simple means of characterizing computer speed, they are commonly misused and often misunderstood. In particular, © 1999 by CRC Press LLC

15-71


TABLE 15.3.2 Sample Solid Mechanics Applications Program

Type

Applications

Contact Address

HKS, Inc. 1080 Main Street Pawtucket, RI 02860 ADINA 71 Elton Avenue Watertown, MA 02172 ANSYS, Inc. Johnson Road, P.O. Box 65 Houston, PA 15342-0065 Computational Mechanics, Inc. 25 Bridge Street Billerica, MA 01821 Energy Science & Tech. Software Ctr. P.O. Box 1020 Oak Ridge, TN 37831-1020 Livermore Software Tech. Corp. 2876 Waverley Way Livermore, CA 94550 MARC Analysis Corp. 260 Sheridan Avenue, Suite 309 Palo Alto, CA 94306 MacNeal-Schwendler Corp. 815 Colorado Boulevard Los Angeles, CA 90041 MacNeal-Schwendler Corp. 815 Colorado Boulevard Los Angeles, CA 90041 Energy Science & Tech. Software Ctr. P.O. Box 1020 Oak Ridge, TN 37831-1020 Engineering Mechanics Research P.O. Box 696, 1607 East Big Beaver Troy, MI 48099 Research Engineers, Inc. 22700 Savi Ranch Yorba Linda, CA 92687 The Titan Corporation 9410 Topanga Canyon Boulevard, Suite 103 Chatsworth, CA 91311

ABAQUS

FE

General solid mechanics, heat transfer, and coupled thermal/stress problems

ADINA

FE


ANSYS

FE


BEASY

BE

Linear-elastic stress analysis and potential (e.g., thermal) problems

HONDO

FE

Static and dynamic stress analysis

LS-DYNA3D

FE

3D explicit solid dynamics

MARC

FE


MSC/DYTRAN

FE

Coupled solid-fluid transient interactions

MSC/NASTRAN

FE


NIKE 2D/3D

FE

2D/3D implicit solid dynamics

NISA II

FE


STAAD III

FE

Structural analysis and design

STARDYNE

FE

Static and dynamic structural analysis

many standard benchmarks provide information that is not always relevant to the performance issues encountered in mechanical engineering practice. Furthermore, it is easy to generate benchmark figures that are misleading by citing results out of context, since computer performance is often strongly dependent on a variety of factors not immediately apparent from simple benchmark comparisons. Therefore, in this section some representative schemes for comparing computer speed are presented to aid in the important task of accurately gauging computer performance for mechanical engineering practice.

Choice of Problem Test Suite for Benchmarking There are many standard benchmarks commonly used in mechanical engineering applications to estimate the relative performance of various aspects of computers. In particular, there are three common types of numeric operations utilized in engineering computation:


15-72

Secti on 15

TABLE 15.3.3 Sample Fluid Fluid Mechanics Mechanics Applications Applications Program

Type Type

Applications

ADINA-F

FE

Incompressible viscous fluid flow

ANSWER

FV

Laminar or turbulent fluid flow

ANSYS

FE

Fluid flow coupled analyses (among many other capabilities)

ARC2D

FD

Navier-Stokes Navier-Stokes equations in 2D

FDL3D

FD

Navier-Stokes Navier-Stokes equations (various explicit/implicit schemes used)

FIDAP

FE

Fluid flow, flow, heat and mass transfer

FLOW-3D FLOW-3D

FV

Fluid dynamics and heat transfer

FLUENT

FV

Navier-Stokes Navier-Stokes equations

INCA/3D

FV


MSC/DYTRAN MSC/DYTRAN

FE

Coupled solid-fluid transient interactions

NEKTON

FE

3D incompressible fluid flow, flow, heat transfer

NISA/3D-FLUID

FE

General fluid flow and heat transfer

RPLUS

FV

Navier-Stokes Navier-Stokes flows, reacting flows

SPEAR/3D

FV


TEMPEST

FD

3D fluid dynamics and heat transfer

VSAERO

AN

Subsonic aerodynamics

Contact Address

ADINA 71 Elton Avenue Watertown, MA 02172 Analytic and Computational Research 1931 Stradella Road Bel Air, CA 90077 ANSYS, Inc. Johnson Road, P.O. Box 65 Houston, PA 15342-0065 COSMIC University of Georgia 382 East Broad Street, Athens, GA 30602 Wright Laboratory WL/FIM Wright Patterson AFB, OH 45433 Fluid Dynamics International 500 Davis Street, Suite 600 Evanston, IL 60201 Flow Science, Inc. P.O. Box 933, 1325 Trinity Drive Los Alamos, NM 87544 Fluent, Inc. Centerra Resource Park 10 Cavendish Court, Lebanon, NH 03766 Amtec Engineering, Inc. P.O. Box 3633 Bellevue, WA 98009 MacNeal-Schwendler Corp. 815 Colorado Boulevard Boulevard Los Angeles, CA 90041 Fluent, Inc. Centerra Resource Park 10 Cavendish Court, Lebanon, NH 03766 Engineering Mechanics Research P.O. Box 696, 1607 East Big Beaver Troy, MI 48099 NYMA 2001 Aerospace Parkway Brook Park, OH 44136 Amtec Engineering P.O. Box 3633 Bellevue, WA 98009 BATTELLE BATTELLE Pacific NW Laboratories P.O. Box 999 Richland, WA 99352 Analytical Methods, Inc. 2133 152nd Avenue N.E. Redmond, WA 98052

• Integer arithmetic, arithmetic, involving involving the calculation of sums, differences, differences, products, and quotients of numbers that represent signed integral quantities (i.e., numbers that have no decimal point or exponent in their numeric representation) • Floating-point Floating-point arithmetic, which which involves involves the same basic basic arithmetic calculations calculations as integer integer arithmetic, but with operands obtained from numbers represented by the composition of sign, mantissa, and exponent (although the computer represents floating-point numbers internally in base 2 format,


15-73

C o m p u t e r -A -A i d ed E n gi gi n eer i n g

TABLE 15.3.4 Sample Electromagnetics Electromagnetics Applications Applications Program

Type

Applications Applicatio ns

Contact Address

ANSYS, Inc. Johnson Road, P.O. Box 65 Houston, PA 15342-0065 Electro Magnetic Applications, Inc. 7655 West Mississippi Avenue Suite 300 Lakewood, CO 80226 Magsoft Corp. 1223 Peoples Avenue, Avenue, J Bulding Troy, NY 12180 Wright Laboratory WL/FIM Wright Patterson AFB, OH 45433 Energy Science & Tech. Software Ctr. P.O. Box 1020 Oak Ridge, TN 37831-1020 MacNeal-Schwendler Corp. 815 Colorado Boulevard Los Angeles, CA 90041 Engineering Mechanics Research P.O. Box 696, 1607 East Big Beaver Troy, MI 48099 Vector Fields, Inc. 1700 North Farnsworth Avenue Aurora, IL 60505

ANSYS

FE

General electromagnetics (as well as solid, thermal, and fluid analysis)

EMA3D

FD

Maxwell’s Maxwell’s equations

FLUX2D/3D

FE

Static and dynamic electromagnetic fields

MAX3D

FV

Time-dependent Time-dependent Maxwell’s Maxwell’s equations

MAXWELL3

FE

Time-dependent Time-depende nt Maxwell’s equations equation s

MSC/EMAS

FE

Maxwell’s Maxwell’s equations for antennas and electrical systems

NISA/EMAG NISA/EMAG

FE

General electromagnetic problems

TOSCA

FE

3D electrostatics and magnetostatics

it is generally easier to convert these binary quantities to an equivalent base 10 form, so that they are similar to more standard “scientific notation” notation” for numeric representation used in engineering) • Transcendental Transcendental computation, computation, involving involving floating-point floating-point results utilizing more complex complex mathematical mathematical functions, such as trigonometric functions, roots, exponentials, and logarithms (transcendental calculations can be loosely defined as those that cannot be implemented using a finite number of algebraic computational operations) Each of these classes of numeric computation has particular characteristics: for instance, integer arithmetic is the simplest and fastest type of numeric calculation, as this class of operand does not require manipulation of exponents and mantissas (which often must be renormalized after calculations). Transcendental calculations are the most expensive native numeric operation on computers appropriate for engineering computation, and the speed of this class of operation is often independent of the performance of integer and floating-point arithmetic (owing to the presence and quality of specialized transcendental hardware available to speed up this class of computation). Most algorithms involved in any branch of computing involve substantial integer arithmetic, so nearly all aspects of computing performance increase as integer arithmetic improves. Many common forms of computer use (such as word processing or some drawing packages) require little or no floating-point calculation, so these applications have performance characteristics largely independent of the speed of a computer’s computer’s floatingpoint arithmetic hardware. Most mechanical engineering applications (and especially computational mechanics software) are highly dependent on floating-point performance issues, and so measuring the floating-point speed of computers is generally important in mechanical engineering settings. While many floating-point applications in mechanical engineering involve negligible transcendental calculation (for example, most finiteelement or finite-difference schemes involve involve little or no transcendental results), there are some particular software packages that require substantial amounts of transcendental computation (for example, Fourier Series approximations, which require large-scale evaluation of trigonometric functions). Depending upon


15-74

Secti on 15

TABLE 15.3.5 Sample Thermal Applications Applications Program

Type Type

Applications

ABAQUS ABAQUS

FE

Heat transfer, as well as solid mechanics and coupled thermal/stress problems

ADINA

FE


ANSYS

FE


BEASY

BE

Potential simulations (including thermal) and linear-elastic stress analysis

MARC

FE


MSC/NASTRAN MSC/NASTRAN

FE


NISA II

FE


TACO3D

FE

Heat transfer transfe r

TAU

FE


TMG

FD


Contact Address

HKS, Inc. 1080 Main Street Pawtucket, RI 02860 ADINA 71 Elton Avenue Watertown, MA 02172 ANSYS, Inc. Johnson Road, P.O. Box 65 Houston, PA 15342-0065 Computational Mechanics, Inc. 25 Bridge Street Billerica, MA 01821 MARC Analysis Corp. 260 Sheridan Avenue, Suite 309 Palo Alto, CA 94306 MacNeal-Schwendler Corp. 815 Colorado Boulevard Boulevard Los Angeles, CA 90041 Engineering Mechanics Research P.O. Box 696, 1607 East Big Beaver Troy, MI 48099 Energy Science & Tech. Software Ctr. P.O. Box 1020 Oak Ridge, TN 37831-1020 AEA Technology Risley Warrington Cheshire, England WA3 6AT MAY MAYA Heat Transfer Tech. Ltd. 43 Thornhill Montreal, Quebec Canada H3Y 2E3

the types of calculations expected, various benchmarks for engineering computation have been commonly used for decades, including: • LINPACK LINPACK benchmarks, benchmarks, which measure measure a mix of integer integer and floating-point instructions instructions that are commonly associated with manipulation manipulation of matrices such as those resulting from many engineerengineering and scientific applications. LINPACK benchmarks are generally reported in terms of the number of floating-point operations performed per second (generally abbreviated as FLOPS, or MFLOPS and GFLOPS, as typical modern computers execute millions or billions of these operations per second). • Whetstone benchmarks, benchmarks, which (supposedly) measure measure an instruction instruction mix representati representative ve of engiengineering and scientific computation, but with a considerably simpler implementation than that available for the complicated LINPACK estimate. (Whetstone benchmarks are reported in terms of the number of Whetstones performed per second). • Savage Savage benchmarks, which which measure both transcendental transcendental performance performance and round-off round-off error in this component of floating-point computation. The Savage benchmark is especially simple, and because of its simplicity, its performance estimates are heavily dependent upon compiler technology quality. • Pure-integer benchmarks, such as the Sieve Sieve of Eratosthenes, Eratosthenes, which require require no floating-point floating-point computation at all, measuring only the speed of integer arithmetic. Integer benchmarks are generally the most commonly quoted measures of computer performance, but these benchmarks are often only of marginal utility in “real-world” mechanical engineering applications, as the © 1999 by CRC Press LLC

15-75


TABLE 15.3.6 Sample Optimization Utilities Program

Type

Applications

Contact Address

ASTROS

FE OPT

Preliminary structural design or structural modification

CSAR/OPTIM2

FE OPT

Automated optimal structural design for NASTRAN

DOT

OPT

General-purpose numerical optimizer suitable for use with other programs

GENESIS

FE OPT

General-purpose structural optimization

OPTDES

OPT

Design and optimization toolbox

OPTISTRUCT

FE OPT

Optimum structural design with finite elements

STARSTRUC

FE OPT

Structural optimization application

USAF WL/FIBRA Wright Laboratory Wright Patterson AFB, OH 45433 Computerized Structural Analysis Corp. 28035 Dorothy Drive Agoura Hills, CA 91301 Vanderplaats, Miura & Associates 1767 S. 8th Street , Suite M200 Colorado Springs, CO 80906 Vanderplaats, Miura & Associates 1767 S. 8th Street , Suite M200 Colorado Springs, CO 80906 MGA Software 200 Baker Avenue Concord, MA 01742 Altair Engineering 1757 Maplelawn Drive Troy, MI 48084 Zentech Incorporated 8582 Katy Freeway, Suite 205 Houston, TX 77024

instruction mix of engineering calculations usually involves a considerable proportion of floatingpoint computation. While these and other benchmarks are commonly quoted and compared, there are many practical problems with their use. Many benchmarks may exhibit wildly different values depending upon minor modifications of the source code, and hence may lead to inaccurate results. For instance, in the C language implementation of many matrix benchmarks, various ways of declaring integer subscripts to be used as matrix indices can result in substantial changes in the performance measured. Since the C language specification includes a “register” declaration (which advises the compiler that the integer variable will be used often, and is hence best placed in a fast on-chip storage location such as a register, instead of being stored in slower main random-access-memory), the use of “register” declarations for some benchmarks will result in substantial speed-ups on many CPUs that contain many general-purpose registers. In some cases, published comparisons are based on a “lowest-common-denominator” approach, so that if one CPU doesn’t support general-purpose register allocation (for example, many earlier Intel CPU designs), this feature is disallowed on all CPUs compared, which can give rise to misleading performance results. In order to remove some of these cross-platform performance problems, better benchmarking schemes have evolved. One improved scheme involves standardized integer and floating-point calculations measured in “SpecMarks”, after the computer-industry standards organization (i.e., the Standard Performance Evaluation Corporation) that proposes them. These benchmarks are termed the SpecInt and SpecFp, and measure integer and floating-point performance, respectively. The standards are updated every few years, as CPU manufacturers often implement design features specifically oriented to improve these important benchmarks (it should be noted that the problem of hardware manufacturers tuning designs to improve standard benchmark performance is a widespread one and is not only encountered among CPU vendors). The particular benchmark is generally suffixed with the year of its standardization (e.g., SpecInt95 for the 1995 version of the integer benchmark suite). SpecMark benchmarks are widely quoted figures available for various processors, and the SpecMark family has been evolving to model more accurately the increasingly complicated schemes available with modern CPU architectures to speed up overall computational performance. Unfortunately, many published SpecMark benchmarks are given


15-76

Secti on 15

only for integer performance, so the important issue of floating-point speed may not be available without more detailed research efforts. For practicing mechanical engineers, the best benchmarks are those that most accurately reflect the computational characteristics of the problems encountered. One good way to measure the relative performance of various computers is to perform large-scale simulations of typical practical problems on the individual computer platforms. The best comparisons are obtained using the same software package on each computer, but if this is not possible, different packages can be run of different machines and the overall results compared (this latter case results in a higher uncertainty, as differences between the individual software implementations may cloud issues of hardware performance). The wider the range of problems run, the better estimate of relative performance that will be obtained. These larger-scale benchmarks can be supplemented with simpler benchmarks such as those discussed above to obtain an estimate of relative computer performance characteristics.

Accurate Measurement of Program Performance Benchmark estimates of computer performance are a useful means for evaluating computer quality, but there are additional considerations to estimate their reliability. In particular, many features available on modern computer conspire to complicate the analysis and interpretation of standard benchmark measures. Some of these issues are addressed below. First, one must consider the hardware and software environment utilized on the computer compared. Different computers provide different support for various types of numeric computation, and these disparate levels of support may substantially alter benchmark results. For instance, many older computers store integers as 16-bit quantities, where more modern computers use 32- and 64-bit storage locations to represent integers. Other things being equal, it is a lot easier to manipulate 16-bit integers than longer representations, and so benchmarks that do not require any integers longer than 16 bits (e.g., the Sieve of Erasthosenes utilized to find all of the primes smaller than 65,536 = 216) may give potentially inaccurate results, especially if problems requiring manipulation of integers larger than 65,536 will be required (this latter case occurs nearly always in engineering practice). In order to compare benchmarks accurately, it is important to know some background information concerning the range of numeric representations used in the published results, and how this range corresponds to expected computational practice and to the ranges readily implemented on a particular CPU. In addition, different types of operating systems can also influence performance of benchmarks. Modern preemptive multitasking operating systems slightly compromise program execution speed by adding the overhead effort of a scheduler subsystem (these and other operating systems principles are detailed later in this chapter), and this additional operating system software effort simultaneously improves the overall quality of the operating environment of the computer, while potentially degrading its numeric performance. If a benchmark requires substantial amounts of random access memory (such as the LINPACK benchmarks, where large quantities of matrix storage must be allocated), then operating systems that implement protected paged virtual-memory subsystems may exhibit substantial slowdowns, especially if the computer’s physical memory is smaller than the virtual memory demanded by the benchmark application. In these cases, the benchmark actually measures a complex combination of CPU, operating system, and disk subsystem performance, as the memory is paged from memory to disk and back by the virtual memory resource subsystem. Finally, the computer language utilized to implement the benchmark may alter the results as well. This phenomenon may be due to obvious causes (such as the overall quality of available compilers, which may penalize newer but faster CPUs that do not have carefully optimized native compilers available relative to slower but more mature platforms), or more subtle effects (such as the original C language specification, which required all floating-point arithmetic to be done in more accurate but less efficient double-precision storage — this feature of the C language often results in slower performance on some benchmarks than that obtained by using single-precision arithmetic, which is the usual default in the FORTRAN language).



15-77

Cross-Platform Comparison of Benchmark Metrics In addition to specific computer software and hardware issues outlined above, there are other important factors that govern comparisons of benchmarks run on different types of computers. When considering performance analyses of different computer platforms, it is important to account for such factors as: • Presence or absence of specialized hardware, such as floating-point processors, vector processors, or other numeric accelerators • Relative quality of optimizing compilers available for the individual platforms • Differences among operating system overhead for the various computers to be compared • Specialized hardware for auxiliary tasks, such as input/output accelerators for problems requiring substantial access to input/output subsystems (for example, mainframes and supercomputers often have only marginally better raw floating-point performance than many workstations and high-end PCs, but for more realistic problems involving substantial transfer of data, these more expensive computers are considerably faster than simple benchmarks generally indicate) Many of these specific hardware issues are outlined in the next section of this chapter, but all of them should be investigated to insure that accurate benchmarks comparisons are measured. In all cases, the basic principle is to be able to normalize the benchmark results to account for variations in the equipment tested (vs. what might be purchased), as well as trade-offs in performance due to desirable features (such as preemptive multitasking resources in an operating system). A benchmark suite containing a range of applications that exercise the aspects of computer performance that are of practical importance in the particular mechanical engineering enterprise can be a useful tool for evaluating relative performance of different computers, different operating environments, and different software applications.


15-78

Secti on 15

15.4 Computer Intelligence Computer intelligence encompasses a wide variety of thought and practice, ranging from philosophical considerations of whether computers are capable of thought to the implementations of complex programs that can play chess as well as virtually any human being. On a purely pragmatic level, computer intelligence can be considered as including nearly every application of computation found in this chapter, as all of the speedy calculations inherent in large-scale computer models can be viewed as the leveraging of the natural (but slow) computational paradigms used by humans to solve problems for centuries. A more narrow and useful view of computer intelligence can be developed by considering the computer as an approximation to a thinking machine, in that computer intelligence can be limited to considerations of simulations of higher-level human activities such as judgment and decision making, instead of the rote issues of multiplication and addition. The narrowext viewpoint of computer intelligence (often connected with the concept of “strong artificial intelligence”) is the belief that computers are actually capable of true thought, just as humans are. In this section, the intermediate philosophy of so-called “weak artificial intelligence” is considered, by which computers are utilized as useful adjuncts for modeling high-level human activities such as decision making. This practical approach to machine intelligence relegates purely computational issues (such as the computational mechanics applications of the last section) to “nonintelligent” status, yet sidesteps the philosophical quagmire of whether the computer is actually thinking. In addition, there are many other topics in the field of artificial intelligence, such as autonomous robots, machine vision, and intelligent control systems, that are addressed elsewhere in this handbook. Finally, the field of artificial intelligence is one of the richest and most diverse areas of research in computer science, with applications that span the full range of human endeavor; the material presented in this section is necessarily only a brief introduction to a few specific areas of interest to practicing mechanical engineers. Broader and deeper treatments of this important field can be found in references such as Shapiro (1992) and Kurzweil (1990).

Artificial Intelligence Considerations of artificial computer intelligence often begin with the famous “Turing test,” in which a computer is judged to be capable of thought if and only if expert human judges (who are carefully insulated from being able to sense whether they are dealing with another human or with a computer) pose a series of questions and receive corresponding answers: if they cannot determine whether the questions were answered by a human or a computer, then the computer is judged to be capable of human thought. Although no computer has passed the Turing test (and it is implicitly assumed that the question “are you a human or a computer?” is disallowed), computers seem to be gaining ground. A simpler motivation is to consider the task of making machines “intelligent”, in that they behave in intuitive and predictable ways, much like people behave (or in some cases, how we wish people would behave). In this broader sense, artificial intelligence ranges in mechanical engineering application all the way from robotics, where machines behave as highly skilled machinists and industrial technicians, to computer interfaces, where such desirable characteristics as consistency and “user friendliness” can be seen as emulating desirable human traits in software.

Classification of Artificial Intelligence Methods There are many facets of artificial intelligence, and only a few will be outlined below. The various threads that constitute this important field include (but are not necessarily limited to): • Expert systems, which attempt to emulate the decision-making capacities of human experts • Neural networks, which mimic the perceived operation of human brains in the hope that computers can become self-learning



15-79

• Fuzzy logic, which utilizes generalizations of classical mathematics to develop models capable of handling imprecise or incomplete data • Data mining, which involves seeking implicitly defined new patterns in existing large data sets • Symbolic mathematics, which utilizes computers to perform many of the most difficult aspects of mathematical derivations, such as integration and algebraic manipulation • Machine vision (or computer vision), where visual pattern-seeking algorithms are used to approximate human visual processing

Comparison of Artificial Intelligence and Computational Science Artificial intelligence and computational science are two contrasting approaches to the same problem in engineering: leveraging the productivity of human engineers by efficient utilization of computer technology. How this augmenting of human efforts is realized is vastly different between the two approaches, however. In artificial intelligence applications, the typical rationale for the computer application is to eliminate wholesale human interaction from some component of the engineering analysis or design process. As a concrete example, expert systems used in design applications have the general goal of codifying the rules and inferences made by a human engineering “expert” into a computer implementation that no longer requires that the engineer make those design decisions. On the other hand, computational science (which represents the integration of high-level engineering knowledge and judgment, relevant computer science, and mathematical numerical analysis) is motivated by the desire to immerse the engineer in the problem-solving process by off-loading the difficult or tedious aspects of the engineering workflow to the computer, while letting the human engineer make the high-level decisions supported by computer tools. This process of putting the engineer into the design/analysis loop (instead of the artificial intelligence motivation of removing engineers from the same process) leads to the class of computer-assisted engineering applications collectively termed “engineer in the loop” solutions. Several particular examples of engineer-in-the-loop applications to computer-aided drafting and design are presented in a later section of this chapter.

Expert Systems in Mechanical Engineering Design Expert systems are one of the oldest and most successful applications of artificial intelligence. Expert systems have been used in such diverse fields as engineering, medicine, and finance, and their range of applicability is enormous. There is an incredible variety of software tools available for doing expert systems development, and this rich library of development tools makes this field especially productive for generating artificial intelligence applications. A substantial component of artificial intelligence practice arises from expert systems, including efforts to develop these applications as well as research in competing technologies (such as neural networks) that have developed at least in part as a reaction to the limitations of expert systems approaches to computer intelligence solutions.

Overview of Expert Systems Methods A simple schematic of an expert system is shown in Figure 15.4.1. There are three fundamental components of the system: a knowledge base representing the concrete expression of rules known to a human expert (and previously communicated to the computer), an inference engine that encapsulates the “how” of the problem-solving process that the expert system is designed to implement, and a data base representing the data relevant to the problem at hand (such as material parameters for a mechanical design expert system, or answers to questions from a sick human patient for a medical diagnostic application). Other important components (such as input/output systems or the computer itself) are not shown in this simplified figure. The expert system uses reasoning based on the rules present in the knowledge base, along with the data at hand, to arrive at appropriate output in the form of decisions, designs, or checks of specification. Once implemented, a well-designed expert system often works very well, but the process of programming such a system is often very difficult. In addition to the obvious aspects of the problem, including


15-80

Secti on 15

Result Results s Inference Engine

Knowledge Base

Data (static and case-specific)

FIGURE 15.4.1 Schematic representation of an expert system.

implementing the data base, there are other nontrivial issues that must be solved, such as coaxing information out of experts who are not always sure what they are doing when they make informed judgments. While programming expert systems is a complicated task, any incomplete progress on elucidating rules for the knowledge base or implementation of an appropriate inference engine may ultimately compromise the overall utility of the resulting expert system.

Advantages and Disadvantages of Expert Systems in Engineering The main advantage of expert systems is that they permit an incredible leveraging of human expertise. Because they are software systems, they are readily cloned (copied) and they don’t forget or misrepresent what they’ve been taught. This amplification of the efforts of the human experts that were used to create the expert system’s knowledge base is frozen within the expert system, and can be readily generalized to include new information or modified to accommodate new ways of dealing with old situations. Human beings have a certain amount of psychological inertia that often prevents them from learning “new tricks”, but this problem does not affect expert systems. In addition, other human foibles, such as emotion or indigestion, can foil the opinions of human experts, but expert systems are completely consistent in their exercise of computer decision-making skills. Finally, expert systems are readily scalable to take advantage of faster computers or parallel computational resources, which permits them to solve larger or more complicated problems than human experts could possibly handle. The biggest disadvantage of expert systems is that they represent only the knowledge base that has been programmed into them, so that such peculiarly human features as engineering judgment or creative problem-solving (which are often important components of engineering decision-making practice) are notoriously absent in this class of artificial intelligence. Another serious disadvantage of expert systems is that they require prodigious amounts of training, which makes their development and implementation costs large for appropriately complex problems. The latter trait of not being capable of autonomous learning is such an important limitation of expert systems approaches that the field of neural networks has developed in large part to remedy this important shortcoming of expert systems technology.

Sample Applications of Expert Systems in Engineering Expert systems are among the most successful implementations of artificial intelligence, and along with this success has come a wide range of problems that have been shown to be amenable to solution using expert systems technology. Areas in which expert systems have been utilized include engineering design (usually in settings of limited scope, where the rules of practice for design can be readily articulated for programming an expert system), management (where expert systems-based decision-making tools have enjoyed considerable success), biomedicine (where expert systems for diagnostic applications have worked well in practice), and finance (where expert systems can be interfaced with computer models for financial modeling to elicit information that would be too complex for most humans to discern). In addition, research oriented toward using expert systems in conjunction with fuzzy logic has shown


15-81


considerable promise for generalizing expert systems approaches to handle noisy, poorly specified, or incomplete data.

Neural Network Simulations Neural networks represent a promising approach to developing artificial intelligence applications in engineering, and neural nets have many characteristics that are very different from traditional expert system-based solutions. The basic principles of neural networks are derived from inquiries into the nature of biological neural networks such as the human brain. These biological systems are not well understood, but are believed to function efficiently because of the web-like system of interconnected nerve cells (“neurons”), which differs markedly from the regular topology of most conventional computers. Artificial computer-based neural networks represent an attempt to capture some of the beneficial characteristics of human thinking, such as autonomous programming and simple pattern-based learning, by mimicking what is known of the human brain. There are many good introductory references to the basic principles of neural network modeling, including books by Fausett (1994) and Wasserman (1989).

Overview of Neural Network Modeling A computational neural network can be idealized as a three-layer system, consisting of individual processors, termed units, and a web of communications circuitry, called connections. The topology of the network is diagrammed in Figure 15.4.2. The individual processors operate only on the data that they store locally or that they send and receive via the communications web. This distributed memory architecture makes neural network computing readily parallelizable. In practice, the hidden layer that connects the input and output layers may be composed of a variety of individual component layers, but this aspect of the hidden layer’s internal structure can be ignored in this elementary overview of neural networks.

Output Data Output Layer Hidden Layer(s) Input Layer Input Data

In the interest of clarity, not all connections are shown in this diagram

FIGURE 15.4.2 Schematic representation of a neural network.

While neural networks are theoretically capable of performing standard deterministic computation (such as the numeric algorithms used in computational mechanics), in practice neural schemes cannot presently compete with traditional computer architectures for these relatively straightforward tasks. It is in artificial intelligence applications that neural networks are used primarily, because they have an important advantage over virtually every other computational model: neural networks learn in a very natural and relatively autonomous fashion. In many regards, neural networks are self-programming, and © 1999 by CRC Press LLC

15-82

Secti on 15

this incredible characteristic makes them very useful in practical computer intelligence applications. In simple terms, they learn by example and develop the capacity to generalize what they have learned to new situations. The mechanism by which the most common forms of neural networks learn to solve a problem is relatively straightforward and similar to human learning: a battery of training examples are fed into the inputs of the neural network, while corresponding outputs are compared to known “correct” values. An alternative mathematical interpretation of this learning is that a weighted sum of the inputs is computed and filtered in a nonlinear manner through the hidden layers to the output layer, and this output response is compared to known output patterns in order to compute an error measure. This learning process is repeated many times utilizing some form of error minimization process to perform a nonlinear regression on the problem data, until the response of the network is sufficiently close to the desired response on all of the sample learning cases. At this point, the system has been trained to solve some set of problems, in that it can generate outputs for any set of input data. The technique described above is termed “backpropagation of error” and is commonly used to develop and train neural network models. In practice, neural networks are not quite this simple to program, as there are many practical issues that must be contended with, and solving these difficult problems is an area of active research in the neural network intelligence field. The whole issue of how the weights are assigned, propagated through the model, and how they evolve to yield an accurate regression of output response upon input data has been glossed over, as has the more vexing problem of how best to train the network to learn autonomously instead of simply memorizing the peculiarities of the training ensemble; this last undesirable trait is termed overfitting and is an important stumbling block in autonomous neural network development. Regardless of these practical considerations, the fact that neural networks are easy to construct and straightforward to program has made them one of the fastest-growing and most important areas of application of computer intelligence.

Advantages and Disadvantages of Neural Networks in Engineering The most obvious advantage of neural networks is that they are very simple to implement and to program. Since they are readily parallelizable and extremely simple to train, they can be easily applied to a wide variety of useful applications requiring pattern matching and machine recognition skills. Neural networks are also inherently scalable, in that their distributed architecture makes them easy to adapt to large problems. One of the most important disadvantages of neural-network systems is that they are presently used only for certain classes of artificial intelligence problems: this limitation arises from their simple architecture and the difficulty of a completely rigorous understanding of how neural networks work. Other important disadvantages include difficult considerations of topology, number and type of connections, training methods, and avoidance of pathological behaviors such as overfitting. As neural networks become more commonplace and well understood, some of these disadvantages should become less important.

Sample Applications of Neural Networks in Engineering In addition to the obvious examples of pattern matching in production and quality control, neural networks have found wide acceptance in a variety of important engineering roles. Other pattern-matching applications commonly occur in imaging problems, and neural networks have performed well in these cases. In addition, neural networks are natural candidates for use in computer-aided decision-making applications, including management and business decision-making cases. In these settings, other computer programs (such as computer analysis programs) may be utilized to generate case studies to be used to train the neural network, and the resulting artificial intelligence application can readily determine reasonable results from generalization of the training examples. When decisions are to be made based on running very expensive computer programs (such as nonlinear transient engineering analysis programs discussed in the computational mechanics section of this chapter), it is often more efficient to run a suite



15-83

of training problems, and then let a large neural network handle the prediction of results from other values of input data without rerunning the original analysis application.

Fuzzy Logic and Other Statistical Methods Fuzzy logic represents an extension of the principles of classical mathematics and statistics to handle “real-world” systems, which are often imprecisely defined and poorly delineated. In simple terms, fuzzy logic achieves this generalization of traditional logic by replacing Boolean values of “either true or false” with a continuous spectrum of “partially true and partially false.” A common analogy is to think of traditional statistical principles as based on black and white issues (each premise is either true or false), while fuzzy logic allows premises to take on different shades of gray (ranging continuously from black to white) and permits more realistic responses to be captured within its conceptual framework. For example, such imprecise and yet common qualifiers as “slightly” and “extremely” are readily handled within the framework of fuzzy methods, yet cause considerable difficulties for many traditional alternative modeling schemes. Engineering systems based on fuzzy logic represent an intermediate state between traditional mathematical representations, such as standard deterministic design and analysis techniques, and purely rulebased representations, such as expert systems. In principle, fuzzy logic methods are superficially similar to expert systems in that they are both dependent upon artificial intelligence and both remove the engineer from many aspects of the design process. In practice, however, fuzzy systems are more closely related to neural networks than expert systems, as fuzzy models permit considerable automation of the process of converting descriptions of system behavior into a corresponding mathematical model. There are many good references on fuzzy logic fundamentals (e.g., Klir and Folger, 1988).

Overview of Fuzzy Set Theory and Fuzzy Logic Principles In traditional set theory, objects are categorized as either members of a set or of its complement (i.e., everything in the universe except the set in question). In real-life applications, it is much more difficult to categorize whether anything is a member of a set. In most practical applications, engineers are interested in determining quickly whether objects are members of a set, and such determinations are naturally “fuzzy,” both in the fact that they may be imprecise in their underlying definitions, and in the recognition that the test for set membership may be carried out only on small samples taken from a larger product population. In order to permit modeling mathematical constructs based on such incomplete, poorly defined, or noisy data, fuzzy set theory and fuzzy logic were developed (see Section 19.15). In a similar manner, traditional mathematical logic represents premises as either true or false. Fuzzy logic recasts these extremes by considering the degree of truth of individual premises as a spectrum of numbers ranging from zero to one. The theory of fuzzy logic is based on extending more complex principles of traditional logic, such as logical inference and Boolean operations, to a wider realm that preserves the structure of the classical approach, yet permits an astonishing amount of realistic behavior by permitting considerable flexibility to model poorly defined systems. There are many connections between fuzzy set theory and fuzzy logic, including the obvious one of logical test of membership in fuzzy sets. Many principles of one field (such as statistical clustering applications from fuzzy set theory) are readily utilized in the other.

Advantages and Disadvantages of Fuzzy Principles in Engineering One of the most important advantages of fuzzy applications in mechanical engineering is their flexibility. Many industrial models represent engineering systems that are either not perfectly characterized or are continuously evolving to better suit changing needs. In these settings, fuzzy systems are often excellent candidates for control and decision making, because the resulting fuzzy model is simpler than traditional approaches, owing to its intrinsic ability to adapt to poorly defined, incomplete, or changing data. Fuzzy inference systems, which are similar to expert systems in that they are utilized for rule-based decision making, are similarly flexible to specify and to implement, especially for engineers experienced in applications of fuzzy principles to engineering control systems. © 1999 by CRC Press LLC

15-84

Secti on 15

Another important advantage of fuzzy models is that they are relatively simple to develop and implement. This advantage is primarily due to the fact that they can more accurately model realistic engineering systems which are difficult to specify either completely or accurately. In general, simpler models are less expensive to develop, and the simplicity of fuzzy models for engineering applications is often directly correlated to improved economies in implementation and maintenance. Probably the most serious disadvantage of fuzzy methods in practice is that they are a relatively new approach to artificial intelligence applications. Because of their novelty, there is not much professional experience with these methods, and a critical mass of software tools for specifying and developing fuzzy models has only recently become available. Until these methods are commonly utilized and understood, it is difficult to categorize their practical advantages and disadvantages.

Sample Applications of Fuzzy Methods in Mechanical Engineering One of the first successful commercial applications of fuzzy logic in an engineering system was developed for autofocusing features in video camcorders. Early autofocus systems for consumer-grade video recorders failed to work in a wide variety of settings, as it is difficult to design a control system for such a complex and dynamic system. In addition to the technical optical issues of rangefinding and focus control, there are other pertinent (and naturally fuzzy) questions that must be solved to enable such automatic devices to work robustly in a motion-recording setting: • What do you focus on when there are many objects in the field of view? • What if some or all of these objects are moving through the field? • What should be done when some objects are approaching and others receding from the viewer? Each of these issues is readily modeled using fuzzy logical principles, and recasting such device control problems into a fuzzy statistical setting often transforms the underlying engineering system into a much simpler formulation. Since simpler models are generally easier to implement and to modify, the cost of developing and extending fuzzy-based engineering models is often substantially lower than the cost of competing traditional control systems. The range of problems thought to be amenable to fuzzy implementations is enormous. Examples range from automotive applications, where sensors generally reflect continuous response instead of Boolean extremes, to tasks requiring categorization of objects as representatives of sets, such as patternmatching applications or quality-control applications. Many household appliances now incorporate fuzzy methods for control, and the growth of this component of artificial-intelligence engineering applications is expected to be rapid. In general, the more imprecise the data available from an engineering system, the more likely a fuzzy approach will work well in comparison to more traditional artificial intelligence approaches.



15-85

15.5 Computer-Aided Design (CAD) Joseph M el l o

Introduction The computer is a powerful tool in the design of mechanical components and entire mechanical engineering systems. There are currently many diverse computer applications that were created to augment the mechanical design process. The development of a mechanical component or system can generally be divided into three tasks: design, analysis, and manufacturing. Historically, the design task was restricted to describing the part geometrically. This task included conceptual sketches, layouts, and detailed drawings, all of which were created on a drawing board. The designer or draftsman generally created drawings using orthographic or axonometric projections of the three-dimensional object being designed or developed. These drawings served to illustrate the mechanical part, and in the case of a detailed dimensional drawing, served as a data base for transferring the design information to the manufacturer or to the shop floor. The drawing performed in the design process has been automated and is now performed using the computer and dedicated software. This automation process is termed computer-aided design, or CAD. CAD generally refers to the geometric description of the part using the computer, but as the computer and its corresponding software have evolved, other tools have been integrated within contemporary CAD systems which are historically categorized as analysis or manufacturing tasks. This form of design, analysis, and manufacturing integration will be discussed later in this section. CAD systems presently fall into two general categories: those based on entities and those based on solids or features. This classification refers to the basic tools used to describe a mechanical part. The entity-based system can be thought of as a three-dimensional electronic drawing board. The designer in this case uses lines, arcs, and curves to describe the part in a manner similar to the way objects were defined on the drawing board. Solid modeler CAD systems take a different approach: the designer in this latter case must think and work more like a manufacturer. The part is created or described using more complicated solids or volumes, for example. Both of these systems are discussed in the following sections.

Entity-Based CAD Systems The entity-based CAD system, as mentioned earlier, can be thought of as a powerful electronic implementation of the drawing board. These systems have been designed for nearly all computer platforms and operating systems. Currently, their low cost and portability allow them to run on an Intel-based personal computer or on an Apple Macintosh, and these advantages result in their availability at a majority of small or medium-sized design engineering or manufacturing firms. The workhouse and a typical example system is the AutoCAD application running on an Intel-based microcomputer using a Pentium microprocessor. Some of these CAD systems have optional digitizer pads that are used in the design process, while most use standard keyboard and mouse hardware for input.

Overview of Modeling and Drafting There are a variety of ways to describe a mechanical component using an entity-based CAD program. For a simple well-defined part, the designer or draftsman may elect to make a two-dimensional (2D) engineering drawing directly. This work is analogous to using a drawing board, in that the designer or draftsman uses basic commands to draft and dimension the part. For a more complex component, the designer may choose to create a three-dimensional (3D) wireframe model of the component, which can be meshed with surfaces. The motivation to do this may be for visualization purposes or for the export of the geometry to an analysis package or a computer-aided manufacturing application. The following material briefly outlines the use of an entity-based CAD system.


15-86

Secti on 15

Two-Dimensional Modeling User Interface. The user interface varies among different systems, but some common user-interface

elements include pull-down menus, iconic menus, and dialog boxes for input of data. Menu systems are manipulated using the mouse and keyboard. Some systems may use a digitizer tablet with icons to select different drawing operations. The software may also provide the experienced user with a command line input prompt as an alternative option to pulling down menus or dialog boxes. Coordinate Systems. The key element of any entity-based CAD application is the Cartesian coordinate

system. All such applications have a default or global system and also allow the user to specify any number of user-defined coordinate systems relative to the global system. Systems usually also offer the user polar coordinate systems. All geometric entity data are referred to a particular coordinate system. Basic Drawing Entities. The designer or draftsman at the drawing board uses a drafting machine to

draw straight lines, a compass or circle template to draw circles and arcs, and a French curve to draft smooth curves. The entity-based CAD system has analogous basic entities which are the line, circle or arc, and spline. Lines are drawn by a variety of methods. The line is defined by its end points in the system coordinates. Basic line construction is often accomplished by pulling down a line construction menu, selecting the option to define the line’s global coordinate end points, and then typing in the Cartesian coordinate pair. Another method for line construction is to use the control points of existing geometry: control points are a line’s or arc’s end or midpoints. All systems allow the user to “snap to” or select control points. Given two lines defined by coordinate end points, one can close in a box with two more lines by selecting the end points of the existing entities. Circles and arcs are constructed in a manner similar to line definition. The most common circle construction is to specify the center point in terms of an active coordinate system and either the radius or diameter. Some other circle construction methods are to define three points on the circumference or two diameter points. There are generally various ways to construct entities in addition to these methods. Arcs are constructed in the same fashion as circles. Some examples of arc construction methods include: start, contour, and end point definition, start and end point radius, or start and end point and angle of arc. This list is not inclusive and of course is system dependent. One important class of arc is the fillet. Most systems offer the user the ability to round a corner by selecting two lines with a common end point and then simply defining the fillet radius. The spline is the mathematical equivalent of using the French curve to fit a smooth curve between points. The CAD user defines the curve’s points and the system fits a cubic spline to these points. There are generally options for specifying a spline’s end point tangents or other end conditions. Design Aids. The utility of a CAD system can be realized when the user appeals to the myriad functions

designed to aid in drawing on the computer. Some typical tools are discussed below. • Layering or layer control gives the designer significant advantages when compared to the drawing board. Layers can be thought of as electronic consecutive sheets of tracing paper. Entities can be placed on different named or numbered layers. Thus the designer can put a whole system design in one file with each component on its own layer. These layers can be turned on or off, and therefore are visible and active or are visible for reference only. • Entity color, thickness, and line type can be set and later changed or modified. Thickness refers to the displayed and plotted line, arc, or spline width. Type is reserved for hidden, centerline, or phantom line types which are generally a variety of dashed lines. • Selection control determines how entities are picked and created. Systems have orthogonal grids analogous to graph paper which can be used to sketch parts. Entity end points can be made to snap to grid points. Grid scales can be modified to suit. Angles can be set to force all geometry to be drawn at an angle to an active coordinate system. When building geometry by selecting end



15-87

points of existing geometry one can filter selections. An example would be to set the appropriate filters so that only entities red in color may be picked or selected. • View control refers to windowing, viewing, zooming, and panning. Generally all parts are created at full scale in a CAD system. One then uses view control to look at the whole part or to zoom in on a small portion of it. These view controls are essential, as even a large computer monitor is deficient in view area compared to an “E” sheet on the drawing board. • Design information menus or calculations are built into CAD systems. These features can be as simple as showing what layer an entity is on or measuring its length or location in Cartesian space. Even the most simple systems can determine the area between groups of entities. Some systems similarly calculate centroids and inertias.

Drafting Drafting is defined herein as operations such as dimensioning, tolerancing, hatching cross-section views, and writing notes and title blocks in the creation of engineering drawings. These tasks are usually performed after the model geometry has been completed. Basic Dimensioning. Using a CAD system does not change where dimensions are placed on a drawing.

The drafter still applies the traditional rules, but the process of creating dimensions changes completely. Since the component’s geometry has been drawn to scale very accurately, a drafter needs to only tell the CAD system where to start, stop, and place the dimension. The system automatically determines the dimension value, draws extension/dimension lines and arrows, and places the dimension text. There are generally five different types of dimensioning commands. Linear dimensions can be aligned with horizontal or vertical geometry. Angular dimensions measure the distance between two nonparallel lines. Radius and diameter commands dimension arcs and circles. Ordinate dimensioning commands call out Cartesian coordinates of entity features such as spline points. These features, combined with the ability to attach notes, allow the drafter to define the part formally. Dimensioning Variables and Standards. Dimensioning variables are system standards that control

dimension format. Examples are arrowhead size, text location, and text size. These are generally controlled by a set of dimensioning subcommands. Most systems’ default settings conform to ANSI Y14.5 standards. CAD systems also are designed to automate geometric dimensioning and tolerancing. Menus and commands create and label reference data. There is usually an extensive ANSI Y14.5 symbol library so that a drafter may add features such as control references, symbols, and finish marks. Drafting Aids. CAD systems are usually equipped with tools or commands to create drafting entities.

These entities include section and center lines. Cross-hatching is generally automated to some degree and a large library of ANSI hatch styles are usually available. If the part drawings are created from a 3D wire frame model as some systems allow, hidden line detection or removal may be automated. This is a very powerful perceptual cue for aiding in the visualization of 3D entities.

Libraries and Data Bases CAD systems are designed to build up data bases and libraries; for example, special symbol libraries can be created. Any component drawn or modeled can be grouped or blocked together, and the resulting part can be saved and imported into future components or drawings as a single entity. It may then be ungrouped or exploded into distinct entities if the designer wishes to modify it to create a different version of the component.

Three-Dimensional Wireframe and Mesh Modeling Entity-based CAD systems generally allow the designer to model in three dimensions. Historically, threedimensional (3D) drafting augmented standard engineering drawings with an isometric or oblique view of the component being described. CAD systems have in a sense reversed this process, as complex parts are now modeled in 3D and then rendered onto engineering drawing views from the 3D data base.


15-88

Secti on 15

3D modeling is a simple extension 2D drawing and modeling using CAD systems. Any of the basic entities of lines, arcs, circles, and splines can be drawn using X, Y, and Z Cartesian coordinates for control points. The basic entities can thus be used to create a “wireframe model”. The wireframe model essentially has every edge of the component or part defined by basic entities. This extension to 3D is simple in theory but is somewhat complex in practice because the interface and display capabilities are two dimensional. Key tools in productive 3D CAD efforts are coordinate system and view angle manipulation. Some systems also allow definition of construction planes which defines a 2D plane in space where all current entities are placed. In addition, some systems allow computer hardware-assisted rotation of viewing which makes visualization of the part in 3D extremely fast. Surfaces. Points, lines, arcs, and splines are used to create wireframes, but surfaces are used to represent

an object accurately. Surfaces can be shaded to render objects in order to make them look realistic or they can be exported to analysis or manufacturing systems. Surfaces on a entity-based system can be idealized as complex entities, as they can be created from wireframe entities such as lines, arcs, and splines or specified directly by input of the particular defining surface parameters. Meshes are arrays of faces. Through the use of meshes, engineers can define multifaceted surfaces as single entities. Some common surface types are • Ruled surface: a surface between two defined curves such as lines, arcs, or splines • Tabulated surface: a surface created by projecting a drafting curve some distance in space • Surface of revolution: a surface created by revolving a generator curve about an axis • Edge-defined coons surface patch: surface created by interpolating with a bicubic function from four adjoining edges defined by lines, arcs, or splines

Solid or Feature-Based CAD Systems CAD systems that are based on solid modeling or feature modeling are significantly different in appearance and use from entity-based systems. There is generally no means to draft a simple part in 2D using a feature-based system, so descriptions of feature-based CAD begins with solid modeling.

Overview of Solid Modeling The design process starts with creating a solid model using solids, primitive shapes, or features. Examples of these include solid extrusions, revolved solids, or solids created from general surfaces. There are also solid removal features such as holes, cuts, and chamfers. One way to build a solid model is to extrude a block and then to cut, make holes, and round the edges in a manner analogous to actual manufacturing, where a block of material may be sawed, drilled, and milled into the desired shape. Some details of creating a solid model follow in a simple case study. It should be noted that some solid modelers are parametric. This allows the part to be reshaped by changing key dimensions. The parametric CAD system automatically reshapes the model or part when the dimensions or parameters are modified. After creation of the solid model the designer can combine solid models or parts to create assemblies. The assembly process with a solid modeler also has analogies to the actual manufacturing assembly process. For example, part surfaces can be mated and aligned to create an assembly. The solid modeler usually has a separate drafting or drawing module that is used to create engineering drawings. Views are generated nearly automatically from the solid model. Reference dimensions can be added along with symbols and other drafting details. In the most powerful systems the drawing, assemblies, and parts are associative; the designer can make changes in parts at the drawing or assembly level, and these changes are automatically reflected in the model. The part, assembly, and drawing features are separate entities but are associated to insure a consistent data base. An important advantage of solid modelers is that one essentially “builds” the parts and assemblies. Shading and viewing from all sides are generally accomplished using simple keyboard commands and standard mouse movements. Complete design information is available from a solid model, including © 1999 by CRC Press LLC


15-89

such parameters as volume, weight, centroids, areas, and inertias. Clearance and interference-checking algorithms prove or test assembly function prior to manufacturing. If detailed computational analyses are to be done or the parts to be made use computer-controlled machinery, complete part or neutral (i.e., intermediate transfer) files can be used to transfer information to analysis or manufacturing applications. The current trend is to integrate CAE and CAM functions with the solid modeler, thus eliminating the need for neutral files.

Hardware and Operating System Requirements The CAD solid modeler generally requires significant hardware and software resources. The typical large CAD system runs optimally on UNIX-based workstations with significant graphics hardware. The recent increased power of personal computers and the availability of Windows NT operating system with its integrated graphic libraries have resulted in the availability of solid modeling on lower-cost RISC workstations and Pentium-based personal computers. This is currently giving small- and mediumsized companies design tools once reserved for aerospace and automaking industries. The software is expensive, but many companies realize payoff if accounting is made for shorter, more efficient design cycles and fewer errors that result from the use of such a system.

Part Solid Modeling Details A case study of the design of a connecting rod will be used in the following section as a concrete demonstration of how solid modeling systems are utilized in practice. The system used in this case study was Parametric Technology Corporation’s Pro/ENGINEER, which is currently considered to be one of the best CAD systems. The hardware used was a Silicon Graphic Indy workstation equipped with a MIPS R4400 processor and 64 megabytes of random access memory. Datums, Sections, and Base Features. Pro/ENGINEER (Pro/E) uses what is termed “feature-based

modeling” to construct a part. This refers to the fact that the part is designed by creating all the features that define the part. One generally begins the model of a part by creating default orthogonal datum planes. Next, a base feature or solid is typically constructed: this is a solid that is approximately the size and shape of the component to be created. Other features are then added to shape the base solid into the part that is desired. The connecting rod’s base feature in this case will be an extrusion that is defined by a section normal to the axis defined by the connecting rod holes. The section for the extrusion is sketched on a default data plane. Mouse and menu picks allow the engineer to sketch the shape using the “sketcher” mode. This part of the process is somewhat similar to entity-based CAD drafting, except that the sketch initially need not be exact. The section is then dimensioned: once again this task is similar to dimensioning on an entity-based system. The part is then “regenerated” or solved mathematically, assuming the given dimensions and alignment to datums are adequate to define the part. The dimensions or “parameters” are then modified to shape and size the part: see Figure 15.5.1 for the connecting rod’s dimensioned section. The resulting extrusion is shown in Figure 15.5.2 as a wireframe plot. The designer has the option of viewing wireframes or shaded solids during the model creation process. Rounds, Holes, and Cuts. The connecting rod can be made lighter in weight with a cut, in this case,

that involves an extrusion that removed material leaving the rod cross section in the form of an “H”. The dimensioned cut section and resulting solid are shown in Figure 15.5.3. Given the cut base feature, rounds can be added in this case to smooth out stress concentrations. These “edge rounds” are constructed by selecting an edge and defining a radius. The solid modeler adds material in the form of a round. Figure 15.5.4 shows the cut and rounded extrusion produced using this approach. Hole features are now used to create the bores for the piston wrist pin and the crankshaft. These hole features are created by defining the hole location, setting the parameters for the diameter, and describing a bore depth or, in this case, by instructing the modeler to drill “through all.” The connecting rod is finished with a collection of cuts, rounds, and chamfers. A shaded image of the finished connecting rod is shown in Figure 15.5.5. Two different versions of the rod are shown. The


15-90

FIGURE 15.5.1 Connecting rod dimensioned section.

FIGURE 15.5.2 Wireframe plot of connecting rod.


Secti on 15


FIGURE 15.5.3 Dimensioned cut rod, solid view.

FIGURE 15.5.4 Edge rounds added to extrusion.


15-91

15-92

Secti on 15

FIGURE 15.5.5 Finished connection rod.

second rendering is a shorter rod with larger main bore and a smaller wrist pin bore. This part was created simply by selecting and changing a few of the defining dimensions and telling the modeler to regenerate the part. This example illustrates the parametric nature of the modeler, which permits design changes to be easily visualized and accommodated. Other Features. The features used to create this simple example are obviously not an inclusive enu-

meration of the solid features available to the designer. A brief list of other key features and corresponding descriptions follows to aid in summarizing the solid modeler’s capabilities. • Surface: extrude, revolve, sweep, or blend sections to create a surface • Shaft: a revolved addition to the part using a specified section • Slot: create a slot from a sketching plane • Protrusion: boss created from the sketching plane by revolving, extruding, sweeping, or blending • Neck: create a groove around a revolved part using a specified axial section • Flange: create a ring around the surface of a revolved part using a specified axial section • Rib: create a rib from a specified sketching plane • Shell: remove the inside of a solid to make it a thin shell • Pipe: create a 3D tube/pipe/wire • Tweak: create part draft, dome, offset, or other surface deformation features Part Modeling Tools. The solid modeler contains a large assortment of tools that can be used to

manipulate the features or solids that comprise the component being designed. A description of a few of these functions follows.



15-93

Solids modelers generally provide a layer control similar to that discussed for entity-based CAD systems. This function is particularly useful for controlling the large number of datums and other features created by a solid modeler. Features may be redefined, reordered, and suppressed or blanked. There are also capabilities built in to allow features to be patterned, copied, or mirrored. Patterns can be used to create splines in a shaft or hole arrays in a flange, for example. Solid protrusions can also be patterned to create spokes on a vehicle wheel. Cross sections can be created by building or selecting a datum plane that passes through the part. The system automatically creates the cross section at this plane. This information can be later used in the drawing mode to create section views at key locations. Pro/ENGINEER has a very powerful utility termed “relations.” A feature’s geometric dimensions can be made functions of other features or geometry. This is similar to having a spread sheet controlling the geometry. Relations can be expressed in terms of algebraic or trigonometric functions as needed. Logic can be built into these relations, as well as utilizing the solution of systems of simultaneous equations.

Assemblies Parts or solid models that have been created can then be put together to form “assemblies.” This process is analogous to assembling actual components in a manufacturing environment. The process starts by placing a base part or component in the assembly. This base part could be the connecting rod example discussed previously. After placement of the base part one can, for example, add or assemble components to the base part such as a wrist pin and piston in this case study. Components are added by defining appropriate constraints. Some typical assembly constraints are • Mate: Planar surfaces are constrained to be coplanar and facing each other. • Align: Planar surfaces are constrained tube coplanar and in the same direction. • Insert: The axis of a feature male part is constrained to be coaxial with a female feature on a parts axis. • Coordinate system: Two data coordinate systems on different components can be aligned. The wrist pin is added to the connecting rod by mating the bore of the rod to the cylindrical surface of the pin and aligning the datum plane at the middle of each component. The piston is added to the assembly in the same way. Figure 15.5.6 shows a shaded view of this example subassembly. It should be noted that changes to any of the components can be made at the assembly level and the associated part is automatically updated even though they are separate entities. There are some advanced tools provided at the assembly level. Material may be added or subtracted from one set of parts to the other set of parts in the assembly. For example, the connecting rod could be added to a block of material such as a mold base. Then the blank could be cut using the connecting rod to form a mold with which to forge or cast the rod. Parts can also be merged at the assembly level, thus becoming essentially one part.

Design Information Tools Pro/Engineer provides utilities that calculate engineering information for both parts and assemblies. There is an option to assign material properties directly or they can be picked from a data base. Given the material data the modeler can generate the mass properties for a part: Figure 15.5.7 shows the mass property results for the connecting rod example. Basic measurement and surface analysis functions are also available, and cross-section properties can also be generated. Assembly mass properties can be calculated in the assembly mode. Powerful clearance and interference calculations can be performed for any combination of subassembly parts, surfaces, or entities — these serve to check the function of hardware before committing to actual manufacturing. In general, the added effort of building solid models is more than offset by the information and checking that are provided.


15-94

Secti on 15

FIGURE 15.5.6 View of example subassembly.

Drawing Documenting designs by creating engineering drawings with a solid modeling system such as Pro/E is done using a drawing module. Since the part is completely described by a solid model, most of the work normally associated with drafting or drawing is already completed. The process of creating a drawing from a part or solid model is outlined briefly below. The first step in drawing creation is to name the drawing, select the drawing size or sheet, and retrieve the appropriate format. Formats are essentially borders and title blocks. A format mode editor exists to create standard or custom formats with any drafting geometry, notes, and call outs desired. Views of the desired model are then placed within the format. The user first places what is called a general view and orients it with view control menu commands. Now the user can place projected views off the first view. The system automatically creates the projected views from the model selected. View types can be projections, auxiliary, or detailed portions of the geometry. View options include full views, broken views, x-sections, or scale settings to scale a particular view independently. Views can subsequently be moved, resized, and modified in a variety of ways. The most important is the drawing scale which the system calculates automatically depending on model size and sheet selected. A new scale can be defined from a modify menu and all drawing views are rescaled accordingly. Dimensions are now placed within the drawing. Since the solid model is dimensioned in the design process, this step simplifies to that of instructing the drawing module to “show all” detailed dimensions. The system then automatically places dimensions on the views defined. The real effort of dimensioning becomes that of cleaning up the dimensions in order to have them to meet traditional drafting standards. Sometimes the dimensions used to model the part are inadequate in a detailed drafting sense, so a complete drafting utility exists to create what are essentially reference dimensions.



15-95

FIGURE 15.5.7 Mass properties calculated for example cross section.

As discussed previously for entity-based CAD systems, the solid modeler drawing or drafting utility has detailed functions designed to create basic dimensions, specify geometric tolerances, and to set data as reference. Large ANSI symbol libraries are also available to aid in the detailing. The part and the drawing exhibit “bi-directional associativity”: if the engineer completes the drawing and then goes back to the part to make modifications, the drawing geometry associated with these changes is automatically updated. In a similar manner, the part definition is changed if a defining dimension is modified on the drawing.

CAD Interface Overview All contemporary CAD systems have utilities to import and export design data. These utilities have translators which support many types of file formats. The most common interfaces and files will be discussed in the following paragraphs. Since the CAD system usually defines the part the focus will be on, export of data and Pro/Engineer will be used as an example. Printing and Plotting. A very important interface is with printing and plotting hardware to get hard

copies of shaded images, wireframe plots, and drawings for use in design reviews and for archiving. Shaded images are commonly written in PostScript page-description format for printing on a color printer with such capabilities. Plot files of objects or parts, drawings, or assemblies can be done with the standard


15-96

Secti on 15

HPGL (Hewlett-Packard Graphics Language) or PostScript formats. Pro/ENGINEER, for example, has specific configuration files for a variety of Hewlett-Packard, Calcomp, Gerber, Tektronix (for shaded images), and Versatec plotters. Computer-Aided Engineering (CAE). It is often desirable to export CAD geometry to other CAD

systems or analysis packages. Example destinations are • Thermal/Structural Finite Element Analysis • Computational Fluid Dynamics Analysis • Moldflow Analysis Packages • Kinematics and Dynamics Programs • Photorealistic Graphics Rendering Programs The most common format to transfer graphic and textual data is the Initial Graphics Exchange Specification (IGES) file format. It is important to determine what type of IGES entities the receiving system desires, then adjust the IGES configuration prior to creation of the file. As an example, a variety of Finite Element Analysis (FEA) packages use an IGES trimmed surface file as opposed to wireframe entities where part edges are output. A finite element model of the case study connecting rod was formulated using an exported IGES trimmed surface file of the Pro/E solid model part file. A stress contour plot of a simple static analysis of this rod model is shown in Figure 15.5.8. The model was automeshed with hexahedral elements directly from the surface files with little user intervention. The meshing procedure took 30 to 40 min to initiate and the automesh time was about 10 hr on a Silicon Graphics Workstation. Most production-quality finite element codes either already have or will eventually possess such capabilities.

FIGURE 15.5.8 Stress contours and geometry of optimized rod.

Data exchange format (DXF) files are also very common and are used to export model and drawing data to products such as AutoCAD or to products that were designed to interface with AutoCAD. Pro/E also has its own neutral file which is a formatted text file containing more design information than an IGES file. Part geometry is formatted so other software packages can use the complete design data.



15-97

Pro/E also directly writes other software package neutral files such as PATRAN geometry files (PATRAN is a generalized finite element pre- and postprocessor). This is only a partial list of export options available. There exists a crucial problem with export, however: associativity is lost. If the part is, for example, exported and analyzed, any subsequent part modification renders the analysis model inaccurate. This is a problem as the current trend is to use computational analysis tools early in the design process instead of using them only as a final check. Presently, there are software package alliances and cooperatives forming that are addressing this problem. This direct integration of analysis packages has been accomplished by Structural Dynamics Research Corporation I-DEAS and Pro/Engineer Mechanica, among others. Once again the Pro/Mechanica integration will be used as an example to review the current capabilities of such systems. The Mechanica packages are thermal, motion simulation, and structural analysis packages that are completely integrated with Pro/E’s solid modeler. Analysis is thus another large set of pull-down menus and dialog boxes within the CAD package. The beauty of the system is that it is a complete bi-directional link, in that design changes made in Pro/E automatically update finite element models or vice versa. This feature greatly simplifies the task of structural design optimization. Mechanica has routines which will optimize and change model geometry based on static stress and structural dynamic considerations. There are practical limitations as Mechanica is currently limited to linear elastic structural analysis. The Mechanica analysis package uses an adaptive p-element, where the order of the tetrahedral finite element is adjusted until convergence is achieved. The adaptive scheme uses up to a ninth-order polynomial in the element formulation. If the model does not converge, the mesh can be refined and the analysis tried again.

Computer-Aided Manufacturing (CAM) Parts that are modeled in 3D are generally fabricated with CAM. This fabrication task can involve rapid prototyping, directly machining the part, or mold making to support casting, forging, or injection molding.

Rapid Prototyping Rapid prototyping is a relatively new manufacturing technology which is complementary to CAD solid modeling. A CAD design file of an object is converted into a physical model using special computercontrolled sintering, layering, or deposition processes. SLA stereolithography machines by companies such as 3D Systems convert 3D CAD data of objects into vertical stacks of slices. A computer-controlled low-power ultraviolet laser then traces across photocurable resin solidifying the part one layer or slice at a time. Selective laser sintering and fused deposition processes operate in a similar manner. In all cases, an accurate nonstructural model is created which can be used in design reviews, mock-ups, and prototype assemblies. A physical model such as this is a very powerful tool in early product design reviews and marketing efforts. The interface to rapid prototyping is an SLA or (*.stl) file. SLA files represent the solid model as groups of small polygons that make up the surfaces. The polygons are written to an ASCII text or binary file. Pro/E has an SLA selection in its interface menu. It is important to note that the designer partially controls the quality of the prototype through two variables, the chord height of the tessellated surface and an angle control variable. The connecting rod example is again used to demonstrate the effects of chord height setting in Figure 15.5.9, which shows the polygon surfaces for SLA files with two different chord heights.

Computer Numerical Control Machining Numerical control machining refers to created parts using computer-controlled machines such as mills, lathes, or wire electric discharge machines. Parts or molds are made by machining away material. In the case of complex parts it is essential to transfer CAD geometric data to a machining software package and finally to the computer-controlled machine. A typical machining center has a numerical control machine wired directly to the serial port of a microcomputer. This configuration is termed computer numerical control or CNC, as it allows the machinist to program the machine tool off-line using specialized machining programs. Most CAD © 1999 by CRC Press LLC

15-98

Secti on 15

FIGURE 15.5.9 Polygonal representation for stereolithography.

systems have optional integrated manufacturing modules similar in architecture and use to their integrated analysis packages. There are also a variety of stand-alone machining software packages which accept a spectrum of CAD input in the form of neutral, IGES, and DXF files. These packages or modules can import and create geometry, as well as determine and simulate cutter paths. As with many CAD programs, these machining applications now have 3D interactive graphic environments. As the programmer generates steps for the machine tool path, 3D models show the part being cut by the tool. Line-by-line programming in a text mode is presently being replaced by graphically selecting geometry, tools, and tool paths. These programs have postprocessors to write the “G and M code” specific to the machine tool being used (“G and M” code is a standard language for programming machine tools). These ASCII text files based on numerical codes using G and M as prefixes form an instruction list for a wide variety of machine tool operations.

Further Information There are a wide variety of excellent references available that summarize many of the principles found in this chapter. For practical discussions of computer technology, the Internet-based UseNet newsgroups form the most detailed and up-to-date sources of information on programming languages, computer architecture, and software engineering. Most UseNet groups provide a list of Frequently Asked Questions (FAQs), which often address introductory issues in considerably more detail than elementary textbooks, and consulting such UseNet FAQs is a good way to begin more detailed study of most of the computational topics outlined in this chapter. Sample UseNet newsgroups include comp.ai (for general information on artificial intelligence research and application), comp.object (for general information on objectoriented programming), and comp.sys.intel (for information regarding Intel hardware). These general UseNet topics are generally further specialized toward more detailed discussions, such as the philosophical information regarding computer intelligence that can be found in comp.ai.philosophy. Since UseNet groups are created (and sometimes disappear) at near-random intervals, it is best to use standard Internet browsing tools to determine the best newsgroups for researching a particular topic. More traditional printed works are available for all the topics found in this chapter. The history and philosophy of software engineering are presented in engaging detail in Yourdon’s Writings of the Revolution: Selected Readings on Software Engineering and Brooks’s classic The Mythical Man-Month . The classic modern reference on object-oriented programming is Booch’s Object-Oriented Analysis and Design, which also contains good descriptions of procedural programming models. An excellent overview of artificial intelligence can be found in Kurzweil’s The Age of Intelligent Machines . One of the most detailed treatments of finite-element modeling available is Hughes’ The Finite Element Method: Linear Static and Dynamic Finite Element Analysis , which presents a comprehensive and detailed view of finite-element modeling as oriented toward mechanical engineering applications, and does an excellent job of presenting time-dependent solution techniques amenable to any numerical discretization approach (including finite-difference methods). There are many standard references on finite-difference methods, including the well-known book by Ames, Numerical Methods for Partial Differential Equations .



15-99

Terms and Associated Acronyms Artificial Intelligence (AI): a spectrum of ideas on the general topic of computer modeling of human intelligence, ranging from “Strong AI” (defined as the premise that computers are capable of emulating human intelligence) to “Weak AI” (defined as the premise that computer can be utilized as useful adjuncts for modeling high-level human activities such as decision-making). Benchmarks: application programs specifically designed to quantify the performance of a particular computer system, or of its component subsystems. Benchmarks provide a convenient means to compare measures of system performance obtained from disparate computer platforms. Boundary-Element Method (BEM): a numerical approximation technique based upon integral equations and related to the finite-element method. Boundary elements possess the advantage of requiring only surface-based representations of the problem domain, in contrast to the volume-oriented data required by finite-element methods. Central Processing Unit (CPU): the main processor (i.e., the “brain”) of a computer, consisting of the hardware necessary to perform the low-level arithmetic and logical operations that form the building blocks of computer software. Compressor/Decompressor (CODEC): a pair of computational algorithms designed to compress the bandwidth required to process large streams of data. The most common applications of CODECs are in computer video/animation applications, where it is physically impractical to process the uncompressed raw data needed to maintain the illusion of continuous motion within a computer animation. Computational Mechanics: the field oriented toward integrating principles of mechanics with tools from computer science and mathematics toward the goal of constructing accurate numerical models of mechanical systems. Computer-Aided Design (CAD): a general term outlining areas where computer technology is used to speed up or eliminate efforts by engineers within the design/analysis cycle. Computer-Aided Engineering (CAE): application of the computer toward general tasks encountered in mechanical engineering, including analysis, design, and production. Computer-Aided Manufacture (CAM): the integration of the computer into the manufacturing process, including such tasks as controlling real-time production devices on the factory floor. Computer-Assisted Software Engineering (CASE): software development tools oriented toward utilizing the computer to perform many rote programming development tasks. Computer Numerical Control (CNC): the creation of mechanical parts using computer-controlled machinery such as lathes, mills, or wire electric discharge machines. Convergence: in the setting of computer-aided engineering, convergence is taken as a measure of how rapidly the computer approximation tends toward the “exact” solution, measured as a function of increased computational effort. Ideally, as more computer effort is expended, the computational approximation rapidly becomes appropriately more accurate. Data base Management: computational techniques specifically oriented toward allocation, manipulation, storage, and management of organized data structures. Discretization: the fundamental tenet of most computational models for physical systems, in which a complex continuous real system is approximated by a simpler discrete replacement. In theory, as the level of refinement of the discretization is increased (i.e., as the discrete components get simultaneously smaller and more numerous), the discrete system more closely approximates the real one. Distributed Multiprocessing: a parallel computer architecture characterized by independent processors working cooperatively on a distributed set of resources (for example, a network of computers, each equipped with its own local memory and input/output devices). In a distributed multiprocessing system, the communication bandwidth of the network connecting the individual CPUs is often the limiting factor in overall performance.


15-100

Secti on 15

Engineer-in-the-Loop: a class of computer-aided design applications oriented toward immersing the engineer into the computational simulation with the goal of separating the rote calculation components of the task from the decision-making processes. The latter efforts are handled by the engineer, while the former are dealt with by the computer. Eulerian Reference Frame: a reference frame attached to a region of space, to be used for constructing computational mechanics approximations. Eulerian reference frames are generally used for fluids, though they may also be profitably utilized in modeling the large deformations of solids. Expert Systems: a class of artificial intelligence applications based on emulating the decision-making capacities of human experts by using specialized computer software for inference and knowledge representation. Expressiveness: the desirable characteristic of a program language’s facility for controlling program execution and abstracting programming functions and data. Finite-Difference Method (FDM): a family of numerical approximation methods based on replacing the differential equation-based statement of a physical problem by a set of discrete difference equations that directly approximate the underlying differential equations. Finite-Element Method (FEM): a family of numerical methods based on approximation of integral statements of the problems of mathematical physics. This emphasis on integral formulations (in contrast to the differential formulations used by finite-difference models) provides considerable numerical advantages, such as better convergence properties and the ability to model discontinuous problem data. Finite-Volume Method (FVM): a family of numerical methods based on integrating the differential statements of physical problems over small subdomains. Finite-volume modeling is essentially a means to maintain the simplicity of formulation of finite-difference models, while permitting realization of some of the advantages of integral finite-element schemes. Fuzzy Methods: computational methods for artificial intelligence that generalize the simple Boolean logical theories that traditionally form the basis of deterministic computer programs. These methods are based on more qualitative (i.e., “fuzzy”) representations of data and instructions than commonly found in conventional computer programs. Graphical User Interface (GUI): a model for software design that emphasizes graphical human/computer interaction through the desired characteristics of responsiveness, intuitiveness, and consistency. Inheritance: a feature of object-oriented programming languages that permits derivation of new objects using a child–parent hierarchy. Inheritance makes is possible to express relationships among objects in a flexible manner that facilitates programmer productivity and the reuse of code. Lagrangian Reference Frame: a reference frame attached to a physical body, to be used for constructing computational mechanics approximations. Lagrangian reference frames are primarily used for solids (where it is relatively easy to track the deformation of the underlying physical domain), and generally result in a simpler formulation of the conservation laws used in engineering mechanicsmultitasking Multiprocessing: the process of distributing threads of execution over different processors on the same computer, or over different computers connected over a network. The various flavors of multiprocessing form the architectural divisions among different types of parallel processing. Multitasking: managing the execution of separate computer 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. Multithreading: managing the execution of separate concurrent threads of program execution by allocating processing time to each thread. This low-level software resource management model forms the basis of many multitasking operating systems and permits various forms of parallel computation by distributing distinct threads over different processors.



15-101

Neural Networks: a class of largely self-programming artificial intelligence applications based on webs of interconnected computational processes. The aggregate goal of the interconnected network of computation is to emulate human thought patterns, and especially the autonomous programming routinely exhibited by humans and notably lacking in computers. Newton-Raphson Iteration: the basic algorithm for solving nonlinear problems, in which a nonlinear equation set is traded for a sequence of linear equation sets, with the ultimate goal of rapid convergence of the linear equation sequence to the solution of the underlying nonlinear problem. Object-Oriented Programming: a standard for software development that emphasizes modeling the data and behavior of the underlying objects that define the program. Object-oriented programs are comprised of a collection of cooperating software objects, with these objects derived from an underlying hierarchical organization of generic classes. Contrast this concept with procedural programming, which uses algorithms as the fundamental component of program architecture. Operating System: the software layers that provide low-level resources for execution of computer programs, including file services for input/output, graphical display routines, scheduling, and memory management. Polymorphism: a feature of object-oriented programming languages where a single name (such as the name of a variable) can be recognized by many different objects that are related by class inheritance. Polymorphism is one of the most important features of object-oriented programming, as it permits many different objects to respond to a common event, a process that is considerably more difficult to implement using procedural programming languages. Portability: the highly desirable program characteristic of ease of implementation on different types of computers. Portable programs are generally written in higher-level computer languages, such as C. Procedural Programming: computer software development oriented toward abstraction of programming function by subdividing the overall task into successively smaller subtasks, which are generically referred to as procedures. Procedures represent the software implementation of algorithms, and hence procedural programming is oriented toward modeling the algorithms of the underlying system. Random Access Memory (RAM): the collection of semiconductor hardware used for memory storage on modern computers. The main memory of a computer is usually composed of Dynamic Random Access Memory (DRAM), which is volatile and does not persist when the power is turned off. Rapid Application Development (RAD): programming tools oriented specifically designed to aid in development of prototype software applications for demonstration and initial application design. Relational Data Base: a standard for data base management emphasizing modeling data by using flexible relations among the various data structures of the program. Schema: the structure of a data base (the term schema generally is taken to mean the structure and organization of the tables in a tabular data base). Software Engineering: the profession concerned with the effective specification, design, implementation, and maintenance of computer programs. Solvability: mathematical conditions relating to the existence and uniqueness of solutions to problems in mathematical physics. Problems that do not possess unique solutions often lead to pathological behavior when implemented on the computer, so determining the solvability characteristics of a problem is an important first step in computational engineering applications. Spiral Model: a standard for the incremental design and implementation of computer programs, characterized by applying regular updates to a flexible design during prototyping and delivery phases. Stability: the numerical characteristic by which errors can be guaranteed not to increase in magnitude as they propagate throughout the mathematical domain of the problem. Unstable methods permit errors to grow until the computed solution may become hopelessly corrupted, while stable methods provide some insurance against this unfortunate outcome. Stress Analysis: a family of computational schemes oriented toward determining the state of stress and deformation of a physical medium. Stress analysis is normally associated with solid mechanics, though its methods can be successfully applied to fluid systems as well. © 1999 by CRC Press LLC

15-102

Secti on 15

Structured Grid: used to characterize finite-difference and finite-volume discretizations, where considerable regularity (such as an evenly gridded rectangular geometry) is imposed on the topological structure of the underlying grid. Structured grids are generally associated with optimal convergence characteristics, but may not accurately represent the geometry of the underlying physical problem. Structured Query Language (SQL): SQL is a standard and portable language for creating and modifying data bases, retrieving information from data bases, and adding information to data bases. Symmetric Multiprocessing (SMP): a parallel computer architecture generally characterized by independent processors working cooperatively on a shared set of resources, such as memory or input/output devices. In a symmetric multiprocessing system, the issue of contention for resources is often the limiting factor in overall performance. Unstructured Grid: used to characterize finite-difference and finite-volume discretizations, where little regularity is imposed on the geometric and topological structure of the underlying grid. Unstructured grids are more easily adapted to realistic problem formulations, but require more effort and often result in poorer convergence characteristics. Vectorization: a process by which certain types of numeric computation (most notably, those involving well-defined operations on vectors) can be internally pipelined on a computer’s processing units, leading to considerable efficiencies in performing the associated vector operations. Virtual Memory: an operating system characteristic where some contents of main memory are temporarily cached on a persistent storage device in order to permit allocation and management of memory exceeding the physically available supply. Virtual Reality: a class of computer graphics applications specifically designed to maintain the illusion of an artificial world in which the user is immersed. Visualization: the graphical representation of data in order to facilitate understanding by human observers. The art and science of visualization exist independently of computers, but their principles are widely used in computer graphics to display the data sets that are commonly encountered in largescale computation. Waterfall Model: a standard for the sequential design and implementation of computer programs, characterized by long lead times to delivery and limited scope for substantial modifications to the program’s function or architecture.

References Ames, W.F. 1977. Numerical Methods for Partial Differential Equations. Academic Press, New York. Apple Computer, Inc. 1985. Inside Macintosh , Vol. 1. Addison-Wesley, Reading, MA. Barton, J.J. and Nackman, L.R. 1994. Scientific and Engineering C++: An Introduction with Advanced Techniques and Examples , Addison-Wesley, Reading, MA. Booch, G. 1994. Object-Oriented Analysis and Design with Applications , 2nd ed. Benjamin/Cummings, Redwood City, CA. Brooks, F.P. 1975. The Mythical Man-Month , Anniversary ed. Addison-Wesley, Reading, MA (original edition published in 1975). Brebbia, C.A. and Dominguez, J. 1989. Boundary Elements: An Introductory Course. McGraw-Hill, New York. DOD Trusted Computer System Evaluation Criteria. December 1985. DOD 5200.28-STD. Fausett, L.V. 1994. Fundamentals of Neural Networks: Architectures, Algorithms, and Applications. Prentice-Hall, Englewood Cliffs, NJ. Foley, J.D. and VanDam, A. 1982. Fundamentals of Interactive Computer Graphics. Addison-Wesley, Reading, MA. Hughes, T.J.R. 1987. The Finite Element Method: Linear Static and Dynamic Finite Element Analysis. Prentice-Hall, Englewood Cliffs, NJ. Humphrey, W.S. 1989. Managing the Software Process. Addison-Wesley, Reading, MA. Kernighan, B.W. and Plauger, P.J. 1976. Software Tools. Addison-Wesley, Reading, MA.


Computer-aided engineering.pdf

Recommend Documents