Analysis of highway bridges using computer assisted modeling, neural networks, and data compression techniques

MISSING IMAGE

Material Information

Title:
Analysis of highway bridges using computer assisted modeling, neural networks, and data compression techniques
Physical Description:
ix, 247 leaves : ill. ; 29 cm.
Language:
English
Creator:
Consolazio, Gary Raph, 1966-
Publication Date:

Subjects

Genre:
bibliography   ( marcgt )
non-fiction   ( marcgt )

Notes

Thesis:
Thesis (Ph. D.)--University of Florida, 1995.
Bibliography:
Includes bibliographical references (leaves 242-246).
Statement of Responsibility:
by Gary Raph Consolazio.
General Note:
Typescript.
General Note:
Vita.

Record Information

Source Institution:
University of Florida
Rights Management:
All applicable rights reserved by the source institution and holding location.
Resource Identifier:
oclc - 33662258
ocm33662258
System ID:
AA00012905:00001

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 Vu-Quoc 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 education-one 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 students-especially Wilson Moy and Prashant Andrade-for

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 Real-Time 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 Post-Tensioning .....................................41
2.5.3 Shielding of Pretensioning ........................... ...................42
2.5.4 Post-Tensioning 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 T-Beam Bridges........49
2.8 Modeling Features Specific to Flat-Slab 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 T-Beam Bridge Components.................74
3.7 Modeling Flat-Slab 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 Example-By-Example 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 two-span flat-slab 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 post-processing 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 packages-especially

the commercial ones-include or can be linked to separate pre- and post-processing

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, post-processing 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

building-type 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 building-type 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 categories-required storage and required

execution time. Required storage can be subdivided into in-core storage, also referred

to as primary or high speed storage, and out-of-core storage, also referred to variously









as secondary storage, low speed storage, and backing store. In-core 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 in-core memory. Out-of-core storage generally refers to available space

on hard disks, also called fixed disks.

Optimizing the use of available in-core storage has been an area of considerable

research during the past few decades. In contrast, little research has been performed

that addresses the large out-of-core storage requirements often imposed by FEA. Out-

of-core 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 post-processing software.

3. To perform blocked, out-of-core equation solutions in cases where the
global stiffness or global load matrices are too large to be contained in-core
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 post-processing software.

In the analysis of highway bridges, the amount of out-of-core 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 out-of-core 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 computers-computers that often have only moderate

amounts of in-core and out-of-core 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 models-models 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-

of-core storage. It is clear then that the issue of out-of-core 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 out-of-core 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 created-using preprocessing software-and 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 design-evaluation 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 out-of-

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 real-time 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 describe-in greater detail-each 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 post-processing 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-

interactively-a 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 characteristics-geometry,
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 semi-automated fashion. The term semi-automated, 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 judgment-where appropriate-into 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 post-tensioning 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 Real-Time Data Compression


To address the issue of the large storage and execution time requirements arising

from the analysis of bridge structures, a real-time 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 real-time lossless data compression

strategy has been developed, implemented, and tested in bridge FEA software.

The term real-time is used to indicate that the FEA data is not created and then

subsequently compressed as a separate step but instead is compressed in real-time 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 on-the-fly 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 real-time 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 two-span flat-slab 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 flat-slab 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 flat-slab 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 classifications-general

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 post-processing 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. CBRIDGE-and its design

counterpart CB-Design-have 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 (non-commercial) 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 user-software 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 T-beam, and
flat-slab 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 in-house 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 in-core storage in FEA software and

optimizing the numerical efficiency of matrix equation solvers. However, relatively

little attention has been focused on the optimization of out-of-core storage

requirements. It is true that researchers have developed various special purpose

bookkeeping strategies that can moderately reduce out-of-core 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 real-time 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 material-level 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 post-processor.

4. SIMPLOT. A graphical post-processor 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 characteristics-geometry,
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 semi-automated 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 asked-depending on the type of bridge being modeled-to specify the amount

of deck steel effective in negative moment regions-i.e. a parameter that is only

applicable to bridges having more than one span.

Both girder-slab bridges and flat-slab bridges may be modeled using the

preprocessor. Girder-slab 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 girder-slab 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. Flat-slab 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 T-beam. 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 flat-slab. 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 vehicles-for

example the HS20-are 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 custom-i.e. nonstandard-vehicles 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 bulb-T types I, II, III, and IV

3. Standard parapets-old 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


Girder-slab 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. Flat-slab 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

flat-slab bridges, these bridges may have edge elements such as parapets or railings just

as girder-slab 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 Girder-slab 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 re-entered 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 re-entered 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

permanent-and commented-record 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 reusable-and editable-history 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 T-beam, and flab slab










bridges. The features and concepts discussed below are common to many-or all-of

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 z-directions respectively in the global coordinate system of the finite

element model.


Transverse
Direction
(Z-Direction)


\Lateral
SDirection
w Lateral t (X-Direction)
g Direction Longitudinal
Direction
(Y-Direction)


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 geometry-constant 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 preprocessor-live load models and full load models. Live load models

are used primarily to compute lateral load distribution factors (LLDFs) for girder-slab

bridges (see Hays et al. 1994 for more information regarding LLDFs). A live load

model represents only the final structural configuration of a bridge-that 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 point-each 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 models-i.e. the stages that contain dead loads-in 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 post-processor. The analysis results are also factored-

according to the type of loading that produced them-before 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 short-term 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 structures-individual 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, direction-forward 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 shifted-by the preprocessor-in 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 loading-represents 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 feet-the 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 girder-slab 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

T-beam bridges can also be classified as prismatic girder-slab 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 post-tensioning tendons.

Another class of nonprismatic girder occurs when the depth of a girder is varied-

usually linearly-along 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 T-beam. Constant skew reinforced concrete T-beam
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,














Girder-Slab
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 bulb-T 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 Post-Tensioning


Prestressed concrete girder bridges modeled by the preprocessor may be either

of the pretensioned type or pre- and post-tensioned type. Pretensioning occurs during

the process of casting the concrete girders whereas post-tensioning occurs after the

girders have been installed in a bridge. The preprocessor can model bridges having

either one or two phases of post-tensioning, however, there are specific-and 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, phase-1 post-tensioning,

or phase-2 post-tensioning, 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 counter-moment

is induced. An alternative is to use a straight pretensioning profile with selected

pretensioning strands being shielded near the ends of the girder.

Shielding-also known as debonding-is 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 Post-Tensioning Termination


In certain situations, it can be advantageous to terminate post-tensioning 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 post-tensioning tendons in prestressed

concrete girder bridges provided that the user has specified the termination points.

Recall that all post-tensioning 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 post-tensioning for a particular phase must be

terminated at a common location. If multiple tendons are used for a particular phase of

post-tensioning 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 post-tensioning tendons.

The preprocessor models girders containing end blocks as special-case

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 X-brace configuration or a K-brace



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 X-brace and K-brace diaphragms were sufficiently

close that K-brace diaphragms can adequately be modeled using the X-brace

configuration. Thus, only the X-brace 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 X-Brace Diaphragm K-Brace 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 non-recoverable 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 not-more 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 loads-such as the weight of a railing or a
nonstructural parapet, and deck overlay loads.









essentially softens the composite girder-slab 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 T-Beam Bridges


Reinforced concrete T-beam 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 T-beam girder is

completely defined by the depth and width of the girder web. A T-beam girder consists

of a rectangular concrete web joined to the deck slab-a 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 T-beam 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
T-Beam Web


Web Width


Figure 2.10 Cross Section of a Typical Reinforced Concrete T-Beam Bridge









2.8 Modeling Features Specific to Flat-Slab Bridges


Flat-slab 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 flat-slab 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 flat-slab bridges are also unique among the bridge types

modeled by the preprocessor. Flat-slab bridges are supported continuously across the

bridge in the lateral direction at each support location. This is in contrast to girder-slab

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 Flat-slab 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, stiffeners-such 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 Reissner-Mindlin 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 flat-slab 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 flat-slab 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 t-diretion 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 flat-slab 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 (nine-node) shape functions for all

element rotational degrees of freedom (DOFs) but serendipity (eight-node) 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 flat-slab 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 T-beam 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 struts-that 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 X-brace and K-brace

diaphragms using the X-brace 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 girder-slab 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.

Flat-slab bridges are supported continuously in the lateral direction at each

support in the bridge. Since bearing pads are not typically used in flat-slab 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 slab-girder 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 girder-slab 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 girder-slab interaction as

either noncomposite, or as composite using one of two composite modeling techniques.

The girder-slab 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 component-the slab and the girder-may 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 elements-elements 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 flexible-not infinitely rigid-girder 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 girder-slab 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 A-A
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 links-i.e. the eccentricities of the girder elements-also

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 post-tensioned in

either one or two phases when using the preprocessor. Post-tensioned continuous

concrete girder bridges are modeled assuming that the girders are pretensioned, placed

on their supports and then post-tensioned 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

bare-i.e. noncomposite-girder 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 post-processor

based on the appropriate AASHTO specifications). Thus, the tendon forces specified by

the engineer must be the initial pretensioning or post-tensioning 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 T-beam)

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 Woinowksy-Krieger 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 y-directions 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 (x-direction) is of interest for the lateral beam

members, only the x-curvature 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 uncoupled-i.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 T-Beam Bridge Components


Reinforced concrete (R/C) T-beam 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 T-beam bridges lack the prestressing

(pretensioning and possibly post-tensioning) tendons that are present in prestressed

concrete girder bridges. However, the girders in each of these bridge types are

constructed from the same material-concrete-and 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 T-beam bridges. In R/C T-beam bridges, this stiffening effect is









represented using the same lateral beam elements that were discussed earlier for

prestressed concrete girders.


3.7 Modeling Flat-Slab Bridge Components


A flat-slab 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 girder-slab 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 large-possibly

multiple span-plate structure. When stiffeners are present on the bridge but do not act

compositely with the slab-and are therefore not considered structurally effective-they

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 flat-slabs 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 stiffeners-which are above the slab-to 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 model-a 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 T-beam and flat-slab 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 post-tensioning, two phases of post-tensioning, 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, and-in most cases-the 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 post-tensioning, 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 girder-slab 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 order-girders, pretensioning,

diaphragms, deck slab, lateral beam elements, phase-1 post-tensioning (if present),









stiffeners, and phase-2 post-tensioning (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 cracking-the extent of which is specified

by the engineer-is 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 two-tenths 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 T-beam and flat-slab 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 T-beam 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 loads-including additional long term dead loads-are

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 (1-a(l) ( .
N2 P2 = Pw (a)(1-p) 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 out-of-core 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 out-of-core storage for the duration of the analysis. Also, while the size

of the bridge model may be physically constrained by the availability of out-of-core

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 real-time 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 out-of-

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 in-core 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 out-of-core storage and

by the availability of out-of-core 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 in-core 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 cases-an extremely common

occurrence in bridge modeling-or 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 out-of-core 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 out-of-core 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 out-of-core 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 software-which is often the critical measure of performance-a

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 to-i.e. are opaquely hidden from-the 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 algorithm-described in

detail later in this chapter-the 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