ANALYSIS OF HIGHWAY BRIDGES USING
COMPUTER ASSISTED MODELING, NEURAL NETWORKS,
AND DATA COMPRESSION TECHNIQUES
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
Gary Raph Consolazio
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
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
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
GARY RAPH CONSOLAZIO
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
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
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
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
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-
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
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
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
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
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
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
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
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
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
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
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.
A PREPROCESSOR FOR BRIDGE MODELING
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
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
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
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
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.
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
AI AI A2 A A A A3 A A A
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
w Lateral t (X-Direction)
g Direction Longitudinal
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
(Zero Skew) Constant Skew Bridge Variable Skew Bridge
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
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
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
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
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
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,
Shear Stud Intrface
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
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
End Block I
+ End 'Block+
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
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.
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
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.
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
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.
Parapet Deck Slab
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
MODELING BRIDGE COMPONENTS
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
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
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
In Zero Energy
(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
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
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
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_
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
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
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.
'I H i st Shell)
Girder Alone Eccentricty
Slab Elements Centmid of (Plate Bending) OfGirder
(Plate Bending) Composite Aloe
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
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
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
(Frame) Girder Rigid Link So A-A
Element Centrid (Eccentricity) Set A
--- Finite Element Node
/ Flat Shell Element
Slan Ce atro And
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
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
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
L / Girder
ThickneOf / Elements
Tnicness Of sy
Slab Over Girder Lateral
Thcktness Of Bm--
Slab Over Girder Elements
Plus Effective Range 4
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
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)
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)
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
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)
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
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
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
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
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.
moidge Axle VWheel Lod
Vh ic I dnast Geometry Distribution
Axle Loads -- Wheel Loads -- Nodal 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.
Equivalet Whel N4
Nodal Load Load Node Statically Equivalent
Pw Number Nodal Loads N3
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
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.
DATA COMPRESSION IN FINITE ELEMENT ANALYSIS
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.
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
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