UFDC Home  Search all Groups  UF Institutional Repository  UF Institutional Repository  UF Theses & Dissertations   Help 
Material Information
Subjects
Notes
Record Information

Full Text 
ANALYSIS OF HIGHWAY BRIDGES USING COMPUTER ASSISTED MODELING, NEURAL NETWORKS, AND DATA COMPRESSION TECHNIQUES By GARY RAPH CONSOLAZIO A DISSERTATION PRESENTED TO THE GRADUATE SCHOOL OF THE UNIVERSITY OF FLORIDA IN PARTIAL FULFILLMENT OF THE REQUIREMENTS FOR THE DEGREE OF DOCTOR OF PHILOSOPHY UNIVERSITY OF FLORIDA Copyright 1995 by Gary Raph Consolazio ACKNOWLEDGMENTS I would like to express my sincere gratitude to Professor Marc I. Hoit for his guidance in both research and professional issues, for his generous support, and for his enthusiastic encouragement throughout the duration of my doctoral program. In addition I would like to express my gratitude to Professor Clifford O. Hays, Jr., for his guidance and support, especially during the initial part of my doctoral program. I would also like to thank Professors Ron A. Cook, John M. Lybas, W. J. Sullivan, and Loc VuQuoc for serving on my committee. I would especially like to thank my wife, Lori, for the enduring patience and support she has shown during my graduate educationone could not possibly hope for a more supportive spouse. I would like to thank my parents, Lynne and Bruce, for instilling in me the importance of an education and my grandfather, William V. Consolazio, for encouraging my interest in science and making it possible for me to pursue an advanced degree. Finally, I would like to thank my friend and colleague Petros Christou and all my other fellow graduate studentsespecially Wilson Moy and Prashant Andradefor their friendship and encouragement. The work presented in this dissertation was partially sponsored by the Florida Department of Transportation. TABLE OF CONTENTS ACKNOWLEDGEMENTS ..................................... ............... iii ABSTRACT ..................... .............. .......... ...............viii CHAPTERS 1 INTRODUCTION ........................................ .................... 1 1.1 Background..................................... ............................ 1 1.1.1 Computer Assisted Bridge Modeling ...................................... 1 1.1.2 Computational Aspects of Highway Bridge Analysis ................. 3 1.2 Present Research..................................... ....................... 6 1.2.1 Computer Assisted Bridge Modeling ....................................... 7 1.2.2 RealTime Data Compression ............................................. 9 1.2.3 Neural Network Equation Solver .........................................12 1.3 Literature Review .........................................................15 1.3.1 Computer Assisted Bridge Modeling .................................... 15 1.3.2 Data Compression in FEA .................................................18 1.3.3 Neural Network Applications in Structural Engineering...............18 2 A PREPROCESSOR FOR BRIDGE MODELING ................................21 2.1 Introduction ........................................................... 21 2.2 Overview of the Bridge Modeling Preprocessor ...............................22 2.3 Design Philosophy of the Preprocessor .........................................25 2.3.1 Internal Preprocessor Databases.................... ....................25 2.3.2 The Basic Model and Extra Members...................................26 2.3.3 Generation................................ ............................ 28 2.3.4 The Preprocessor History File..........................................29 2.4 Common Modeling Features and Concepts......................................30 2.4.1 Bridge Directions................................... ......................31 2.4.2 Zero Skew, Constant Skew, and Variable Skew Bridge Geometry...32 2.4.3 Live Load Models and Full Load Models ..............................33 2.4.4 Live Loads ...........................................................34 2.4.5 Line Loads and Overlay Loads........................ ...................36 2.4.6 Prismatic and Nonprismatic Girders......................................37 2.4.7 Composite Action ..........................................................38 2.5 Modeling Features Specific to Prestressed Concrete Girder Bridges .........40 2.5.1 Cross Sectional Property Databases ....................................40 2.5.2 Pretensioning and PostTensioning .....................................41 2.5.3 Shielding of Pretensioning ........................... ...................42 2.5.4 PostTensioning Termination .........................................43 2.5.5 End Blocks ....................................... .............. 43 2.5.6 Temporary Shoring ........................................................44 2.5.7 Stiffening of the Deck Slab Over the Girder Flanges.................45 2.6 Modeling Features Specific to Steel Girder Bridges ...........................46 2.6.1 Diaphragms ........................ ......... ................... 46 2.6.2 Hinges.................................................... .............. 47 2.6.3 Concrete Creep and Composite Action...................................48 2.7 Modeling Features Specific to Reinforced Concrete TBeam Bridges........49 2.8 Modeling Features Specific to FlatSlab Bridges ...............................50 3 MODELING BRIDGE COMPONENTS .........................................51 3.1 Introduction ........................................ ...................... 51 3.2 Modeling the Common Structural Components.................................51 3.2.1 Modeling the Deck Slab............................ ......................51 3.2.2 Modeling the Girders and Stiffeners......................................54 3.2.3 Modeling the Diaphragms..........................................55 3.2.4 Modeling the Supports..................... .......................57 3.3 Modeling Composite Action................................................ .......58 3.3.1 Modeling Composite Action with the Composite Girder Model ......60 3.3.2 Modeling Composite Action with the Eccentric Girder Model........61 3.4 Modeling Prestressed Concrete Girder Bridge Components .................65 3.4.1 Modeling Prestressing Tendons ...........................................65 3.4.2 Increased Stiffening of the Slab Over the Concrete Girders ...........68 3.5 Modeling Steel Girder Bridge Components ....................................70 3.5.1 Modeling Hinges ..................................... ....................70 3.5.2 Accounting for Creep in the Concrete Deck Slab .....................72 3.6 Modeling Reinforced Concrete TBeam Bridge Components.................74 3.7 Modeling FlatSlab Bridge Components ........................................ 75 3.8 Modeling the Construction Stages of Bridges...................................76 3.9 Modeling Vehicle Loads ..................................................80 4 DATA COMPRESSION IN FINITE ELEMENT ANALYSIS ..................83 4.1 Introduction .................................. ..... .................... 83 4.2 Background............................. ........ ...........................84 4.3 Data Compression in Finite Element Software..................................86 4.4 Compressed I/O Library Overview ....................... .....................91 4.5 Compressed I/O Library Operation.......................................92 4.6 Data Compression Algorithm.................... .......................95 4.7 Fortran Interface to the Compressed I/O Library...............................99 4.8 Data Compression Parameter Study and Testing ............................ 101 4.8.1 Data Compression in FEA Software Coded in C..................... 102 4.8.2 Data Compression in FEA Software Coded in Fortran.............. 112 5 NEURAL NETWORKS.................................. ............ 119 5.1 Introduction ............................ ............ ..... .......... 119 5.2 Network Architecture and Operation................... ..................... 120 5.3 Problem Solving Using Neural Networks .................................... 124 5.4 Network Learning ......................... .... ...................... 125 5.5 The NetSim Neural Network Package ....................................... 128 5.6 Supervised Training Techniques ........................... .................. 130 5.7 Gradient Descent and Stochastic Training Techniques...................... 133 5.8 Backpropagation Neural Network Training................................... 137 5.8.1 ExampleByExample Training and Batching ......................... 141 5.8.2 Momentum ......................... ..... .................. 143 5.8.3 Adaptive Learning Rates ........................... ................... 146 6 NEURAL NETWORKS FOR HIGHWAY BRIDGE ANALYSIS ............. 151 6.1 Introduction ............................................................. 151 6.2 Encoding Structural Behavior .............................. .................. 151 6.3 Separation of Shape and Magnitude ........................................ 153 6.3.1 Generating Network Training Data.................................... 157 6.3.2 Using Trained Shape and Scaling Networks.......................... 160 6.4 Generating Analytical Training Data........................................ 163 6.5 Encoding Bridge Coordinates....................... ..................... 168 6.6 Shape Neural Networks ....................................... 172 6.7 Scaling Neural Networks.................................... 175 6.8 Implementation and Testing ............................. .............. 183 7 ITERATIVE EQUATION SOLVERS FOR HIGHWAY BRIDGE ANALYSIS ......................................... ................... 185 7.1 Introduction ........................................ .. .................... 185 7.2 Exploiting Domain Knowledge...................... ................. 186 7.3 Iterative FEA Equation Solving Schemes...................................... 188 7.4 Preconditioning in Highway Bridge Analysis ................................. 194 7.4.1 Diagonal and Band Preconditioning ................................... 195 7.4.2 Incomplete Cholesky Decomposition Preconditioning ............... 201 7.5 A Domain Specific Equation Solver...................... ................... 205 7.6 Implementation and Results...................................................... 212 7.6.1 Seeding the Solution Vector Using Neural Networks .............. 213 7.6.2 Preconditioning Using Neural Networks............................... 229 8 CONCLUSIONS AND RECOMMENDATIONS................................ 234 8.1 Computer Assisted Modeling ............................. .............. 234 8.2 Data Compression in FEA ........................ .................... 236 8.3 Neural Networks and Iterative Equation Solvers ............................ 238 REFERENCES........................ ....... ............ 242 BIOGRAPHICAL SKETCH ..................... ........... ....................... 247 vii Abstract of Dissertation Presented to the Graduate School of the University of Florida in Partial Fulfillment of the Requirements for the Degree of Doctor of Philosophy ANALYSIS OF HIGHWAY BRIDGES USING COMPUTER ASSISTED MODELING, NEURAL NETWORKS, AND DATA COMPRESSION TECHNIQUES By GARY RAPH CONSOLAZIO August 1995 Chairman: Marc I. Hoit Major Department: Civil Engineering By making use of modern computing facilities, it is now possible to routinely apply finite element analysis (FEA) techniques to the analysis of complex structural systems. While these techniques may be successfully applied to the area of highway bridge analysis, there arise certain considerations specific to bridge analysis that must be addressed. To properly analyze bridge systems for rating purposes, it is necessary to model each distinct structural stage of construction. Also, due to the nature of moving vehicular loading, the modeling of such loads is complex and cumbersome. To address these issues, computer assisted modeling software has been developed that allows an engineer to easily model both the construction stages of a bridge and complex vehicular loading conditions. Using the modeling software an engineer can create large, refined FEA models that otherwise would have required prohibitively large quantities of time to prepare manually. However, as the size of these models increases so does the demand on the computing facilities used to perform the analysis. This is especially true in regard to temporary storage requirements and required execution time. To address these issues a real time lossless data compression strategy suitable for FEA software has been developed, implemented, and tested. The use of this data compression strategy has resulted in dramatically reduced storage requirements and, in many cases, also a significant reduction in the analysis execution time. The latter result can be attributed to the reduced quantity of physical data transfer which must be performed during the analysis. In a further attempt to reduce the analysis execution time, a neural network has been employed to create a domain specific equation solver. The chosen domain is that of twospan flatslab bridges. A neural network has been trained to predict displacement patterns for these bridges under various loading conditions. Subsequently, a preconditioned conjugate gradient equation solver was constructed using the neural network both to seed the solution vector and to act as a preconditioner. Results are promising but further network training is needed to fully realize the potential of the application. CHAPTER 1 INTRODUCTION 1.1 Background In spite of the widespread success with which finite element analysis (FEA) techniques have been applied to problems in solid mechanics and structural analysis, the use of FEA in highway bridge analysis has suffered from a lack of requisite pre and postprocessing tools. Without question, the finite element method (FEM) affords engineers a powerful and flexible tool with which to solve problems ranging in complexity from static linear elastic analyses to dynamic nonlinear analyses. During the past few decades, numerous high quality FEA software packages have been developed both in the form of commercial products and research codes. 1.1.1 Computer Assisted Bridge Modeling In addition to containing a core FEA engine many of these packagesespecially the commercial onesinclude or can be linked to separate pre and postprocessing modules to aid the engineer in preparing and interpreting FEA data. Modeling preprocessors for building structures that allow the engineer to accurately and efficiently prepare FEA models are common. Once the core FEA engine has been executed, postprocessing packages facilitate interpretation of the often voluminous quantities of analysis results generated by such software. Whereas the development of such packages for the analysis and design of buildingtype structures has roughly kept pace with the demands of industry, the same is not true for the case of highway bridge analysis. This is probably attributable to the fact that there are simply many more buildingtype structures constructed than there are highway bridge structures, and therefore a greater demand exists. However, this is not to say that there is not a demand for such software in bridge analysis. With an inventory of more than half a million bridges in the United States alone, and roughly 20 percent of those bridges considered structurally deficient and in need of evaluation, the demand for computer assisted bridge analysis packages exists. Modeling highway bridges for FEA presents certain challenges that are not present in the analysis of building structures. For example, in addition to being subjected to the usual fixed location loads, bridges are also subjected moving vehicular loads which are often complex and cumbersome to describe with the level of detail needed for FEA. Also, because moving vehicle loads are typically represented using a large number of discrete vehicle locations, bridge analyses often contain a large number of load cases. As a direct result, the engineer is faced not only with the daunting task of describing the loads, but also of interpreting the vast quantity of results that will be generated by the analysis. In order to properly analyze bridge systems for evaluation purposes, as in a design verification or rating of an existing bridge, each distinct structural stage of construction should be represented in the model. This is because the bridge has a distinct structural configuration at each stage of construction, and it is that structural configuration that resists loads at that point in the construction sequence. Stresses and forces developed at each of these stages will be locked into the structure in subsequent stages of construction. Such conditions cannot simply be modeled by applying all dead loads to the final structural configuration of the bridge. Modeling of the distinct construction stages is important in the analysis of steel girder bridges and is very important in prestressed concrete girder bridges. Therefore, in addition to describing complex vehicular loading conditions the engineer is also faced with preparing multiple FEA models to represent each distinct stage of the bridge construction. Thus, the need for the development of computer assisted bridge modeling software is clear. 1.1.2 Computational Aspects of Highway Bridge Analysis Assuming that modeling software for highway bridges exists, an actual analysis must still be performed. As a result of advances in computational hardware and decades of refinement of FEA code, is it now possible to perform analyses of complex structural systems on a more or less routine basis. However, there arise certain considerations specific to bridge analysis that must still be addressed if the full potential of computer assisted modeling is to be realized. In the FEA of bridge structures, the computational demands imposed by the analysis generally fall into one of two categoriesrequired storage and required execution time. Required storage can be subdivided into incore storage, also referred to as primary or high speed storage, and outofcore storage, also referred to variously as secondary storage, low speed storage, and backing store. Incore storage generally refers to the amount of physical random access memory (RAM) available on a computer, although on computers running virtual memory operating systems there can also be virtual incore memory. Outofcore storage generally refers to available space on hard disks, also called fixed disks. Optimizing the use of available incore storage has been an area of considerable research during the past few decades. In contrast, little research has been performed that addresses the large outofcore storage requirements often imposed by FEA. Out ofcore storage is used for three primary purposes in FEA : 1. To hold temporary data such as element stiffness, load, and stress recovery matrices (collectively referred to as element matrices) that exist only for the duration of the analysis. 2. To hold analysis results such as global displacements and element stresses that will later be read by postprocessing software. 3. To perform blocked, outofcore equation solutions in cases where the global stiffness or global load matrices are too large to be contained incore as a single contiguous unit. In cases 1 and 3, once the analysis is complete the storage is no longer needed, i.e. the storage is temporary in nature. In case 2, the storage will be required at least until the analysis results have been read by postprocessing software. In the analysis of highway bridges, the amount of outofcore storage that is available to hold element matrices can frequently become a constraint on the size of model that can be analyzed. It is not uncommon for a bridge analysis to require hundreds of megabytes of outofcore storage during an analysis. Also, as a result of the proliferation of low cost personal computers (PCs), there has been a migration of analysis software away from the large mainframe computers of the past toward the smaller PC and workstation platforms of today. This migration has resulted in greater demands being placed on smaller computerscomputers that often have only moderate amounts of incore and outofcore storage. Although the development of preprocessing tools is necessary to make routine use of FEA in bridge analysis a reality, it also introduces a new problem. Using computer assisted modeling software, it becomes quite simple for an engineer to create very large FEA bridge modelsmodels that would otherwise would be too tedious to prepare manually. While this is generally regarded as desirable from the standpoint of analysis accuracy it also has the adverse effect of greatly increasing the demand for out ofcore storage. It is clear then that the issue of outofcore storage optimization must addressed in conjunction with the development of computer assisted modeling software if the full potential of the latter is to be realized. While the size of FEA bridge models may be physically constrained by the availability of outofcore storage, these same models may also be practically constrained by the amount of execution time required to perform the analysis. When moving vehicle loads are modeled using a large number of discrete vehicle positions, the number of load cases that must be analyzed can quickly reach into the hundreds. Combine this fact with the aforementioned ease with which complex FEA models can be createdusing preprocessing softwareand the result is the need to analyze large bridge models for potentially hundreds of load cases. In such situations, the execution time required to perform the analysis may diminish the usefulness of the overall system. This is especially true in situations where multiple analyses will need to be performed, as in an iterative designevaluation cycle or within a nonlinear analysis scheme. Thus, it is evident that in order for a computer assisted bridge modeling system to be practical and useful, the FEA analysis component must be as numerically efficient as possible so as to minimize the required analysis time and minimize the use of outof core storage. 1.2 Present Research The research reported on in this dissertation focuses on achieving three primary objectives with respect to FEA bridge modeling. They are : 1. Developing an interactive bridge modeling preprocessor capable of generating FEA models that can account for bridge construction stages and vehicular loading conditions. 2. Developing a realtime data compression strategy that, once installed into the FEA engine of a bridge analysis package, will reduce the computational demands of the analysis. 3. Developing a domain specific equation solver based on neural network technology and the subsequent installation of that solver into the FEA engine of a bridge analysis package. Each of these objectives attempts to address and overcome a specific difficulty encountered when applying FEA techniques to the analysis of highway bridge systems. The following sections describein greater detaileach objective and the methods used to attain those objectives. 1.2.1 Computer Assisted Bridge Modeling Widespread use of FEA techniques in highway bridge analysis has been curtailed by a lack of requisite pre and postprocessing tools. Routine use of FEA in bridge analysis can only occur when computer assisted modeling software has been developed specifically with the highway bridge engineer in mind. To address this issue, an interactive bridge modeling program has been developed as part of the research reported on herein. The resulting bridge modeling preprocessor, called BRUFEM1, is one component of the overall BRUFEM system (Hays et al. 1990, 1991, 1994). BRUFEM, which is an acronym for Bridge Rating Using the Finite Element Method, is a software package consisting of a series of Fortran 77 programs which, when working collectively as a system, is capable of modeling, analyzing, and rating many types of highway bridge structures. The BRUFEM preprocessor, which will hereafter be referred to simply as the preprocessor, allows an engineer to create detailed FEA bridge models by specifying interactivelya minimal amount of bridge data. Information needed specifically for the modeling of bridge structures and bridge loading is embedded directly into the software. Thus the usual barriers that would prevent an engineer from manually constructing the FEA bridge model are overcome. The primary barriers are : 1. Discretizing each and every structural component of the bridge into discrete finite elements and subsequently specifying the characteristicsgeometry, material properties, connectivities, eccentricities, etc.of each of those elements. 2. Modeling the structural configuration and the appropriate dead loads at each distinct stage of construction. 3. Computing potentially hundreds of discrete vehicle positions and subsequently computing and specifying the load data required for FEA. All of these barriers are overcome through the use of the preprocessor because it handles these tasks in a semiautomated fashion. The term semiautomated, which is used synonymously with computer assisted in this dissertation, alludes to the fact that there is an interaction between the engineer and the modeling software. Neither has complete responsibility for controlling the creation of the bridge model. General characteristics of bridge structures and bridge loading are built into the preprocessor so as to allow rapid modeling of such structures. However, the engineer retains the right to introduce engineering judgmentwhere appropriateinto the creation of the model by interacting with the software. Thus, the engineer is freed from the tedium of manually preparing all of the data needed for FEA and allowed to focus on more important aspects of the rating or design process. In addition to handling the primary modeling tasks discussed above, the preprocessor handles numerous other tasks which are required in bridge modeling. The most important of these are listed here. 1. Modeling composite action between the girders and slab, in some cases including the calculation of composite girder section properties based on the recommended AASHTO (AASHTO 1992) procedure. 2. Modeling pretensioning and posttensioning tendons, including the specification of finite element end eccentricities. 3. Modeling variable cross section girders, including the generation and calculation of all necessary cross sectional properties and eccentricities. 4. Modeling complex bridge geometry such as variable skew. 5. Modeling live loading conditions considering not only a single standard vehicle but often several different standard vehicles. These features facilitate the rapid development of FEA bridge models by alleviating the user of manually performing these tasks. Detailed descriptions of the capabilities of the preprocessor will be given in subsequent chapters. 1.2.2 RealTime Data Compression To address the issue of the large storage and execution time requirements arising from the analysis of bridge structures, a realtime data compression strategy suitable for FEA software has been developed and implemented. In the of discretization stage of FEA modeling, any repetition or regularity in either structural geometry or configuration is usually exploited to the fullest possible extent. This exploitation of regularity has the advantage of not only minimizing the effort needed to prepare the model but also of generally leading to a model that is desirable from the standpoint of accuracy. An additional yet largely unexploited benefit of this regularity is that because the model itself is highly repetitive, the data generated by the analysis software will also be highly repetitive. Such conditions are ideal for the use of data compression. Data compression is the process of taking one representation of set of data and translating it into a different representation that requires less space to store while preserving the information content of the original data set. Since compressed data cannot be directly used in its compressed format, it must be decompressed at some later stage in the life cycle of the data. This process is called either decompression or uncompression of the data. However, the term data compression is also used to refer to the overall process of compressing and subsequently decompressing a data set. It should be clear from context which meaning is intended. Data compression techniques may be broadly divided into two categories lossless data compression and lossy data compression. In lossless data compression, the data set may be translated from its original format into a compressed format and subsequently back to the original format without any loss, corruption, or distortion of the data. In contrast, lossy data compression techniques allow some distortion of the data to occur during the translation process. This can result in greater compression than that which can be achieved using lossless techniques. Lossy compression methods are widely used in image compression where a modest amount of distortion of the data can be tolerated. In the compression of numeric FEA data such as finite element matrices it is necessary to utilize lossless data compression methods since corruption of the data to any extent would invalidate the analysis. Thus, in the present work, in order to capitalize on the repetitive nature of FEA data, a realtime lossless data compression strategy has been developed, implemented, and tested in bridge FEA software. The term realtime is used to indicate that the FEA data is not created and then subsequently compressed as a separate step but instead is compressed in realtime as the data is being created. Thus the compression may be looked upon as a filter through which a stream of numeric FEA data is passed in, and a stream of compressed data emerges. This type of compression is also more loosely referred to as onthefly data compression. Of course, the direction of the data stream must eventually be reversed so that the numeric FEA data can be obtained by decompressing the compressed data. This reversed process is also performed in realtime with the data being decompressed and retrieved on demand as required by the FEA software. The compression strategy developed in the present work consists of the combination of a file input/output (i/o) library and a buffering algorithm both wrapped around a core data compression algorithm called Ross Data Compression (RDC). RDC is a sequential data compression algorithm that utilizes run length encoding (RLE) and pattern matching to compress sequential data streams. Once developed, the technique was implemented into two FEA programs used in the analysis of highway bridge structures and tested using several realistic FEA bridge models. Due to the repetitive nature of FEA bridge models, the data compression strategy of the present work has been shown to greatly reduce the storage requirements of FEA software. In the bridge models tested, the storage requirements for FEA software equipped with data compression were roughly an order of magnitude smaller than the storage requirements of the same FEA software lacking data compression. Also, the use of data compression was shown to substantially decrease the analysis execution time in many cases. This is due to the fact that when using data compression, the quantity of disk i/o that must be performed by the FEA software is greatly decreased often resulting in decreased execution time. This benefit has been shown to be especially advantageous on workstation and personal computer platforms running FEA software written in Fortran 77. Under such circumstances, the execution time required for the bridge analysis was shown to decrease to as little as approximately one third of the execution time needed when compression was not utilized. 1.2.3 Neural Network Equation Solver In order for a computer assisted bridge modeling system to be effective, the time required to perform each FEA analysis must be minimized. To address this issue, an application of Artificial Neural Networks (ANNs) has been used to create a domain specific equation solver. Since the equation solving stage of a FEA accounts for a large portion of the total time required to perform an analysis, increasing the speed of this stage will have a significant effect on the speed of the overall analysis. In the present work, the approach taken to minimize the analysis execution time is to implicitly embed, using ANNs, domain knowledge related to bridge analysis into the equation solver itself. In this way a domain specific equation solver, i.e. an equation solver constructed to solve problems within the specific problem domain of bridge analysis, is created. The concept behind such an equation solver is that by exploiting knowledge of the problem, e.g. knowing displacement characteristics of bridge structures, the solver will be able to more rapidly arrive at the solution. In the present application ANNs have been trained to learn displacement characteristics of twospan flatslab bridges under generalized loading conditions. Using analytical displacement data generated by numerous finite element analyses, a set of network training data was created with which to train the ANNs. Next, using ANN training software that was developed as part of the present research, several neural networks were trained to predict displacement patterns in flatslab bridge under generalized loading conditions. Once the networks were trained, a preconditioned conjugate gradient (PCG) equation solver was implemented using the neural networks both to seed the solution vector and to act as an implicit preconditioner. In the case of seeding the solution vector, the networks attempt to predict the actual set of displacements that would occur in the bridge under the given loading condition. These displacements are then used as the initial estimate of the solution vector in the equation solving process. Conceptually, the idea here is to make use of the domain knowledge embedded in the ANNs to allow for the computation of a very good initial guess at the solution vector. Clearly, for any iterative method, the ideal initial solution estimate would be the exact solution since in that case no iteration would be required. Since the exact solution is obviously not known, it is typically necessary to use a simplified scheme to estimate the solution vector. Such schemes include seeding the solution vector with random numbers, zeros, or values based on the assumption of diagonal dominance. None of these methods works particularly well for bridge structures. In the present research, these simplistic methods are replaced by a sophisticated set of neural networks that can predict very good initial estimates by exploiting their 'knowledge' of the problem. In general, the neural networks are not be able to predict the exact set of displacements that occur in the bridge. Therefore it will be necessary to perform iterations within the PCG algorithm in order to converge on the exact solution. The PCG algorithm was specifically chosen for this application because one component of that algorithm involves the use of an approximate stiffness matrix to precondition the problem. Preconditioning reduces the effective condition number of the system and thus increases the rate of convergence of the iterative process. A more detailed discussion of this phenomenon will be presented later in this work. Implicitly embodied in the connection weights of the neural networks is the relationship between applied loads and resulting displacements in flatslab bridge structures. This is precisely the same relationship that is captured in the more traditional stiffness matrix of FEA. Since the PCG algorithm calls for an approximation of the stiffness matrix to precondition the problem, what is actually needed is an approximation of the relationship between loads and displacements. While that approximate relationship is usually expressed explicitly in terms of an approximate stiffness matrix, in the present research it is expressed implicitly within the neural networks. Thus, the current application of neural networks seeks to accelerate the equation solving process by 1. Using the embedded domain knowledge to yield very accurate initial estimates of the solution. 2. Using the implicit relationship between loads and displacements embodied in the networks to precondition, and thus accelerate, the convergence of the PCG solution process. Detailed descriptions of neural network theory, the representation of bridge data, network training, and implementation of the trained networks into a PCG solver will be presented in later chapters. 1.3 Literature Review The research being reported on herein focuses on three distinct yet strongly linked topics related to FEA of highway bridge structures. In the following sections the work of previous researchers in each of these three areas will be surveyed. 1.3.1 Computer Assisted Bridge Modeling The widespread proliferation of FEA as the tool of choice for solid mechanics analysis has resulted in the demand for and creation of numerous computer assisted modeling packages during the past few decades. In the area of structural analysis, these modeling packages generally fall into one of three general classificationsgeneral purpose, building oriented, or bridge oriented. Computer assisted preprocessors that are intended for use in the modeling and analysis of highway bridge structures can be further classified as commercial packages or research packages. Software packages for the modeling, analysis, and postprocessing of bridge structures are often bundled together and distributed or sold as a single system. For this reason, bundled packages falling into the general category of bridge analysis will be considered here along with packages which belong to the narrower category of bridge modeling. Also, because the determination of wheel load distributions on highway bridges is often needed during both design and evaluation phases, packages that are aimed at determining such distribution characteristics are also considered here. Zokaie (1992) performed an extensive review and evaluation of software capable of predicting wheel load distributions on highway bridges. Included in the review were general purpose analysis programs such as SAP and STRUDL as well as specialized bridge analysis programs such as GENDEK, CURVBRG, and MUPDI. In addition, simplified analysis packages such as SALOD (Hays and Miller 1987) were also reviewed. Each of the various programs were evaluated and compared primarily on the basis of the analysis accuracy. However, the modeling capabilities of the software were not of primary concern in the review. At present, there are several commercial packages available for bridge modeling and analysis, however, their modeling capabilities and analysis accuracy vary widely. The commercial program BARS is widely used by state departments of transportation (DOTs) throughout the United States. However BARS utilizes a simplified one dimensional beam model to represent the behavior of the bridge and therefore cannot accurately account for lateral load distribution between adjacent girders or skewed bridge geometry. Another commercial package is CBRIDGE. CBRIDGEand its design counterpart CBDesignhave the ability to model and analyze straight and curved girder bridges as well as generate bridge geometry and vehicular loading conditions. Although CBRIDGE is now a commercial package, the original analysis methods were developed under funded research programs at Syracuse University. A limitation of the CBRIDGE package is that the bridge models created do not account for the individual construction stages of the bridge. Public domain (noncommercial) programs for finite element modeling and analysis include the CSTRUCT and XBUILD packages developed by Austin. CSTRUCT (Austin et al. 1989) is an interactive program developed for the design, modeling, and analysis of planar steel frames under both static and seismic loading conditions. Although CSTRUCT is not capable of modeling highway bridges, the general approach to usersoftware interaction developed in that package was later extended in the development of the XBUILD bridge modeling system (Austin et al. 1993, Creighton et al. 1990). The XBUILD package allows a user to interactively build, and simultaneously view via a graphical interface, finite element models of steel girder highway bridge structures. XBUILD also allows the user to interactively specify the location and type of vehicle loading present on the bridge. However XBUILD also has several important limitations. 1. It can only model steel girder bridges. Thus, the modeling of other types of bridges such as prestressed concrete girder, reinforced concrete Tbeam, and flatslab bridges cannot be accomplished. 2. It can only model right (90 degree) bridges having a rectangular finite element mesh. Thus, neither constant skew nor variable skew bridges can be modeled. 3. It cannot model the construction stages of the bridge. In summary, although the XBUILD package provides a user friendly environment for bridge modeling as well as some powerful graphical features, it is still limited in scope. While additional bridge modeling packages do exist which have not been mentioned here, the vast majority of these packages never appear in the literature. This is due to the fact that such modeling systems are often informal projects developed by engineering firms strictly for inhouse use. 1.3.2 Data Compression in FEA During the past few decades a great deal of effort by FEA researchers has been directed at both optimizing the use of available incore storage in FEA software and optimizing the numerical efficiency of matrix equation solvers. However, relatively little attention has been focused on the optimization of outofcore storage requirements. It is true that researchers have developed various special purpose bookkeeping strategies that can moderately reduce outofcore storage demands in specific situations. However, aside from his own work (Consolazio and Hoit 1994), the author has been unable to find any references in the literature regarding general purpose strategies directly incorporating the use of data compression techniques in FEA software. In contrast, the development of advanced data compression techniques has been an active area of research in the Computer and Information Science (CIS) field for at least two decades. In recent years, system software developers have realized the many fold benefits of using realtime data compression and have begun embedding data compression directly into the computer operating systems they develop. However, no such applications of data compression in FEA have appeared in the engineering literature. 1.3.3 Neural Network Applications in Structural Engineering During the past five to ten years, there has been a steadily increasing interest in applying the neural network solution paradigm to structural engineering problems. VanLuchene and Sun (1990) illustrated some potential uses of neural networks in structural engineering applications by training networks to perform simple concrete beam selection and concrete slab analysis. Since that time, researchers have begun using neural networks in many areas of structural engineering. Ghaboussi et al. (1991) utilized neural networks for material modeling of concrete under static and cyclic loading conditions. Neural networks were employed to capture the materiallevel behavior characteristics (constitutive laws) of concrete using experimentally collected results as network training data. In this way, the constitutive laws of the material were derived directly from experimental data and implicitly embedded in the networks. This is in contrast to the traditional method of formulating a set of explicit mathematical rules that collectively form the constitutive laws of a material. Wu et al. (1992) explored the use of neural networks in carrying out damage detection in structures subjected to seismic loading. This was accomplished by training a network to recognize the displacement behavior of a frame structure under various damage states each of which represented the damage of a single structural component. Elkordy and Chang (1993) refined this concept by using analytically generated training data to train networks to detect changes in the dynamic properties of structures. Accurate prediction of the absolute dynamic properties of a structure by analytical techniques such as FEA can be very difficult. Instead, Elkordy and Chang used analytical models to identify changes in dynamic properties. In this way they were able to train neural networks to detect structural damage by recognizing shifts in the vibrational signature of a structure. Szewczyk and Hajela (1994) extended the concept once again by utilizing counterpropagation neural networks instead of the more often used backpropagation neural networks. Counterpropagation networks can be trained much more rapidly than traditional "plain vanilla" backpropagation networks and are therefore well suited for damage detection applications where a large number of training sets need to be learned. Several other diverse applications of neural networks in structural engineering have also appeared in the literature. Garcelon and Nevill (1990) explored the use of neural networks in the qualitative assessment of preliminary structural designs. Hoit et al. (1994) investigated the use of neural networks in renumbering the equilibrium equations that must be solved during a structural analysis. Gagarin et al. (1994) used neural networks to determine truck attributes (velocity, axle spacings, axle loads) of in motion vehicles on highway bridges using only girder strain data. Rogers (1994) illustrated how neural network based structural analyses can be combined with optimization software to produce efficient structural optimization systems. CHAPTER 2 A PREPROCESSOR FOR BRIDGE MODELING 2.1 Introduction This chapter will describe the development and capabilities of an interactive bridge modeling preprocessor that has been created to facilitate rapid computer assisted modeling of highway bridges. This preprocessor is one component of a larger system of programs collectively called the BRUFEM system (Hays et al. 1994). BRUFEM, which is an acronym for Bridge Rating Using the Finite Element Method, is a software package consisting of a series of Fortran 77 programs capable of rapidly and accurately modeling, analyzing, and rating most typical highway bridge structures. The development of the BRUFEM system was funded by the Florida Department of Transportation (FDOT) with the goal of creating a computer assisted system for rating highway bridges in the state of Florida. Bridge rating is the process of evaluating the structural fitness of a bridge under routine and overload vehicle loading conditions. With a significant portion of existing highway bridges in the United States nearing or exceeding their design life, the need for engineers to be able to accurately and efficiently evaluate the health of such bridges is evident. Development of the complete BRUFEM system was accomplished in incremental stages of progress spanning several years and involving the efforts of several researchers. Early work on the BRUFEM preprocessor was performed by Selvappalam and Hays (Hays et al. 1990). Subsequently, the author took over responsibility for the development of the preprocessor and took this portion of the BRUFEM project to completion. The four primary component programs that make up the BRUFEM system are the following. 1. BRUFEM1. An interactive bridge modeling preprocessor. 2. SIMPAL. A core finite element analysis engine. 3. BRUFEM3. An interactive bridge rating postprocessor. 4. SIMPLOT. A graphical postprocessor for displaying analysis results. The modeling capabilities of the preprocessor, BRUFEM1, will be the focus of this chapter and also Chapter 3. Enhancements to the FEA program, SIMPAL, using data compression techniques will be discussed later in Chapter 4. For complete descriptions of the other component programs, see Hays et al. (1994). 2.2 Overview of the Bridge Modeling Preprocessor The primary design goal in developing the preprocessor has been to create an easy to use, interactive tool with which engineers can model complete bridge systems for later finite element analysis. By using a computer assisted modeling preprocessor, the usual barriers that would prevent an engineer from manually constructing an FEA bridge model are overcome. These barriers, which were first introduced in Chapter 1, are listed below. 1. Discretizing each and every structural component of the bridge into discrete finite elements and subsequently specifying the characteristicsgeometry, material properties, connectivities, eccentricities, etc.of each of those elements. 2. Modeling the structural configuration and the appropriate dead loads at each distinct stage of construction. 3. Computing potentially hundreds of discrete vehicle positions and subsequently computing and specifying the load data required for FEA. Each of these obstacles is overcome through the use of the preprocessor because it handles these tasks in a semiautomated fashion in which the engineer and the software both contribute to the creation of the model. Bridge modeling is accomplished using the preprocessor in an interactive manner in which the user is asked a series of questions regarding the characteristics of the bridge being modeled. Each response given by the user determines which questions will be asked subsequently. For example, assume that the user is asked to specify the number of the spans in the bridge and a response of '2' is given. Then the user may later be askeddepending on the type of bridge being modeledto specify the amount of deck steel effective in negative moment regionsi.e. a parameter that is only applicable to bridges having more than one span. Both girderslab bridges and flatslab bridges may be modeled using the preprocessor. Girderslab bridges are those characterized as having large flexural elements, called girders, that run in the longitudinal direction of the bridge and which are the primary means of applied bridge loads. In a girderslab bridge, the girders and deck slab are often joined together in such a way that they act compositely in resisting loads through flexure. This type of structural behavior is called composite action and will be discussed in detail later. Flatslab bridges are constructed as thick slabs lacking girders and resisting loads directly through longitudinal flexure of the slab. The preprocessor has been developed so as to allow maximum flexibility with respect to the types of bridges that can be modeled. Each of the following bridge types can be modeled using the preprocessor. 1. Prestressed concrete girder. Bridges consisting of precast prestressed concrete girders, optional reinforced concrete edge stiffeners, a reinforced concrete deck slab, and reinforced concrete diaphragms. 2. Steel girder. Bridges consisting of steel girders, optional reinforced concrete edge stiffeners, a reinforced concrete deck slab, and steel diaphragms. 3. Reinforced concrete Tbeam. Bridges consisting of reinforced concrete T beam girders, optional reinforced concrete edge stiffeners, a reinforced concrete deck slab, and reinforced concrete diaphragms. 4. Reinforced concrete flatslab. Bridges consisting of a thick reinforced concrete deck slab and optional reinforced concrete edge stiffeners. The general characteristics of each these bridge types are built into the preprocessor so as to allow rapid modeling. Information regarding the construction sequence of each type of bridge is also embedded in the preprocessor. This information includes not only the structural configuration of the bridge at each stage of construction but also the sequence in which dead loads of various types are applied to the bridge. Finally, the preprocessor allows the engineer to rapidly and easily model live loading conditions consisting of combinations of vehicle loads and lane loads. Vehicle data, such as wheel loads and axle spacing, for a wide range of standard vehiclesfor example the HS20are embedded in the preprocessor. In addition, there are a variety of methods available to the user for specifying vehicle locations and shifting. 2.3 Design Philosophy of the Preprocessor In the design of the preprocessor, the basic philosophy has been to exploit regularity and repetition whenever and wherever possible in the creation of the bridge model. This idea applies to bridge layout, bridge geometry, girder cross sectional shape, vehicle configuration, and vehicle movement as well as several other bridge variables. 2.3.1 Internal Preprocessor Databases Regularity in the form of standardized bridge components and loading has been accounted for by using databases. Standard girder cross sectional shapes, such as the AASHTO girder cross sections, and standard vehicle descriptions are included in internal databases that make up part of the preprocessor. Thus, instead of having to completely describe the configuration of, say for example, an HS20 truck, the user simply specifies an identification symbol, in this case 'HS20', and the preprocessor retrieves all of the relevant information from an internal database. The vehicle database embedded in the preprocessor contains all of the information necessary for modeling loads due to the standard vehicles H20, HS20, HS25, ST5, SFT, SU2, SU3, SU4, C3, C4, C5 TC95, T112, T137, T150, and T174. In addition to these standard vehicle specifications, the user may create specifications for customi.e. nonstandardvehicles by specifying all of the relevant information in a text data file. The cross sectional shape databases embedded in the preprocessor contain complete descriptions of the following standard cross sections used for girders and parapets. 1. AASHTO prestressed concrete girder types I, II, III, IV, V, and VI 2. Florida DOT prestressed concrete girder bulbT types I, II, III, and IV 3. Standard parapetsold and new standards In addition to these standard cross sectional shapes, the user may describe nonstandard cross sectional shapes interactively to the preprocessor. 2.3.2 The Basic Model and Extra Members Girderslab bridges typically contain a central core of equally spaced girders that is referred to as the basic model when discussing the preprocessor. In addition to this central core the bridge may have extra girders at unequal spacings, parapets, and railings near the bridge edges. The basic model and extra edge members are depicted in Figure 2.1. Equal girder spacing arises because it simplifies the design, analysis, and construction of the bridge. Flatslab bridges also contain a central core, or basic model, in which the deck slab has a uniform reinforcing pattern. While there are no girders in flatslab bridges, these bridges may have edge elements such as parapets or railings just as girderslab bridges may. Almost all of the bridge types considered by the preprocessor utilize the concept of a basic model to simplify the specification of bridge data. Exceptions to this rule are the variable skew bridge types in which the concept of a basic model is not applicable. Within the basic model all bridge parameters are assumed to be constant and therefore Parape Deck Slab Diaphragm Girder I I II I I I bI 2 bsic basic basic S3 S4 Extra Extra Extr Extra Left Left Basic Model Right Right Parapet Girder Girder Parape Figure 2.1 Cross Section of a Girderslab Bridge Illustrating the Basic Model and Extra Left and Right Edge Members only need to be specified once by the user. For example, in the bridge shown in Figure 2.1 notice that the girder spacing Sbaic is constant within the basic model and that the cross sectional shape of each of the girders in the basic model is the same. In this case, the user would only need to specify Sbasic once and describe the girder cross sectional shape once for all four of the girders in the basic model of this bridge. While the technique of using a basic model to describe a bridge can greatly speed the process of gathering input from the user, most bridges possess additional members near the edges that do not fit into the basic model scheme. In the preprocessor these edge members are termed extra members and are appended to either side of the basic model to complete the description of the bridge. For example, on each side of the bridge in Figure 2.1 there is an extra girder and an extra stiffener. In this case the extra girders have different cross sectional shapes and spacings than the girders of the basic model. In addition, edge stiffening parapets are present which clearly are different from the girders of the basic model. In the example shown, the bridge is symmetric but this need not be the case. By specifying some of the girders in a bridge as extra girders, unsymmetrical bridges can be modeled. A limit of three extra left members and three extra right members is enforced by the preprocessor. 2.3.3 Generation In order to further reduce the amount of time that an engineer must spend in describing a bridge, the preprocessor performs many types of generation automatically. Generation in this context means that the user needs only to specify a small set of data that the preprocessor will use to generate, or create, a much larger set of data needed for complete bridge modeling. To illustrate the types of generation that the preprocessor performs, consider the following example. Bridges containing nonprismatic girders, i.e. girders that have varying cross sectional shape, can be easily modeled using the preprocessor. To describe a non prismatic girder, the user only needs to define the shape of the girder cross section at key definition points. Definition points are the unique locations along the girder that completely describe the cross sectional variation of the girder. In the example steel girder illustrated in Figure 2.2, the user only needs to specify the cross sectional shapes Al through A6 at the six definition points. Using this data, the preprocessor will auto matically generate cross sectional descriptions of the girder at each of the finite element nodal location in the model. Also, the preprocessor will generate cross sectional properties at each of these nodes and assign those properties to the correct elements in the final model. Thus, the amount of data that must be manually prepared by the engineer is kept to a minimum. SI D2 D 3 D 4 D A, G CCross Section Figure 2.2 Nonpismatc Steel Girder Bridg WitDefinition Paints AI AI A2 A A A A3 A A A Finite Element Nodal Location D = Distances Between Definition Points Nonprismatic A i Unique Girder Cross Sections Gi Figure 2.2 Nonprismatic Steel Girder Bridge With User Specified Definition Points and Finite Element Nodes The methods by which a user positions vehicles on a bridge provides another illustration of the types of generation performed by the preprocessor. As will be seen later, the user needs only to provide a minimal amount of information in order to generate potentially hundreds of discrete vehicle positions. 2.3.4 The Preprocessor History File When using a primarily interactive program such as the preprocessor, the majority of required data is gathered directly from the user, as opposed to being gathered from an input data file as in a batch program. An interactive approach to data collection generally results in easier program operation from the viewpoint of the user. However, one disadvantage of this approach is that because the user has not prepared an input data file in advance, as is the case in batch programs, there is no record of the data given by the user. This is undesirable for two reasons. First, there is no permanent record of what data was specified by the user and therefore there is no 'paper trail' that can be used to trace the source of an error should one be detected at some later date. Second, if the user wishes to recreate the bridge model at a future date, all of the necessary data must again be reentered exactly as before. Similarly, if the user wishes to recreate the model but with a small variation in some parameter, all of the data must again be reentered including the modified parameter. To circumvent these problems, the preprocessor maintains a history file containing each of the responses interactively entered by the user. Thus, there is a permanentand commentedrecord of what data was in fact entered by the user should this ever become a matter of dispute in the future. Since the history file contains all of the data provided by the user, it may also be used to recreate an entire bridge model. The user simply tells the preprocessor to read input data from the history file instead of interactively from the user. In addition to the uses mentioned above, the history file may also be used to resume a suspended input session, revise selected bridge parameters, or revise the vehicle loading conditions imposed on a bridge. Thus, the combination of an interactive program interface and a reusableand editablehistory file results in a program that exhibits the advantages of both the interactive and batch approaches without the exhibiting the disadvantage of each. 2.4 Common Modeling Features and Concepts Many of the modeling features available in the preprocessor are common to several of the types of bridges that can modeled. Recall that the preprocessor is capable of modeling prestressed girder, steel girder, reinforced concrete Tbeam, and flab slab bridges. The features and concepts discussed below are common to manyor allof these bridges types. 2.4.1 Bridge Directions In discussing the preprocessor, the meaning of certain terminology regarding bridge directions must be established. In this context, the longitudinal direction of a bridge is the direction along which traffic moves. The lateral direction of the bridge is the direction perpendicular to and ninety degrees clockwise from the longitudinal direction. Finally, the transverse direction is taken as the direction perpendicular to the bridge deck and positive upward from the bridge. These directions are illustrated in Figure 2.3. The lateral, longitudinal, and transverse bridge directions correspond to the global x, y, and zdirections respectively in the global coordinate system of the finite element model. Transverse Direction (ZDirection) \Lateral SDirection w Lateral t (XDirection) g Direction Longitudinal Direction (YDirection) Figure 2.3 Lateral, Longitudinal, and Transverse Bridge Directions 2.4.2 Zero Skew. Constant Skew. and Variable Skew Bridge Geometry Bridges modeled using the preprocessor may be broadly divided into two categories based on the bridge geometryconstant skew and variable skew. A constant skew bridge is one in which all of the support lines form the same angle with the lateral direction of the bridge. The constant skew category includes right bridges as a particular case since the skew angle in a right bridge is a constant value of zero. Right bridges are those bridges in which the support lines are at right angles to the direction of vehicle movement. Constant skew geometry, including zero skew, can be modeled for all of the bridge types treated by the preprocessor. Variable skew geometry may also be modeled using the preprocessor but only for steel girder bridges and single span prestressed girder bridges. In a variable skew bridge, each support line may form a different angle with the lateral direction of the bridge. Each of the bridge skew cases considered is illustrated in Figure 2.4. End Support Lines Interior Support Line 0e= Right Bidge (Zero Skew) Constant Skew Bridge Variable Skew Bridge I I Constant Skew Geometry Figure 2.4 Zero Skew, Constant Skew, and Variable Skew Bridge Geometry 2.4.3 Live Load Models and Full Load Models Broadly speaking, there are two basic classes of bridge models that can be created by the preprocessorlive load models and full load models. Live load models are used primarily to compute lateral load distribution factors (LLDFs) for girderslab bridges (see Hays et al. 1994 for more information regarding LLDFs). A live load model represents only the final structural configuration of a bridgethat is the bridge configuration that is subjected to live vehicle loads. By contrast, a full load model is actually not a model at all but rather a series of models that represent the different stages of construction of a single bridge. Full load models are analyzed so that a bridge rating can subsequently be performed using the analysis results. Each of the individual construction stage models, which collectively constitute a full load model, simulates a particular stage of construction and the dead or live loads associated with that stage. After all of the construction stage models have been analyzed a rating may be performed by superimposing the forcet results from each of the analyses. This is a very important pointeach analysis considers only incremental loads, not accumulated loads. In fact, this procedure must be used in order to account for locked in forces, i.e. forces that are developed at a particular stage of construction and locked into the structure from that point forward. The last construction stage model in any series of full load models is always a live load model, i.e. a model representing the final structural configuration of the t In this context, the term force is used in a general sense to mean either a shear force, axial force, bending moment, shear stress, axial stress, or bending stress. bridge and live loading. When analyzed, the force results from this analysis do not represent the true forces in the structure but rather the increment of forces due only to applied live loading. These force results must be combined with the force results from the other construction stage modelsi.e. the stages that contain dead loadsin order to determine the actual forces present in the structure. In the BRUFEM bridge rating system, the superposition of analysis results is performed automatically by the postprocessor. The analysis results are also factored according to the type of loading that produced thembefore they are superimposed. Thus, the preprocessor always creates bridge models that are subjected to unfactored loads. Load factoring is then performed later in the rating process when the post processor reads the analysis results. 2.4.4 Live Loads The term live load is applied to loads that are shortterm in duration and which do not occur at fixed positions. Live loads on bridge structures are those loads that result from either individual vehicles or from trains of closely spaced vehicles. Bridges are typically designed and rated for large vehicles such as standard trucks, cranes, or special overload vehicles. Two vehicle loading scenarios are generally considered when modeling highway bridge structuresindividual moving vehicle loads and stationary lane loads. Both of these conditions can be modeled using the preprocessor. The first scenario represents normal highway traffic conditions in which vehicles move across the bridge at usual traffic speeds. In this scheme the vehicles are assumed to be moving with sufficient speed that, when they enter onto the bridge, there is an impact effect that amplifies the magnitude of the loads exerted by the vehicle on the bridge. There may be multiple vehicles simultaneously on the bridge in this scenario depending on the number of spans, spans lengths, and number of traffic lanes. To model individual vehicle loads using the preprocessor, the engineer simply specifies the type, directionforward or reverse, and position of each of the vehicles on the bridge. Vehicles may be placed at fixed locations, shifted in even increments, or shifted relative to the finite element nodal locations. If the vehicles are moved using either of the shifting methods, then the entire vehicle system is shifted as a single entity. A vehicle system in this context refers to the collection of all vehicles simultaneously on the bridge. Vehicles may be positioned and moved on the bridge using any of the following three methods. 1. Fixed positioning. A single position (location and direction) is specified for each vehicle on the bridge. 2. Equal shifting. Each vehicle is placed at an initial position and subsequently shifted a specified number of times in the lateral and longitudinal bridge directions. The user specifies the incremental shift distances and has the option of shifting only in the lateral direction, only in the longitudinal direction, or in both directions. 3. Nodal shifting. Each vehicle is placed at an initial position after which it is automatically shiftedby the preprocessorin the positive longitudinal bridge direction such that each axle in the system is in turn placed at each line of nodes running laterally across the bridge. This option is not available in constant or variable skew bridge types. Initial vehicle positions are specified by stating the coordinates of the centerline of the vehicle's lead axle relative to the lateral and longitudinal directions of the bridge. The second live loading scenario introduced at the beginning of this section stationary lane loadingrepresents the case in which traffic is more or less stopped on the bridge and vehicles are very closely spaced together. Lane loading is usually thought of as a uniform load extending over specified spans in the longitudinal direction and over a specified width in the lateral direction. AASHTO defines lane loads as being ten feet wide. However, because lane loading is intended to represent a series of closely spaced vehicles, the preprocessor instead models uniform lane loads as a series of closely spaced axles with each having a width of six feetthe approximate width of a vehicle axle. Lane loads are described by specifying which spans the lane load extends over, and by specifying the lateral position of the centerline of the lane. 2.4.5 Line Loads and Overlay Loads In addition to the live load modeling capabilities provided by the preprocessor, an engineer may also specify the location and magnitude of long term dead loads such as line loads and uniform overlays. Dead loads due to structural components such as the deck slab, girders, and diaphragms are automatically accounted for in the bridge models created by the preprocessor and therefore do not need to be specified as line or overlay loads. Dead loads due to nonstructural elements such as nonstructural parapets or railings can be modeled by specifying the location and magnitude of line loads. For example, the dead weight of a nonstructural parapet may be applied to the bridge by specifying a line load having a magnitude equal to the dead weight of the stiffener per unit length. Uniform dead loads, such as that which would result from the resurfacing of a bridge, may be accounted for by specifying a uniform overlay load. 2.4.6 Prismatic and Nonprismatic Girders Prismatic girderslab bridges, in which the cross sectional shape of the girders remains the same along the entire length of the bridge, are the simplest type of girder slab bridge. Prismatic girders are commonly used in prestressed concrete girder bridges where standard precast cross sectional shapes are the norm. Most reinforced concrete Tbeam bridges can also be classified as prismatic girderslab bridges. Nonprismatic girders, in which the cross sectional shape of the girders varies along the length of the bridge, are commonly used to minimize material and labor costs in steel girder bridges. The cross sectional shape of a steel girder can be easily varied by welding cover plates of various sizes to the top and bottom flanges of the girder, thus optimizing the use of material. Nonprismatic girders are also used in post tensioned prestressed concrete girder bridges in which thickened girder webs, called end blocks, are often required at the anchor points of the posttensioning tendons. Another class of nonprismatic girder occurs when the depth of a girder is varied usually linearlyalong the length of a girder span. Linearly tapering girders occur in both steel and prestressed concrete girder bridges. Prismatic girders can be modeled for all of the bridge types treated by the preprocessor, either for live load analysis and full load analysis. Nonprismatic girders are also permitted for the following bridge types. 1. Steel girder. Constant skew steel girder bridges modeled for either live load analysis or full load analysis and variable skew bridges modeled for full load analysis. 2. Reinforced concrete Tbeam. Constant skew reinforced concrete Tbeam bridges modeled for either live load analysis or full load analysis. 3. Prestressed girder. Prestressed girder bridges that are prismatic except for the presence of end blocks can be modeled for full load analysis. Constant skew nonprismatic prestressed girder bridges may be modeled for live load analysis. Using the preprocessor, the task of describing and modeling the cross sectional variation of nonprismatic girders has been greatly simplified. Flexible generation capabilities are provided that minimize the quantity of data that must be manually prepared by the user. Refer to 2.3.3 for further details. 2.4.7 Composite Action Composite action is developed when two structural elements are joined in such a manner that they deform integrally and act as a single composite unit when loaded. In the case of highway bridges, composite action may be developed between the concrete deck slab and the supporting girders or between the deck slab and stiffening members such as parapets. Designing a bridge based on composite action can result in lighter and shallower girders, reduced construction costs, and increased span lengths. The extent to which composite action is developed depends upon the strength of bond that exists between the slab and the adjoining flexural members. In a fully composite system, strains are continuous across the interface of the slab and the flexural members and therefore no slip occurs between these elements. Vertical normal stresses and interface shear stresses are developed at the boundary between the two elements. Proper development of the interface shear stresses is necessary for composite action to occur and is provided by a combination of friction and mechanical shear connection schemes. In steel girder bridges, as illustrated in Figure 2.5, shear studs are often welded to the top flanges of the girders and embedded into the deck slab so that the two elements deform jointly. Concrete girders and parapets may be mechanically connected to the concrete deck slab by extending steel reinforcing bars from the concrete flexural members into the deck slab during construction. In each of these shear connection schemes the goal is to provide adequate mechanical bond between the members such that they behave as a single composite unit. In a noncomposite bridge system, there is a lack of bond between the top of the girder and the bottom of the slab. As a result, the two elements are allowed to slide relative to each other during deformation and do not act as a single composite unit. Only vertical forces act between the two elements and there is a discontinuity of strain at the boundary between the elements. The preprocessor can represent the presence or absence of composite action in a bridge by using one of three composite action models. The first model, called the noncomposite model (NCM), represents situations in which composite action is not present. The second and third models, termed the composite girder model (CGM) and the eccentric girder model (EGM) respectively, simulate composite action using two different finite element modeling techniques. Using the concept of an effective width, GirderSlab Interface Shear Stud Intrface Shear I_Steel Girder Stresses Figure 2.5 Composite Action Between a Girder and Slab the composite girder model represents composite action by including an effective width of slab into the calculation of girder cross sectional properties. A more accurate approach using a pseudo three dimensional finite element model is used in the eccentric girder model. Additional details of each of the composite action models are given in the next chapter. 2.5 Modeling Features Specific to Prestressed Concrete Girder Bridges Several of the modeling features available in the preprocessor relate specifically to the modeling of prestressed concrete girder bridges (see Figure 2.6). This section will provide an overview of those features. 2.5.1 Cross Sectional Property Databases Databases containing cross sectional property data for standard prestressed concrete girder sections have been embedded into the preprocessor to quicken the modeling process and reduce errors. The databases contain cross sectional descriptions of standard AASHTO girders and FDOT bulbT girder types. When modeling a bridge based on one of these standard girder types, the engineer simply specifies a girder identification symbol. The preprocessor then retrieves all of the cross sectional data needed for finite element modeling from an internal database. This technique saves the user time and eliminates the possibility that he or she may accidentally enter erroneous data. Since the majority of prestressed concrete girder bridges are constructed using standard girders, a typical user may never have to manually enter cross sectional data. To cover cases in which nonstandard girders are used, the preprocessor also allows the user to manually enter cross sectional data. 2.5.2 Pretensioning and PostTensioning Prestressed concrete girder bridges modeled by the preprocessor may be either of the pretensioned type or pre and posttensioned type. Pretensioning occurs during the process of casting the concrete girders whereas posttensioning occurs after the girders have been installed in a bridge. The preprocessor can model bridges having either one or two phases of posttensioning, however, there are specificand distinct construction sequences associated with each of these schemes. Figure 2.6 Cross Section of a Typical Prestressed Concrete Girder Bridge Each type of prestressing, whether it be pretensioning, phase1 posttensioning, or phase2 posttensioning, is modeled by the preprocessor as a single tendon having a single area, profile, and prestressing force. In reality, prestressing is usually made up of many smaller strands located nearby one another so as to form a prestressing group. This means that when specifying the profile of prestressing strands, the user needs to specify the profile of the centroid of the prestressing group. Several methods of describing tendon profiles are provided by the preprocessor including straight profiles, single and dual point hold down profiles, and parabolically draped profiles. 2.5.3 Shielding of Pretensioning Pretensioning is used to induce moments into an unloaded girder that will eventually oppose moments produced by normal bridge loading. In many situations, however, when normal loads are applied to bridge there is little or no moment at one or both ends of the girders. In these situations, the pretensioning may be placed in a profile that has zero eccentricity at the ends of the girder so that zero countermoment is induced. An alternative is to use a straight pretensioning profile with selected pretensioning strands being shielded near the ends of the girder. Shieldingalso known as debondingis the process of preventing bond between the pretensioning strand and the concrete so as to effectively eliminate a portion of the pretensioning at a particular location. The preprocessor is capable of modeling pretensioning shielding. The user must specify the percentages of pretensioning that are shielded and the distances over which those percentages apply. 2.5.4 PostTensioning Termination In certain situations, it can be advantageous to terminate posttensioning tendons at locations other than at the ends of the girders. For example, selected tendons may be brought out through the top of the girder near, but not at, the end of the girder. The preprocessor can model early termination of posttensioning tendons in prestressed concrete girder bridges provided that the user has specified the termination points. Recall that all posttensioning in a bridge must be represented using either one or two phases when using the preprocessor. Since each of these phases is represented using a single tendon, all of the posttensioning for a particular phase must be terminated at a common location. If multiple tendons are used for a particular phase of posttensioning and those tendons do not terminate at the same location, then a single approximate termination point for the entire phase must be determined by the user. 2.5.5 End Blocks End blocks are regions of a girder in which the web has been significantly thickened but the overall shape of the cross section remains unchanged. They are often provided at the ends of prestressed concrete girders to increase the shear capacity of the cross section and to accommodate the large quantity of reinforcing that is often necessary at the anchorage points of posttensioning tendons. The preprocessor models girders containing end blocks as specialcase nonprismatic girders. End blocks are permitted at the end supports and permanent interior supports of a bridge. The only information that the engineer must specify is the thickness and length of each end block. End blocks are assumed to have the same general shape as the normal girder cross section except for an increased web thickness that extends some specified length along the end of the girder. A typical end block is illustrated in Figure 2.7. Actual girders generally have a transition length in which the web thickness varies from the thickness of the end block to the thickness of the normal section. This transition length is not actually specified by the user, however, the preprocessor will model the transition from the end block cross section to the normal cross section using a single tapered girder element. 2.5.6 Temporary Shoring There are practical limitations to the length of girders that can be fabricated and transported. As a result, some bridges are built by employing a construction method in which more than one prestressed girder is used to form each span. The preprocessor can model bridges in which each main span is constructed from two individually I End Block Length ni Length End Block I WWb Widdh + End 'Block+ Cetroid Cenrooid Cross Sectiono idupp To Cro Secon Of Ed Block .. ,. Of Girder Figure 2.7 End Block Region of a Prestressed Concrete Girder prestressed girders that are temporarily supported, bonded together, and then post tensioned for continuity. This feature of the preprocessor is only available for the modeling of multiple span bridges and a maximum of one temporary shore per span is permitted. Finally, all of the girders within a particular span must have the same condition with respect to whether or not temporary shoring is present. Once the preprocessor has determined which spans in the bridge contain temporary shoring, it will create structural models for each stage of construction accounting for the presence of shoring. 2.5.7 Stiffening of the Deck Slab Over the Girder Flanges The top flanges of prestressed concrete girders are usually sufficiently thick that they stiffen the portion of the deck slab lying directly above them. As a result the lateral bending deformation in the portion of the slab that lies directly over the girder flanges is markedly less than the deformation of the portion of the slab that spans between the flanges of adjacent girders. In the models created by the preprocessor, this stiffening effect is accounted for by attaching lateral beam elements to the slab elements that lie directly above the girder flanges. The stiffnesses of the lateral beam elements are computed in such a way that they reflect the approximate bending stiffness of the girder flange. A more detailed discussion of this modeling procedure is presented in the next chapter. 2.6 Modeling Features Specific to Steel Girder Bridges Several of the modeling features available in the preprocessor relate specifically to the modeling of steel girder bridges (see Figure 2.8). This section will provide an overview of those features. 2.6.1 Diaphragms In the steel girder bridge models created by the preprocessor diaphragms are permitted to be either of the steel beam type or the steel cross brace type. Each of these types is illustrated in Figure 2.9. The diaphragms connect adjacent girders together but are not connected to the deck slab between the girders. Structurally, the diaphragms aid in lateral load distribution, prevent movement of the girder ends relative to one another, and are assumed to provide complete lateral bracing of the bottom flange in negative moment regions. If a large number of diaphragms are used, as is often the case for steel girder bridges, the diaphragms may have a significant effect on lateral load distribution. Cross brace diaphragms are constructed from relatively light steel members such as angles and are often arranged in either an Xbrace configuration or a Kbrace Conrete Concrete Steel Beam Steel Parapet Deck Slab Diaphragm Girder Figure 2.8 Cross Section of a Typical Steel Girder Bridge configuration. The steel girder bridge type is the only bridge type for which the preprocessor allows cross brace diaphragms to be modeled. A detailed study was performed by Hays and Garcelon (see Hays et al. 1994, Appendix I) in which steel girder bridges were studied using full three dimensional models. The studies indicated that the behavior of bridges having Xbrace and Kbrace diaphragms were sufficiently close that Kbrace diaphragms can adequately be modeled using the Xbrace configuration. Thus, only the Xbrace configuration is modeled by the preprocessor. The engineer must specify whether beam diaphragms or cross brace diaphragms will be used and provide the section properties for either the steel beam or the elements of the cross brace. These section properties are then used for all of the diaphragms in the bridge. However, in the case of cross brace diaphragms, the depth of the diaphragms will vary if the depth of the girders vary. 2.6.2 Hinges Hinged girder connections are occasionally placed in steel girder bridges to accommodate expansion joints or girder splices. The preprocessor is capable of Deck Slab Steel Beam LightSteel Elements Light Steel Elements Beam Diaphragm XBrace Diaphragm KBrace Diaphragm Cross Brace Diaphragms Figure 2.9 Diaphragm Types Available for Steel Girder Bridges modeling hinge connections for constant skew steel girder bridges. Hinges are assumed to run laterally across the entire width of the bridge, thus forming a lateral hinge line at each hinge location. Along a hinge line, each of the girders contains a hinge connection and the deck slab is assumed to be discontinuous. Modeling the slab as discontinuous across the hinge line is consistent with the construction conditions of an expansion joint. 2.6.3 Concrete Creep and Composite Action Long term sustained dead loads on a bridge will cause the concrete deck slab to creep. Concrete creep is time dependent nonrecoverable deformation that occurs as the result of sustained loading on the concrete. Over time, the concrete will flow similar to a plastic material and will incur permanent deformation. In a steel girder bridge the deck slab and girders are constructed from materials that have different elastic moduli and different sustained load characteristics. Steel has a higher elastic modulus than concrete and does not creep under sustained loads as concrete does. If long term dead loads are applied to the bridge after the concrete deck slab and steel girders have begun to act compositelyt, the slab will be subjected to sustained loading and creep will occur. As the deck slab undergoes creep deformation but the steel girders do notmore and more of the load on the bridge will be carried by the girders and girder stresses will consequently increase. Creeping of the deck slab t Long term dead loads that are applied after composite action has begun include the dead weight of structural parapets, line loadssuch as the weight of a railing or a nonstructural parapet, and deck overlay loads. essentially softens the composite girderslab load resisting system and therefore increases the stresses in the girders. When modeling steel girder bridges that fit the conditions described above, the preprocessor will automatically account for the effects of concrete deck creep. Details of this modeling procedure are presented in the next chapter. 2.7 Modeling Features Specific to Reinforced Concrete TBeam Bridges Reinforced concrete Tbeam bridges (see Figure 2.10) are modeled very similarly to prestressed concrete girder bridges except that there is no prestressing present. A notable exception is that the cross sectional shape of a Tbeam girder is completely defined by the depth and width of the girder web. A Tbeam girder consists of a rectangular concrete web joined to the deck slaba portion of which acts as the girder flange. Thus the engineer simply specifies the depth and width of the web of each girder when modeling Tbeam bridges. Databases of standard cross sectional shapes are not needed as was the case in prestressed concrete girder bridges. Concrete Concrete Parapet Deck Slab Concrete TBeam Web Web Width Figure 2.10 Cross Section of a Typical Reinforced Concrete TBeam Bridge 2.8 Modeling Features Specific to FlatSlab Bridges Flatslab bridges (see Figure 2.11) consist of a thick reinforced concrete deck slab and optional reinforced concrete edge stiffeners. Thus, unlike all of the other bridge types modeled by the preprocessor, there are no girders in flatslab bridges. However, there can still be composite action between the deck slab and edge stiffeners such as parapets, if such stiffeners are present and considered structurally effective. Support conditions for flatslab bridges are also unique among the bridge types modeled by the preprocessor. Flatslab bridges are supported continuously across the bridge in the lateral direction at each support location. This is in contrast to girderslab bridges in which supports are only provided for girder elements and the remainder of the bridge is assumed to be supported by the girders. Conrete Concrete Flat Slab Parapet Deck Slab Thickness Figure 2.11 Cross Section of a Typical Flatslab Bridge CHAPTER 3 MODELING BRIDGE COMPONENTS 3.1 Introduction In creating finite element bridge models, the preprocessor utilizes modeling procedures that have been devised specifically for the types of bridges considered. Some of the procedures are used to model actual structural components such as girders and diaphragms whereas others are used to model structural behavior such as composite action and deck slab stiffening. This chapter will discuss the preprocessor modeling procedures in detail. 3.2 Modeling the Common Structural Components The common structural components that are modeled by the preprocessor include the deck slab, girders, stiffenerssuch as parapets or railings, diaphragms, and elastic supports. The modeling of these common structural components, which are the components that are common to several or all of the bridge types considered, will be discussed below. 3.2.1 Modeling the Deck Slab Plate bending elements are used to model the bridge deck for the noncomposite model (NCM) and the composite girder model (CGM). However, in cases where composite action is modeled with the eccentric girder model (EGM), flat shell elements are used. The shell element combines plate bending behavior and membrane behavior, however the membrane response is not coupled with the plate bending response. The thickness of the slab elements is specified by the engineer and is assumed to be constant throughout the entire deck except over the girders, where a different thickness may be specified. The plate bending elements and the bending (flexural) portion of the flat shell elements used in the present bridge modeling are based on the ReissnerMindlin thick plate formulation (Hughes 1987, Mindlin 1951, Reissner 1945). In the Reissner Mindlin formulation, transverse shear deformations, which can be significant in thick plate situations such as in flatslab bridge modeling, are properly taken into account. Consolazio (1990) studied the convergence characteristics of isoparametric elements based on the thick plate formulation and found that these elements are appropriate for bridge modeling applications. While typical isoparametric plate and shell elements may generally have between four and nine nodes, bilinear (four node) plate and shell elements are used for all of the bridge models created by the preprocessor. This choice was made for a number of reasons. Because vehicle axle loads occur at random locations on a bridge, accurately describing these axle loads requires a substantial number of nodes in the longitudinal direction. It is generally suggested that when using the preprocessor at least twenty elements per span be used in the longitudinal direction. Use of biquadratic (nine node) elements in models following this suggestion would require substantially more solution time than would models using the simpler bilinear elements. This was shown to be true by Consolazio (1990) for all but trivially small bridge models. Another important reason for using bilinear elements instead of biquadratic elements is related to the fact that both of these elements are known to be rank deficient when their stiffness matrices are numerically underintegrated. Selective reduced integration (Bathe 1982, Hughes 1987) is often used to alleviate the problem of shear locking in plate elements. Shear locking, which results in greatly exaggerated structural shear stiffness, occurs when elements based on the thick plate formulation are used in thin plate situations. Selective reduced integration is used to soften the portion of the element stiffness matrix that is associated with transverse shear. When underintegrated elements are used in thick plate situations such as the modeling of a flatslab bridge, zero energy modes may develop which can cause the global stiffness matrix of the structure to be locally or globally singular (or nearly singular). Both the bilinear and biquadratic elements suffer from zero energy modes. However, it has been the author's experience that the mode associated with biquadratic elements, illustrated in Figure 3.1, is excited far more frequently in bridge modeling situations than the modes associated with bilinear elements. In fact the biquadratic  Undefomed Element SDfonmed Eleoment In Zero Energy Mode Configuration (r.st) Local Element Directions The tdiretion is the transverse transnational dircion of the element Figure 3.1 Zero Energy Mode in a Biquadratic Lagrangian Element element zero energy mode occurs quite often in the modeling of flatslab bridges and must be used with great caution in such situations. One solution to this problem is to use the nine node heterosis element developed by Hughes (1987) which inherits all of the advantages of using higher order shape functions without the disadvantage of being rank deficient. Correct rank is accomplished by utilizing standard lagrangian (ninenode) shape functions for all element rotational degrees of freedom (DOFs) but serendipity (eightnode) shape functions for the translational DOFs. Both a nine node standard lagrangian element and a nine node heterosis element have been implemented by the author in a FEA program that was developed as part of the present research. In tests on flatslab bridge models, the heterosis element performed flawlessly in situations where lagrangian elements suffer from zero energy modes. However, because there is no translational degree of freedom associated with the center nodes of heterosis elements, bridge meshing and distribution of wheel loads is considerably more complex. Thus, a simpler solution is to simply use bilinear elements and ensure that an adequate number of such elements is used both the lateral and longitudinal directions of the bridge. This is the solution that has been adopted for use in the preprocessor. 3.2.2 Modeling the Girders and Stiffeners Girders and stiffeners are modeled using standard frame elements. Frame elements consider flexural effects (pure beam bending), shear effects, axial effects, and torsional effects. Each of these groups of effects are considered separately and are therefore not coupled. If the CGM is chosen, composite section properties are used for the elements representing girders and stiffeners in the bridge. If the NCM is selected then the noncomposite element properties are used. If the EGM is used, then the noncomposite girder and stiffener properties are used and the composite action is modeled by locating the frame elements eccentrically from the centroid of the slab. In modeling steel girders using frame elements, the transverse shear deformations in the elements are properly taking into account. Hays and Garcelon (Hays et al. 1994, Appendix I) found that, when using the type of models created by the preprocessor, shear deformations in the girders must be considered for the analysis to be accurate. This conclusion was based on a study comparing the response of models created by the preprocessor and the response of fully three dimensional models. Shear deformations are not, and do not need to be, accounted for in concrete girders or concrete parapets where such deformations are typically negligible. The term stiffener, as used in this research, refers to structural elements such as parapets, railings, and sidewalks that reside on the bridge deck. Stiffeners can improve the load distribution characteristics of bridges by adding stiffness to the bridge deck, usually near the lateral edges. 3.2.3 Modeling the Diaphragms Diaphragms are bridge components that connect girders together so as to provide a means of transferring deck loads laterally to adjacent girders. In prestressed concrete girder bridges and R/C Tbeam bridges, the diaphragms are assumed to be constructed as concrete beams and are thus modeled using frame elements. Beam diaphragms are assumed to not act compositely with the deck slab. This is true whether or not composite action is present between the girders, stiffeners, and deck slab. Therefore the diaphragm elements in concrete girder bridges are located at the elevation of the centroid of the slab, as illustrated in Figure 3.2. In this manner, the diaphragm elements assist in distributing load laterally but do not act compositely with the deck slab. In steel girder bridges, diaphragms may be either steel beams or cross braces constructed from relatively light steel members called struts. Steel beam diaphragms, shown in Figure 3.2, are modeled in the same manner that concrete diaphragms are modeled. Cross brace diaphragms, however, are modeled using axial truss elements representing the strutsthat are located eccentrically from the centroid of the slab. The struts are located eccentrically from the finite element nodes regardless of whether or not composite action is present between the girders, stiffeners, and deck slab. Truss eccentricities are computed as the distances from the centroid of the slab to the top and Finite Deck Concrete Concrete Deck Steel Stel Diaphragm Elemnt Slab Diaphragm Girder Slab Diaphragm Girder Elements Ndes Concrete Girder Bridge Steel Girder Bridge Elevation of Cntroid Of Deck Slab Figure 3.2 Modeling Beam Diaphragms bottom strut connection points, as is shown in Figure 3.3. Thus, the centroid of the deck slab is used as a datum from which eccentricities are referenced. Of primary importance in computing these eccentricities is correctly representing the slopes of the cross struts, since these slopes determines how effective the diaphragm will be in transferring loads laterally. Finally, recall that the preprocessor models both Xbrace and Kbrace diaphragms using the Xbrace configuration for the reasons that were discussed in the previous chapter. 3.2.4 Modeling the Supports Bridge models created by the preprocessor use axial truss elements to model elastic spring supports rather than using rigid supports. In girderslab bridges, vertical support is usually provided by elastomeric bearing pads located between the ends of the girders and the abutments and at interior support piers. Bearing pads are modeled using elastic axial truss elements of unit length, unit elastic modulus, and a cross sectional area that results in the desired support stiffness. By default the preprocessor will automatically provide reasonable values of bearing pad stiffness (see Hays et al. 1994 oi t 't Axial Tuss_ ut Elements Figure 3.3 Modeling Cross Brace Diaphragms for details) however the engineer may manually adjust these values if detailed bearing stiffness data are available. In addition to vertical supports, horizontal supports must also be provided to prevent rigid body instability of the models at each stage of construction. Horizontal support is provided through finite element boundary condition specification rather than by using elastic supports. Flatslab bridges are supported continuously in the lateral direction at each support in the bridge. Since bearing pads are not typically used in flatslab bridge construction the support stiffnesses cannot not be easily determined. However, the preprocessor assumes a reasonable value of bearing stiffness, which again can be manually adjusted by the engineer if better data are available. 3.3 Modeling Composite Action Composite action is developed when two structural elements are joined in such a way that they deform together and act as a single unit when loaded. In the case of bridges, composite action can occur between the concrete slab and the supporting concrete or steel girders. The extent to which composite action can be developed depends upon the strength of bond that exists between the slab and the girders. Composite action may also occur between stiffeners and the deck slab. In a composite system there is continuity of strain at the slabgirder interface and therefore no slip occurs between these elements. Horizontal shear forces and vertical forces are developed at the boundary between the two elements. The interaction necessary for the development of composite action between the slab and the girder is provided by friction and the use of mechanical shear connectors. In a noncomposite girderslab system, there is a lack of bond between the top of the girder and the bottom of the slab. As a result, the two elements are allowed to slide relative to each other during deformation and do not act as a single composite unit. Only vertical forces act between the two elements and there is a discontinuity of strain at the boundary between the elements. The preprocessor allows the engineer to model the girderslab interaction as either noncomposite, or as composite using one of two composite modeling techniques. The girderslab interaction models available in the preprocessor are illustrated in Figure 3.4. Noncomposite action is modeled using the noncomposite model (NCM) in which the centroid of the girder is effectively at the same elevation as the centroid of the slab. The section properties specified for the girders are those of the bare girders alone. In this model the primary function of the slab elements is to distribute the wheel loads laterally to the girders, therefore plate bending elements are used to model the deck slab. Composite action between the slab and the girder is modeled in one of two ways using the preprocessor. One way involves the use of the composite girder model (CGM) and the other the eccentric girder model (EGM). These composite action models are also illustrated in Figure 3.4. Effective Width 'I H i st Shell) Centroid of Girder Alone Eccentricty Slab Elements Centmid of (Plate Bending) OfGirder (Plate Bending) Composite Aloe Section A Noncomposite Composite Girder Eccentric Girder Model (NCM) Model (CGM) Model (EGM) Figure 3.4 Modeling Noncomposite Action and Composite Action 3.3.1 Modeling Composite Action with the Composite Girder Model One method of modeling composite action is by utilizing composite properties for the girder elements. The centroid of the composite girder section is at the same elevation as the midsurface of the slab in the finite element model. A composite girder section is a combination of the bare girder and an effective width of the slab that is considered to participate in the flexural behavior. Due to shear strain in the plane of the slab, the compressive stresses in the girder flange and slab are not uniform, and typically decrease in magnitude with increasing lateral distance away from the girder web. This effect is often termed shear lag. In certain cases of laterally nonsymmetric bridge loading, the compressive stress in the deck may vary such that the stress is higher at the edge of the bridge than over the centerline of a girder. An effective slab width over which the compressive stress in the deck is assumed to be uniform is used to model the effect of the slab acting compositely with the girder. The effective width is computed in such a way that the total force carried within the effective slab width due to the uniform stress is approximately equal to the total force carried in the slab under the actual nonuniform stress condition. In order to compute composite section properties, the effective width must be determined. Standard AASHTO recommendations are used to compute the effective width for the various bridge types that can be modeled using the preprocessor. In computing composite girder properties, the width of effective concrete slab that is assumed to act compositely with the girder must be transformed into equivalent girder material. This transformation is accomplished by using the modular ratio, n, given by =E (3.1) where Ec is the modulus of elasticity of the concrete slab and Eg is the modulus of elasticity of the girder. For steel girders the modulus of elasticity is taken as 29,000 ksi. For concrete, the modulus of elasticity is computed based on the concrete strength using the AASHTO criteria for normal weight concrete. When using the composite girder model, composite action is approximated by using composite section properties for the girder members. The primary function of the slab elements in the CGM finite element model is to distribute wheel loads laterally to the composite girders, thus plate bending elements are used to model the deck slab. 3.3.2 Modeling Composite Action with the Eccentric Girder Model The second method available for modeling composite action involves the use of a pseudo three dimensional bridge model that is called the eccentric girder model (EGM). In this model, the girders are represented as frame elements that have the properties of the bare girder cross section but which are located eccentrically from the slab centroid by using rigid links. By locating the girder elements eccentrically from the slab, the girder and slab act together as a single composite flexural unit. In general, each componentthe slab and the girdermay undergo flexure individually and may therefore sustain moments. However, because the components are coupled together by rigid links, the composite section resists loads through the development not only of moments but also of axial forces in the elements. Rigid links, also referred to as eccentric connections, are assumed to be infinitely rigid and therefore can be represented exactly using a mathematical transformation. Thus, by using the mathematical transformation, additional link elements do not need be added to the finite element model to represent the coupling of the slab and girder elements. In the eccentric girder model, shear lag in the deck is properly taken into account because the deck slab is modeled with flat shell elementselements created by the superposition of plate bending elements and membrane elements. Because the slab and girders are eccentric to one another and because they are coupled together in a three dimensional sense, the EGM is referred to as a pseudo three dimensional model. It is not a fully three dimensional model because the coupling is accomplished through the use of infinitely rigid links. In an actual bridge the axial force in the slab must be transferred to the girder centroid through a flexiblenot infinitely rigidgirder web. In a fully three dimensional model, the girder webs would have to be modeled using shell elements as was done by Hays and Garcelon (Hays et al. 1991). Therefore the models created by the preprocessor are pseudo three dimensional models. The main deficiency of using rigid links occurs in modeling weak axis girder behavior. The use of rigid links causes the weak axis moment of inertia of the girders to become coupled to the rotational degrees of freedom of the deck slab. This coupling will generally result in an overestimation of the lateral stiffness of the girders. To avoid such a problem the preprocessor sets the weak axis moment of inertia of the girders to a negligibly small value. This procedure allows rigid links to be used in modeling composite action under longitudinal bridge flexure but does not result in overestimation of lateral stiffness. Since the preprocessor models bridges for gravity and vehicle loading and not for lateral effects such as wind or seismic loading, this procedure is reasonable. Illustrated in Figure 3.5 is the eccentric girder model for a girderslab system consisting of a concrete deck slab and a nonprismatic steel girder. The system is assumed to consist of multiple spans of which the first span is shown in the figure. In modeling the slab and girder, a total of six elements have been used in the longitudinal direction in the span shown. A width of two elements in the lateral direction are shown modeling the deck slab. Nodes in the finite element model are located at the elevation of the slab centroid. The girder elements are located eccentrically from the nodes using rigid links whose lengths are the eccentricities between the centroid of the slab and the centroid of the girder. Because the girder is nonprismatic, the elevation of the girder centroid varies as one moves along the girder in the longitudinal direction. For this Deck Slab Centroid Of (Shell) Element Shell Elements ; yi i I IEccntricity Ar Girder (Frame) Girder Rigid Link So AA Element Centrid (Eccentricity) Set A  Finite Element Node / Flat Shell Element SEccentricity Betceen Slan Ce atro And Girder Certroid Figure 3.5 Modeling Composite Action with the Eccentric Girder Model reason the lengths of the rigid linksi.e. the eccentricities of the girder elementsalso vary in the longitudinal direction. Displacements at the ends of the girder elements are related to the nodal displacement DOF at the finite element nodes by rigid link transformations. Slab elements, modeled using flat shell elements, are connected directly to the finite element nodes without eccentricity. Recall that in the EGM the slab elements are allowed to deform axially as are the girder elements. In this manner the slab and girder elements function jointly in resisting load applied to the structure. Since the slab elements must be allowed to deform axially a translating roller support is provided at the end of the first span. By using a roller support, the girder and slab are permitted to deform axially as well as flexurally and can therefore act compositely as a single unit. The EGM composite action modeling technique is generally considered to be more accurate than the CGM modeling technique. This is because in the CGM an approximate effective width must be used in the determination of the composite section properties. However, while the EGM is more accurate, the analysis results must be interpreted with greater care since the effect of the axial girder forces must be taken into consideration when the total moment in the girder section is determined. Also, when using the EGM, it is necessary to use a sufficient number of longitudinal elements to ensure that compatibility of longitudinal strains between the slab and girder elements is approached (Hays and Schultz 1988). It is therefore recommended that at least twenty elements in the longitudinal direction be used in each span. 3.4 Modeling Prestressed Concrete Girder Bridge Components The modeling of structural components and structural behavior that occur only in prestressed concrete girder bridges will be described in the sections below. 3.4.1 Modeling Prestressing Tendons Prestressed concrete girder bridges make use of pretensioning and post tensioning tendons to precompress the concrete girders, thus reducing or eliminating the development of tensile stresses. The tendons used for pretensioning and post tensioning of concrete will be referred to collectively as prestressing tendons in this context. Prestressed bridges are pretensioned and may optionally be posttensioned in either one or two phases when using the preprocessor. Posttensioned continuous concrete girder bridges are modeled assuming that the girders are pretensioned, placed on their supports and then posttensioned together to provide structural continuity. In order to model prestressing tendons using finite elements, both the tendon geometry and the prestressing force must be represented. Tendons are modeled as axial Girder Prestressing Rigid Prestressing Finit (Fme) Tendon (Truss) Link Tendon Element Element Element (Eccentricity) Centroid Node Prestressing irder Hold Don Points Cros Setion Figure 3.6 Modeling the Profile of a Prestressing Tendon truss elements that are eccentrically connected to the finite element nodes by rigid links (see Figure 3.6). Since straight truss elements are used between each set of nodes in the tendon, a piecewise linear approximation of the tendon profile results. The tendon is divided into a number of segments that is equal to the number of longitudinal elements per span specified by the user. As long as a reasonable number of elements per span is specified, this method of representing the profile will yield results of ample accuracy. The reference point from which tendon element eccentricities are specified in the model varies depending on the particular type of composite action modeling being used and on the particular construction stage being modeled. In the noncomposite model (NCM) tendon element eccentricities are always referenced to the centroid of the barei.e. noncompositegirder cross section. In the composite model (CGM), for construction stages where the slab and girder are acting compositely, the eccentricities are referenced to the centroid of the composite girder cross section which includes an effective width of deck slab. Eccentricities in the eccentric girder model (EGM) for construction stages where the slab and girder are acting compositely are referenced to the midsurface of the slab. Prestressing element eccentricities for construction stages in which the deck slab is structurally effective are illustrated in Figure 3.7. In construction stages where the deck slab has not yet become structurally effective, the tendon eccentricities are always referenced to the centroid of the bare girder cross section regardless of which composite action model is being used. When using the preprocessor, the engineer always specifies the location of the prestressing tendons relative to the top of the girder. With this data, the preprocessor computes the proper truss element eccentricities for each construction stage of the bridge based on the composite action model in effect. The example girder that is shown in Figure 3.6 has a piecewise linear tendon profile tendon created by dual hold down points. Note however that the preprocessor is capable of approximating any tendon profile, linear or not, as a series of linear segments. In addition to modeling the profile of the prestressing tendons, the prestressing force must also be represented. This is accomplished simply by specifying an initial tensile force for each tendon (truss) element in the model. Since the tendons are modeled using elastic truss elements, prestress losses due to elastic shortening of the concrete girder are automatically accounted for in the analysis. However, nonelastic Nonconposie Composite Girder Eccentric Girder Model (NCM) Model (CGM) Model (EGM) Figure 3.7 Modeling the Profile of a Prestressing Tendon losses due to effects such as friction, anchorage slip, creep and shrinkage of concrete, and relaxation of tendon steel are not incorporated into the model. (In the BRUFEM system, these nonelastic losses are accounted for automatically by the postprocessor based on the appropriate AASHTO specifications). Thus, the tendon forces specified by the engineer must be the initial pretensioning or posttensioning forces in the tendons, prior to any losses. 3.4.2 Increased Stiffening of the Slab Over the Concrete Girders During lateral flexure in prestressed (and also reinforced concrete Tbeam) girder bridges, the relatively thin slab between the girders deforms much more than the portion of the slab over the flanges of the girders. This behavior is due to the fact that the girder flange and web have a stiffening effect on the portion of the slab that lies directly above the girder. Rather than using thicker plate elements over the girders, lateral beam elements are used to model this stiffening effect. These lateral beam elements are located at the midsurface of the slab and extend over the width of the girder flanges, as is shown in Figure 3.8. Slab Lateral Beam _ Elemen\ I / Elements Slab SElements L / Girder ThickneOf / Elements Tnicness Of sy Slab Over Girder Lateral Thcktness Of Bm Slab Over Girder Elements Plus Effective Range 4 Thickne L Cross Sectional View Plan View Figure 3.8 Modeling the Stiffening Effect of the Girder Flanges on the Deck Slab The lateral bending stiffness of these elements is assumed to be that of a wide beam of width SY (SY/2 for elements at the ends of the bridge). From plate theory (Timoshenko and WoinowksyKrieger 1959) the flexural moment in a plate is given by Et3 Mx= x + 4 ) (3.2) 12( 1 v2) where M, is the moment per unit width of plate, E is the modulus of elasticity, t is the plate thickness, v is Poisson's ratio, and x, and ,y are the curvatures in the x and ydirections respectively. Since the value of Poisson's ratio for concrete is small (v= 0.15), it can be assumed that the quantity (1 v) is approximately unity. Also, since only bending in the lateral direction (xdirection) is of interest for the lateral beam members, only the xcurvature x, is taken into consideration. From Equation (3.2) and the simplifications stated above, the moment of inertia of a plate element having thickness t is I (SY) (3.3) 12 Since the moment of inertia of the slab is automatically accounted for through the inclusion of the plate elements in the bridge model, the effective moment of inertia of the lateral beam element is given by I =t(+f) t (SY) (3.4) 12 where t(sg+ef) is the thickness of the slab over the girder plus the effective flange thickness of the girder and t, is the thickness of the slab of the girder. The torsional moment of inertia of the lateral beam members is obtained in a similar manner. From plate theory the twisting moment in a plate of thickness t is given by SGt3 (3.5) 6y 6 where G is the shear modulus of elasticity, and 4y is the cross (or torsional) curvature in the plate. Thus, the effective torsional moment of inertia of the lateral beam elements is given by J sg+ef) t (SY) (3.6) 6 where the parameters t(sg+ef) and tg are the same as those described earlier. 3.5 Modeling Steel Girder Bridge Components The modeling of structural components and structural behavior that occur only in steel girder bridges will be described in the sections below. One of the areas of modeling that is specific to steel girder bridges is that of modeling cross brace steel diaphragms. However, since this topic was already considered in 3.2.3 in a general discussion of diaphragm modeling, it will not be repeated here. 3.5.1 Modeling Hinges Hinged girder connections are occasionally placed in steel girder bridges to accommodate expansion joints or girder splices. Hinges are assumed to run laterally across the entire width of the bridge, thus forming a lateral hinge line at each hinge location. Along a hinge line, each of the girders contains a hinge connection and the deck slab is made discontinuous. When using the preprocessor, the engineer inserts hinges into the bridge by specifying the distances from the beginning of the bridge to the hinges. If the hinge distances specified do not match the locations of finite element nodal lines, then the hinge lines are moved to the location of the nearest nodal line. Also, note that the insertion of hinges into a bridge must not cause the structure to become unstable. For example, one may not insert a hinge into a single span bridge since this would result in an unstable structure. Hinge modeling is accomplished by placing a second set of finite element nodes along the hinge line at the same locations as the original nodes. In Figure 3.9, this is depicted by showing a small finite distance between the two set of nodes at the hinge line. In the actual finite element bridge model the distance between the two lines of nodes is zero. Girder, stiffener, and slab elements on each side of the hinge line are then connected only to the set of nodes on their corresponding side of the hinge. At this point the bridge is completely discontinuous across the hinge line. Figure 3.9 Modeling a Hinge in a Steel Girder Bridge Girders are the only structural components assumed to be even partially continuous across hinges. The deck slab and stiffeners are assumed to be completely discontinuous across hinges. Girder are continuous with respect to vertical translation and, in some cases, axial translation but not flexural rotation. As a result, the end rotations of the girder elements to either side of a hinge are uncoupledi.e. a hinge is formed. Displacement constraints are used to provide continuity at the points where girder elements cross a hinge line. In bridges modeled using the NCM or CGM composite action models, the vertical translations of the nodes that connect girder elements across a hinge line are constrained. When the EGM composite action model is used, all three translations must be constrained due to the axial effects in the model. Nodes to which girder elements are not connected are left unconstrained and therefore are allowed displace independently. 3.5.2 Accounting for Creep in the Concrete Deck Slab As was explained in the previous chapter, long term sustained dead loads on a bridge will cause the concrete deck slab to creep. In steel girder bridges, the deck slab and girders are constructed from materials that have different elastic moduli and therefore different sustained load characteristics. As the concrete slab creeps over time, increasingly more of the dead loads will be carried by the steel girders. Since the models created by the preprocessor are not time dependent finite element models, the creep effect must be accounted for in some approximate manner. Depending on the composite action model being used, creep is accounted for in one of the ways discussed below. If the CGM is being used to represent composite action, then the creep effect is accounted for when computing composite section properties for the girders. Normally, when composite section properties are computed, the effective width of concrete slab that acts compositely with the girders is transformed into an equivalent width of steel by dividing by the modular ratio. This equivalent width of steel is then included in the computation of composite section properties for the girder. The modular ratio is a measure of the relative stiffnesses of steel and concrete and is given by Ec Eg (3.7) where Ec is the modulus of elasticity of the concrete deck slab and Eg is the modulus of elasticity of the steel girders. In order to account for the increased deformation that will arise from creeping of the deck, the preprocessor uses a modified modular ratio when computing composite girder properties. When transforming the effective width of concrete slab into equivalent steel, a modular ratio of 3n is used instead of n. This yields a smaller width of equivalent steel and therefore smaller section properties. Because the section properties are reduced, the stiffness of the girders are reduced, deformations increase, and stresses in the girders increase. If the EGM is used to represent composite action, then the effect of creep is accounted for by employing orthotropic material properties in the slab elements. In the EGM, the deck slab is modeled using a mesh of shell elements. By using orthotropic material properties for these shell elements, different elastic moduli may be specified for the longitudinal and lateral directions. To account for creep, the elastic modulus of the shell elements is divided by a factor of 3.0 in the longitudinal direction, but left unmodified in the lateral direction. Using this technique, the effects of creep, which relate primarily to stresses in the longitudinal direction, are accounted for without disturbing the lateral load distribution behavior of the deck. If the noncomposite model (NCM) is used, then the girders and deck slab do not act compositely and the girders are assumed to carry all of the load on the bridge. Since the girders carry all of the load, the effects of creep in the concrete deck will be negligible and therefore no special modeling technique is necessary. 3.6 Modeling Reinforced Concrete TBeam Bridge Components Reinforced concrete (R/C) Tbeam bridges are modeled by the preprocessor in essentially the same manner that prestressed concrete girder bridges are modeled. The obvious exception to this statement is that R/C Tbeam bridges lack the prestressing (pretensioning and possibly posttensioning) tendons that are present in prestressed concrete girder bridges. However, the girders in each of these bridge types are constructed from the same materialconcreteand are therefore modeled in the same manner. Diaphragms have precisely the same configuration in both of these bridge types and are therefore modeled in identical fashion. Finally, the deck slab stiffening effect that was discussed in 3.4.2 in the context of prestressed concrete girders also occurs in R/C Tbeam bridges. In R/C Tbeam bridges, this stiffening effect is represented using the same lateral beam elements that were discussed earlier for prestressed concrete girders. 3.7 Modeling FlatSlab Bridge Components A flatslab bridge consists of a thick reinforced concrete slab and optional edge stiffeners such as parapets. If stiffeners are present and structurally effective, they are modeled using frame elements as is the case for girderslab bridges. If stiffeners are not present on the bridge or are not considered structurally effective, then the slab is modeled using plate elements and the entire bridge is represented as a largepossibly multiple spanplate structure. When stiffeners are present on the bridge but do not act compositely with the slaband are therefore not considered structurally effectivethey should be specified as line loads by the engineer. If stiffeners are considered structurally effective, then the engineer can choose either the CGM or EGM of composite action. If the CGM is chosen, then the slab is modeled using plate elements and composite section properties are computed for the stiffener elements using the effective width concept. If the EGM is chosen, the slab is modeled using shell elements and the stiffeners are located eccentrically above the flat slab using rigid links. The NCM is not available for flatslabs because if sufficient bond does not exist between the stiffeners and slab to transfer horizontal shear forces, it cannot be assumed that there is sufficient bond to transfer vertical forces either. In order for stiffenerswhich are above the slabto assist in resisting loads, there must be sufficient bond to transfer vertical forces to and from the slab. 3.8 Modeling the Construction Stages of Bridges To properly analyze a bridge for evaluation purposes, such as in a design verification or the rating of an existing bridge, each distinct structural stage of construction must be represented in the model. Using the preprocessor, this can be accomplished by creating a full load modela model in which the full construction sequence is considered. Each of the individual construction stage models, which collectively constitute the full load model, simulates a particular stage of construction and the dead or live loads associated with that stage. Modeling individual construction stages is very important in prestressed concrete girder bridges, important in steel girder bridges, and of lesser importance in R/C Tbeam and flatslab bridges. For each of these bridge types, the preprocessor assumes a particular sequence of structural configurations and associated loadings. These sequences will be briefly described below, however, for complete and highly detailed descriptions of each sequence see Hays et al. (1994). Several different types of prestressed concrete girder bridges may be modeled using the preprocessor. These include bridges that have a single span, multiple spans, pretensioning, one phase of posttensioning, two phases of posttensioning, and temporary shoring. Each of these variations has its own associated sequence of construction stages the highlights of which are described below. All prestressed girder bridges begin with an initial construction stage in which the girders are the only components that are structurally effective. In multiple span prestressed concrete girder bridges, the girders are not continuous over interior supports at this stage but rather consist of a number of simply supported spans. At this stage, the bridge is subjected to pretensioning forces and to dead loads resulting from the weight of the girders, diaphragms, andin most casesthe deck slab. In subsequent construction stages the bridge components that caused dead loads in this first stage, e.g. the diaphragms and deck slab, will become structurally effective and will assist the girders in resisting loads due to posttensioning, temporary support removal, stiffener dead weight, line loads, overlay loads, and ultimately vehicle loads. Prestressed concrete girder bridges may go through a construction stage that represents the effect of additional long term dead loads acting on the compound structure. Loads that are classified as additional long term dead loads include the dead weight of the stiffeners, line loads, and overlay loads. The compound structure is defined to be the stage of construction at which the deck slab has hardened and all structural components, except for stiffeners, are structurally effective. The term compound is used to refer to the fact that the various structural components act as a single compound unit but implies nothing with regard to the composite or noncomposite nature of girderslab interaction. Since the deck slab has hardened at this construction stage, the girders and deck slab may act compositely. Also, lateral beam elements are included in the bridge model to represent the increased stiffening of the girder on the deck slab. As construction progresses from one stage to the next, the bridge components become structurally effective in the following ordergirders, pretensioning, diaphragms, deck slab, lateral beam elements, phase1 posttensioning (if present), stiffeners, and phase2 posttensioning (if present). The final construction stage is represented by a live load model, i.e. a model which represents the final structural configuration of the bridge and its associated live loading. At this stage, each and every structural component of the bridge is active in resisting loads and the loads applied to the bridge are those resulting solely from vehicle loading and lane loading. Steel girder bridges have simpler construction sequences than prestressed concrete girder bridges due to the lack of prestressing and temporary shoring. Steel girder construction sequences begin with a construction stage in which the girders and diaphragms are assumed to be immediately structurally effective. The bridge model consists only of girder elements and diaphragm elements which, acting together, resist the dead load of the girders, diaphragms, and the deck slab. It is assumed that the girders in multiple span steel girder bridges are immediately continuous over interior supports. The assumption of immediate continuity of the girders is reasonable since multiple span steel bridges are not typically constructed as simple spans that are subsequently made continuous as is the case in prestressed concrete girder bridges. It is also assumed that the diaphragms in steel girder bridges are installed and structurally effective prior to the casting of the deck slab. Steel girder bridges may go through a construction stage that represents additional long term dead loads acting on the compound structure just as was described above for prestressed concrete girder bridges. Since the deck slab has hardened at this construction stage, the girders and deck slab may act compositely. However, lateral beam elements are not used in steel girder bridge models as they are in prestressed concrete girder bridge models. Also, in steel girder bridges, the effects of concrete deck creep under long term dead loading must be properly accounted for. This is accomplished by using the techniques presented in 3.5.2. In the final (live load) construction stage of steel girder bridges, each and every structural component of the bridge is active in resisting loads. At this stage, cracking of the concrete deck in negative moment regions of multiple span steel girder bridges may be modeled by the preprocessor. This deck crackingthe extent of which is specified by the engineeris assumed to occur only in the final live load configuration of the bridge. In modeling deck cracking, the preprocessor assumes a region in which negative moment is likely to be present. This assumption is necessary since only after the finite element analysis has been completed will the actual region of negative moment be known. Thus, the preprocessor assumes negative moment will be present in regions of the bridge that are within a distance of twotenths of the span length to either side of interior supports. See Hays et al. (1994) for further details of the cracked deck modeling procedure used by the preprocessor. In R/C Tbeam and flatslab bridges, the construction sequence is not of great significance and has little effect on the analysis and rating of the bridge. During the construction of these bridge types, the bridge often remains shored until all of the bridge components have become structurally effective. In such situations, all of the structural components become structurally effective and able to carry load before the shoring is removed. The preprocessor therefore assumes shored construction for these two bridge types. Based on the shored construction assumption, all of the structural elements used to model R/C Tbeam and flat bridges are assumed to be immediately structurally effective in resisting dead load. Thus, there exists only a single dead load construction stage in which all of the dead loadsincluding additional long term dead loadsare applied to the fully effective structural bridge model. The final live load construction stage consists of the same structural model as that used in the dead load stage, but subjected to vehicle and lane loading instead of dead loading. 3.9 Modeling Vehicle Loads Using the vehicle live loading features provided by the preprocessor, an engineer can quickly describe complicated live loading conditions with relative ease. In describing live loading conditions, the engineer only needs to specify the type, location, and direction of each vehicle on the bridge and the location and extent of lane loads. Once these data have been obtained, the preprocessor can generate a complete finite element representation of the live loading conditions. Recall from the previous chapter that the preprocessor models lane loads not as uniform loads on the deck slab, but instead as trains of closely spaced axles. Thus, both individual vehicles and lane loads are modeled using collections of axles. To model these live loads using the finite element method, the preprocessor must convert each axle, whether from a vehicle or a lane load, into an equivalent set of concentrated nodal loads that are applied to the slab nodes in the model. In order to accomplish this conversion to nodal loads the multiple step procedure illustrated in Figure 3.10 is performed by the preprocessor. 81 Vehicle or moidge Axle VWheel Lod Vh ic I dnast Geometry Distribution Axle Loads  Wheel Loads  Nodal Loads Lane Loads Figure 3.10 Conversion of Vehicle and Lane Loads to Nodal Loads Given the location of a vehicle on the bridge, the preprocessor computes the location of each axle within the vehicle, and then the location of each wheel within each axle. In the case of a lane load, the preprocessor computes the location of each axle in the axle train, and then the computes the location of each wheel within each axle. Finally, after computing the magnitude of each wheel load, the preprocessor distributes each wheel load to the finite element nodes that are closest to its location. Each wheel load is idealized as a single concentrated load acting at the location of the contact point of the wheel. Wheel loads are distributed to the finite element nodes using the static distribution technique illustrated in Figure 3.11. This distribution technique is used for zero, constant, and variable skew bridges. X2 Equivalet Whel N4 Nodal Load Load Node Statically Equivalent Pw Number Nodal Loads N3 P4 P1 : N1 PI Pw (1a(l) ( . N2 P2 = Pw (a)(1p) N2 Y N3 P3 Pw (1)(P) NI N4 P4 Pw (a)() a SIIl, emen t  I Slab Sb E t Static Distribution Factors Element Finite a = XI / X2 Prspetive Element 3 YI / Y2 Plan View Figure 3.11 Static Distribution of Wheel Loads Wheel loads that are off the bridge in the longitudinal direction are ignored. Wheel loads that are off the bridge in the lateral direction are converted into statically equivalent loads by assuming rigid arms connect the loads to the line of slab elements at the extreme edge of the bridge. After making this assumption, the same static distribution procedure described above is used to compute the equivalent nodal loads. This procedure of assuming a rigid arm allows the engineer to model rare cases in which the outside wheels of a vehicle are off the portion of the deck that is considered to be structurally effective. The ability of the preprocessor to perform vehicle load distribution is one of its most time saving features since very often many load cases must be explored to determine which ones are critical for design or rating. Each of these load cases consists of many wheel loads that must be converted into even more numerous equivalent nodal loads. The number of nodal loads required to represent a moderate number of load cases can quickly reach into the thousands. CHAPTER 4 DATA COMPRESSION IN FINITE ELEMENT ANALYSIS 4.1 Introduction In the analysis of highway bridges, the amount of outofcore storage that is available to hold data during the analysis can frequently constrain the size of models that can be analyzed. It is not uncommon for a bridge analysis to require hundreds of megabytes of outofcore storage for the duration of the analysis. Also, while the size of the bridge model may be physically constrained by the availability of outofcore storage, it may also be effectively constrained by the amount of execution time required to perform the analysis. The use of computer assisted modeling software such as the bridge modeling preprocessor presented in Chapters 2 and 3 further increases the demand on computing resources. Using the preprocessor, an engineer can create models that are substantially larger and more complex than anything that could have been created manually. To address the issues of the large storage requirements and lengthy execution times arising from the analysis of bridge structures, a realtime data compression strategy suitable for FEA software has been developed. This chapter will describe that data compression strategy, its implementation, and parametric studies performed to evaluate the effectiveness of the technique in the analysis of several bridge structures. It will also be shown that by utilizing data compression techniques, the quantity of outof core storage required to perform a bridge analysis can be vastly reduced. Also, in many cases the execution time required for an analysis can be dramatically reduced by using the same data compression techniques. 4.2 Background During the past three decades a primary focal point of research efforts aimed at improving the performance of FEA software has been the area of equation solving techniques. This is due to the fact that the equation solving phase of a FEA program is one of the most computationally intensive and time consuming portions of the program. As a result of research efforts in this area, equation solvers that are optimized both for speed and for minimization of required incore memory are now widely available. The performance of FEA programs implementing such equation solvers is now often constrained not by the quality of the equation solver but instead by the speed at which data may be moved back and forth between the program core to outofcore storage and by the availability of outofcore storage. Although the coding details of FEA software vary greatly from program to program, all FEA programs must perform certain common procedures. As the size of the finite element model increases, three of these common procedures begin to dominate a program in terms of the portion of total execution time that is spent in these procedures. They are solving the global set of equilibrium equations, forming element stiffness and force recovery matrices, and performing element force recovery. In many FEA programs, the element stiffness and force recovery matrices are formed incore and then written to disk sequentially as each element is formed. This procedure requires that all of the element stiffness and force recovery matrices be moved from the program core to disk. In all but the smallest of finite element models, this is necessary because there is insufficient memory to hold all of the element matrices for the duration of the analysis. Once the element matrices have been written to disk, the global equilibrium equations are formed by assembling the element stiffness and load matrices into the global stiffness and load matrices. This step requires that all of the element matrices that have been written to disk be moved from disk storage back to the program core. Finally, when the global equilibrium equations have been solved and displacements are known, the element force recovery matrices must be transferred from disk back to the program core to perform element force recovery. Under certain circumstances, such as in analyses involving multiple load casesan extremely common occurrence in bridge modelingor in nonlinear analyses where element state determination and element matrix formation must be performed many times, some or all of the steps discussed above may need to be performed more than once. Consequently, element matrices must be transferred to and from disk many times during the analysis. Due to rapidly improving computational power and relatively low cost, the personal computer (PC) has gained widespread use in the area of FEA rivaling more expensive workstations in terms of raw computational power. However, PCs are generally slower than workstations in the area of disk input/output (I/O) speed and often have far less available disk space. To address the issue of slow I/O speed on PCs, some FEA software developers write custom disk I/O routines in assembly language. This results in an FEA code that is considerably faster than that which can be achieved using only the disk I/O routines provided in standard high level languages. However, while the use of assembly language yields increased disk I/O speed, it does so at the cost of portability. This is because assembly language is intimately tied to the architecture of central processing unit (CPU) on which the software is running and is therefore not portable to machines having different CPU architectures. Furthermore, the use of assembly language I/O routines achieves nothing with respect to the problem of the large of outofcore storage demands made by FEA software. Instead of using assembly language disk I/O routines, the author has chosen a different approach in which the quantity of data written to the disk is reduced while preserving the information content of that data. This is accomplished by using a data compression technique to compress the data before writing it to disk, and decompress it when reading the data back from disk. The result is faster data transfer and vastly reduced outofcore storage requirements. 4.3 Data Compression in Finite Element Software In using compressed disk I/O in finite element software the goals are twofold to reduce the quantity of outofcore storage required during the analysis and to reduce the execution time of the analysis. Data compression is used to accomplish these goals by taking a block of data that the FEA software must transfer to or from disk storage and compressing it to a smaller size before performing the transfer. Compression preserves the information content of the data block while reducing its size, thus reducing the amount of time that must be spent performing disk I/O. Of course the process of compressing the data before writing it to disk requires an additional quantity of time. Also the data must now be decompressed into a usable form when reading it back from disk which also requires additional time. However, the end result is often that the amount of additional time required to compress and decompress the data is small in comparison to the amount of time saved by performing less disk I/O. This is especially true on PC platforms where disk I/O is known to be particularly slow. While one benefit of using compressed I/O can be a reduction in the execution time required by FEA softwarewhich is often the critical measure of performancea second benefit is that the quantity of disk space required to hold data files created by the software is substantially reduced. A typical FEA program will create both temporary data files, which exist only for the duration of the program, and data files containing analysis results which may be read by post processing software. The data compression strategy presented herein compresses only files that are binary data files, i.e. raw data files. This is opposed to formatted readable output files that the user of a FEA program might view using a text editor. Binary data files containing element matrices, the global stiffness and load matrices, or analysis results such as displacements, stresses, and forces are typically the largest files created by FEA software and are the types of files which are therefore compressed. Formatted output files can just as easily be compressed but the user of the FEA software would have to decompress them before being able to view their contents. For reasons of accuracy and minimization of roundoff error, virtually all FEA programs perform floating point arithmetic using double precision data values. In addition, much or all of the integer data in a program consists of long (4 byte) integers as opposed to short (2 byte) integers either because the range of a short integer is not sufficient or because long integers are the default in the language (as is the case in Fortran 77). An underlying consequence of using double precision floating point and long integer data types is that there is a tremendous amount of repetition in data files created by FEA software. Consider as an example the element load vector for a nine node plate bending element. A plate bending element has two rotational and one translational degrees of freedom at each node in the local coordinate system, but when rotated to the global coordinate system there are six degrees of freedom per node. Thus, for a single load case the rotated element load vector which might be saved for later assembly into the global load vector will have 9*6 = 54 entries. If the entries are double precision floating point values then each of the 54 entries in the vector is made up of 8 bytes resulting in a total of 54*8 = 432 bytes. Now consider an unloaded plate element of this type where the load vector contains all zeros. Typical floating point standards represent floating point values as a combination of a sign bit, a mantissa, and an exponent. A value of zero can be represented by a zero sign bit, zero exponent, and zero mantissa. Thus a double precision representation of the value zero may consist of eight zero bytes. A zero byte is defined as containing eight unset (zero) bits. Consequently, the load vector for an unloaded plate element will consist of 432 repeated zero bytes resulting, in a considerable amount of repetition within the data file. This type of data repetition, in which there are sequences of repeated bytes, will be referred to hereafter as small scale repetition. In addition to the small scale repetition described above, data files created by FEA software contain large scale repetitions of data as well. Consider the element stiffness of the plate element described above. When rotated to the global coordinate system, the element stiffness will be a 54 x 54 matrix of double precision values. Using the symmetric property of stiffness matrices, assume that only the upper triangle of the matrix is saved to disk for later assembly into the global stiffness matrix. Thus, a total of 54*(54+1)/2 = 1,485 double precision values, or 1,485*8 = 11,800 bytes of information must be saved to disk for a single element. Now consider a rectangular slab model of constant thickness consisting of a 10 x 10 grid of elements where there is a high degree of regularity in the finite element mesh. Assume that the rotated element stiffness for each element in the model is identical to that of all the other elements. To save the element stiffnesses for each of the elements in the model, a total of 10*10*11,800 = 1,188,000 bytes of data must be transferred from the program core to disk, and then back to the program core at assembly time when there are actually only 11,448 unique bytes of information in that data. Somewhere in between the small and large scale repetitions described above lies what will be appropriately referred to as medium scale repetition. Medium scale repetition refers to sequences of repeated byte patterns. If the length of the pattern is a single byte, then medium scale repetition degenerates to small scale repetition, whereas if the length of the pattern is the size of an entire stiffness matrix, then medium scale repetition degenerates to large scale repetition. As used herein, the term medium scale repetition will refer to patterns ranging from two bytes in length to a few hundred bytes in length. It should be noted the data compression strategy being presented herein is intended to supplement rather than replace efficient programming practices. Take as an example, the case of the repeated plate element stiffness matrices described above. A well implemented FEA code might attempt to recognize such repetition and write only a single representative stiffness matrix followed by repetition codes instead of writing each complete element stiffness. In this case the compression library will supplement the already efficient FEA coding by opaquely compressing the single representative element stiffness that must be saved. The term opaquely is used to indicate that the details of the data compression process, and the very fact that data compression is even being performed, are not visible toi.e. are opaquely hidden fromthe FEA code. Thus, the reduction of data volume is performed in a separate and self contained manner which requires no special changes to the FEA software. If however, the FEA code makes no such special provisions for detecting element based repetition, then the compression library described herein will reduce the volume of data that must be saved by compressing each element stiffness matrix as it is written. In each case, compression is accomplished primarily by recognizing small and medium scale repetition within the data being saved. In fact, due to the small size of the hash key used in the hashing portion of the compression algorithmdescribed in detail later in this chapterthe likelihood of the compression library identifying large scale repetitions such as entire stiffness matrices is very remote. Instead, the vast majority of the compression is accomplished by recognizing small and medium scale repetition, both of which are abundant in the type of data produced by FEA software. 4.4 Compressed I/O Library Overview The compressed disk I/O library being presented herein uses a buffered data compression technique that performs compression on both small and large scale repetitions like those described above. Written in the ANSI C language, the compressed I/O library was originally intended for use in FEA software written in C. From this point on ANSI C will be referred to simply as C, and the ANSI C I/O functions will be referred to as standard C I/O functions to distinguish them from the compressed I/O functions being presented. In its present form, the library can be used to manipulate sequential binary 1/O files, although it could also be adapted to manipulate direct access (as opposed to sequential), and formatted (as opposed to binary) data files. Contained in the library are compressed I/O functions that are direct replacements for the standard C I/O functions that a FEA program would normally utilize. The compressed I/O library functions have identical prototypes to their standard C counterparts. As a result, converting a FEA program written in C which utilizes sequential binary I/O over to compressed I/O requires only that the names of the standard C functions called by the program be replaced with the corresponding compressed I/O function names. Table 4.1 lists the compressed I/O functions that are provided in the library. The CioModify function has no counterpart in the standard C library because it allows the FEA code to modify certain characteristics of the 