Ontario Modular Bridge Analysis System'

R. A. DORTON,B. S. RICHARDSON,
AND A. FAM
Structural Oflce, Ministry of Transportation and Communications, 3501 Dufferin Sticet, Downsview, Ont., Canada M3K 1N6
Received November 30, 1983
Revised manuscript accepted June 18, 1984

A software system, the Ontario Modular Bridge Analysis System, being developed by the Province of Ontario for the design
Can. J. Civ. Eng. Downloaded from www.nrcresearchpress.com by University of Queensland on 11/11/14

and analysis of highway structures is described. The new Ontario Highway Bridge Design Code, an entirely limit states code,
created the need for a new or drastically revised system. An outline is given of the advisability study that led to the design
of an entirely modularized, data base supported system, providing the low processing costs and user convenience of single-
purpose programs together with sophisticated analytical methods for nonroutine problems.
The system comprises an applications subsystem and a utilities subsystem. The applications subsystem consists of 1 1
macro-modules, each performing a distinct task and capable of being replaced or modified without necessitating changes
elsewhere in the system. The macro-modules are Input, Control, Geometry, Idealization, Load, Solution, Live Load,
Combination, Resistance, Design and Detailing, and Output.
The utilities subsystem consists of modules providing services to construct or facilitate the use of the applications subsystem.
These include a problem-oriented language analyzer, memory and data base manager, output utilities, and mathematical
utilities.
The description of the system is general with more details given concerning important or original features such as methods
of analysis and the specifications analyzer, which places all design code requirements in a single, readily changeable module.
Key words: analysis, bridges, codes, computers, data base, design, modular systems, software, structures.

L'article decrit un logiciel pour I'analyse et le calcul de structures d'auto-routes mis au point par la province d'ontario. L a
For personal use only.

nouvelle norme ontarienne sur le calcul des ponts-routes, ne considerant que le calcul aux Ctats limites, necessite un nouveau
systtme complktement revise. L'article donne un aperGu de I'Ctude qui conduisit a une analyse constitute uniquement d e
modules reclamant un faible coct d'execution et permettant a l'usager I'utilisation de programmes resolvant des problkmes
spkcifiques mais aussi de programmes utilisant des mCthodes analytiques complexes afin de rtsoudre des problkmes speciaux.
Le systkme comprend un sous-systkme d'applications et un sous-systkme de services. Le sous-systkme d'applications
consiste en I I macro-modules executant une tdche differente et permettant leur remplacement ou leur modification en ne
ntcessitant pas de changement dans le reste du systtme. Les macro-modules sont: Entree, Contr6le, Geometric, Idealisation,
Charge, Rtsolution, Surcharge, Combinaison, Rtsistance, Calcul et Sortie.
Le sous-systkme de services contient des modules facilitant I'utilisation du sous-systkme d'applications. I1 comprend un
analyseur de probltmes relies au langage, un systkme de gestion de la memoire et des donntes, des facilitis de sorties et des
facilitks mathematiques.
L'article donne une description gCnCrale du systkme avec plus de details au sujet de possibilites importantes et originales
telles que les methodes d'analyse et I'analyseur de normes qui placent toutes les exigences du code dans un m&memodule avec
la possibilitk d'une mise a jour.
Mots clis: analyses, ponts, normes, ordinateur, banque de donntes, calcul, systkme modulaire, logiciel, structures.
[Traduit par la revue]

Can. J . Civ. Enp. 11. 751-759 (19x4)

Introduction the following concerns: (a) the need for a SI metric

In the past, highway structures in Ontario, including
bridges, culverts, tunnels, retaining walls, and lumi-
naire and sign support structures, have generally
been designed in accordance with American Asso-
ciation of State Highway and Transportation Officials
(AASHTO) specifications.
In 1976 the Ministry of Transportation and Commu-
nications undertook the preparation of the Ontario
Highway Bridge Design Code (OHBDC) in response to
'This paper was presented at the 1983 Annual Conference
of the Canadian Society for Civil Engineering, Ottawa,
Ontario, June 1-3.
code; (b) recent research findings were slow to be im-
plemented; (c) legal vehicle weights in Ontario were
nearly twice the AASHTO vehicle live load; and (d) a
probability-based limit states design (LSD) code would
give more consistent safety levels than the AASHTO
specifications.
Since 1979, the first edition of the OHBDC has been
used for bridges under the Ministry's jurisdiction. A
second edition was recently published and is expected
to become mandatory for the design of all bridges in
Ontario early in 1985.
The LSD code requires the designer to investigate the
ultimate limit state and one or more serviceability limit
 752 CAN. J. CIV. ENG. VOL. 11. 1984
states. A new live load model has three levels for the
various limit states, and a new approach to dynamic
loading. The code requires a more sophisticated load
distribution technique and more rigorous methods of
analysis for certain structures. The overall effect is an
increase in the amount and complexity of design and a
greater dependence on computer methods for efficient
operation.
Can. J. Civ. Eng. Downloaded from www.nrcresearchpress.com by University of Queensland on 11/11/14
The Ministry has a fairly large computer program
library consisting of separate, self-contained programs.
Of these, about 15 perform structural analysis or design
functions and are design code dependent. Each program
is intended to analyse a particular type of structure.
With the exception of a few that were acquired from
other authorities, the programs were written within the
Ministry, one at a time, over a period of about 15 years.
Within the library, subprograms performing the same
function are different, often dating from quite different
periods. Programming staff, methods, and standards
changed extensively during that period. Nearly all pro-
grams have been extensively modified from their origi-
nal form. Most changes were hurried attempts to correct
errors, add new features, or adapt to changing design
codes. The entire library was more recently converted
For personal use only.
to SI units as part of the Ontario metrication program.
This conversion was fairly well organized and some
program "cleanup" was undertaken as part of the work.
Most programs were made available in the interactive
mode within the past few years, although all were orig-
inally written for fixed format, batch input. User manu-
als are available for nearly all programs but pro-
gramming documentation is generally deficient, and
coding is not systematically structured.
Since the provisions of the OHBDC differ greatly
from those of the AASHTO specifications, the existing
program library is no longer suitable and the programs
have to be substantially modified or a completely new
system has to be developed. It is considered that full
adoption of the OHBDC hinges upon the availability of
suitable software.
Software systems within the Ministry now have to be
developed following a project management scheme that
imposes fairly rigorous requirements for investigation,
justification, task assignment, estimating, and periodic
review. Within this scheme, the first phase is concerned
with establishing user requirements, systems definition,
the identification of alternatives, and the selection and
justification of the preferred alternative. The phase
terminates with an advisability study report. The second
phase, which includes all programming, begins with
preliminary design and ends with program testing. A
third phase is concerned with installation, user training,
and project wrap-up.
The advisability study investigated alternatives rang-
ing from a minimal patch-up of existing programs to the
development of an entirely new system. The estimates,
including only direct salary and computer costs, ranged
from $390 000 to $730 000 in 1980 dollar value, but the
new proposal, although the most expensive, has a much
more attractive costlbenefit ratio. The details of the
proposal are given below.
Description of the overall system
The Ontario Modular Bridge Analysis System
(OMBAS) consists of a number of macro-modules, a
data base, and some utilities. Each macro-module will
perform a separate and unique function that is recog-
nizable to the user and constitutes a normal step in the
solution of an engineering problem. Each macro-
module in turn reads its input from the data base, pro-
cesses the data in compliance with instructions encoded
with the data or supplied by a control macro-module,
and stores the results in the data base.
It is important to note that there is no direct data flow
between the macro-modules, other than with the control
macro-module. All data must pass through the data
base, which then acts as a universal interface in addition
to providing a large, well-organised, and protected data
storage facility. It follows that development, testing,
and subsequently maintenance of each macro-module
can proceed almost independently. Any software pack-
age that can perform the desired processing functions
and is provided with interfaces compatible with the data
base, could be made to serve as a macro-module.
Modularization is carried throughout the system.
Each macro-module is made up of submodules, which
communicate with each other through a control sub-
module. During execution of any macro-module, con-
trol normally resides within that macro-module. The
control macro-module is invoked infrequently, and in
most cases will predetermine the processing sequence at
the commencement of a problem run, passing the direc-
tions through the data base in the form of codes.
The system as described thus far can be represented
in conceptual form as shown in Fig. 1. It is convenient
to regard the system components shown as the applica-
tions subsystem. The complexity, size, and difficulties
in programming and maintaining this subsystem can be
substantially reduced by means of a number of utilities.
They are also modular and some may be identified
as macro-modules but they are regarded as part of a
utilities subsystem. Figure 2 shows diagrammatically
the interaction of various components of the two sub-
systems and the user and programmer interfaces.
A. Applications subsystem
The following is a brief functional description of
each macro-module in the applications subsystem.
Control macro-module
The control macro-module ensures the proper exe-
 DORTON ET AL.
Can. J. Civ. Eng. Downloaded from www.nrcresearchpress.com by University of Queensland on 11/11/14
FIG. 1. Conceptual representation of system structure.
cution of the whole system during the problem-solving
process and would enable the system to be restarted
using problem data stored from a previous solution
step. The control macro-module directs and monitors
For personal use only.
the transfer of control between macro-modules.
Predefined legal execution sequence is generated by
default or in accordance with the needs of other macro-
modules and is stored in tabular, decision logic table
form. The control macro-module analyses these tables,
determines the action required, allocates the necessary
resources, and sets up the operating environment before
passing control to another macro-module.
In addition to the above, the control macro-module
maintains a log file containing a complete history to all
jobs related to one project and performs certain statis-
tical functions in monitoring usage.
Input macro-module
The input macro-module reads and checks user's
input for syntax and logical errors. The data can be
entered in either batch or TSO (time shaving option)
mode using a free-format, user-oriented language. A
utility is provided to code and decode the processing
logic of input data in order to ensure its conformity with
the rules of the language and with the user's instruction
manual.
The input macro-module processes the data in
blocks. Each block corresponds to a module in the
system performing a function recognizable to the user.
The user has the option of changing defaults, including
input units, using simple commands. A HELP com-
mand instructs the system to provide guidance in the
form of texts, messages, etc. to assist the user in con-
structing input data.
The input macro-module is divided into five groups
753
of submodules:
(i) General data submodules-These submodules
perform functions that are not explicitly related to
engineering problems, but rather to operational
procedure.
(ii) Base data input submodules-These submodules
accept data that describe the basic components of a
structural problem, such as nodes, elements, material
properties, combination tables, etc. The base data is a
library of information related to the structure, to be
referenced in describing the structural model. This is
done using the input data in groups (iii) and (iv).
(iii) Application data submodules-These sub-
modules accept data for general engineering application
that would be applicable to all types of structures.
(iv) Standard structure input submodules-These
submodules accept data for the analysis of common
types of structures, identified as standard structures
(e.g. rigid frames, culverts, CPCI-type girder bridges,
etc.).
(v) Utilities input submodules-These submodules
accept data required to execute selected utilities sub-
system modules that can be used to solve problems that
do not involve the applications subsystem (e.g. solution
of equations, curve fitting, etc.).
Geometry macro-module
The geometry macro-module performs all geometric
calculations related to bridge geometry (e.g. vertical
and horizontal alignment). Geometric functions such as
cross-section properties, quantity calculations, curve
fitting, intersection of lines, etc., which are used by
other macro-modules in random fashion, form part of
the engineering application utility modules.
Idealization macro-module
The idealization macro-module uses the simplified
input for a standard structure and generates a detailed
mathematical model of the structure, which, when ap-
plicable, shares the same structure of the data base used
by the more general input application data submodules.
In this regard, it can be compared with a preprocessor
used to facilitate the use of a general system (such as
STRUDL) to solve specific engineering problems.
The standard structures included in the scope of
OMBAS are assembled from components shown in
Figs. 3a-3e. Each component is an assembly of ele-
ments selected from a library of one-, two-, and three-
dimensional finite elements.
Load macro-module
This macro-module generates the global load vectors
due to (i) general load patterns on elements, e.g. uni-
form loads, line loads, point loads, etc.; (ii) predefined
strains, e.g. temperature effects and displacements; (iii)
support releases; (iv) prestressing cables; (v) moving
load patterns, to generate influence lines or surfaces;
 CAN. 1. CIV. ENG. VOL. l I . 1984

MEMORY

POLO DATA BASE

MANAGEMENT SYSTEM
Can. J. Civ. Eng. Downloaded from www.nrcresearchpress.com by University of Queensland on 11/11/14

- L 1

DLT
5RC
) FILE
BUILDER
. * SPEC
FlLE

-
For personal use only.

FIG. 2. A general system flowchart showing all macro-modules (one load module)

LONGITUDINAL GIRDERS (STEEL) SLABS

wSTEEL I BEAMS MULTISEPARATED
STEEL BOX GIRDERS

SOLID VOIDED

LONGITUDINAL GIRDERS (CONCRETE) CROSS GIRDERS

STEEL CONCRETE

~ l o ] i o ] i o ~
4
fi E r n z l m
STEEL CROSS GIRDERS REINFORCED CONCRETE
,u, ,-, ,Lm, A CROSS GIRDERS

MULTlSEPARATED CONCRETE I BEAMS TRUSS

C O N C R m BOX BEAMS \

L
\ CI r- fA
,JL:
STEEL DECK TRUSS

MULTICEU CONCRETE BOX GIRDER

FIG. 30. Longitudinal girders (steel and concrete).
and (vi) change in material properties with time, for
shrinkage, creep, relaxation, etc.
Solution macro-module
The solution macro-module uses the stiffness method
F I G . 3b. Slabs and cross girders.
of analysis to calculate the response of the idealized
structure to the applied loadings taking into account
changes in stiffness, loading, and boundary conditions
for every stage of construction. A time interval is as-
sumed for every stage to account for time-dependent
effects and two analyses are performed, at the start and
at the enct of each interval.
 DORTON ET AL. 755

PIERS
Can. J. Civ. Eng. Downloaded from www.nrcresearchpress.com by University of Queensland on 11/11/14

MULTICOLUMN PIERS PILES WITH CAPPING BEAM

- ARTICULATED HAMMER-HEADED
SOLID WALL PIER
FRAME SHAFT
FIG.3c. Piers

RETAINING WALLS
SIGN SUPPORT STRUCTURES
For personal use only.

CANTILEVER SECTION TRUSS-TYPE SUPPORT STRUCTURE

COUNTERFORT WALL

ABUTMENTS

MONO-TUBE SUPPORT STRUCTURE

CULVERTS

U ABUTMENTS
CCOUNTERFORT OPTIONAL)
PILE-BENT ABUTMENT
m
CLOSED CONCRETE OPEN CONCRETE
FOUNDATIONS CULVERT CULVERT

PILE FOUMDATION SPREAD FOOTHG F O U W D A ~ CONCRETE BARREL ARCH CULVERT

FIG. 3d. Retaining walls, abutments, and foundations. FIG. 3e. Sign support structures and culverts.
 CAN. J. CIV. ENG. VOL. I I . 1983
Can. J. Civ. Eng. Downloaded from www.nrcresearchpress.com by University of Queensland on 11/11/14
SRCIF-
-LCATION 4
I I
SPECIFICATION ANALYZER
FIG. 4. Specification filc builder and analyzer interface flowchart.
For personal use only.
The solution macro-module also includes sub-
modules to calculate free vibration frequencies and to
set up the influence lines or surfaces required by the live
load macro-module. It will also include special anal-
ytical methods for the analysis of shallow and deep
foundation structures.
Live load macro-module
This macro-module uses influence lines or influence
surfaces, as required, for responses at given locations,
to compute extreme responses due to live loading,
taking into account the dynamic load allowance, lane,
truck, and sidewalk loading, distribution of loads, and
variations in loading criteria for each limit state.
Combination macro-module
This macro-module uses the individual load re-
sponses to calculate the combined factored responses
for the serviceability and ultimate limit states specified
in OHBDC. It also identifies critical design responses
for checking strength requirements to be used sub-
sequently by the resistance and (or) detailing macro-
module. This latter capability is available for structures
and components for which behaviour under various
load patterns can be predicted by the system.
Resistance macro-module
The resistance macro-module checks the strength of
all common types of cross sections or members in ac-
cordance with OHBDC criteria. The macro-module
will make design adjustments to sections and members
having moderate discrepancies between actual and re-
quired resistance.
FlLE BULDER
FILE
INTERFPCE
A
FlLE
w
FlLE
ORGANIZE STATUS
I I
SPECIFICATION FILE BUILDER
Detailing macro-module
The detailing macro-module generates partial or
complete detailing in compliance with the OHBDC and
current Ministry practice for a limited range of standard
structures. Examples of such detailing data are (i) rein-
forcing bar sizes, spacing, laps, cutoffs, and bar sched-
ules for standard reinforced concrete culverts, rigid
frames, and retaining walls; (ii) alternatives for the dis-
tribution of main and distribution steel, spirals, stirrups
in spread footings, colunlns, beams, and slabs; and (iii)
flange and web splice details (cover plates, number of
bolts, etc.) and stiffener and shear connector sizes and
spacings.
Oittput macro-moc/ule
The output macro-module operates on the data cre-
ated by various application macro-modules according
to user input or program logic. These data, stored in the
data base, are then manipulated using the output com-
mands to view or to obtain a selective printout of the
results.
Commands allow the user to do some postprocessing
on output before it is printed (e.g. shift rows and
columns, search for maximums and minimums, pro-
duce envelope for selected columns, etc.).
At the end of all output requests, the output
macro-module produces a summary index of all reports
generated.
B . Utilities subsystem
The utilities subsystem consists of modular units,
which are used to facilitate, improve, and ensure con-
 DORTON ET A L .
sistency in system development, operation. and mainte-
nance. They are of primary interest to the programmer.
However, some utilities can be accessed by users to
solve individual problems arising during the design
process.
Table builder and syntactic latlg~rageatzalyzer
This utility provides a tool with which programmers
code and decode the processing logic of input data
Can. J. Civ. Eng. Downloaded from www.nrcresearchpress.com by University of Queensland on 11/11/14
written in accordance with the rules of a standardized
problem-oriented language (POL) and in accordance
with the user's instruction manual. This process is
achieved by two modules in a package called GAME,
which was obtained from Europe Etude, a company
based in France.
(i) Table builder-This module processes input logic
coded.in a "graph" language written in POL. The coded
logic is stored in tabular form on an INPUT LOGIC
FILE. FORTRAN source code is then generated and
later included in the source deck of theinput macro-
module.
(ii) Syntactic latlgitage analyzer ( S L A t T h i s module
reads the user's input, written in POL, checks the syn-
tax of the language, and compares the input labels and
sequence against the coded logic tables produced by the
For personal use only.
TABLE BUILDER. If the data is acceptable, the SLA
returns control to the calling INPUT submodule, giving
an action code "GoTo number". and makes the data
being read available; otherwise an error message is pro-
duced and an error recovery is initiated.
Formatter and editor
This utility allows programmers to share a library
of standard write formats, which can be edited with-
out the need to recompile the source program. The
FORMATTER, executed externally to OMBAS, pro-
duces a FORMAT file containing formats for writing
error messages, help texts, etc. The EDITOR consists
of a group of submodules, which when invoked by any
OMBAS submodule retrieves a format from the file and
output data accordingly. In addition, it provides other
output facilities, such as page control and output index
summary.
Specification file builder and analyzer
This utility facilitates the isolation of design code
dependent logic and coding. The utility requires a sys-
tematic approach to the implementation of code pro-
visions, reduces the possibility of errors in the inter-
pretation, and facilitates making changes to the system
required as a result of design code revisions.
Figure 4 shows schematically how the specification
utilities are integrated into OMBAS. First, the pro-
grammer identifies criteria that are design code de-
pendent (e.g. minimum or maximum reinforcement,
load combinations, and factors). For each criterion,
using decision tables, all pertinent combinations of
757
conditions are identified together with the corres-
ponding course of action or sequence of computations.
These computations are translated using the SPECI-
FICATION FILE BUILDER by a series of macro-
instructions stored on a SPECIFICATION FILE. A
macro-instruction is a record containing codes and
numbers defining the operation to be performed and the
location in memory of all input and output variables
related to this operation. Each macro-instruction im-
plies the use of one or more elementary FORTRAN
modules where functional definitions are constructed
from detailed analysis of various clauses of the design
code.
Note that, in the above, any changes to a clause in the
specification will imply, in most cases, only a change
in the instructions on the specifications file.
The SPECIFICATION ANALYZER is called upon
by an application submodule with specific instructions
to check criteria "n," say, given its basic data. The
SPECIFICATION ANALYZER checks the validity of
the input data and checks all conditions, using in-
structions stored in the code file. As a record is read, the
subroutine named in the record is called and given a list
of arguments extracted from input or from parameters
defined in preceding operations.
In summary, the SPECIFICATION FILE BUILDER
is responsible for creating, updating, or deleting records
on the SPECIFICATION FILE, whereas the SPECIFI-
CATION ANALYZER is responsible for locating the
criterion record group and subsequently processing the
instructions implied by these records.
POLO dutcr buse mcit~clgetnetit.yvstetn (DBMS)
POLO is the name of a software package developed
at the University of Illinois under the direction of
Dr. L. A. Lopez. The POLO DBMS constitutes a set of
specialized modules designed to allow the programmer
to construct complex hierarchical data structures that
would appear to be in memory even though the total
data space is many times the size of available primary
memory.
The data structure is defined separately from OMBAS
application FORTRAN modules in what is called a
FILE DEFINITION. The file definition, described in a
language called "F," is translated by the POLO SCAN-
NER and then compiled by a POLO subsystem called
FILES. The communication link between POLO- and
OMBAS-dependent FORTRAN modules is provided
by interface subroutines written in POLO host language
"G" and compiled using the POLO GENERATOR
SUBSYSTEM. At execution time, references to data
are mapped onto both memory and data base by the
POLO DATA BASE MANAGER. The data is then
located in the memory and available as arguments to the
application FORTRAN submodules.
 CAN. 1. CIV. ENG. VOL. 11. 1984

1000 k N
Can. J. Civ. Eng. Downloaded from www.nrcresearchpress.com by University of Queensland on 11/11/14

; I N I T I A T E THE OMBAS SYSTEM, IDENTIFY PROJECT AND USER;

0110AS
PROBLEM ' TRUSS '
PROJECT 1 2 3 8 4 0 4 USER 1
9
DEFINE BASE DATA;
BASE DATA
GEOtl
tIODE 1 THRU 7
For personal use only.

COOR X1 5 . 0 15.0 25.0 0.0 20.0 30.0

X3 3 n l - 8 . 8 8 0 3 1 RETURN
9
DEFINE MATERIAL PROPERTIES # l ;

. MATERIAL 1 STEEL GRADE 3 5 0

DEFINE CROSS SECTION OF TRUSS MEMBER;

RETURN

SECTION 1 STAGE 1
GENERAL STIFFNESS EAXl 1000000. RETURN

DEFINE ELEMENT TYPE, IAND J NODES, AND CORRESPONDING SECTIONS;

ELEllENT 1 THRU 11
TRUSS PT NODE1 4 1 5 2 3 7 1 3 5 5 7
NODEJ1 5 2 6 6 3 2 2 4 6 6
SECT l l s l RETURN
9
ASSEMBLE STRUCTURE I N STAGE 1;
GENERAL STRUCTURE STAGE 1 ASSEMBLE RETURN
9
DEFINE SUPPORT CONDITION;
RESTRAIN SUPPORT 4 DISP X1 X3
SUPPORT 7 DISP X3 RETURN
i
DEFINE LOAD KIND, MAGNITUDE, DIRECTION, AND LOCATION OF LOAD SET 81;
LOAD 1 KIND D l
FORCE X3 CONC 1 0 0 0 . 1000. ;DEFINE MAGNITUDE:
NODE 2 6 ;DEFINE LOADED LINE;
AT JOINTS ;DEFINE LOCATION ;
FORCE X 1 CONC 500.
NODE 2 3
AT JOINTS 3 RETURN
D
COMPUTE RESPONSES;
COMPUTE STATIC DEFLECTIONS
REACTIOtlS
LOCAL FORCES X1
; DEFINE OUTPUT REPORT;
OUTPUT REPORT GR 1 RETURN
STOP

FIG. 5 . Input example.

 DORTON ET AL.
Engineering ~~pplic(~tioiz utilities
These include common functions utilized by any of
the macro-modules in the Applications subsystem.
They will also include those modules in the system that
could be accessed by the user to perform small indi-
vidual functions required to make design decisions, to
evaluate assumptions, or collect information related to
preparation of input data.
Can. J. Civ. Eng. Downloaded from www.nrcresearchpress.com by University of Queensland on 11/11/14
Examples of engineering application utilities are
GEOMETRIC UTILITIES, IDEALIZATION UTIL-
ITIES, and MATHEMATICAL UTILITIES. The num-
ber of utilities is expected to increase as the system is
developed. During system design, more functions
will be identified that can be best provided as callable
utilities rather than being built into application
macro-modules.
Example
Figure 5 shows the input that would be required for
For personal use only.
759
the simple truss shown. The purpose o f each block of
input is stated in a comment that precedes the block.
The comments. preceded and followed by semicolons,
do not form part of the input.
Project status
The preliminary design subphase was con~pletedin
September 1981, giving an estimated cost very close to
the earlier estimate, although based o n a much more
detailed study. The project is expected t o be con~pleted
in 1987. A workable version of the system, identified as
stage I , which will equal or exceed the capability of the
preexisting program library but will c o n ~ p l yentirely
with the OHBDC and use state-of-the-art technology,
will be available in 1984.
Work is currently proceeding in the detailed design,
programming, and assembly subphases, with many
subsystems already coded and under test.