Programmer's Manual for the Fire

Safety Evaluation System Cost

Minimizer Computer Program

U.S. DEPARTMENT OF COMMERCE

National Bureau of Standards

National Engineering Laboratory

Center for Applied Mathematics

Washington, DC 20234

July 1 983

Sponsored by:

U.S. DEPARTMENT OF COMMERCE

National Bureau of Standards

National Engineering Laboratory

Center for Fire Research

shington, DC 20234

QC

100

.1156

NO. 83-2749

1983

partment of Health and Human Services

shington, DC 20201

NBSIR 83-2749

tf <# PROGRAMMER'S MANUAL FOR THE FIRE

SAFETY EVALUATION SYSTEM COST

MINIMIZER COMPUTER PROGRAM

NATIONAL BUREAU OF STANDARDS

LIBRARY AUG 19 1983

yxcrV eoc-C. -’’?*** • 5O

|OiT3

Robert E. Chapman and William G Hall

U S. DEPARTMENT OF COMMERCE

National Bureau of Standards

National Engineering Laboratory

Center for Applied Mathematics

Washington, DC 20234

July 1 983

Sponsored by:

U.S. DEPARTMENT OF COMMERCE

National Bureau of Standards

National Engineering Laboratory

Center for Fire Research

Washington, DC 20234

and

Department of Health and Human Services

Washington, DC 20201

U.S. DEPARTMENT OF COMMERCE, Malcolm Baldrige, Secretary

NATIONAL BUREAU OF STANDARDS, Ernest Ambler, Director

PREFACE

This research was conducted under the sponsorship of the Center for Fire

Research and the Department of Health and Human Services by the Operations

Research Division, Center for Applied Mathematics, National Engineering

Laboratory, National Bureau of Standards.

This report is a product of the Fire and Life Safety Program. This program is

a joint Department of Health and Human Services (HHS) and National Bureau of

Standards (NBS) effort directed at the development of rational, technically

sound solutions to fire safety problems in health care facilities. In

addition to the types of work described in this report, the joint HHS/NBS

program has produced products in the areas of decision analysis, fire and

smoke detection, smoke movement and control, automatic extinguishment, and

behavior of institutional and other populations in fire situations.

This study serves as a Programmer's Manual for applying and interpreting the

results of the Fire Safety Evaluation System Cost Minimizer (FSESCM) computer

program. The mathematical optimization techniques which are the core concept

of the FSESCM are used to identify the least-cost means of upgrading health

care facilities to compliance with the Life Safety Code. The program uses the

"optimal’* solution as a reference point from which 10 to 20 compliance

strategies based on design considerations are generated. The computer program

is intended to be used as a management tool to facilitate the design selection

process by providing both information on relative costs and a chance to match

common compliance strategies across . fire zones.

iii
ABSTRACT

The Fire Safety Evaluation System Cost Minimizer (FSESCM) computer program

integrates engineering and economic considerations with a linear programming

algorithm which permits the least-cost means of upgrading health care facilities to compliance with the Life Safety Code to be identified. A

mathematical discussion of the application problem is used to introduce the

basic philosophy behind the computer program. Each routine is described with

emphasis on such topics as: (1) purpose; (2) calling sequence; (3) common

blocks used; and (4) reports produced. A series of descriptive tables and a glossary are used to define all reports and variables. A discussion of test

results and provisions for updating or modifying the source code are also

given. The program is written in FORTRAN and complies with the ANSI X3. 9-1978

software standard.

Keywords: Building codes; building economics; economic analysis; fire safety;

health care facilities; hospitals; life safety; mathematical programming;

nursing homes; renovation.

iv
Table of Contents

Page

Preface lil

Abstract iv

List of Exhibits vi

List of Figures vi

List of Tables vi

1. Introduction 1 1.1 Background 1 1 .2 Purpose 1 1.3 Scope and Approach 2

2. Functional Description of FSESCM 4

2.1 Problem Structure 4

2.2 Data Structures 16

3. Operational Characteristics 24

3.1 Model Outputs..... 24

3.2 Model Test- Results 43

4. Software Exchange 49

4.1 Transfer Medium and Contents of Files Provided 49

4.2 Provisions for Updating or Modifying the Source Code 50

Appendix A Program Documentation 55

A.l Relationship to the Federal Information Processing

Standards 55

A. 2 Variable Definition 56

A. 3 Descriptions of the Subroutines 66

References 91

v
List of Exhibits

Page

2.1 Worksheets for Calculating the General Safety Requirement 9

2.2 Worksheet for Determining the Values of Each Building Safety

Feature/State Pair 10

2.3 Worksheet for Calculating Containment Safety, Extinguishment

Safety, People Movement Safety and General Safety 11

2.4 Worksheets for Evaluating Equivalance With the Life Safety Code.. 12

3.1 Sample Title Page 28

3.2 Sample FSES Tables 30

3.3 Sample Input Summary.. 32

3.4 Sample Summary of Estimated Retrofit Costs 34

3.5 Sample Fire Zone Summary Report 36

3.6 Sample Total Building Summary Report 38

List of Figures

2.1

Flowchart of the FSESCM Computer Program 6

List of Tables

2.1 Input Data Requirements for the FSESCM Computer Program 17

2.2 User Options Available with the FSESCM Computer Program 18

2.3 Retrofit Measures Considered by the FSESCM Computer Program 19

2.4 "SETUPA" COMMON Storage 22

2.5 "SETUPB" COMMON Storage 22

2.6 "RESET" COMMON Storage 23

3.1 Outputs of the FSESCM Computer Program 25

4.1 Specifications for Transfer of 9-Track Unlabeled Magnetic Tape.. 49

4.2 Source Code Modifications for Key Variables 53

4.3 Source Code Modifications by Routine 54

vi
1 . INTRODUCTION

1 . 1 BACKGROUND

The identification of cost-effective levels of fire safety in health care facilities is a major concern to hospital administrators, fire safety

engineers and public policy makers. Rising construction and operating costs

coupled with more stringent building codes and continuing advances in medical

and building technology have complicated the issue, forcing health care facility administrators to carefully assess the alternative means through

which they can design, construct or update their facilities.

The National Fire Protection Association (NFPA) has long been recognized as a leader in the development of voluntary codes which establish acceptable fire

safety levels. The Life Safety Code-*- is a widely used guide for identifying

the minimum acceptable level of fire safety in buildings. Although the code

may be thought of as prescriptive since it prescribes fixed solutions for life

safety in designated occupancies, performance concepts can be explicitly

introduced through a provision which allows for equivalent solutions

.

In light of this provision, the National Bureau of Standards' Center for Fire

Research, through support from the Department of Health and Human Services,

has developed a system, the Fire Safety Evaluation System (FSES), for

determining how combinations of several widely accepted fire safety systems

could be used to orovide a level of safety equivalent to that required in the

Life Safety Code. The FSES equivalency methodology which emerged from this

effort is particularly attractive since it lends itself to computer

optimization techniques. Such optimization techniques should result in

improved fire safety in health care facilities because they will resolve many

of the differences of opinion surrounding the cost impacts of fire safety in

health care facilities in general and the Life Safety Code in particular.

1.2 PURPOSE

The purpose of this report is to present a programmer-oriented description of

the economic and engineering considerations that went into the development of

a linear programming algorithm which permits the least cost means of achieving

compliance to the Life Safety Code to be identified. The Fire Safety

Evaluation System Cost Minimizer (FSESCM) computer program discussed in this

report is particularly useful because it is based on the equivalency

methodology developed by the Center for Fire Research. Since Che NFPA has

^-National Fire Protection Association, Code for Safety to Life from Fire in

Buildings and Structures , NFPA 101-1981, Quincy, Mass., 1981.

^H. E. Nelson and A. J. Shibe, A System for Fire Safety Evaluation of Health

Care Facilities , National Bureau of Standards, NBSIR 78-1555, Washington,

D.C., 1980.

1
adopted this equivalency methodology into the Life Safety Code, any solutions

from the computer program will be in compliance with the Life Safety Code.

Furthermore, since each of the parameters used in the equivalency methodology

has a unique value which corresponds to prescriptive compliance, it is

possible to quantify the cost savings attributable to a performance based

approach, or equivalency methodology, over that of prescriptive compliance.

Although the procedure is valid for-^both new and existing facilities, it is

anticipated that its primary use will be in identifying alternative courses of

action open to decision makers faced with retrofitting existing facilities.

The computer program uses as its primary input information collected as an integral part of a thorough fire safety evaluation. This information permits

the current state of the health care facility to be unambiguously identified.

The least-cost or optimal combination of retrofits is identified using the

following information:

(1) the current state of the health care facility;

(2) the minimum passing "score" needed to achieve compliance; and

(3) the anticipated costs of each retrofit measure.

The computer program then generates and analyzes a class of alternative

retrofits. The optimal combination of retrofits and any alternatives which

the program produces, usually between 10 and 20, are then summarized in

tabular form and ranked according to cost. By using this approach, health

care facility decision makers should have greater flexibility in choosing

among retrofit combinations. In particular, by providing alternatives, the

decision maker has the opportunity to assess very effectively the impact that

non-construction costs would have on the choice of the optimal retrofit

combination

.

1.3 SCOPE AND APPROACH

The documentation for the FSESCM computer program is divided into two parts,

each of which is designed to be self-contained and hence may be read

independently. The first part is designed to serve as a User's Manual . ^ The

second part, which includes this document, is intended for use as a Programmer's Manual. This approach was taken because most users are not

concerned with the internal workings of the program.

Chapter 2 uses a mathematical discussion of the FSESCM package of programs to

Introduce the basic philosophy behind the algorithm. All data structures are then described.

Ir.E. Chapman and W.G. Hall, User's Manual for the Fire Safety Evaluation

System Cost Minimizer Computer Program , National Bureau of Standards,

NBSIR (in preparation)

.

2
The operational characteristics of the model are described in the third

chapter. First, the basic outputs associated with a prespecified data file

used in generating test results are described. Emphasis is then placed on an analysis of model test results (e.g., run times experienced, validation

activities , and program portability)

.

, The final chapter provides a set of guidelines for obtaining and setting up

"the model. The transfer medium is first discussed followed by an examination ' of the contents of the four files provided whenever a request for the source

code is made. These files consist of: (1) background information; (2) the

FSESCM source code; (3) a data file for initial testing; and (4) an output

file for insuring model validity across operating systems. The chapter

concludes with a set of provisions for updating or modifying the FSESCM source

code

.

The report also contains a technical appendix. Appendix A relates the

documentation for the model with that outlined in the relevant Federal

Information Processing Standards (FIPS) documents. A series of descriptive

tables are then used to define all variables and reports . Each subroutine is

then described focusing on such topics as: (1) purpose; (2) calling sequence;

(3) common blocks used; and (4) reports produced. The FSESCM source code is

written in FORTRAN and complies with the guidelines set down in the ANSI

X3. 9-1978 software standard.^

^•American National Standards Institute, American National Standard Programming

Language FORTRAN, ANSI X3 . 9-1 978, New York, 1978.

3
2. FUNCTIONAL DESCRIPTION OF FSESCM

2 . 1 PROBLEM STRUCTURE

The FSESCM 'computer program is designed to balance score improvements against

the cost of retrofitting so that the least-cost means of achieving compliance

to the Life Safety Code can be identified. The core concept behind FSESCM is

a mathematical technique known as linear programming. In its usual context

linear programming deals with the problem of allocating limited resources

among competing activities in an optimal way. At the foundation of any linear

programming problem is a mathematical model which describes the problem of

concern. In this case, the mathematical model is the Fire Safety Evaluation

System. The term "linear" refers to the requirement that all mathematical

functions in the model are linear. The term "program" is used in the general

sense in that it refers to a plan rather than a computer program per se .

In addition to the least cost solution, FSESCM contains a procedure for

systematically generating alternative solutions, many of which are close in

cost to the optimum. Two groups of alternative solutions are generated to

facilitate the design selection process. The first group is based on the

input condition of each fire zone. The objective here is to provide an opportunity to force each initial condition to stay in a solution and for each

potential retrofit to be in a solution. The second group of solutions is

based on a prespecified set of design variable qualifiers. The objective here

is to insure design compatibility across fire zones. A fire zone is defined

as a space separated from all others by floors, horizontal exits, or smoke

barriers. Both groups of solutions are generated for each fire zone input.

The second group of solutions is used to produce a series of compliance

strategies for the entire building within which the key design variable

qualifiers are held constant. These solutions are then printed out in

ascending order of cost.

The basic methodology behind the FSESCM computer program is summarized in

figure 2.1. This figure is a gross-level flowchart of the computer program;

it consists of two pages of diagrams. In the discussion which follows, it

will be assumed that data on several buildings are being run in a batch mode . ^

The computations begin with the circular symbol labeled as FSESCM. Prior to

the analysis of any data, however, all key variables are first initialized.

Background information which includes the facility name and location, the

contact person, the type of facility, and a set of cost multipliers is then

read in. If the facility type or cost multipliers are out of range, an error message is written and the defective varaible is reset to its default value.

These errors are not treated as fatal (i.e., they do not cause the run for

this building to abort) since it was rationalized that users would benefit

more from diagnostics received later on (most of which are associated with

fatal errors) if the program were allowed to continue screening their data.

Thus although it is possible that the incorrect problem could be solved, due

to a default setting, it is more likely that other errors will be encountered

^•Without loss of generality the term card image could be substituted wherever

the word card is used.

4
later on whose diagnostics will give the user a better idea of where the

problem is incorrectly formulated than if the run for the building were

aborted after the first block of cards was read. The . background information

as input or after modification is then printed out for reference and as an aid

for comparing the results of different sets of runs for the same building.

The fire zone inputs are then read. If an error is encountered at this time,

the logic flow is transferred to statement label C on the second page of the

flowchart. Immediately after entering the section of logic which begins with

statement label C, the program writes an error message which should enable the

user to locate the problem. The model then reads over the remaining data for

this building, printing out the information on the cards (up to 20) following

the one where the error occurred. If this was not the last building in the

batch, then the program is transferred back to the logic flow which follows

statement label A, where the program attempts to read the background

information on the next building. If this was the last building in the batch,

then the program stops. If no error was encountered when the fire zone inputs

were read, then an input summary is printed out as well as the estimated costs

for each retrofit state in Table 4 of the FSES which was deemed feasible.

The control cara(s) for the fire zone are then read within the section of

logic which follows statement label D on the first page of the flowchart. If an error is encountered on a control card, the logic flow is transferred to

statement label C and the operations discussed above are performed. If no error was encountered, then the program will check if a solution is desired.

If so, the logic flow is transferred to statement label E on the second page

of the flowchart

.

The logic associated with the four processing symbols (shown below statement

label E) is as follows. First, the linear programming relaxation^ is solved

and stored as a bounding solution and an advanced starting point^ for all

future solutions for this fire zone. The two classes of solutions discussed

earlier are then generated. A class of design equivalent solutions for use in

matching common retrofit strategies across fire zones is then generated. The

program then classifies and sorts all solutions. Once all four processes have

been completed, a fire zone summary report is printed out. This report

includes data on the fire zone location and a set of information on each

solution generated. The logic flow is then returned to statement label D

where the next control card is read.

Following the logic flow down to the second decision block beneath statement

label D and assuming no solution is desired, the program checks if a modification is required. If so, the modification is read and checked for

correctness. If an error is encountered, the logic flow is transferred to

statement label G where the operations described earlier are carried out. If no error was encountered, then the logic flow is returned to statement label D

where the next control card is read.

•'The formulation associated with the FSES is actually a 0-1 integer

programming problem. FSESCM uses a heuristic post-processor to ensure

integrality

.

‘The advanced starting point permits all other solutions to be generated with

only a fraction of the iterations which would otherwise have been required.

5
Figure 2.1 Flowchart of the FSESCM Computer Program

f FSESCM

j

INITIALIZATION

7

K

WRITE SET DEFAULT BACKGROUND VALUES INFORMATION

WRITE INPUT SUMMARY ANO

ESTIMATED

RETROFIT COSTS

*3
Figure 2.1 Flowchart of the FSESCM Computer Program (continued)

CALCULATE

BOUNDING

SOLUTION

GENERATE TWO

CLASSES OF

SOLUTIONS BASED

ON INPUT CONDITIONS

GENERATE A CLASS

OF DESIGN

EQUIVALENT

SOLUTIONS

CLASSIFY AND SORT

SOLUTIONS

/
Returning to statement label D, following the logic flow down to the third

decision block and assuming no modifications are required, the program checks

if all fire zones for this building have been analyzed. If more fire zones are to be analyzed, the logic flow is transferred to statement label B, where

data on the next fire zone are read. The program then checks if the testing

option has been exercised for this building. The testing option permits users

to check their input data for consistency without incurring the costs of

generating the various classes of solutions for the first fire zones and then

encountering a fatal error on one of the last fire zones. * If the testing

option for the building has been exercised, then the logic flow skips down to

statement label F where the program checks if this is the last building in the

batch. If so, the program stops.

If the testing option has not been exercised, then this is the last fire zone for the building under consideration and the building summary report is

output. This report is divided into two parts. The first part shows for each

design classification: the design variable qualifiers; the total cost for the

building; and the cost of prescriptive compliance for the building. The

second part shows for each fire zone: the fire zone location; the

post-retrofit name for each building safety feature; any surplus over the

safety requirement; and the cost to comply for that fire zone. The program

then checks if this is the last building in the batch. If it is not, then the

logic flow is transferred to statement label A where the program attempts to

read the background information on the next building. If this is the last

building in the batch, then all buildings have been analyzed and the program

stops.

The FSES consists of seven worksheets. FSES Tables 1 through 3 (exhibit 2.1)

and 6 (exhibit 2.4) use existing service activities at the facility to

determine the level of general safety required to be equivalent to the 1981

edition of the Life Safety Code. FSES Table 4 (exhibit 2.2) gives the scores associated with each building safety feature/state pair.“ FSES Table 3 (exhibit 2.3) provides the means for calculating performance against each of

four safety requirements (containment, extinguishment, people movement, and

general safety). FSES Table 7 provides a check against compliance with each

of the four safety requirements.

^The solutions from a previous batch run for a particular building are not

stored, so it would be necessary to rerun the entire building.

-There are 13 building safety features (construction, interior finish

(corridors and exits), interior finish (rooms), corridor partitions/walls

,

doors to corridor, zone dimensions, vertical openings, hazardous areas, smoke

control, emergency movement routes, manual fire alarms, smoke detection and

alarms, and automatic sprinklers} defined in the FSES. Each feature is

subdivided into a set of states

.

8
Exhibit 2.1 Worksheets for Calculating the General Safety Requirement

Table 1 . OCCUPANCY RISK PARAMETER FACTORS

RISK PARAMETERS RISK FACTOR VALUES

1. PATIENT

MOBILITY (M)

MOBILITY

STATUS

MOBILE

LIMITED

MOBILITY

NOT

MOBILE

NOT

MOVABLE

RISK FACTOR 1.0 1.6 3.2 4.5

2. PATIENT PATIENT 1-5 6-10 11- 30 >30

DENSITY (D) RISK FACTOR 1.0 1.2 1.5 2.0

3. ZONE FLOOR 1ST 2ND OR

3RO

4TH TO 6TH

7TH AND

ABOVE

BASEMENTS

LOCATION (L) RISK FACTOR 1.1 1.2 1.4 1.6 1.6

4. RATIO OF

PATIENTS TO

PATIENTS

ATTENDANT

hi

1 hi

1

6-10

1

>_1]

1

ONE OR*

MORE

NONE

ATTENDANTS (T) RISK FACTOR 1.0 i.i 1.2 1.5 4.0

5. PATIENT

AVERAGE

AGE UNDER 65 YEARS

AND OYER 1 YEAR

65 YEARS & OYER

1 YEAR & YOUNGER

AGE [A] RISK FACTOR 1.0 1.2

* RISK FACTOR OF 4.0 IS CHARGED TO ANY ZONE THAT HOUSES

PATIENTS WITHOUT ANY STAFF IN IMMEDIATE ATTENDANCE

Table 2. OCCUPANCY RISK FACTOR CALCULATION

M

OCCUPANCY RISK *

0 * *

F

Table 3A. (NEW BUILDINGS) Table 33. (EXISTING BUILDINGS)

u1

F =R

Q.S

X

F =

R

9
Exhibit 2.2 Worksheet for Determining the Values of Each Building

Safety Feature/State Pair

Table 4. SAFETY PARAMETERS VALUES

PARAMETERS PARAMETERS VALUES

1. CONSTRUCTION

C0M8USTIBLE

MON-COMBUSTIBLE

*000 FRAME OROINARY

FLOOR OF ZONE UNPROTECTED PROTECTEO UNPROTECTED PROTECTED UNPROTECTED PROTECTEO FIRE RESIST.

FIRST -2 0 -2 0 0 2 2 SECOND -7 -2 -4 -2 -2 2 4

THIRO -9 -7 -9 -7 -7 2 4

4TH 1 A80VE -13 -7 -13 -7 -9 -7 4

2. INTERIOR FINISH

(Corr. & Exit)

cuss c CLASS S CUSS A -5 0 3

3. INTERIOR FINISH [Rooms)

CLASS C CLASS 1 CLASS A -3 1 3

4. CORRIDOR

PARTITIONS/WALLS

NONE OR incomplete *1/1 HR >1/10 .0 HR >1.0 HR.

-10 [0)‘ 0 1 [0|* 2(0|*

5. DOORS TO CORRIOOR

NO ooor <20 MINER >20 MIN. FR >20 MIN. FR L AUTO CIOS. -10 0 i nr 2 10) +

6. ZONE DIMENSIONS

OEAO ENO MORE THAN 100' OEAO ENO

SO'-lOO' DUO ENO

10-50' NO OEAO ENOS >30' 1 ZONE LENGTH IS. >150* 100'- 150' <I00' -8 (0|- -4 [0|- - 2 ior -2 0 1

7. VERTICAL OPENINGS

OPEN 4 OR MORE

FLOORS OPEN 2 OR 3 FLOORS

ENCLOSED NITH INOICATEO FIRE RESIST

<1 HR. 5l HR. < 2 HR. *2 HR. -14 -10 a 2 ior+

3 [or

8. HAZARDOUS AREAS

30U8LE OEFICIENCY SINGLE DEFICIENCY NO DEFICIENCIES

IN ZONE OUTSIDE ZONE IN ZONE IN 40IACENT ZONE

-11 -5 -2 0

9. SMOKE CONTROL

NO CONTROL SMOKE PARTITION MECH. ASSISTED SYSTEMS JT ZONE

3 -sior*

0

10. EMERGENCY MOVEMENT

ROUTES

.2 ROUTES MULTIPLE ROUTES

-3

DEFICIENT CAPACITY «/0 HORIZONTAL

aiTisi horizontal urns. OIRECT EXITtsI

-2 0 3 5

11. MANUAL FIRE ALARM

>10 MANUAL f'.m ALARM MANUAL FIRE ALARM

—4

W/O F 3. CONN. N/F 0. CONN.

1 2

12. SMOKE DETECTION

4 ALARM

NONE CORRIOOR ONLY ROOMS ONLY CORRIOOR t -IA8IT SPACE

4

TOTAL SPACE

0 2 3 5

13. AUTOMATIC

SPRINKLERS

NOME CORRIOOR t HA8IT. SPACE

3

-dtal spice

0 10

NOTE. 'Use |0| «ni» tjm 5 is -10. + Usi I0| *n>n item 4 is -10. •*Usa 1 0 1 (den itiffl 10 is -0. ** Jsa 0| men itsm I is :ased sn first floor :oae —•Use [0| io :om «itn loss than 31 jatients 3f in unoratsetea typo of construction, m existing Duildmgs.

10
Exhibit 2.3 Worksheet for Calculating Containment Safety, Extinguishment

Safety, People Movement Safety, and General Safety

11
Exhibit 2.4 Worksheets for Evaluating Equivalance With the Life Safety Code

Table 6. MANDATORY SAFETY REQUIREMENTS

CONTAINMENT

$a

EXTINGUISHMENT

Sb

PEOPLE MOVEMENT

Sc

ZONE LOCATION New Exist. New Exist. New Exist.

FLOOR 1 9 5 614]' 3 6(4]' 1

ABOVE OR BELOW FLOOR 1 14 9 8(6]' 5 9(7]' 3

* Use values in parentheses ( ) for hospitals

Table 7. ZONE SAFETY EQUIVALENCY EVALUATION YES NO

CONTAINMENT

SAFETY (Si)

less

MANDATORY

CONTAINMENT [S a ] "°

Si Sa C

EXTINGUISHMENT . SAFETY (S 2 )

MANDATORY

EXTINGUISHMENT (S b)

S 2 Sb E -era

PEOPLE

MOVEMENT (c

SAFETY 1*3

less

1

MANOATORY

PEOPLE >0

MOVEMENT (S c )

S3 Sc P

GENERAL

SAFETY |Sq]

less

OCCUPANCY

RISK (R)

i0

Sg R G

12
The notation for exposition of the model is based on the worksheets. Consider

the numbered building safety features of FSES Table 4 as rows, and denote them

by i. (Note that although construction contains four rows, only one is

appropriate at any given time.) Consider the columns of FSES Table 4 as states, and denote them by j.

The problem then becomes one of minimizing the total cost of compliance, where

the objective function is a linear combination of the state variables, X-m , and the transition costs, Cj_j . In particular, the state variable X^j , takes on a value of 1 if the j

c ^ state of the ith building safety feature is in the

solution and is 0 otherwise. The transition cost, C-jj , associated with the

transition from the initial state of the ith building safety feature to the

j state is defined as follows:

i

Cj_j = 0 if in the initial state (i.e., j = jinp U t)>

= arbitrarily large if j is less than the initial state or is deemed to be

nonfeasible on engineering grounds; otherwise

= estimated cost.

The problem may now be expressed algebraically as:

minimize

13

V

L i=l

i

3max

L i

3 =3min

C ij Xij

subject to

(1) a generalized upper bound constraint for each building safety feature

i

imax

l Xjj = 1 i = 1,..., 13 where Xjj = 0 or 1 i

3 =3min

and

(2) a performance constraint for each safety requirement

^ Imax

l i «ikvijXij - \ - \ k - 1, 2, 3, 4

1=1

-_-

i

1 “3 min

13
where

the minimum state number^- associated with the i

c ^ building

safety feature;

the maximum state number associated with the i

c ^ building

safety feature;

a weighting factor for the state value (W^ = 0, 1/2, or 1);

the state value;

a nonegative surplus variable; and

the safety requirement.

The above formulation indicates that the problem is a binary ( 0- 1 ) integer

program. However, due to the structure imposed on the problem by the 13

generalized upper bound constraints, the integrality requirements may be

relaxed to non-negativity constraints. The associated linear programming

relaxation is easily solved through application of the revised simplex

method. ^ This algorithm was selected both because a non-proprietary version

had been developed in house and it had the capability for using an advanced

starting basis. The advanced starting basis was particularly important

because, for each fire zone, the optimizer is called interatively in order to

generate the two sets of alternative solutions. 3 Thus, for each fire zone, it

is only necessary to solve the problem from scratch once; all other solutions

use the initial bounding (continuous) solution as a starting basis.

i

Jmin

i

Jmax

wik

V ij

Yk

Rk

^•States are numbered sequentially from 1 to 56 (e.g., construction consists of

state numbers 1 through 7, and automatic sprinklers consists of state numbers

54 through 56)

.

‘-Additional information on this subject may be found in the introductory text

by Gass (S.I. Gass, Linear Programming: Methods and Applications (New York,

McGraw-Hill 3ook Company, 1975)). Additional documentation for the revised

simplex algorithm used in FSESCM is contained in: W. G. Hall, R. H. F.

Jackson and P. 3. Saunders, The National Sureau of Standards Linear and

Quadratic Programming Subroutines , NBS Report 10695, 1972.

3a process known as state forcing is used to generate the alternative

solutions. This process systematically forces building safety feature/state

pairs into and out of the basis by changing their transition costs. Since

changing transition costs operates on the objective function, it does not

affect the feasibility of the linear programming relaxation. An advanced

starting basis may therefore be used which permits the relaxation to be

solved very efficiently. State forcing is particularly valuable because it

facilitates the answering of many' what-if questions.

14
It should be noted that the linear programming relaxation does not, in

general, produce an all integer solution. Furthermore, the interdependencies

defined on FSES Table 4 (e.g., between corridor partitions/walls and doors to

the corridor) were not stated in the formulation given above. The program

thus contains a heuristic post processor to impose integrality and to assure

that any interdependencies do not render the problem infeasible.

Three state-forcing loops within the MAIN program are used to generate the

alternate solutions. In the first state-forcing loop, a subset of up to 13

alternate solutions based on the input states of FSES Table 4 is generated.

Each building safety feature, in turn, is inhibited from making a transition

to any but the input state. The linear programming relaxation is then solved

and integerized. The mechanism for generating this subset, for each i, is to

i i i

set C±j

arbitrarily large for all j, j min < j < j max , j * j input .

In the second state-forcing loop, a subset of up to 56 alternative solutions

based on the bounding solution of the linear programming relaxation is

generated. Each Xj_j of the bounding solution is examined in turn. If X^j is

unequal to 1, then the Cjj's are adjusted so that the corresponding X^ is

forced into the solution. If X-jj is equal to 1, then the C^j's are adjusted

so that Xj_j is inhibited from appearing in the solution.

The solutions so generated are not necessarily distinct. The number of

solutions will, of course, depend upon the input states and the number of

allowable transitions. These solutions constitute the first of the two

classes mentioned earlier.

In the third state-forcing loop, a subset of up to 40 alternative solutions

based on design considerations is generated. Six building safety features

have their transition states preset to insure design compatibility. The

design variable qualifiers used in establishing the 40 design classifications

are defined in table 2.1. Each Xj_j within a building safety feature is

examined in turn, however; unlike the two previous cases, all building safety

features must be examined before the optimizer is called. If the i

1-^1 building

safety feature is to be preset, then all of the C-j. j' s are adjusted so that the

corresponding X^j is forced into the solution. If the i

1-^ building safety

feature is not to be preset, then no changes are made to the C-jj ’ s . Once all

building safety features have been examined, all appropriate variables have

been preset, and if a meaningful transition^- can take place for each of the

six building safety features, the optimizer is called to solve the linear

programming relaxation. The solution is then integerized and checked for

feasibility should an interdependency come into play.

^If a preset design variable qualifier, X-<_j , has a cost, C^j , which is

arbitrarily high, then no meaningful transition is possible and the logic

jumps to the end of the loop.

15
2.2 DATA STRUCTURES

There are four types of data referenced in any run of the FSESCM model. Two

of these data types are external; their values are determined by entries made

by the user. The two remaining are internal; they are associated with the

three labeled COMMONS.

Those data required of the user in order to run the model can be divided into

two types. The first type is designated as "background information" (see

table 2.1). This information covers such items as the name and location of

the facility, who to contact if a question arises and the type of building

being analyzed. The second type is designated as "specific information" and

refers to data which must be input for each fire zone. These data are used to

set up the optimization problem. They are summarized in table 2.1. The user also has available a set of options which affect the optimization problem in a variety of ways. Each option and its effect on the solution are described in

table 2.2.

All data are designed so that they can be easily and reliably collected at the same time as the fire zone is evaluated. Since some of the states within FSES

Table 4 are not associated with a single element, a worksheet was developed

which lists those building components requiring treatment in order to move from one state within a building safety feature to another. ^ The information

collected on the worksheet closely follows the design of FSES Table 4. The

retrofit measures which the data -from the worksheet permit the program to

consider are summarized in table 2.3. Associated with each potential retrofit

(i.e., one which is deemed feasible on engineering grounds) is a set of

information on the one or more elements which must be treated to -move to a higher state. This information is stored in an "element count matrix." The

product of the element count matrix and the element cost matrix, which is

initialized in the BLOCK DATA routine, yields the total cost associated with

each potential retrofit. In order to address a wide variety of “what-if"

questions, the user has the option to modify the costs of a particular

retrofit, the score required to pass, or both.

All data under the background information category are read within the MAIN

program. These data are always the first seven lines of the first building in

the external "user data file." The first six lines are used as an address

label as well as a means for identifying a contact person should additional

information be required. The data are read as alphanumeric (A4Q) and stored

in the character array HBLDG (CHARACTER*40 HBLDG(6)). The building type

(i.e., hospital or nursing home), the building age (i.e., new single story,

new multistory, existing single story, existing multistory), and construction

cost modifiers are then read. The first two variables are read under an 12

format, whereas the last three are read under an F5.2 format. The

construction cost modifiers are used to update the per unit labor and material

cost figures initialized in the BLOCK DATA routine to reflect differences in

the regional markets for labor services and building materials as well as cost

growth. This approach was taken so that it would not be necessary for users

to load their own values into the CPUL and CPUM arrays. Both arrays are 13 by

7 by 10.

1 The worksheet is described in detail in the User’s Manual.

16
Table

2.1

Input

Duta

Requirements

for

the

FSESCM

Computer

Program

Oa

"3 • ’J a a

05 • a

a

4-4 00

aa

aa 31

a

4-4

u 30

a

a 3 —4m

-C „3

a • 10 • —4 -2 CVI 3 4J U a

<r4 c 4J

a c a 4-1 <B a

05 s a

a 3 X

a.

a —4 2 a

-3 o a 3 a

a

C 4-4 ,3 E <0 3 a a - a

•*-4

a o- <+4a •—i a

4-1

U CJ

a

a

u JZ. CO

O •H

a

a

a

a 3 a -o 4J 4-1 a

0) CO Uta >*

u

a

B • > a 0) 4-1 u 3 a a 0 > a a O a 2 a X 3 1*4 04 B a a a —- a •o (—< a 0 2 3 c

4-1 c 0 CO r—•

j3 1) a • 3 a a a —* a — a

a • c * 0 <H * U1 *—4 a a a O 3 0 • a «J • C 3 a O a a 3 vO 10 -4 SO o C a u a a U a 4J a a a 0 c C0 a 4-1 3 05 4-1 c • <^i a a a O

V

a 00

V

a CJ

a

a 3 a

aO

co

a

a .2

O

a -3 3 j* o —* a

O CJ

aa 0 J= 0 CO CJ 15 a a o • a —4 a a a B U-4 H <4-1 H 4-1 £ a <N u a a CO a a a c a <a a a -C O CL a O 3 C —H co O a CO c 4-1 4-1 a 0 3 10

a*a

M <4-1 TJ CJOa •vH

a e 0

<4-4 to CO CJ .3 04 -2

a

a • a "O

k4 ua oj Ca 4J 0 i-4 4-1 •a

O

a -r

a

O

u CJ 04

A 3 <a

aa o g <4-4 a a <4-1 O <4-1 a X a O a a —4 a

4J 0 O J* 0 O 3 a

ua

a

a 3 a CJ c. a v u a B J2

a

a

O 05 5 05

a

a 3 a £ a 0 U-J e 0) a O a a > —4 a a 3 a

<4-1

g > a l- 0 0 3 a 'J 3 0 3 a 3 o a a a a a .3 a

i—4

a

a 4-1

O 05

aa JZ i-H .3 E 10

a S V o a a -C u M 4-1 a • 3 a a

JD -X CJa 10

W 05

a

a

a E sz

a

a

CT3a

a oi Xi JZ

a C-4aB 3 a o 10

a CO

a

aa • a 4-» i-i

aaC

a 3 aa o

4-1

a

a

a c CO c a

a

a

no —4a

u

a «h

a

a S3

Ha > c o •o 2. c O <4-4 4J O *H <4-4 U 4-1 g CO s a a a a 4-1 t4 a <4-4 a a CJ a u s< u a a B a CO a cj 3 a cj a a a a B a 3 a a f-4 •H 0 a now a <4-i <4-1 4-1 a 4—1 C a O > a a B -c c_ •oca Q. <44 <4-1 a a a o a JZ o C a 2 z CO < a E CO < < £3 CO a CJ B CO CJ £-4 aa

-2£ a Z ua 0) J3 c E 3 c 3 O .3 Z a 3. U 3 a « a a

CJ

a 3 0 M —J a

“3 3 a

a

"3

C 0 4-1 3 CTJ a •H 3 2 a a 4-1 a

a >% 3 3 3 a — u -j

B

a 0) C

a —4 CJ 4J

aa

a

w £ CO 3-

Q

a 4-1 o- 3

<3

a c.

—-

3-

aa 3 Z V H «H g CO 3

2- 4-1

a ’-14a CJ

>> 10

a 3 0 u 10

a 4-1 3 3 O

a 3 a CO

a 'J

— Z NJ

a 2-— 3 3

—4 CO T3

a "3a

C

— 4-1 1—4 4-4

a J2 <—* 2 a

'J 3 --4a

a 2 a •—« a

a

.“0

O 3 c -4 3 -4 3 — 3. CJ 23 CJ Ca Z 0

—4 3 a O

10a -4 3 2 -J •a a a a 04 a 0 3 3 — <4-4 u *3 fZ, —) 3 a

•o 3 — a 04

10

a

'J

a

Q,

a CO

17

M'SliS

Table 6

(exhibit

2.A)

defines

the

mandatory

safety

requirements

for

containment,

extinguishment

and

people

movement
Table 2.2 User Options Available with the FSESCM Computer Program

Option Purpose

SOLVE Causes an optimum solution for the fire zone input to be generated. A set of retrofit

strategies which satisfy all of the

requirements of the Life Safety Code as well

as several building design criteria is also

generated

.

CHANGE Adjusts the state transition cost to the value

specified by the user.

REQUIR Increases a safety requirement by a percentage

specified by the user.

NEXT Tells the program to look for the data on the

next fire zone or the next building.

LAST Signals that all data for the building under

study have been analyzed and that the

solutions' for the total building should be

output

.

TEST Checks all input data for consistency.

FINAL Tells the program to stop; all data for the run have been output

.

18
Table 2.3 Retrofit Measures Considered by the FSESCM Computer Program

Building Safety Feature Retrofit

1

.

Construction Resheath walls and partitions

Protect columns

Protect beams

Protect decking

2. Interior Finish Install drywall

(Corridors and Exits) Coat walls with retardant

Coat ceilings with retardant

Install carpet

3. Interior Finish (Rooms) Install drywall

Coat walls with retardant

Coat ceilings with retardant

4. Corridor Partitions/Walls Install partition slab to slab

Extend existing partitions to slab

Replace see-through panels and frames

Replace see-through panels only

Install drywall

5. Doors to Corridor Replace doors and frames

Replace doors only

Replace latch

Replace view panel

Install closers

6. Zone Dimensions Install cross connection

Install stairway

Install smoke partition

7. Vertical Openings Frame and sheath

Sheath only

Install doors and frames

Install doors only

8. Hazardous Areas Install sprinklers

Install Class B door

Install drywall

9. Smoke Control Install smoke partition

10. Emergency Movement Routes Install exit stairway

Install emergency lighting

Install horizontal exit

11. Manual Fire Alarm Install control panel

Install pull station

Connect to fire department

12. Smoke Detection and Alarm Install smoke detectors

13. Automatic Sprinklers Install wet system

Install dry system

19
All data under the specific information category begin with card eight and

continue until a LAST card is encountered. Data are read in sequence, a single fire zone at a time. Solutions are generated for each fire zone. Five

of the 13 building safety features require special treatment; they are handled

as subroutines. All other data is read within the MAIN program. Data on the

zone location and number of patients are first read in according to an 14

format. Information on FSES Table 1 is then read in according to an 13

format; it is used to calculate the general safety requirement. Information

on the existing state for each of the 13 building safety features is then read

in according to an 13 format. Since a regression in score is not permitted,

these values set lower limits on DO loops. With the exception of

construction, zone dimensions, hazardous areas, smoke detection and alarm, and

automatic sprinklers, all data are read according to an 16 format. Each line

of the file corresponds to a potential retrofit. The number of entries on the

line ranges from 1 to 8; critical element counts follow closely the retrofit

measures defined in table 2.3.

Construction and smoke detection and alarm use the same 16 format as in the

MAIN program but have more complicated costing procedures than allowed in the

MAIN's general purpose routine. The three other building safety features

which require special handling also require special formats. The zone dimension feature requires information on the length of the fire zone to be

entered according to an 16 format. This information is used to calculate the

number of smoke partitions which must be installed in order to reduce the

zone's dimensions to the levels -defined in FSES Table 4. Hazardous areas require special treatment because any of three complicating factors can occur. Some hazardous areas within the fire zone may have: (1) a double deficiency;

(2) a single deficiency but lack sprinklering; or (3) a single deficiency with

sprinklering present. Since the state value is determined by the worst-case

condition, a mixture of hazardous area types may exist. By separately

accounting for these complicating factors, it becomes possible to

unambiguously estimate the transition costs to all higher states. Qualifiers

for each of the chree complicating factors are read in according to an 13

format. Sprinklers require qualifiers for both sprinkler type and water

supply. The sprinkler type qualifiers are: (1) wet exposed; (2) wet

concealed; (3) dry exposed; and (4) dry concealed. The water supply

qualifiers are: (1) adequate; (2) not adequate; and (3) unknown. Both sets

of qualifiers are read according to an 13 format.

The option/control cards defined in table 2.2 are read within the MAIN

program. They are composed of an alphanumeric portion and an integer portion.

The command itself is read according to an A6 format. If the user is

exercising the CHANGE option, then the building safety feature aumber/state

number designators are read in according to an 13 format. The user-defined

transition cost in dollars is then read according to an 17 format. If the

user is exercising the REOUIR option, then both the percentage change and the

safety requirement to which that change is to be applied are read according to an 13 format. The integer portion for all other commands has no meaningful

interpretation and should therefore be left blank.

20
The internally stored data are made available to the program through the

SETUPA, SETUPB , and RESET COMMONS. The SETUPA and SETUPB labeled COMMONS are associated with the BLOCK DATA routine. This routine initializes all

variables in the SETUPA and SETUPB COMMONS. Once initialized, regardless of

the number of facilities analyzed, all SETUPA and variables remain constant

throughout the run. The variables contained in the SETUPA COMMON are listed

in alphabetical order in table 2.4. Dimensions, variable type, and purpose

are also given in the table. The variables contained in the SETUPB COMMON are described in table 2.5.

The RESET COMMON is associated with subroutine INSETS. The INSETS subroutine

initializes (or reinitializes) the values of all major work spaces. It is

designed to clear the working spaces so that no information from a previous

building could influence the calculations for the one being analyzed

currently. INSETS is called in four ways:

(1) initially;

(2) after each building has been analyzed;

(3) if the output of the revised simplex (RVSMPX) subroutine was other

than normal; and

(4) if an error in the runstream for the building under analysis was encountered

.

The variables contained in the RESET COMMON are described in table 2.6.

21
Table 2.4 "SETUPA” COMMON Storage

Variable Data Type Contents

CPUL( 13,7,10) REAL Labor cost per unit

CPUM( 13,7,10) REAL Materials cost per unit

G( 13 ,7) REAL FSES Table 4 for print out

IEC1 (40) INTEGER Design classification qualifiers

IEC5(40 ,5) INTEGER Design classification flags

IST4(56,2) INTEGER Simplex/Table 4 crosswalk

IT1M( 5) INTEGER FSES Table 1: maximum state number

IT4A( 7

)

INTEGER FSES Table 4: construction state

number

IT4B(7) INTEGER FSES Table 4: construction states

in increasing order

IT4M( 13) INTEGER FSES Table 4: maximum state number

IT4S( 13 , 2) INTEGER Simplex variable limits

IT8( 5

)

INTEGER FSES Table 4: hazardous area states

in increasing order ' JPR( 13,8) INTEGER FSES Table 4: descriptive state

numbers

LCV( 13) INTEGER Length of cost vector

Tl(5 ,5) • REAL FSES Table 1 T48A( 5) REAL FSES Table 4: hazardous area increasing values row T4A(4 , 7) . REAL FSES Table 4: construction row T4B(4,7) REAL FSES Table 4: construction row in

increasing values

T6A(3 , 2 , 2) REAL FSES Table 6 for hospitals

T6B(3 ,2,2) REAL FSES Table 6 for nursing homes

Table 2.5 "SETUPB" COMMON Storage

Variable Data Type Contents

SLAB (56) CHARACTER*! State number labels

HOUT(40) CHARACTER*4

5

Design classification labels

HPAR( 18

)

CHARACTER* 30 FSES Table 4 labels

HTl(lO) CHARACTER*8 FSES Table 1 labels

22
Table 2.6 "RESET" COMMON Storage

Variable Data Type Cotents

C ( 56

)

REAL

IECT(44) INTEGER

IPAC( 100 ,22) INTEGER

ISRT( 100 , 22) INTEGER

ISTAT( 13) INTEGER

ISTK( 500 , 22) INTEGER

L ( 150) INTEGER

X( 150) REAL

Y( 150) REAL

Z ( 150) REAL

State transition cost

Design classification solution

counts

Integerized solution storage

Sorted solution storage

State numbers/f lags

Stacked solution storage

Simplex general purpose vector

Simplex solution vector

Working solution vector

Prototype solution vector

23
3. OPERATIONAL CHARACTERISTICS

3.1 MODEL OUTPUTS

The information printed out by the FSESCM computer program fits into three

major output classifications, which are summarized in table 3.1. Each output

classification is described briefly in the text which follows. The three

classifications are: (1) background information; (2) reference data and

solutions; and (3) design solutions.

Background Information

The first class of outputs reports includes a title page and FSES Tables 1, 6

and 4.

Title Page

The title page report also serves as a mailing label and identifies the

appropriate staff member to contact in the event that a problem is

encountered in analyzing the facility.

FSES Tables

FSES Tables 1, 6 and 4 are included in order to show how the occupancy

risk factors are used to calculate the General Safety requirement, what

values for Containment, Extinguishment and People Movement Safety are required for equivalence, and the full range of state values which

contribute toward fire zone safety.

Reference Data and Solutions

The second class of output reports are generated for each fire zone. These outputs consist of a summary of all data input for the fire zone,

the estimated costs of moving from the input state to each potential

retrofit, and all distinct solutions generated for the fire zone.

Input Summary

The input summary provides the user with a concise statement of the data

used in setting up the problem for solution. It provides the user an opportunity to check the correctness of any values input as well as a means of differentiating among several runs for the same fire zone. This

report shows the location of the fire zone, the number of patients and

the appropriate set of occupancy risk factors for the fire zone under

study. Data on each of the 13 building safety features are then printed

out. These data show the input and prescriptive state and the number of

elements which must be upgraded in order to move to a higher state.

24
Table

3.1

Outputs

of

the

KSESCM

Computer

Program

u . V • 33 4k A z«\ 1m —j • y a Im y a 3 'm Vm 2 O O 3 O Z a A '4m CJ M ’4M u s —4 u CO V c 5 —4 y a y >k C 1) z 3 y y 4h r—i o a c o 2_ J= 4) -V » A >. a J a a u u M • y M Tl 4M o U CO '- 3 CO y /—s y -h y y CJ

f-4 3 u

y 33 Ofl OJ '4My r— Cb 2 4m

y a- CO

—1 U

H 3 2 -C = 0 y o

£-• a»

w 33 i3 33

U C/3

O 3 N4 CO Li Q£ U -M C & 5

IM •m CJ • —* 2 "5 CJ .2 1m

y 00 Ml

C >% 3 O

y

yyy Im 2 a

O

U <U 0 Z 2 >»

y 3 1m > > -4 -M 0 y 03 3 —i

CJ 0 -S £ CJ •M

rJL -c CJ

V

U 4m j2 4J m4 ea 2u

U W'

M

Li 1) 3 33

m VJ

U 2 Z m oc 2. >M • u a. vj *M 2 O M 0 y M -M — y 2 M o N-/ y CJ 33 TH y > CO y U 2 £ 2

CL

M 4—1

m £ C

M 1-1 o JZ

yy o y 2 y A a) U y 3 3 3 Li a a n ~ £

<0

y 33

U 1-1

u 33 'S

y

y

y

u <y

u 3 Ed

CH 0 co 3 M

u

y

y Im

a 2 —< 3 O c CO 0 2 2-

U CJ

—. 0 0 A u CJ * —« 4k u 2. VM O -M 3

•M cj

y

y

y ooy

M JOU •M • a. lM •

5-

y IM > y > 33y um 3 >1 Li 00 0 y

«J • Cm c M 20 *M 0 3 O CO •H

y 2 21 'M £ 5 <fl • 2 Ml u CJ 2J 'm a. y -i y u a >% —1 2, y 2. imi *k a -M -2 3 y >% 0 V ^ Li Li —4 £ M y L V y o VIM 2J £ Li

U-i boo CO

u

—i u CJ 0 2S

y CJ •H •M

y

y c T3 *h u_ a* y Cm y 2 Cl | 3 a 3 M z VIM M q » o < co a 33 CO Li u 0 33 22 O y • y • y v* • 33 O M y Eb y CO

>> c u c M

—

C 0 y -4y

—j

TJ CJ 50 0 CL 0 Cm CL o c- Cb

M CJ 2 •4-N

y JZ CSC — •M S -M W 73 M 00 u y

35 -H 4J • u 4k

O Li >iO c c CO

y

a. -o CO 4J 3 CJ

y c U CJ oo Im

m

w

y

O 3 HU 3 w 3 y o y «HO -3

M 2 S O *H q

C. 3C.

y o -* CM • 33 4m

H

—i u 3 o y 3 2 c > -J M 3 u y -M VIM y CM Z o 33 —1 m4 CO CO C c5 M 3 O > V y W y y y X 32 M c y

>> c 2 3. 3 -H 00 £ j2 0 MM

1-1

— 0 <T 2 M

a '-u 2 yy cjy

y

a —4

M IM CM

u T-. ~Mu

y _2 as 3 £b

h o y

yy

y 33 -a -H Ed

— LJ I •H —4 V y r—i CD y 33 rH 3 y Li a.

M

aa

a

L .3

L -3

y

u 2 y iM IM iM 33u

y

CO 35 CO tH

y

H 3 'm

M r—i 3 ^y 0 0 3 O 3 H H Sb 04 Cl CJ SC £b c- 4m 3- CO

CD M

CD0

CJu—1

4m0uuy

V >i £ u y "3 Z 2 y £ m a u 3 >N 3 u 2 u CO o —4 ca Cm u £ 00 V >N 33 £ c

as

u CJ 3

<n CO CO *3

yy e CM i-H 00 -< £ 3 y •M

CO

A 2 2 — 33 IO >s 2 22

e-1 U N1

V •4 3 4-1 —• CO 2 £ y y u CJ C. E iM M

7* 5/3

C 3 •M 0

CO 'JL Sm 2 6 20

mJ—i

JJ 2 i _<

vim 0 0

-MM CO

a

M

33 -3 *2 y £M y

a

CJ 2

’4m 33 3 m 2 -M 2 !—4

JO

JM

-J 23 -M 2 2 2 | 3 o 2 •J CO 0 2

Lt

J 2 1 =0 M 20 y -Ma y y y

33

a

25
Summary of Estimated Retrofit Costs

The costs of moving from the input state to all potential retrofits are then presented. This output includes the location of the fire zone and

three types of construction cost modifiers. The modifiers are needed

because all costs used within the FSESCM computer program reflect the

cost of installing a particular retrofit in the Washington, D. C. area during the summer of 1981. The modifiers permit the user to adjust not

only for regional price differences in the markets for labor services and

building materials but also for cost growth over time. Through reference

to modifiers it is not necessary to change the entries in the CPUL and

CPUM arrays. All three of these cost factors are readily available from

construction industry publications. Each of the 13 building safety

features are then output. The data show the input and prescriptive state

and the estimated cost of going to each potential retrofit. The cost of

prescriptive compliance for the fire zone is also shown as a basic

reference point.

Fire Zone Summary Report

This report shows each distinct solution generated as a line of output.

In order to easily identify a particular solution and for ease in

differentiating among solutions, the state name is printed beneath each

of the 13 building safety feature column headings. The state names closely resemble and hence can be easily matched to the labels in Table 4

of the FSES. The order in which the solutions are output is based on the

40 design classifications listed in table 2.4. All solutions are ranked

from least costly to most costly within a design classification; so if

more than one solution was. generated, the least costly is printed first

followed by the second, until all solutions for that design

classification are output. The program then outputs the solution(s) for

the next design classification for which at least one solution was generated until the list is exhausted. The prescriptive compliance

solution is then output. Three other groups of solutions are also

output. They are: (1) solutions which have no deficiencies in hazardous

areas but do not. belong to one of the design classifications; (2)

solutions which have a single deficiency in a hazardous area; and (3)

solutions which have a double deficiency in a hazardous area.

Design Solutions

The third class of output reports consists of the best solutions by

design classifications for the entire building. The design

classification solutions are generated and stored for each fire zone. Once all data on the fire zones have been input and analyzed, all

solutions are screened. The ones which match the prespecified set of

design variable qualifiers are identified. If every fire zone input has

at least one solution which was identified as a member of the design

classification under consideration, then a solution for the entire

building is generated.

26
Total 3uilding Summary Report

This report gives the design variable qualifiers, the total cost of

retrofitting the building for this design classification and the total

cost of prescriptive compliance for the building under study. The

prescriptive solution serves as a bench mark for comparison. The design

classification solutions are printed out in ascending order of estimated

retrofit cost for the entire building to facilitate comparison among

competing design alternatives. In order to facilitate the identification

of each solution, the state names for each of the 13 building safety

features are printed out as are the surpluses and retrofit cost for each

fire zone. Each fire zone takes up one line in the printout. If one or more fire zones did not contain this design class , no printout for the

entire building is generated. Should the user wish such a retrofit, it

would be necessary to synthesize it from the individual fire zone printouts

.

Six exhibits are used to illustrate the type of output produced by the

FSESCM model. The titles of the exhibits are designed for easy cross reference to the output reports listed in table 3.1. Each exhibit has

two parts. In part A, the output report as produced by the model is

shown. Part B contains a brief description of the purpose of the report

and the data output. The routines, either MAIN or a subroutine, from

which the report is generated are identified for reference purposes. The

outputs shown in the exhibits are based on a test case example. A

line-by-line description of this output for this case example may be

found in the User's Manual.

The Title Page (exhibit 3.1) and FSES Tables (exhibit 3.2) output reports

are generated once for each building immediately after the background

information is read into the character array HBLDG. The Input Summary

(exhibit 3.3) and the Summary of Estimated Retrofit Costs (exhibit 3.4)

reports are generated for each fire zone prior to optimization. The Fire

Zone Summary Report (exhibit 3.5) is generated once all three state

forcing loops have been completed. The Total Building Summary Report

(exhibit 3.6) is generated for each building after all fire zones for the

building have been analyzed.

27
NORTH-WEST

GENERAL

HOSPITAL

wain

building

U J JdUJ^IC UUC r<i^c

Parc A: Prlncouc

o

o

o

z o

< Cl 2

CL O

< z in z • < m U Q J CD > v n • -j a • uj m < —

2 ci - r

ecu - • uj a > ^

a < cr — OwujO

q: o 2

aj O —

•

•• a: O

z >- -

*- - z -j *- o O UJ < - 5 -

28
Exhibit 3.1 Sample Title Page

Part B: Discussion

The title page is produced through a call to subroutine PRTBAC. The character

array HBLDG is ’.passed as an argument. The subroutine prints the contents of

HBLDG (i.e., the mailing label and the contact person). The carriage returns

within subroutine PRTBAC also serve as a separator between runs for different

facilities. Subroutine PRTBAC is called immediately after it has read into

HBLDG the facility ID, name of the contact person and facility address.

29
OCCUPANCY

RISK

FACTORS

Exhibit 3.2 Sample FSES Tables

Part A: Printout

o o o o

<m «r

»- o o

U) • • — — o

x

U Ui m

3 0 0

Ui • • Z. ro o o o

(1 Cl Cl N

o o o o

ci r» ci

c o o o

ci r* f*

o o o o o

o o o o o o o

ci d ci ci ci r> v

H. O o

l/l . . — V m

X

CD Ui m

3 0 0

ui * • Z <T CO

oooooooooooooooo

cN^a>nnn--n cocn cicjo

oooooooooooooooo

ex r* c* — cOifl ci — cm aj OOOOOOOOOOOOOOOO

MNOxninnooifiT — m a) «r

>- o o

m • • — mo

u. < m

3 0 0

Cl <T a: o

; o cr uj z o o o > <

>— *- > o o < Ui o o -J o O i/> < o <

.2 — 2 — — O H- —

i

CD X ? X </l Ui UJ — o o < < < X o m o X — — — m Ui < — — cr o o C c z z ui

CD *- z z u V- Ui UJ z N— z O u X o X m z 2 < —

j

< O < ui o o < )— > O < m o X -• o a ui X X

a. 2 CL O rsi _j x a. < < 2 a X u — x x x — Q m z m 2 < z z O — Ui X •— m — — z — < Ui _ O —

z o u. — *T — — — 2: o z VU -J > < — X o 2 z z X 2: — ui X o o u- X

— Cl n m — a: u. o — — < O m x < x 2 Ui o

- o — w X o 2 o — X 'UJ < C UJ y> z > o

o -J o X 2: 21 o 2 -J 3 0 0 u. ui —

O u. — 3 O C O — — < O O Z o

_j X — — 2 c o 3 ui X <

UJ X X — l/i — X 'ui o < UJ 5

ui cn > UJ W X 21 Ui — < X X 3 X o

Z cr O 2 — *— X c z X N O UJ Z o p- O — 23 o z O c o Ui < 5 Z < 2 3

N: u < u “ o a (VI > I ilui 2 m <

«.* Cl Cl <T m d o o Cl ci

30
Exhibit 3.2 Sample FSES Tables

Part B: Discussion

This report is generated by the MAIN program. The labels for FSES Table 1 stored in the character array HT1 are first printed followed by the occupancy

risk factors stored in the T1 array. Next, depending on the value of ITYPE

,

the mandatory safety requirements for the problem under analysis are output.

The value of ITYPE determines whether this is a hospital (T6A) or a nursing

home (T6B). FSES Table 4 is then printed out; it consists of three parts.

First, the labels stored in the character array HPAR are printed out. Next,

the state values for the four rows associated with the construction building

safety feature stored in array T4A are printed out. Finally, the state values

associated with the remaining 12 building safety features, which are stored in

the G array, are printed out.

31
CONS

l

WUC

11

ON

NCOM*

R

NCOM'R

C‘WF*U

C*WF*P

C«OR*U

C»OR*P

NCOM»U

NCOM»P

NCOM*R

Exhibit 3,3 Sample Input Summary

Part A: Printout

oooa>r»ooo

o

oooot^ooo

o

z o o o

ao 00)000330)00

Z < <T CM - o

cm

UJ UJ

0000)0000 ZOOf^O

o o o

< o

< r*

•• *

• » n •

20) 000000)00

O <T CM <7 CM OOOOOOOO n

X O O o o

CD « a

o • 33

O O O

O 20000330)00O CM <7 O

ID * o * •

• CM

a. • O

z* acoooooooo o • — • o O

* o - 2*0 a • 0*0 uj • 2 2 a

<T •

UJ • o • a • O

32
Exhibit 3.3 Sample Input Summary

Part B: Discussion

The purpose of this report is to summarize the data used in setting up the

problem for solution. Portion^ are generated by the MAIN program and portions

are generated by the five special purpose subroutines (CCONST, CZODIM, CHAZAR,

CSMOKE, CSPRNK) . In addition to its use as a summary report, it is also

useful in distinguishing among runs when a sensitivity analysis is performed.

The first descriptive line shows the location of the fire zone (IFLOR, IZONE),

the number of patients (IPATS), and the state numbers for FSES Table 1 (IT1X)

as read by the MAIN program. Each of the 13 building safety features are then

listed by number, I, and label, HPAR(I). The two columns to the right of the

building safety feature name show the input and prescriptive state names

i i

(HLAB(Ml), HLAB(M2) where Ml = ji npu t and M2 = jpresc^* UP t0 ^ columns are

i i

then used as labels (HLAB(J) , J=j mi n > j max ) t0 show the number of elements

which must be upgraded in order to move to higher state. The element counts

correspond to the contents of the arrays IECCON (construction) IECZDM (zone

dimensions), IECHAZ (hazardous areas), IECSMO (smoke detection and alarm),

IECSPR (sprinklers), and INELT (otherwise). The actual element counts consist

of from 1 to 8 rows depending on the building safety feature and its

condition. If the building safety feature was input in the highest state,

then only one row is used regardless of the number of elements which can be

treated. If the building safety feature was not in the highest state, then

each row corresponds to a particular element. In interpreting the values, it

is necessary to note that the symbol ****** indicates that the state whose

name appears above it not a permissible retrofit. This may result because the

state is below the input and hence would result in a regression in score or it

is precluded on engineering grounds. The states which are permissible have

either a value of zero or some positive integer recorded. The second page of

the printout consists of data on building safety features 8 through 13. These

data are not reproduced here since their interpretation is the same as given

above

.

33
SUMMARY

OF

ESTIMATED

RETROFIT

COSTS

Exhibit 3,4 Sample Summary of Estimated Retrofit Costs

Part A: Printout

33 *

33 *

33

S3

<r < «r < a

33 O

33 ID

CD

o o o 03 — cm

• r» O O

2 OI o O X o u. o — • o 03 CM <r UJ — a 6

to— CM <T a <o UJ * M

r* U a X * a o o z o — P- 2 OI UJ z a a

x o O 03 C o 2 m a • >- a o

2 < <T in o CM 03 a — o < o o — 03 • 03 o * X — x

o* 03 <

a

O in -i • UJ 03 X

UJ UJ 03 o CO 2 o » • o O O z — uj 1/3 * X a

2 • 5 03 o o 2 o z o z UJ O Z O — • O <T 03 — o • « O in

i • CM o • • NJ • 2 U z

03 * 0> a C-) o O o

• UJ n UJ 2 o UJ • N a o O a UJ 1/3 s • 3 a X

2 • 2 n o * 03 • a • 2 O Q. O 2 X n • O 03 in • i a * a < O o V CM CM • • CM • o • a a u o *- in 3 * » • a • <r a o X a H- UJ Q. • a < UJ \ * o

-i a Q • o » a • a a 2 a

2 « cr o O • <r • 2 a • 1/3 * a • — o o * UJ w • a w— to —j • UJ

• o — • O • • u X * < * z

Z • Q a • • # a • • CM • o o • O UJ • a * aa » O • a » o z

2 • z a O a z -J • 2 • — 2 o 2 a 2 UJ Z

m- o o CM UJ a • o UJ

i CM — i a a X o z

03 O X o o

UJ o 2 o < \ a 2

"" O 2 UJ 2 a. 2 x

c

r

cr o 2 2 2 X z X O 03 —

-

—

*

— < o UJ o a a a Z a a U —

•

X a o

UJ o UJ z o < UJ a z

O 03 a <r

33 03

33 03 < rt 2 33 3: o* o n

a —

UJ z >- a a »- >- •— p- to- p- u- p- < to- ta- X v/3 < l/3 m z n n n n n rn 2 in m a in in — x o o »n o < a O o O o O O o o < o o p— a X a 2 a u u u a a a X a a a <n a

< X , o n 2 x

uu UJ a o *- c z >- — mm to- — —- Z •— a —

z a — CJ — X — o — X — — in — mm — z — 2 — < — a —

o a u. -to U. o u. u. O u. U. a a a a a a

04 > o 2 O x o - O a o n o a n a a 2 O < O 2 a Z O

r— X i/3 X U3 X -to X — X 2 X — X < x X a X a X o X — X

UJ to— — mm —

•

— to— mm x — O to- z to— UJ to— to— > — < p— —• p— x a

a z UJ Z UJ z UJ X UJ x UJ —to UJ UJ UJ x a O a a a a to- a X a

03 < o X — X mm x < X a x n X x x < X X X 2 X a x a X n X

1/3 — a a X o z o »— X a

pm o a a a a UJ a a n a z a o — a to- o a o

X O a UJ X uu x ui X uj a UJ 2 UJ UJ a UJ a a a UJ a. a a a —to a

o 2 a mm O *- o to- o - p— mm to- < A— a to- a >- 2 — u- a a *- o — X < — < — < a < < a < CJ < a < < a < mJ < < < <

mmi a ta- 5 a 2 X s mm ^ in 2 2 —to X 2 a 2 O 2 < 2 a 2 2 2 a a in — UJ — UJ — X — x — UJ — to- — <j —

•

* — x — D — x -to O -to — z to- to- p— p— — x — a to— 2 — X to- N a *” a — 2 to- o P— — ta- a o rn z in z m C m o •n O n mj n < n 2 >n 2 n < n z n a in a a UJ -to UJ “ UJ sj UJ UJ UJ > UJ “ a n a a a 2 a n a < a

- CM 03 a a r*to a a O - CM 03

34

THE

COST

OF

PRESCRIPTIVE

COMPLIANCE

FOR

THIS

FIRE

ZONE

IS:

254T22
Exhibit 3.4 Sample Summary of Estimated Retrofit Costs

Part B: Discussion

The purpose of this report is to summarize the cost data used in generating

the bounding solution (i.e., the solution to the continuous linear programming

problem). This report is generated through a call to subroutine PCOSTS. The

first descriptive line shows the location of the fire zone (IFLOR, IZONE) , and

the three construction cost modifiers (CMODT, CMODL, CMODM) . As in the

previous report, each of the 13 building safety features are then listed by

number, I, and label, HPAR(I). The two columns to the right of the building

safety feature name show the input and prescriptive state names (HLAE(Ml),

i i

HLAB ( M2 ) where Ml =j j_ nput and

^ = j presc )* Up to 7 columns are then used as

i i

labels (HLAB(J), J = j max ) t0 s h°w the transition costs which must be

incurred in order to move to a higher state. The estimated values of the

transition costs (C(J), J = 1,56) are stored temporarily in the L vector prior

to output so they are consistent with an integer format. In interpreting the

values, it is necessary to note that the symbol ****** indicates that the

state whose name appears above it is not a permissible retrofit; it is

assigned an arbitrarily high value to prevent its occurrence. The cost of

prescriptive compliance (IPRES) is also output.

35
FIRE

ZONE

SUMMARY

REPORT

Exhibit 3.5 Sample Fire Zone Summary Report

Part A: Printout

©

croo

>- <r TT CO CO <T jo ro © s* CO © © © a ro 3 .2 © © <7 <7 a © ©

- —

-

*T *7 p- 3 <3 — > V 3 © © © © © 3 © © © © © © 3 © 3

k/0 o a 3 JO © 3 3 O — CM 3 CM 2 «• — n o o r- © 0 *7 — © c © CM *7 o 5 CM •0 O *T *T ro ro ro PO — O — 3 CM o v*0 O *7 © © a o T 3 ©

o O T JO 3 *r *7 O cj © r* © ro *7 © — © © P" — o CM — CM CM ro CM ro ro * ro ro <7 CM <7 z a o 3 r* © r- © *7 3 r- 2 <o T7 T ri © © r* © CM CM © <7 UJa © ""

</0 > © © O o o O o © CM CM r* © CM CM a © ro © o © ©

3 o JO — 2

a

a: cm o o o o o O O o O O O ^7 •7 V 'T o 3 3) 3 © © © © o o O

D X JO — © UJZ •. © _ «. ro JO o n ro ro ro ro ro © © © © ro ro n © r* p^ 1 o JO u

cr 3 3 3 2 O 3 3

UJ UJ UJ UJ UJ UJ UJ UJ 3 3 3 3 3 3 •3 C < < < 3 3 3 3 3 2 z 2 z Z z z z Z 2 Z z 2 z 2 2 2 2 2 z z 2 z 3 3 ©

z O o O o o o 3 c o O o o O o O 3 3 3 3 o o O o 3 3 3

cr z z z z z z 2 z 2 2 z z z z 2 o o o o z z z z >— •— -

a

VO 3 3 3 3 ^ ' 2 2 a 3 2 z z z z

UJ UJ UJ UJ UJ UJ UJ UJ uJ 3 3 3 < < < < 3 3 3 3 o o o o 3 3 3 1 X < z z z z 2 z Z z 2 z z 2 2 X X z z z z ISI (SI (Si z z z O o o o o O o o o C o o 3 3 3 3 o o o o 3 3 3 3 o o o

2 >— z z z z z z z z z z z o o o o z 2 z 2 — 3 3 z z z

00 UJa

3 3 3 3 —

-J z z z z z z z z z z Z Z Z Z z Z z Z 2 z z z z z z

< 2 o o o o o o o o o o o o o o O o o o o c o o o o o o

D a: u o o 3 3 u O 3 3 3 3 3 3 3 3 3 3 3 3 3 3 3 3 3 3 3

Z < < —i 3 a o 3 3 Q 3 O 3 O Q o a O 3 O Q 3 3 3 a a 3 o Q 3 . 2 < u. U_ u. ““ u. u_ u. u. 3 3 3 3 “• 3 3 3 3 3 3 3 1

UJ UJ UJ UJ UJ UJ UJ 3 3 3 3 — 3 3 3 3 3 3 b- 3 1 O z c 2 X X 2 2 2 2 2 2 X X X X 2 2 X X X X

uJ > UJ UJ o O O O O O o o o 3 3 O O 3 3 0 0 3 3 O O 3 3 O

£ O • • \ \ \ \ • . \ • . * \ « N

UJ 2 2 X 3 3 3 * 3 3 3 3 X 2 3 3 s - 3 2 2 2 2 S

-j Z Z z Z z z z Z z 2 Z z Z Z Z 2 z Z Z z 2 z z z z Z

UJ O

X cr O »— cr 3 3 2 3 c: 3 3 3 3 3 3 Cl 3 2: 3 3 3 3 3 cr 3 2: cr 3

2 z < <3 <3 < < < < <3 < <3 < < < < < < < < < < < < < < < <

UO o Cm, a. 3 a. 3 3 3 3 3 3 3 3 3 3 3 3 3 3 3 3 3 3 3 3 3 3 • UJ 3

2

< O U. u. u. u. u. u. 3 3 u. 3 3 3 u. u. u. 3 3

Z a: JO UJ UJ UJ UJ UJ UJ UJ UJ 3 3 3 3 3 UJ 3 3 3 3 3 3 3 3 3 3 3 3

< < 3 3 o 3 3 3 3 3 3 3 3 3 3 3 3 3 3 3 3 3 3 3 3 3 3 3

UJ (M UJ

a; < a: O O o O O O O O O O O O O O O O O o o o O O o O O o - C - < z Z z z z z z z Z = z z z z Z z 2 2 z Z z z z z z z . <

UJ o O — z — — CM — — CM CM CM CM — CM —

-

•— — — — — — — — — — — — — — z

> c: UJ 3 o o o o 3 3 3 3 3 3 3 3 3 3 3 3 3 3 3 3 3 3 3 3 3 1 >— UJ a. z Z Z 2 z z Z Z Z Z Z z Z Z Z Z Z z Z Z 2 2 z z Z

UJ > o UJ UJ UJ UJ UJ UJ UJ UJ 3 3 3 3 3 3 3 3 3 3 3 3 3 3 3 3 3 3

<© JO o O O O c c O O c o c o 0 3 C 3 O o o o C c o o 3 3

UJ z o ro JO O o ro ro ro ro ro ro c n © ro o ro © ro o ro © © o © ©

O Z UJ Z O 2 — 3 — 3 3 3 o 3 3 3 •• O — 2 3 c — 2 • 2 * — <S» — Q UJ c o o UJ mj mJ mi c UJ o UJ 3 2 _ 2 3 2 3 2 2 c Q 2 — z 2 z 3 3 3 C 3 C 2 3 z 3 2 c 2 3 2 3 Z 2 z 3 - © c: 7 2 2 2 2 r 5 2 3 2 2 y 2 z 2 5 5 2 2 2 2 2 2 2 2 © <r o o 3 o c 3 C c o c <3 O 3 c C c c c 3 c o c o o 2 2 2 o o CM CM CM CM CM CM CM CM CM O CM CM CM CM CM CM CM CM CM CM CM CM CM CM CM CM o vM 3 o

-J -J •mi —

J

c U — — 3 — — « JO s 3 3 - O -J c

a: *3 O UJ UJ UJ UJ UJ 3 UJ UJ 3 3 3 3 3 3 3 3 3 3 3 3 3 3 3 3

o Q. O O O O o O c O c o o 3 o O o O o O o o 0 O 2 o 3

JO JO 3 3 3 3 3 3 < 3 (23 ro 2 < < < «* 3 3 3 3 < < < < 3 3 3 — 2 3 3 3 3 3 3 < 3 3 3 3 < < < < 3 3 3 < < < < 3 3 3

z O 3 3 3 3 3 3 < 3 3 3 3 < < < < 3 3 3 3 < < < < 3 3 3 — O 3 3 3 3 3 3 < 3 3 2 3 < < < < 3 3 3 3 < < < < 3 3 3

u. a: = X

JO UJ < < < < <3 < < <3 <3 vt < < < < < < <J < < < < < < < < < — *3 < < < < < < < < < < < < < < < < < < < < < < < < < < z ac <3 < < < < < < <3 < < < < < < < < < < < < < < < < < < — o < < < < < < <3 < < < < < < < < < < < < < < <S < < < <

a: a: 03 cr

J uj O O oo < uj O

3 3 a: 3

Q. aj p- ui ui

2 2 2 2 2

a- a- 3 3 3 Z Z

UiOiOJUJUJUiUiUJ CC3000000 .-iQnnnnnnn

3 -0303333

Q

- C i 3 z

2 2 2 COO CM CM CX

2 2 2 x x x 3 3 3 3

<<<<<<<<<

<r© 22222222222222522222222222252222222 z oooocoocoooocoooocccoccoooooooooooo O 30333333333333333333303333333333333 o zzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzz

36

ENC-tH

SCI

IN

PARTIN

W/OH*

E

FO

CON

NONE

TTLBLD

S

4

3

ft

32UI
Exhibit 3.5 Sample Fire Zone Summary Report

Part B: Discussion

This report shows all of the distinct solutions generated for the fire zone under study; it is generated through a call to subroutine PRTZON. Upon entry

to subroutine PRTZON, the ISRT matrix contains all distinct solutions sorted

by design classification. A given row of the ISRT matrix, K, contains all

data required to characterize the solution. The first descriptive line shows

the fire zone location (ISRT(K,14) and ISRT(K,15). Each of the 13 building

safety features are then listed followed by the 4 safety requirements. The

estimated cost to comply is presented in the last column. The name of the

post retrofit state (HSTAT(I), 1=1,13) for each of the 13 building safety

features are listed beneath the appropriate column heading. Each solution

takes up one line of the output. The surpluses over the required score for

containment, extinguishment, people movement and general safety are then

recorded (ISRT(K, 16) , . .

. , ISRT(K,19)). The order in which the solutions are output is based on the 40 design classifications (see table 2.1). All

solutions are ranked and printed out in ascending order of cost (ISRT(K, 22) )

.

The program then outputs the solution(s) for the next design classification

for which at least one solution was generated until the list is exhausted.

The prescriptive solution is then output. Solutions which do not fit a design

classification are then ranked and printed out according to whether they have

no deficiencies, a single deficiency, or a double deficiency in hazardous

areas

.

37
TOTAL

BUILDING

SUMMARY

REPORT

Exhibit 3 .6 Sample Total 3uilding Summary Report

Part A: Printout

> e* ci

*— _j o J n

tO O C. T O J) o *- 2 «n u oo

z o <7> r» O VI —

lOx > n

-J 2 to

CM O O O

a£ K CN X UJ tO

Ul ® O O O

z - *- 03 o o) u to — n (X as

03 -J < UJ UJ UJ o SC X Z Z Z n Z z o o o

a o z z z

a o

to

f*

cm 2

03 UJ -J UJ UJ UJ ul

•• cm SC < z z z z

vo o o o o o o — 03 2 >

vO UJ z z z z

Z a

oM -j z z z z

F- < 2 o o o o

< - X cr ouuu to (J cO z < 3 M » < -j o o o o

O u. 2 < U. U. U. U. -j — o -j a: to z O -J - cO — UJ - UJ UJ UJ UJ

u. ac X < a O Z * * • Z a. -j -j cs 2 X X X X

tO cc z u — UJ > o o o o

<

toa -

Z X

03 uj2 O

2 W\N 2 3 3 2

wu o

cc 2 — cO < UJ -j to — _j z z z z

* < X UJ X uj O F— - - F—

to o CL X h- a: 2: ^ —

to 2 >— z O — z z z z

< <o a to a: 2 Z < < < <

-j - o O o a a a a. u X U. o

UJ UJ

to O z • UJ a u u u u. — a: 2 21 * u Z to UJ UJ UJ UJ X uj > o z < < q a o a

2 O O u. < (S4 UJ

UJ 2 z — < Z o o o o

z O -J X < z z z z o Z a. UJ

u. CO o - 2 *2

UJ Z r> Q O < U O X X X X o z UJ -J U z — z — — CM CM

cc o 2 a »- z • • I • UJ NJ UJ X UJ UJ Z UJ U U (J (J — o o CD > z ui a z z z z

u. •U X > o UJ UJ UJ UJ

UJ F-

-j a: X a. < < — CO •— «-« uj to o o o o

X <0 cc u. uj Z 03 03 03 0 O Z CO o u Z uj ~ — V » o UJ Z to >02 * o

uj CJ 2 — UJ N- FS4 — O O O UJ —

j

>— Z uj Q z z z o

a - Q. u. < a CO Cl- — < — z < uj u. u» to to z 2 2 2 2 z < UJ a o o z O o o o o

< /SI Z a: a o u CM CM CM CM > < < O — z c

z UJ to - o o V- - F- -

Z as O o f- -J -1 -J -I o u

u. M

to O -J x z to z z z z

UJ < z o -» X X X X Q O 2 O o z -• UJ o — o — UJ UJ UJ UJ X u u a o o o a

UJ < »—

<o to <1 < 33 03 o - 2 < o a a

•— z o < < a a

— o < < a s

UJ u. z

X X

to UJ < < < < — < < < < z z < < < < - o

u. CJ < < < <

z z z z z

to 2 2 2 2 z o o o o

o uuuu u z z z z M z «. — ^

-j <r — — cm n

u» O •

38

NCOM

•H

AAA

A

8

UBB

GE

THR

LT

20M

0

£

0*30

ENC2

H

NO

DEF

PARTTN

W/OH*E

FO

CON

NONE

NONE

3007

13074
Exhibit 3.6 Sample Total Building Summary Report

Part B: Discussion

This report shows the solution for the entire building based on a prespecified

design classification; it is generated through a call to subroutine PRJBLDG.

Upon entry to subroutine PRJ3LDG-, the ISTK matrix contains the least-cost

solution for each of the 40 design classifications for each fire zone in the

building. ISTK(K,20) is then checked to see if a given design classification

was generated for all fire zones. If a perfect match occurs, the solution for

the entire building is printed. The first descriptive heading shows the

design variable qualifiers for this design classification (HOUT). The total

cost of retrofitting the entire building to this design classification (KOST)

is then given followed by the cost of prescriptive compliance (KPRES).

Information on the location of the fire zone (ISTK(K,14) and ISTK(K,15)), the

post retrofit state (HSTAT(I), 1=1, 13) for each of the 13 building safety

features, the surplus over each of the 4 safety requirements

(ISTK(K, 16) , . . . ,ISTK(K, 19) ) , and the estimate cost to comply (ISTK(K,22)) are then printed out. Each fire zone takes up one line of output.

39
The remainder of this section will deal with error messages. In order to

address the everyday problems of incorrect formatting, recording and

sequencing, FSESCM has an elaborate system for edit-checking the values of

key input variables. If an error is encountered, then a message is printed

out to the user which should help to locate and correct the error. There are two basic types of error messages: (1) those which FSESCM treats as fatal for

the building under analysis; and (2) those which result in the setting of

default values. A third type of error relates to the message generated within

the revised simplex (RVSMPX) subroutine. Since all entries to the constraint

matrix are constructed within the MAIN program based on data from the SETUPA

COMMON, no errors on input should affect the feasibilty of the application

problem. The full range of RVSMPX error messages are included primarily as an aid to debugging should it be necessary to modify the FSESCM source code due

to changes in the Life Safety Code or peculiarities of the operating system.

The subroutine may also be uncoupled from the model for use as an optimizer in

other applications.

The discussion of FSESCM generated error messages which follows is designed to

be reasonably comprehensive but should not be considered exhaustive. The

diagnostic associated with each error message is presented first. The routine

which generated the message is then identified. The action taken by the

program and the data output are then given. Recommendations for ways in which

the problem may be corrected are also given.

It is important to point out that the discussion which follows is limited to

first-order effects. If a non-fatal error (type 2), in which a default value

is set, is followed by a fatal error (type 1), then both errprs should be

analyzed carefully for a possible relationship. In particular, a default

setting to correct for an earlier error may result in a sequencing problem

which triggers a fatal error. In every case where a fatal error is

encountered, there should be sufficient information to easily locate the card

which caused the problem. Non-fatal errors which do not require treatment

should be subjected to close scrutiny to insure that the interpretation of the

problem is not rendered meaningless.

Type 1 Errors

Diagnos tic:

Routine

:

Action:

NO SATISFACTORY SOLUTIONS ENCOUNTERED

MAIN

Analysis of current building terminates. Subroutine SEARCH

is called to locate where data on the next building starts.

Data Output: None

Remedy

:

Output from RVSMPX is abnormal. Check application problem

and input data.

Diagnostic:

Routine

:

Action:

SAPETY REQUIREMENT OUT OF RANGE

MAIN

Analysis of current building terminates. Subroutine SEARCH

is called to locate where data on the next building starts.

Data Output: None

Remedy: Check the value of the first integer variable, II, after the

command REQUIR on this control card. II must take on a value

between 1 and 4.

40
Diagnostic:

Routine:

Action:

Data Output:

Remedy

:

USER MOD INCORRECT

MAIN

Analysis of current building terminates. Subroutine SEARCH

is called to locate where data on the next building starts.

Command on control card (HIN) plus option qualifiers

(11,12,13).

Check the value of the command on this control card against

those given in table 2.3.

Diagnostic

:

Routine

:

Action:

Data Output:

Remedy

:

Diagnostic:

Routine

:

Action:

Data Output:

Remedy:

PARAMETER CARD INCORRECT

MAIN

Analysis of current building terminates. Subroutine SEARCH

is called to locate where data on the next building starts

.

Building safety feature number as read.

Check application problem and input data. An improper

setting of the input state for a building safety feature can cause this problem. Check for missing cards.

THE VALUES ON CARD AFTER THE ERROR

ARE:

SEARCH

Analysis of current building terminates. This subroutine

searches through the data file for a LAST or FINAL command.

Card number in sequence (1-20) and its values in alphanumeric

(A6, A72) formats.

Use output to locate the card which caused the error. Additional diagnostics will also be available.

Diagnostic:

Routine

:

Action:

Data Output:

Remedy

:

Type 2 Errors

AN ATTEMPT TO RELAX A SAFETY REQUIREMENT IS BEING MADE

MAIN

None

None

None is required but it would be advisible to verify that

relaxing (reducing) the safety requirement was the intent of

the user.

Diagnostic

:

Routine

:

Action

:

Data Output:

Remedy

:

BUILDING SAFETY FEATURE OUT OT RANGE

MAIN

The incorrect value is set to a default value of either 1 or

13.

None

Check the value on the first integer variable, II, after the

command CHANGE on this control card. It must take on a value

between 1 and 13.

41
Diagnostic:

Routine

:

Action:

RETROFIT STATE OUT OF RANGE

MAIN

The incorrect value is set to a default value of either 1 or IT4M(I) where I is the building safety feature number.

Data Output:

Remedy

:

None

Check the initial settings of the state variables read into

IT4X(I). Check the value of the second integer variable, 12,

after the command CHANGE on this control card. Both 12 and

IT4X(I) must take on values between 1 and IT4M(I).

Diagnostic:

Routine

:

Action:

BUILDING TYPE QUALIFIER OUT OF RANGE

MAIN

The incorrect value is set to a default value of either 1

Data Output:

Remedy

:

(hospitals) or 2 (nursing homes).

None

Check the value on the seventh card for this building in the

data file. ITYPE must be either 1 or 2.

Diagnostic:

Routine

:

Action

:

BUILDING AGE QUALIFIER OUT OF RANGE

MAIN

The incorrect value is set to a default value of either 1

Data Output:

Remedy

:

(new single story) or 4 (existing multistory).

None

Check the value on the seventh card for this building in the

data file. IBLDG must be between 1 and 4.

Diagnostic

:

Routine

:

Action:

Data Output:

Remedy:

PARTITION QUALIFIER OUT OF RANGE

CZODIM

The incorrect value is set to a default value of 0.

None

Check the value on the first card for the sixth building

safety feature (zone dimensions) for this fire zone. IPART

must be either 0 or 1.

Diagnostic:

Routine

:

Action

:

Data Output:

Remedy

:

DEFICIENCY QUALIFIER OUT OF RANGE

CHAZAR

The incorrect value is set ot a default value of 0.

None

Check the value on the first card for the eighth building

safety feature (hazardous areas) for this fire zone. Each

of three deficiency qualifiers must take on values of either

0 or i

.

42
Diagnostic:

Routine:

Action:

Data Output:

Remedy:

Diagnostic:

Routine

:

Action:

Data Output:

Remedy

:

SPRINKLER DESIGNATION OUT OF RANGE

CSPRNK

The incorrect value is set to a default value of 2 (wet

concealed) . None

Check the value on the first card for the thirteenth building

safety feature (sprinklers) for this fire zone. The

allowable values are 1 through 4.

WATER SUPPLY DESIGNATION OUT OF RANGE

CSPRNK

The incorrect value is set to a default value of 3 (unknown)

.

None

Check the value on the first card for the thirteenth building

safety feature (sprinklers) for this fire zone. The

allowable values are 1 through 3.

3.2 MODEL TEST RESULTS

The purpose of this section is twofold. First, it provides a description of

activities carried out to insure model portability and summarizes run times

experienced. Second, it includes a description of the validation activities

used to insure that the model does in fact what it should do (as stated in the

documentation) . The second issue is included because model builders are becoming more aware of the need for a coherent means of validation. Such

activities, especially with regard to third party assessments, are summarized

in a series of papers dealing with energy models. ^ The discussion of model

validation in the latter part of this section will draw on the information

contained in the above-mentioned report

.

The issue of model portability was addressed in two ways. First, the model

was written in FORTRAN for which a nationally accepted standard exists.

FSESCM was written in FORTRAN 77 and tested extensively against the ANSI

standard. ^ The model is designed to be run on any system which: (1) complies

with the X3.9 ANSI standard; and (2) can accomodate an intermediate-sized

program. FSESCM complies with the full FORTRAN 77 standard. Compliance with

the subset standard would require at a minimum the elimination of the BLOCK

DATA routine. Since no testing to the subset standard was carried out,

^P.3. Saunders, editor, Selected Assessment Strategies Applied to Short-Term

Energy Models , National 3ureau of Standards, NBSIR 83-2672, March 1983.

-American National Standards Institute, American National Standard Programming

Language FORTRAN

,

ANSI X3.9-1978, New York, 1978.

43
detailed specifications for compliance with the subset standard are not

available from the model developers. Compliance with the subset standard may

not prove to be a problem, however, since programmers familiar with the host

operating system can take advantage of special features which may not be in

the standard. Second, the model was tested independently on two types of

hardware with different word lengths and memory capabilities. In all cases

the solutions produced by the model were identical. In order to increase the

likelihood that the model is portable, a test case with solutions for

comparison is included with the source code whenever a request for the model

is made.

A wide variety of test problems were run on a Sperry Univac 1100/82 and a Perkin-Elmer 3242. Both sets of runs were designed to test for portability

and to provide information on the time it takes to analyze: (1) a single

fire zone; (2) a single building; and (3) a batch of buildings. In estimating

the run time on a machine, it is important to point out that the initial

conditions of a building's fire zones must be critically analyzed. If all

fire zones are in poor condition, then the optimizer is called more frequently

and more alternative solutions are generated. Since the model uses an initial

basis for all but the first call to the optimizer for a given fire zone, the

subsequent calls will generate solutions quickly. Thus computation time for a particular fire zone should be nearly linear in the number of alternative

solutions. The test case building contained four fire zones, two of which

could be considered in poor condition.

All preliminary developmental work on the FSESCM model was done on a Sperry

Univac 1100/82. This machine is the NBS mainframe computer; it has a 36-bit

word. When the model was run on the Univac; it had a memory requirement of

43,000 words. The time to analyze a typical building on this machine ranged

from 30 to 60 CPU seconds.

The Perkin-Elmer 3242 is a second generation mini computer; it is used by

NBS's Center for Fire Research for a wide variety of applications. The

Perkin-Elmer has a 32-bit word. When the model was run on the Perkin-Elmer,

it had a memory requirement of 154 kilobytes. Two versions of the model were run on this machine: (1) a standard version which was compiled without

options; and (2) an optimized version of the source code. For the first

version, run times averaged approximately 3 CPU minutes. For the second

version, run times ranged from 40 to 90 CPU seconds per building. Thus, if a mini computer is used and a code optimization option is available on the

compiler, it may be wise to use it. This would especially be true if the

system were supporting several users and a large number of buildings are to be

batched together'.

The validation of a complex model aims at demonstrating that the model bears a close resemblance to the physical system. The validation process is, in

reality, three separate tasks: (1) technical validity; (2) operational

validity; and (3) dynamic validity. Since program documentation provides a basis from which the validity of the model can be assessed, it will be

discussed prior to the three major tasks of the validation process.

44
Documentation

From a model user’s point of view, documentation (the written description of

the model) is essential if the model is to be useable, useful, and used.

Since the abstract model is a mathematical representation whereas the

operational FSESCM model appears as a computer code, it is necessary to verify

that there exists a unique relationship between the abstract (mathematical)

model and the operational model. The relationship between the abstract and

operational model can best be understood through reference to section 2.1.

There it was shown how FSESCM was related to the FSES developed by NBS’s

Center for Fire Research. Documentation also requires that portability be

established (not just that the program can be run on a variety of machines,

but that it produces the desired result) . Portability in that sense was the

subject of the earlier discussion. Documentation also serves to explain all

relevant relationships between inputs, outputs and analysis. The model's

documentation also should provide some measure of user friendliness . Complex

models often involve subtle techniques which, in the absence of a buffer

between the user and the model, could cause frustration and lead to a highly

inefficient use of the model. Documentation and an executive code (e.g.,

extensive edit-checking and message generating capabilities) should serve to

shield the user from unnecessary detail without withholding any information

which is essential to confidently use the model. The FSESCM model addresses

this issue through reference to three reports: (1) an extended executive

summary; (2) the User's Manual; and (3) the Programmer's Manual. Each report

discusses -a particular aspect of the model. These aspects are (1) management;

(2) application; and (3) operation and maintenance. Each report is designed

to be self contained. Where necessary, connections between the reports are - given. The source code provides ample information to users so they can find

and correct errors in their file. The source code also contains extensive

comments and a glossary of terms for each routine, should it become necessary

to make changes to the source code. This subject is covered in great detail

in section 4.2.

Technical Validity

Technical validity requires the identification of all model assumptions,

including those dealing with data requirements and sources. As a first step, one should identify all stated and implied assumptions, all decision

variables, and any hypothesized relationship between variables. This step

sheds light on the correspondence between the model and the real world

phenomena it attempts to explain. Three types of assumptions may be readily

defined. First, the mathematical assumptions include its functional form and

the continuit]? of its relationships (e.g., the linearity of the model). A

second type, content assumptions, define all model terms and variables. They

should also define the scope and limitations of the model. (This topic will

be discussed at the end of the chapter.) The final type, causal assumptions,

are concerned with the assumed or hypothesized relationships between terms and

variables (e.g., the way the safety scores are calculated).

45
Ideally, one would like to build a model which would produce true conclusions

whenever all of the assumptions are true. To translate such abstract concepts

into a form which is concrete and testable, it is necessary to:

(i) determine if the model's calculations are correct and accurate;

(ii) analyze if the logical flow of data and intermediate results are correct and consistent; and

(iii) ensure that variables and relationships have not been omitted.

Establishing the correctness and accuracy of the calculation and solution is

directly related to the formulation of the problem. As mentioned earlier, the

problem formulation is tied directly to the version of the FSES which was formally adopted into the Life Safety Code. The edit-checking routine which

has been built into the model should ensure that infeasible problems do not

reach the optimizer. The revised simplex (RVSMPX) routine has been thoroughly

tested and used extensively for over ten years. It is therefore unlikely that

it would produce incorrect or inaccurate solutions. The integerization

routine (INTSOL) combines data from RVSMPX with a straight forward approach to

impose integrality.

The second issue relates to the basic philosophy behind FSESCM. Since the

objective is to minimize the cost of compliance, where some factors which

affect the decision makers choice may not be known, it was necessary to define

classes of solutions. This problem is approached by first generating a bounding solution for the fire zone. The bounding solution is then used as a starting basis for all subsequent calls to the optimizer where the alternate

solutions are generated. Solutions are then assigned to a design

classification and sorted. All solutions for a fire zone are then output.

The best solution from each class is saved and the next zone is analyzed.

This continues until all fire zones have been analyzed. All fire zones are then screened to see if a match within a design classification exists. If so,

these solutions for the entire building are ranked by cost and output.

The third issue relates to the treatment of costing and interdependencies.

Since the objective is cost minimization, it is essential that all costs be

reasonably correct and accurate. Design specialists worked with the model

builders to identify a candidate set of critical elements which span all

possible transitions in FSES Table 4. This exercise resulted in a worksheet

which is contained in the User's Manual along with directions for completing

it and transferring the data to the user's data file. A general purpose or one of five special purpose subroutines, then calculate the transition costs

for the building safety feature under consideration. The effect of

interdependencies is assessed in subroutine INTSOL. Interdependencies are treated as part of the post-optimalitv analysis because including them in the

application problem could have complicated the process of integerizacion . As

such, larger surpluses may result. A series of tests is used to insure that no solution which violates a constraint (i.e., renders the problem infeasible)

due to an interdependency can be passed to the packing routine (TNPSOL)

.

46
Operational Validity

Operational validity is concerned with whether or not the model can produce

bad answers for proper ranges of parameter values {i.e., the model should be

robust in that a user would find it difficult to make the model yield (in

terms of the decision maker) an ostensibly wrong answer) . Sensitivity

analysis, is related to, but distinct from, robustness. This technique seeks

to systematically vary the values of the model parameters to determine how

much (i.e., how sensitive) the solution changes. The state-forcing loops and

the user options CHANGE and REQUIR address these issues.

The last aspect of operational validity and the most difficult is

implementation validity. Implementation validity is concerned with the extent

to which the real world system being modeled will respond in a manner

indicated by the recommended solution. This task is difficult because if a decision maker kn'ew how the system would respond to a given change in a parameter or decision variable, there would be considerably less need for a model. Implementation validity has been addressed in an informal matter.

Since the model has not been released to the general public (at the time of

this writing), it is impossible to state definitively whether its results will

merely vindicate engineering judgment or provide genuine insight. Discussions

between the model builders and a small group of design professionals, strongly

indicate that the model will increase the productivity of the engineering

staff by enabling them to carefully weigh the benefits of a large, but well

defined, set of solutions.

Dynamic Validity

Dynamic validity is concerned with determining how the model will be

maintained during its life cycle so it will continue to be an acceptable

representation of the real system. The two aspects associated with dynamic

validity are updating and review. Both subjects will be discussed in section

4.2. In updating, the person incorporating the changes needs to be satisfied

that the model developers have established a procedure by which information is

collected and analyzed to determine if and when model parameters or model

structure needs to be changed. It is also important that a process exists by

which such changes can be incorporated into the model and disseminated to

users. A regular schedule for reviewing the success or failure of the model

during its life cycle is also necessary. These reviews should be carried out

regularly and should focus on documenting any systematic divergences between

the solution predicted and the actual outcomes. The implications and means of

accomplishing any proposed model changes should also be commented on.

Program Limitations and Qualifications

The program does have several limitations which may be important in certain

instances. First, the costing procedure used in the model is limited to the

costs of installing (including any demolition and removal costs) all possible

combinations of the fire safety measures defined in FSES Table 4.

Consequently, any costs which are not construction related (e.g., lost

revenues, future operations and maintenance costs and insurance differentials)

47
are not included in the procedure. If these costs are deemed sufficiently

important, a life-cycle cost analysis of the alternatives which result from

this procedure should be performed. The accuracy of the costs presented by

the model should be sufficient to discriminate among alternative solutions;

however, these costs should not be used as a firm figure for actually carrying

out the work.

Second, FSESCM does not contain a procedure for estimating the costs of

mechanically assisted smoke control systems. Thus, if a transition to the

mechanically assisted by zone state is desired, the user must input a cost

estimate via the CHANGE option (see table 2.3). A similar limitation exists

for the direct exit state for emergency movement routes. The user can,

however, input a cost estimate by using the CHANGE option. If these

modifications are deemed important, it would be desirable to prepare a special

purpose subroutine to handle each one.

Next, there are two states listed in FSES Table 4 which the model treats as impossible; they are cases where a hazardous area has either a double or single deficiency outside the fire zone. These states are precluded because

the entire cost of upgrading the deficiency is allocated to the fire zone where the deficiency occurs. If the costs can be satisfactorily allocated,

say through a judicious change in subroutine CHAZAR, then no ambiguity would

exist and these states can be analyzed as potential retrofits by the

optimizer. No such allocation scheme was, however, evident to the builders of

the FSESCM model.

Finally, givdn the current procedure for insuring the compatibility of a set

of designs for the entire facility, a limitation of 10 fire zones for any one building is imposed. The maximum of 10 can be increased however, by merely

increasing row dimension of the ISTK matric and resetting the upper limits on its associted do loops. ^ For some specific uses, the way in which alternative

solutions are generated may not provide enough flexibility. In such a case, a modification to the program code will be required. Persons wishing to modify

the way in which the alternative solutions are generated should carefully

follow the directions given in section 4.2.

*ISTK is contained in the RESET COMMON storage block; it is passed as an argument from the MAIN program to the following subroutines: INSETS; STXSOL;

and PRBLDG.

43
4. SOFTWARE EXCHANGE

4.1 TRANSFER MEDIUM AND CONTENTS OF FILES PROVIDED

The preferred transfer medium for the model is 9-track magnetic tape. All

tapes provided by NBS will be written in either ASCII or EBCDIC. The request

for the source code should specify which bit configuration is required for the

user's operating system. All tapes provided by NBS will be unlabelled. The

2400 foot real will be recorded with a density of 1600 frames per inch (FPI).

Since one of the files recorded on the tape is the test case output, a logical

record length of 132 characters is used throughout. A fixed block length of

1320 characters is also used. Table 4.1 summarizes the information on magnetic tapes.

Table 4.1 Specifications for Transfer of 9-Track Unlabelled Magnetic Tapes

Characteristic Specification

Bit configuration ASCII or EBCDIC

Density 1600 FPI

Logical record length 132 characters

Block length 1320 characters

Software exists at NBS for producing either ASCII or EBCDIC punched card code.

NBS will therefore provide a deck of punched cards if such a request is" made.

Since the deck will consist of only the source code and data files discussed

below, punched cards should only be used when no compatible magnetic tape

equipment is available on the user's operating system.

Whenever a request for the FSESCM model is made, the tape sent to the

requestor will contain four files. These files contain: (1) background

information; (2) the FSESCM source code; (3) a test case "User Data File"; and

(4) the test case output file.

The first file contains a table of contents of the tape. It describes what is

in each file and how the three remaining files relate to each other. It will

also contain information on what portions of the model have been updated and

the reason for the change since the publication of the User's Manual and

Programmer's Manual.

The second file contains the FSESCM source code. The MAIN program and all

subroutines are written into a single element. The file name is FSESCM; the

element name is OPTI. The programmer is free to choose which compiler options

are to be used. As noted earlier, it may be advisible to exercise the code

optimization option if such an option is available on the host system.

The third file is a test case "User Data File". It contains a known correct

set of data for use in initial testing on the host system. Once these tests

have been performed, it is recommended that this file be provided to users so that they can check out their knowledge of the model with a known set of input

data. Similarly, users can duplicate the data file and through an editor

49
introduce errors to test their troubleshooting skills. This file is

thoroughly described in the User's Manual where it is used to illustrate how

the model operates. Guidelines for constructing the file based on the FSESCM

worksheets are also given.

The last file contains a complete set of solutions to the problem defined by

the test case data. The primary purpose of this file is to insure model

validity across operating systems. Two major points of comparison between

this file and that generated by running the test case file are:

(1) the order and characterization of the solutions contained in the

Total Building Summary Report; and

(2) the transition costs for each fire zone, especially with regard to

their relationship with the Fire Zone Summary Report.

4.2 PROVISIONS FOR UPDATING OR MODIFYING THE SOURCE CODE

Although the procedure described in this report focuses on the 1981 edition of

the Life Safety Code, it is natural to expect that some changes will occur as the code is periodically revised. Any changes which occur in future editions

of the Life Safety Code will thus entail changes to the FSESCM computer

program. The nature of the change will determine the ease with which program

modifications can be made. At this time three types of changes are envisioned. In an increasing order of complexity these changes are: (1)

increasing or decreasing one or more of the state values; (2) adding a new

state to a given building safety feature; (3) adding a new building safety

feature. (Although shortcuts may be possible, decisions to delete a state or

a building safety feature would be of a similar level of complexity as those

changes denoted as (2) and (3), respectively.) A fourth type of change is

also possible; it relates to the way in which the design classifications are defined and generated. The complexity of this type of change is similar to

the levels associated with types (1) and (2), respectively.

The design of the FSESCM model was kept deliberately simple. Where, in the

opinion of the model developers, the potential for change existed, the clarity

of the logic flow dominated all other considerations. This may have resulted

in some reduction in computational efficiency, as indicated by the run time

statistics from section 3.2, but since much of the packing and unpacking of

solutions involves integer operations the tradeoff between efficiency and

clarity seems justified. In the discussion which follows, it should be kept

in mind that the model has already undergone one major change. This change

was initiated because a preliminary version of the model had been coded to the

1973 edition of the Life Safety Code. This version of the Life Safety Code

was used by Nelson and Shibe to illustrate the potential for the FSES. Since

the 1981 edition of the Life Safety Code adopts a variant of the Nelson-Shibe

FSES as an alternative to prescriptive compliance, It was decided to adapt the

model to the official version. The incorporation of the 1981 edition of the

Life Safety Code, along with a number of recommendations by design

professionals, required the model builders to exercise almost the full

spectrum of changes just described. The guidelines which follow can thus be

considered reasonably comprehensive but should not be viewed as exhaustive.

50
Given a change in the Life Safety Code, the programmer is faced with two

courses of action. The first would be to obtain an updated version of the

model directly from NBS. If the changes in the Life Safety Code are substantial, this approach would seem preferable. The second would require a programmer to incorporate all model changes on the user’s system. Should this

approach be adopted, the information in tables 4.2 and 4.3 should be studied

carefully prior to making any changes. Table 4.2 lists all major arrays and

shows for each type of change whether that variable will be affected (yes),

may be affected (?), or will not be affected (no). Table 4.3 provides the

same information for each subroutine. This information is supplemented by the

glossary of terms (appendix A. 2) where all subroutines within which a given

array appears are listed. It is important to note that the changes in the

RVSMPX routine are limited to the sizes of arrays as defined in the DIMENSION

statement. No other changes should be required. In RVSMPX, as in all other

subroutines, the arrays are fully dimensioned. This approach was taken so that operating system debugging options could be employed as an integral part

of the change to insure that such inconsistencies as attempting to reference a non-existent element in an array due to an incorrect setting on a DO loop

could be easily detected.

In interpreting the information in tables 4.2 and 4.3, two points should be

kept in mind. First, the modular design of the FSESCM model reduces most

subroutines to 100 lines or less. Thus areas where changes are needed (or

where errors occur) should be easy to find. Five routines are well over 100

lines; they are: (1) MAIN; (2) BLOCK DATA; (3) RVSMPX; (4) INTSOL; and

(5) STKSOL. It is worth noting however that the changes to be made in the

BLOCK DATA routine should be apparent from the context and any changes to

RVSMPX are minimal. The three remaining routines will require some preplanning and attention to detail. Second, the responses in the table serve

to focus attention on general topics. For certain specific cases, the changes

may be significantly more complex than those of a general nature. This is why

so many arrays and subroutines have question marks (?) associated with them

indicating that a change may be required. In approaching these problem areas,

as well as for the general case, one should pay special attention to:

(i) ranges on DO loops;

(ii) tests for branching based on logical IF statements, and

(iii) resetting of values within an array.

Referring now to table 4.2, the first column shows the variable name and

current size, the second column its type, and the third through sixth columns

characterize the nature of the change.

^All information contained in tables 4.2 and 4.3 are with respect to FSES

Tables 4 through 6. If modifications to FSES Tables 1 through 3 are required, then the problem is much simpler, all data for this situation

relate to: HT1 ; IT1M; IT1X; and T1 . The only routines which may require

changes are therefore MAIN and BLOCK DATA.

51
The first type of change, modifying one or more state values, is the easiest

to incorporate. Changes will definately have to be made to the G matrix, the

analogue of FSES Table 4. However, a number of other changes may be required

should this modification affect the computation of one or more of the safety

requirements (FSES Table 6). Modifying a state value may also change the

ordering for the states for building safety feature 1 or 8. It is also

necessary to check if any interdependencies among building safety features are affected and if so adjust them to reflect the new value(s).

If a state is added (subtracted) , then all changes described earlier would be

in effect, there would also be a need to redimension certain arrays. Examples

of arrays which require redimensioning include: A; C; HLAB; and IST4. The

indices of certain DO loops will also be affected. For example, the index on the second state-forcing loop in the MAIN program will have to be increased

(decreased) . If a new interdependency comes into play (or an existing one requires modification), then logic must be incorporated to insure that all

penalties or bonuses are properly recorded.

The addition (deletion) of a building safety feature is the most complicated

change envisioned. This modification affects FSES Tables 4, 5, and 6. It

Incorporates all changes discussed so far. It also affects the first two

state forcing loops and may have a significant impact on the third (design

classifications). Many arrays will have to be redimensioned, including:

IPAC; ISRT; and ISTK. The use of a debugging option is recommended.

A modification of the way the design classifications are generated is limited

to several well-defined areas of seven subroutines. As a first step, the

major arrays (HOUT, IEC1 and IEC5) in the BLOCK DATA routine must be

reconstructed. Depending on the outcome of this exercise, the third

state-forcing loop in the MAIN program will have to be revised. The

assignment of solutions to the various design classifications made in

subroutine DESCLS will have to incorporate this new logic. The same is true

for the way in which individual fire zones are sorted (SRTSOL), printed in the

Fire Zone Summary Report (PRTZON), and stacked (STKSOL) . Finally, the logic

for sorting and printing the Total Building Summary Report (subroutine PRBLDG)

will have to be modified.

Table 4.3 summarizes the information from the previous text and table 4.2

showing how it affects each of the routines. As mentioned earlier, the nature

of the change will dictate how closely the routine must be scrutinized prior

to any attempt to modify the code.

52
Table 4.2 Source Code Modification for Key Variables

ARRAY SPECIFICATION TYPE OF CHANGE

NAME OF

ARRAY

TYPE OF

ARRAY

STATE

VALUE

ADD/

SUBTRACT

STATE

ADD/

SUBTRACT

BUILDING

SAFETY

FEATURE

DESIGN

CLASSIFICATION

A( 18 , 61

)

REAL NO YES YES NO

B( 19 , 19) REAL NO NO YES NO

G ( 56

)

REAL NO YES YES NO

CPUL( 13 , 7,10) REAL NO YES YES NO

CPUM( 13 , 7,10) REAL NO YES YES NO

CPUT( 13,7,10) REAL NO 7 YES NO

G( 13 , 7) . REAL YES YES YES NO

HLAB( 57) CHARACTER*? NO YES YES NO

H0UT(40) CHARACTER*45 NO 7 7 YES

HPAR( 18) CHARACTER* 30 NO NO YES NO

HSTAT( 13) CHARACTER* 30 NO NO YES NO

IEC1 (40) INTEGER NO 7 7 NO

IEC5(40,5) INTEGER NO 7 7 YES

IECC0N(4, 7) INTEGER NO ? 7 NO

IECDBL(3 ,5) INTEGER NO 7 7 NO

IECHAZ(3 ,5) INTEGER NO 7 7 NO

IECN0S(3 ,5) INTEGER NO 7 7 NO

IECSM0(5 ,5) INTEGER NO 7 7 NO

IECSPR(7 ,3) INTEGER NO 7 7 NO

IECT( 44) INTEGER NO 7 7 YES

IECYES(3 ,5) INTEGER NO 7 7 NO

IECZDM( 7,6) INTEGER NO 7 7 NO

INELT( 7 ,10) INTEGER NO 7 7 NO

IPAC( 100,22) INTEGER NO 7 YES .7 ISRT( 100,22) INTEGER NO 7 YES 7 IST4( 56 ,2) INTEGER NO YES YES NO

ISTAT( 13

)

INTEGER NO NO YES NO

ISTK( 500 , 22

)

INTEGER NO ? YES 7 IT4A( 7

)

INTEGER NO 7 7 NO

IT4B ( 7

)

INTEGER 7 7 7 NO

IT4M( 13

)

INTEGER NO YES YES NO

IT4S( 13 ,2) INTEGER NO YES YES NO

IT4X( 13) INTEGER NO NO YES NO

IT4XA( 13) INTEGER NO NO YES NO

IT8 ( 5) INTEGER 7 7 7 NO

JPR( 13 , 8) INTEGER NO 7 YES NO

K0ST( 4 1

)

INTEGER NO 7 7 YES

LCU( 13) INTEGER NO 7 YES NO

T48A(5) REAL 7 7 7 NO

T4A( 4,7) REAL 7 7 7 NO

T4B (4,7) REAL ? 7 7 NO

53
Table 4.2 Source Code Modification for Key Variables (Continued)

ARRAY SPECIFICATION TYPE OF CHANGE

NAME OF

ARRAY

TYPE OF

ARRAY

STATE

VALUE

ADD/

SUBTRACT

STATE

ADD/

SUBTRACT

BUILDING

SAFETY

FEATURE

DESIGN

CLASSIFICATION

T6A(3 ,2,2) REAL ? ? YES NO

T6B(3 ,2 ,2) REAL ? 9 YES NO

TEST(7 , 12) REAL NO NO 9 NO

X(150) REAL NO YES YES NO

Y( 150) REAL NO YES YES NO

Table 4.3 Source Code Modifications by Routine

TYPE OF CHANGE

NAME OF ROUTINE

STATE

VALUE

ADD/ SUBTRACT

STATE

ADD/ SUBTRACT

BUILDING SAFETY

FEATURE

DESIGN

CLASSIFICATION

MAIN ? YES YES YES

BLOCK DATA YES YES YES YES

CCONST NO YES YES NO

CHAZAR NO YES YES NO

COSEST NO YES YES NO

COSMOD NO ? YES NO

C SMOKE NO YES YES NO

CSPRNK NO YES YES NO

CZODIM NO YES YES NO

DESCLS NO 9 YES YES

INSETS NO YES YES NO

INTSOL 9 YES YES NO

PCOSTS NO YES YES NO

PRBLDG NO YES YES YES

PRESOL NO YES YES NO

PRTBAC NO NO NO NO

PRTZON NO YES YES YES

RVSMPX NO YES YES NO

SEARCH NO NO NO NO

SRTSOL NO 9 YES YES

STKSOL NO YES YES YES

TNPSOL NO YES YES NO

54
APPENDIX A PROGRAM DOCUMENTATION

A . 1 RELATIONSHIP TO THE FEDERAL INFORMATION PROCESSING STANDARDS

The three reports which describe the FSESCM model are patterned after

recommendations given in the Federal Information Processing Standards (FIPS)

Publication 38 ^ and MBS Special Publication 500- 73 ^. The information

contained in these documents permits one to define four general classes of

publications. These four classes are associated with the programming and test

stages of the software life cycle as defined in FIPS Publication 38. The four

general classes of publications are:

(1) Management Summary Manual;

(2) User’s Manual;

(3) Programmer’s Manual; and

(4) Analyst’s Manual.

The first manual is designed as a management tool. It provides the

information necessary to assess the model's input requirements (including

time, money, and other resources) and the usefulness of the model's results.

The Management Summary Manual focuses on how the model can facilitate the

decision making process rather than the specifics of how to set up and run the

model. The FSESCM equivalent of a Management Summary Manual is A CostConscious Guide to Fire Safety in Health Care Facilities .-^

The second manual is designed as a reference document for a nonprogramming

model user. Information contained in this manual is similar to the first but

with increased emphasis on detail. In-depth discussions of the following

topics are included: the model's logical structure; the input data

requirements; the results produced by the model; and the use of the model's

results. The FSESCM equivalent of such a document is User's Manual for the

Fire Safety Evaluation System Cost Minimizer Computer Program. -4

National Bureau of Standards, Guidelines for Documentation of Computer

Programs and Automated Data Systems , FIPS Publication 38, 1976.

^National Bureau of Standards, Computer Model Documentation Guide , NBS Special

Publication 500-73, 1981.

^Robert E. Chapman, A Cost-Conscious Guide to Fire Safety in Health Care

Facilities , National 3ureau of Standards, NBSIR 82-2600, 1982.

4 Robert E. Chapman and William G. Hall, User's Manual for the Fire Safety

Evaluation System Cost Minimizer Computer Program , National Bureau of

Standards, NBSIR (in preparation).

55
The third and fourth documents are designed for use by programmers and

analysts, respectively. The third manual provides guidelines for maintaining

and modifying the model. These guidelines should be of sufficient detail to

enable the programmer to understand the operation of the model and to trace

through it for debugging, for making modifications, and for determining if and

how the model can be converted to other computer systems. The fourth manual

differs from the third in that its emphasis is on the model's functional

structure, the algorithms used, and the techniques employed for model

verification and validation. This report is the FSESCM equivalent of the

Programmer's and Analyst's Manuals described above.

A. 2 VARIABLE DEFINITION

This section serves as a glossary of terms. It is designed to be both

informative and a source of information should the code require updating or modification. The glossary is arranged in alphabetical order by variable

name. Each array is dimensioned as it is currently in the model. The purpose

of the array is then given. The rows and columns of each array are then

defined. Associated with each variable is a list of all subroutines which

reference it.

A( 18 , 61)

3(19,19)

C(5o)

Purpose: A is the constraint matrix augmented by a right-hand-side column and an objective function row. The

first 13 rows are generalized upper bound constraints with

right hand sides of 1. Rows 14 through 17 are greater than

or equal to constraints associated with the safety

requirements. The last row contains the transition costs.

Columns 1 through 56 are the states of the system. Columns

57 through 60 are surplus variables associated with rows 14

through 17. Column 61 is the right hand side. The A matrix

is constructed within the MAIN program.

Routines: MAIN, RVSMPX, INTSOL, PRESOL.

Purpose: Upon exit from RVSMPX, the 3 matrix contains: the

inverse of the matrix of the current basic columns; the

negative of the current values of the dual variables (row 18

columns 1 through 17); the current values of the basic

variables (column 19 rows 1 through 17); the negative of the

value of the real objective function 3(18,19); and the

negative of the value of the artificial objective function

(3(19,19)).

Routines: MAIN, RVSMPX.

Purpose: This vector contains the estimated transition cost

for each of the 56 possible retrofit states. It is used to

reinitialize the objective function row of the A matrix

during the state-forcing loops. It is used extensively for

costing and checking.

Routines: MAIN, INSETS, CCONST , CZODIM, CHAZAR, CSMOKZ,

CSPRNK, COSEST, PCOSTS, INTSOL, STXSOL.

56
CMODL

CMODM

CMODT

CPUL( 13,

CPUM( 13

,

CPUT( 13

,

G(13,7)

HBLDG( 6)

CHARACTE

Purpose: This input variable is used to update the labor

costs contained in the CPUL array to reflect regional

variations in the demand for labor.

Routines: MAIN, COSMOD, PCOSTS

.

Purpose: This input variable is used to update the material

costs contained in the CPUM array to reflect regional

variations in the demand for building materials.

Routines: MAIN, COSMOD, PCOSTS.

Purpose: This input variable is used to update the per unit

costs in the CPUL and CPUM arrays to refect cost growth over

time

.

Routines: MAIN, COSMOD, PCOSTS.

7,10)

Purpose: CPUL contains the per unit labor costs prevailing

in the Washington, D. C., metropolitan area during the

summer of 1981. The leading dimension is the building safety

feature number. The middle dimension is the number of the

state (rank) according to the appropriate row of FSES

Table 4. The last dimension is the critical element which

would be retrofitted. All values are initialized within the

BLOCK DATA routine.

Routines: MAIN, BLOCK DATA, COSMOD.

7,10)

Purpose: CPUM contains the per unit material cost prevailing

in the Washington, D. C. metropolitan area during the summer

of 1981. The dimensions have the same interpretation as CPUL. All values are initialized within the BLOCK DATA

routine

.

Routines: MAIN, BLOCK DATA, COSMOD.

7,10)

Purpose: CPUT contains the total per unit cost for each

potential retrofit. The values have been adjusted to reflect

regional price differences in the labor and materials market

as well as cost growth over time. The dimensions of Che

array have the same interpretation as CPUL and CPUM.

Routines: MAIN, COSMOD, CCONST, CZODIM, CHAZAR,

CSMOKE, CSPRNK, COSEST

.

Purpose: G is the program analogue of FSES Table 4. The

rows of G correspond to the building safety feature numbers

in FSES Table 4. The columns correspond to the state number

(rank) within a given row of FSES Table 4.

Routines: MAIN, BLOCK DATA.

Purpose: This input variable is used as a mailing label and

R*40 provides information of whom to contact should problems

arise. The rows refer to: (1) the name of the facility;

(2) the name of the building; (3) the name of the contact;

(4) the street address; (5) the city, stats and zip code; and

(6) the telephone number.

Routines: MAIN, PRT3AC.

57
HFIND

CHARACTER*6

HIN

CHARACTER*

6

HLAB( 56)

CHARACTER*?

HOUT(AO)

CHARACTER*45

HPAR( 18)

CHARACTER* 30

HSTAT( 13)

CHARACTER*?

HTl(lO)

CHARACTER*

8

HTEST

CHARACTER* 7

2

13 ( 5 ) CHARACTER*

6

IBLDG

IEC1 (40)

Purpose: This variable contains the first six characters on on a card read after a fatal error has occurred. The value

is checked against the LAST and FINAL commands to locate the

last card for the building or the batch.

Routine: SEARCH

Purpose: This input variable is used for declaring which

options are to be exercised.

Routines: MAIN.

Purpose: This array contains the state names for each of the

56 possible retrofits.

Routines: MAIN, BLOCK DATA, CCONST, CZODIM, CHAZAR, CSMOKE,

CSPRNK, PCOSTS , PRTZON, PRBLDG.

Purpose: This array contains the design variable qualifiers

for each of the 40 design classifications. All values are initialized within the BLOCK DATA routine.

Routines: MAIN, BLOCK DATA, PRBLDG.

Purpose: This array contains the labels for the rows (building safety features) shown in FSES Table 4.

Routines: MAIN, BLOCK DATA, CCONST, CZODIM, CHAZAR, CSMOKE,

CSPRNK, PCOSTS, PRTZON, PRBLDG.

Purpose: This array is initialized from the settings of HLAB

which correspond to the state within each of the 13 building

safety features which is in the solution.

Routines: PRTZON, PRBLDG.

Purpose: This array contains the labels for FSES Table 1.

All values are initialized within the BLOCK DATA routine.

Routines: MAIN, BLOCK DATA.

Purpose: This variable is used to output information on the

contents of those cards which immediately follow a fatal

error

.

Routines: SEARCH.

Purpose: This character array is used for outputting

information from the RVSMPX routine.

Routines: RVSMPX.

Purpose: This input variable specifies whether the building

is: (1) new single story; (2) new multistory; (3) existing

single story; or (4) existing multistory.

Routines: MAIN.

Purpose: This array contains the integer value of each

design classification's set of design variable qualifiers.

This value is used in testing, assigning and matching design

equivalent solutions within and among fire zones. All values are initialized within the BLOCK DATA routine.

Routines: MAIN, BLOCK DATA, DESCLS , SRTSOL, STKSOL, PRBLDG.

58
IEC5(40 ,5)

IECC0N(4 , 7

)

IECDBL(3 , 5)

IECHAZ(3 ,5)

IECNOS( 3 , 5

)

IECSM0(5 ,5)

IECS?R(7 ,3)

IECT(44)

IECYES (3 , 5

)

Purpose: This array contains a set of flags which are used

to check if a perfect match between a solution and a design

classification exists. The five columns, correspond to:

(1) construction; (2) zone dimensions; (3) emergency movement

routes; (4) somke detection and alarm; and (5) sprinklers.

All values are initialized within the BLOCK DATA routine.

Routines: MAIN, BLOCK DATA, DESCLS

.

Purpose: This array is used to store the inputs for the

critical element counts (rows) requiring treatment in order

to retrofit one of the construction states (columns).

Routines : CCONST

.

Purpose: This array is used to store the input values for

the critical element counts (rows) in high hazard areas requiring treatment in order to move to a higher state

( columns )

.

Routines: CHAZAR.

Purpose: This array is used to store the sum across all

three possible input categories for each critical element

(row) in hazardous areas. The column dimension refers to the

state within this building safety feature.

Routines: CHAZAR.

Purpose: This array is used to store the input values for

the critical elements counts (rows) for non-sprinklered

single deficiency hazardous areas. The column dimension

refers to the state within this building safety feature.

Routines: CHAZAR.

Purpose: This array is used to store the input values for

all critical element counts for smoke detection and alarm

(the twelfth building safety feature). The column dimension

refers to the state within this building safety feature.

Routines: CSMOKE

.

Purpose: This array is used to store the input values for

the critical element counts (rows) associated with automatic

sprinkler systems . The column dimension refers to the state

within the building safety feature.

Routines: CSPRNK.

Purpose: This array is used to store the number of distinct

solutions for each of the 40 design classifications , the

prescriptive compliance solution, and the three types of

solutions which do not fit one of the above cases. Routines: MAIN, INSETS, DESCLS, SRTSOL, PRTZON.

Purpose: This array is used to store the input values for

the critical element counts (rows) for sprinklered single

deficiency hazardous areas. The column dimension refers to

the state within the building safety feature.

Routines: CHAZAR.

59
IECZDM(7 ,6)

IFLOR

INELT( 7

,

INV

IP(5)

IPAC( 100

I PART

Purpose: This array is used to store the input values for

the critical element counts (rows) associated with zone dimensions (the sixth building safety feature). The column

dimension refers to the state within the building safety

feature

.

Routines: CZODIM.

Purpose: This input variable records the floor number of the

fire zone currently under analysis.

Routines: MAIN, PCOSTS , INTSOL, TNPSOL, PRESOL.

10) Purpose: INELT is used to store the input values for the

critical element counts (columns) associated with each

building safety feature for which a special purpose routine

was not written. The row dimension refers to the state

within the building safety feature.

Routines: MAIN, COSEST

Purpose: INV is a switch that allows the user to provide

RVSMPX with an initial basis. If INV is non-zero, an initial basis is expected. If INV is zero, the subroutine

will start from scratch. Except for the first call to

RVSMPX, an initial basis is supplied.

Routines: MAIN, RVSMPX.

Purpose: IP stores the numbers of the variables which are entering and leaving the basis. The generation of a basis

print is governed by the settings in the L vector.

Routines: RVSMPX.

,22) Purpose: IPAC is a multipurpose array. It is used for

intermediate storage of solutions generated by the INTSOL

routine. Each row of IPAC is a distinct solution. Columns 1 through 13 contain the number of the post retrofit state

within each building safety feature, columns 14 and 15

contain the floor number and zone number columns 16 thorough

19 contain the surplus over each of the four safety

requirements. Column 22 contains the post-retrofit cost.

Columns 20 and 21 are left blank until entry Into the DESCLS

and SRTSOL routines. Upon exit they are design

classification number and the rank according to cost within

that design classification respectively.

Routines: MAIN, INSETS, INTSOL, TNPSOL, PRESOL, DESCLS,

SRTSOL, STXSOL.

Purpose: This input serves as a partition qualifier. If the

input value is 0 then partitions can not be installed to

reduce the length of the fire zone. If the input value is 1,

then partitions can be installed. The number of partitions

is dependent on the length of the fire zone, LZONE.

Routines: MAIN, CZODIM, INTSOL

60
IPATS

IPRES

ISRT( 100,

IST4(56,

I STAT (13)

ISTK( 500

,

IT1M(5)

IT1X( 5)

IT4A(7)

Purpose: This input variable tells how many patients are in

the fire zone under consideration. It is used in calculating

the score for the no control state of the ninth building

safety feature (smoke control)

.

Routines: MAIN

Purpose: This variable is used to store the cost of the

prescriptive compliance solution.

Routines: MAIN, PCOSTS, PRESOL, STKSOL.

22) Purpose: ISRT contains the solutions for each fire zone sorted within each design classification. Each solution

occupies one row. The columns have exactly the same meaning

as for IPAC.

Routines: MAIN, INSETS, SRTSOL, PRTZON, STKSOL.

) Purpose: IST4 provides a crosswalk between the number of the

simplex variable (row J, column 1) and the row of FSES Table

4 (row J, column 2) . All data are initialized in the BLOCK

DATA Routine.

Routines: MAIN, BLOCK DATA.

Purpose: ISTAT is a multipurpose array. Within MAIN,

CCONST , CZODIM, CHA2AR, CSMOKE , CSPRNK, ISTAT is used as a flag for input errors. Within TNPSOL, ISTAT is used to set

flags to identify the prescriptive compliance solution.

Routines: MAIN, INSETS, CCONST, CZODIM, CHAZAR, CSMOKE,

CSPRNK, INTSOL, TNPSOL.

22) Purpose: ISTK contains the best solutions for each fire zone for each design classification which had one or more

solutions. Solutions as stored in blocks by fire zone. The

columns of ISTK have the same interpretation as for IPAC and

ISRT.

Routines: MAIN, INSETS, STKSOL, PRBLDG

Purpose: IT1M defines the maximum state number for each of

the five occupancy risk factors shown in FSES Table 1. These

values are used to check against the inputs IT1X and as default values should the maximum be exceeded. All values

are initialized in the BLOCK DATA routine.

Routines: MAIN, BLOCK DATA.

Purpose: IT1X contains the input values of the five

occupancy risk parameters for FSES Table 1. Routines : MAIN

Purpose: IT4A provides a crosswalk between T4A (the construction portion of FSES Table 4) and T43 (the construction

portion of FSES Table 4 arranged as an increasing function

of score) . It is used as a crosswalk between IT4X and IT4XA

in setting up the simplex tableau. All values are initialized in the 3L0CK DATA routine.

Routines : MAIN, BLOCK DATA.

61
IT4B( 7

)

IT4M(13)

IT4S( 13 , 2)

IT4XC13)

IT4XA( 13)

IT8(5)

ITYPE

I ZONE

Purpose: IT4B provides a crosswalk between T4B (the

construction portion of FSES Table 4 arranged as an increasing function of score) and T4A (the construction

portion of FSES Table 4) . All values are initialized in the

BLOCK DATA routine.

Routines: MAIN, BLOCK DATA, PRTZON.

Purpose: This array contains the maximum state number within

each of the 13 building safety features. It is used as a check against the input state numbers (IT4X) . All values are initialized in the BLOCK DATA routine.

Routines: MAIN, BLOCK DATA.

Purpose: IT4S provides a crosswalk between the simplex

tableau (A) and FSES Table 4. The rows of IT4S correspond

to the 13 building safety features. The first column of IT4S

contains the first simplex variable number for a given

building safety feature. The second column contains the last

simplex variable number for a given building safety feature.

All values are initialized in the BLOCK DATA routine.

Routines: MAIN, BLOCK DATA, PCOSTS, INTSOL, TNPSOL, PRESOL,

PRTZON, PRBLDG.

Purpose: IT4X stores the input state numbers for each

building safety feature. The value input should reflect the

current condition of that building safety feature.

Routines: MAIN, CCONST, CZODIM, CHAZAR, CSMOKE, CSPRNK,

PCOSTS.

Purpose: This array is used to define the input states for

each of the 13 building safety features when setting up the

simplex tableau. IT4XA differs from the user input array

IT4X in that all state numbers are arranged so that their

scores are monotonically increasing.

Routines: MAIN, INTSOL, PRESOL, DESCLS

.

Purpose: IT8 provides a crosswalk between IT4X and IT4XA for

hazardous areas. All values are initialized in the BLOCK

DATA routine.

Routines: MAIN, BLOCK DATA, PRTZON.

Purpose: This input variable defines whether the facility

under analysis is a hospital (ITYPE = 1) or a nursing home

(ITYPE =2). It is later used to define whether T6A or T6B

should be used and which rows of the prescriptive requirement

matrix (JPR) should be referenced.

Routines: MAIN.

Purpose: This input variable qualifies the zone under

analysis. It is essential if more than one fire zone exists

on a floor.

Routines: MAIN, PCOSTS, INTSOL, TNPSOL, PRESOL.

62
JPR( 13 , 8)

JPRES

Kl, K2, K3

K0ST(41)

KPRES

KQP

L( 150)

Purpose: JPR defines Che number of the prescriptive

compliance state for each of the 13 building safety features.

The first four columns are for hospitals; the last four

columns are for nursing homes. All values are initialized in

the BLOCK DATA routine.

Routines: MAIN, BLOCK DATA, CCONST, CZODI.M, CHAZAR, CSMOKE

,

CSPRNK, PCOSTS , PRESOL, DESCLS.

Purpose: This variable defines the column of the JPR matrix

which contains the prescriptive compliance state numbers.

Routines: MAIN, CCONST, CZODIM, CHAZAR, CSMOKE, CSPRNK,

PCOSTS, PRESOL, DESCLS.

Purpose: The interpretation of these variables is limited to

the loop where critical element counts are input. Within

that loop, Kl is the length of the cost vector for the

building safety feature under analysis, K2 is the number of

the state above the one input, and K3 is the maximum state

number. This information is passed to the COSEST subroutine

where transition costs are estimated.

Routine: MAIN, COSEST.

Purpose: KOST contains the cost of retrofitting the entire

building to each of the 40 design classifications; the last

row contains the cost of prescriptive compliance. KOST is

used to govern the order in which design classifications are output

.

Routines: PRBLDG.

Purpose: This variable is used to store the cost of

prescriptive compliance. It is used as a baseline against

which the savings due to the FSES can be compared.

Routines: MAIN, PCOSTS, STKSOL, PRBLDG.

Purpose: KQP is a switch which allows the RVSMPX subroutine

to solve quadratic programming problems. KQP is preset

within the MAIN program to indicate that the application

problem is linear.

Routines: MAIN, RVSMPX.

Purpose: L is a multipurpose array. Its major purpose is to

preset switches which define the constraint structure and

output options for the RVSMPX subroutine. Values are preset

within the MAIN program. Within subroutine PCOSTS, L is used

to store the integerized values of the retrofit costs.

Within subroutines INTSOL, TNPSOL and SRTSOL, L is used for

integer manipulations.

Routines: MAIN, INSETS, PCOSTS, RVSMPX, INTSOL, TNPSOL,

SRTSOL.

63
LCV( 13)

LZONE

MA

MB

MT

NT

PR(5)

Tl(5 ,5)

T48A(5)

T4A(4,7)

Purpose: LCV records the length of the cost vector for each

of the 13 building safety features. It is used for reading

in the critical element counts. All values are initialized

in the BLOCK DATA routine.

Routines: MAIN, BLOCK DATA.

Purpose: LZONE as input determines the lepgth of the fire zone. It is used to calculate how many partitions would be

needed to reduce the overall zone length.

Routines: CZODIM.

Purpose: MA is the row dimension of the simplex tableau A.

It is preset within the MAIN program.

Routines: MAIN, RVSMPX.

Purpose: MB is the row dimension of the basis inverse matrix

B. It is preset within the MAIN program.

Routines: MAIN, RVSMPX.

Purpose: MT is the number of rows of information in the A

matrix. MT is preset within the MAIN program.

Routines: MAIN, RVSMPX.

Purpose: NT is the number of columns in the A matrix. NT is

preset within the MAIN program.

Routines: MAIN, RVSMPX.

Purpose: PR contains the values of the basic variables

within the Basis Print Report of subroutine RVSMPX.

Routines: RVSMPX.

Purpose: T1 contains values of the occupancy risk factors

defined in FSES Table 1. All values are initialized in the

BLOCK DATA routine.

Routines: MAIN, BLOCK DATA.

Purpose: T48A contains the scores for the five hazardous

area states in increasing order. The crosswalk from FSES

Table 4 and T48A and vice versa is made through reference to

IT8 . All values are initialized in the BLOCK DATA routine.

Routines: MAIN, 3L0CK DATA.

Purposes: T4A contains the scores for the four floor

categories associated with the first building safety feature

(construction). T4A is identical with that portion of FSES

Table 4 and is used in the output of the appropriate FSES

tables. All values are initialized within the BLOCK DATA

routine

.

Routines: MAIN, BLOCK DATA.

64
T4B(4,7)

T6A(3 , 2,2)

T6B(3 , 2,2)

TEST(7 ,12)

TOLP

X( 150)

Y( 150)

2(150)

Purpose: T4B contains the same type of information as T4A

but with its states reorganized so that their values are monotonically increasing. IT4A is used as a crosswalk

between T4A and T4B . IT4B is used as a crosswalk between T4B

and T4A. All values are initialized within the BLOCK DATA

routine

.

Routines: MAIN, BLOCK DATA.

Purpose: This array contains the safety requirements for

hospitals. T6A(I,J,K) may be interpreted as follows. K=1

implies a first floor fire zone; K=2 implies above the first

floor. J=1 implies new; J=2 implies an existing facility.

1=1 implies containment; 1=2 implies extinguishment; and 1=3

implies people movement. All variables are initialized in

the BLOCK DATA routine.

Routines: MAIN, BLOCK DATA.

Purpose: This array contains the safety requirements for

nursing homes. All indices have the same meaning as under

T6A. All variables initialized in the BLOCK DATA routine.

Routines: MAIN, BLOCK DATA

Purpose: TEST is used to store intermediate data during the

integerization process.

Routines: INTSOL.

Purpose: TOLP is used in the construction of epsilon (EPS)

and capital epsilon (CEPS) in the RVSMPX routine. These

variables are used to test tolerances during optimzation.

TOLP is preset in the MAIN program.

Routines: MAIN, RVSMPX.

Purpose: X is the solution vector which results from the

call to RVSMPX. Upon exit from RVSMPX the vector X contains:

the terminal values of the variables in the original problem

in X(l) through X(56); the surplus over each of the four

safety requirements in X(57) through X(60); the artificial

variables for the 17 equations in X(61) through X(77);. and

the negative value of the objective function in X(78). After

the first call, X has its values read into 2. Prior to each

call in the state-forcing loops, X is reinitialized with the

values from 2 so that an initial basis is provided to

RVSMPX.

Routines: MAIN, INSETS, RVSMPX, INTSOL.

Purpose: Y is a multipurpose working solution vector. The

solution stored in X is read into Y, all manipulations

(testing, integerizing, packing) are then based on Y.

Routines: MAIN, INSETS, RVSMPX, INTSOL, TNPSOL.

Purpose: 2 contains the optimal solution to the continuous

linear program. It is used to restore the X vector so that

RVSMPX may be entered with an initial basis.

Routines: MAIN, INSETS, PRTZON.

65
A. 3 DESCRIPTION OF THE SUBROUTINES

This section provides a brief description of all subroutines in the model.

For the MAIN program, a more detailed description by functional block is given

in chapter 2. Similarly, the specification program (BLOCK DATA) associated

with the initialization of all variables in the SETUPA and SETUPS COMMON

blocks is described in section 2.2.

The section is arranged in alphabetical order by subroutine name. Each

subroutine is described on a single program summary sheet. This summary sheet

includes: (a) the name of the subroutine; (b) the call statement; (c) a narrative description; (d) the calling routines (e) the called routines; (f)

the commons referenced; and (g) any messages generated. ^ The information

provided on the summary sheets in conjunction with the model flowchart shown

in chapter 2 should facilitate the programmer’s task of effectively

maintaining the model. The interactions among subroutines which are explicitly stated on the summary sheets should also assist the programmer in

updating or making any modifications to the source code dictated by user needs

or peculiarities of the operating system.

It is important to note that some of the output listed under the messages

generated section of the revised simplex (RVSMPX) program summary sheet would

not normally occur. This is because the MAIN program contains an elaborate

system of edit checking. In particular, all entries to the constraint matrix

are constructed within the MAIN program based on data from the SETUPA COMMON

block, so errors in input would not affect the feasibility of the application

problem. However, input errors could affect the objective function and hence

render the problem meaningless. The complete RVSMPX program was incorporated

into FSESCM because, should it become necessary to revise the source code

(e.g., due to a major change in the Life Safety Code), ill-defined problems

could be sent to the optimizer. Having the full range of error messages

should therefore facilitate finding any flaws in logic introduced by the

changes. The program may also be uncoupled from the model for use as an optimizer in other applications.

^Throughout this section the term messages generated refers to an error

condition. Consequently, those subroutines which produce output reports

under normal circumstances will not reference these reports under the

heading of messages generated. Reference to the output report will be made

in the narrative section, however. Each report is described in detail in

section 3.1.

66
PROGRAM SUMMARY SHEET

SUBROUTINE NAME: CCONST — Costing for CONSTruction

CALL STATEMENT:

CCONST( CPUT , JPR , C , IT4X , ISTAT , HPAS , HLAB , JPRES

)

DESCRIPTION:

This subroutine reads and prints the critical element counts and

estimates the cost of installing retrofits which affect construction.

It is entered each time data on a fire zone is input.

MAIN

CALLED BY:

CALLS:

N0NE

COMMONS REFERENCED: NONE

MESSAGES GENERATED: NONE
PROGRAM SUMMARY SHEET

SUBROUTINE NAME: CHAZAR — Costing for HAZARdous areas

CALL STATEMENT:

CHAZAR( CPUT , JPR , C , IT4X , ISTAT , HPAR , HLAB , JPRES

)

DESCRIPTION:

This subroutine reads and prints the critical element counts and

estimates the cost of installing retrofits which affect hazardous

areas. It is entered each time data on a fire zone is input.

CALLED BY: MAIN

CALLS: NONE

COMMONS REFERENCED:

NONE

MESSAGES GENERATED: See Attachment

68
PROGRAM SUMMARY SHEET (ATTACHMENT)

SUBROUTINE NAME : CHAZAR

MESSAGES GENERATED:

Deficiency qualifier out of range. The allowable values are:

0. None present (e.g., Double, Single—Not sprinklered, and Single

Sprinklered) , and

1. Aggregated count.

The values input were:

Double , Single—Non sprinklered , Single—Sprinklered

The run continues using a default value of 0 for the qualifiers incorrectly

input

.

69
PROGRAM SUMMARY SHEET

SUBROUTINE NAME: COSEST — COSt ESTimation

CALL STATEMENT:

COSEST ( CPUT , INELT , C , 1 , 1 1 ,K1,K2,K3)

DESCRIPTION:

This subroutine is entered each time the data on a building safety feature

is read in. The retrofit costs associated with each state in that

building safety feature are then estimated. The following working

parameters are transferred from the MAIN program:

1. I denotes the building safety feature number;

2. K1 denotes the length of the cost vector;

3. K2 is the state above that input;

4. K3 gives the maximum number of retrofit states, and;

5. II is the first simplex variable number.

CALLED BY: MAIN

CALLS: NONE

COMMONS REFERENCED:

NONE

MESSAGES GENERATED: NONE

WB

70
PROGRAM SUMMARY SHEET

SUBROUTINE NAME:

COSMOD — COSt MODifier

CALL STATEMENT: COSMOD ( CPUT , CPU! , CPUM , CMODT , CMODL , CMODM

)

DESCRIPTION:

This subroutine is entered each time data on a new building is input. The

purpose of the subroutine is to adjust the component costs stored in the

CPUL (per unit labor costs) and CPUM (per unit material costs) matrices to

reflect cost growth (CMODT) and regional price differentials (where CMODL

captures variations in the prevailing wage and CMODM captures variations

in material prices). These adjustments are recommended since all costs in

the CPUL and CPUM matrices are based on the rates prevailing in the

Washington, D. C. metropolitan area during the summer of 1981. It is

recommended that the values of CMODT, CMODL and CMODM be based on data

from a construction cost index report or some other recognized source.

MAIN

CALLED BY:

CALLS:

NONE

COMMONS REFERENCED: NONE

MESSAGES GENERATED: NONE

71
PROGRAM SUMMARY SHEET

SUBROUTINE NAME: CSMOKE — Costing for SMOKE detection and alarm

CALL STATEMENT: CSMOKE ( CPUT , JPR , C , IT4X , ISTAT , HPAR , HLAB , JPRES

)

DESCRIPTION:

This subroutine reads and prints the critical element counts and

estimates the cost of installing smoke detection and alarm systems

is entered each time data on a fire zone is input.

It

CALLED BY:

MAIN

CALLS: NONE

COMMONS REFERENCED: NONE

MESSAGES GENERATED: NONE

72
PROGRAM SUMMARY SHEET

SUBROUTINE NAME: CSPRNK. — _Costing for Automatic SPRINKlers

CALL STATEMENT: csprnk(cput,jpr,c,it4x,istat,hpar,hlab,jpres)

DESCRIPTION:

This subroutine reads and prints the critical element counts and

estimates the cost of installing retrofits which affect sprinkler systems.

It is entered each time data on a fire zone is input.

CALLED BY:

CALLS:

NONE

COMMONS REFERENCED: NONE

MESSAGES GENERATED:

See Attachment

73
PROGRAM SUMMARY SHEET (ATTACHMENT)

SUBROUTINE NAME : CSPRNK

MESSAGES GENERATED:

Sprinkler designation out of range. The allowable values are:

1. Wet, exposed;

2. Wet, concealed;

3. Dry, exposed; and

4. Dry, concealed.

The value input was: . The run continues using a default value of 2.

Water supply designation out of range. The allowable values are:

1 . Adequate

;

2. Not adequate; and

3 . Unknown

.

The value input was: . The run continues using a default value of 3.

74
PROGRAM SUMMARY SHEET

SUBROUTINE NAME: CZODIM — ^Costing for ZOne DIMensions

CALL STATEMENT:

CZODIM( CPUT , JPR , C , IT4X , ISTAT , HPAR , HLAB , JPRES

,

IPART)

DESCRIPTION:

This subroutine reads and prints the critical element counts and

estimates the cost of installing retrofits which affect zone dimensions

It is entered each time data on a fire zone is input.

CALLED BY:

MAIN

CALLS: NONE

COMMONS REFERENCED: NONE

MESSAGES GENERATED: NONE

75
PROGRAM SUMMARY SHEET

SUBROUTINE NAME: DESCLS — DESign CLaSsif ication

CALL STATEMENT: DESCLS ( IPAC , IEC5 , JPR , IEC 1 , IECT , IT4XA, JPRES

)

DESCRIPTION:

This subroutine attempts to assign each solution to a design

classification. If the solution does not fit any of the predetermined

design classes, a test flag is set to zero. The subroutine is entered

from the MAIN program after the first two sets of alternate solutions

have been generated and the class forcing loop of the MAIN program has

been completed.

CALLED BY:

MAIN

CALLS: N0NE

COMMONS REFERENCED: NOne

MESSAGES GENERATED: NONE

76
PROGRAM SUMMARY SHEET

SUBROUTINE NAME:. INSETS — Initialize SETtingS

CALL STATEMENT: INSETS

DESCRIPTION:

This subroutine initializes (or reinitializes) the values of all major

work spaces. It is designed to clear the working space so that no information from a previous building could influence the calculations for

the one currently being run. This subroutine initializes all settings for

integerized, sorted, and stacked solutions for a building. Solution

counts by design class, all retrofit costs and the last fire zone’s

solutions for a building are also set to zero. It is called in four ways:

1. initially;

after each building has been solved;

if the output of the revised simplex routine was other than

normal; and

if an error in the runstream was encountered.

2 . 3 .

4 .

CALLED BY: MAIN

CALLS:

NONE

COMMONS REFERENCED:

MESSAGES GENERATED:

NONE

77
PROGRAM SUMMARY SHEET

SUBROUTINE NAME: INTSOL — INTegerize SOLution

CALL STATEMENT: INTS0L(A,IPAC,IT4S,TEST,L,X,Y,C,IT4XA, ISTAT,

IFLOR , IZONE , IPART , X2

)

DESCRIPTION:

This subroutine is entered each time a new solution has been generated.

Upon entry the X vector contains the optimal (continuous LP) solution to

the problem being solved. The entries in the X vector are then examined

one at a time. Each building safety feature where a split occurs is

flagged and counted. If no splits are encountered, the program then

checks to see if an interdependency has rendered the problem infeasible.

If the problem is still feasible, the TNPSOL subroutine is called and the

solution is tested and packed into a row of the IPAC matrix. Control is

then returned to the MAIN program. If one or more splits were encountered, an ad hoc integerization procedure is used whereby each

building safety feature is used as the first entry, the second entry,

etc., in integerizing the solution. The resultant solutions are then

checked for feasibility in the event that one or more interdependencies

came into play. The TNPSOL subroutine is then called and control is

returned to the MAIN program.

CALLED BY:

CALLS: tnpsol

COMMONS REFERENCED: N0NE

MESSAGES GENERATED: NONE

78
PROGRAM SUMMARY SHEET

SUBROUTINE NAME: PCOSTS — Print COSTS

CALL STATEMENT: PCOSTS( JPR,IT4S ,IT4X,L,C ,HLAB ,HPAR, JPRES , IFLOR,

IZONE , CMODT , CMODL , CMODM ,KPRES . IPRES >

DESCRIPTION:

This subroutine prints back the estimated retrofit cost for each state

within a given building safety feature. In order to facilitate

comparisons with any solutions generated as well as for identifying if

and/or where a cost needs modification via the 'CHANGE' option, each cost

is listed immediately below the state name.

CALLED BY:

MAIN

CALLS: NONE

COMMONS REFERENCED: N0NE

MESSAGES GENERATED: NONE

79
PROGRAM SUMMARY SHEET

SUBROUTINE NAME: PRBLDG — Pkint ^uiLDinG

CALL STATEMENT: ?R3LDG( ISTK, IEC1 , IT4S ,H0UT,HLAB ,KPRES

)

DESCRIPTION:

This subroutine is entered once all sets of alternate solutions for all

fire rones have been generated and printed. The least cost solution for

each of the 40 design classifications for each fire zone in the building

is stored in the ISTK natrix. ISTK is then checked to see if a given

design classification was generated either naturally or artificially for

all fire zones. If a perfect natch occurs, the solution for the entire

building is printed. Each fire zone takes up one line in the printout.

In order to facilitate the identification of each solution, the state

values taken on by each of the 13 building safety features are printed out

as are the surpluses and retrofit cost for each zone. If some fire zone did not contain this class of retrofits, no printout for the entire

building is generated. Should the user wish such a retrofit, it would be

necessary to synthesize it fron the individual fire zone printouts.

CALLED BY:

MAI-N

CALLS: none

COMMONS REFERENCED: NONE

VESS^ES GENERATED: none

30
PROGRAM SUMMARY SHEET

SUBROUTINE NAME: PRESCL — Inscriptive SlLutlcn

CALL STATEMENT: ?RESCL(A, IPAC , HAS , JPR , ITAZA,J?S£5 , I7LOR, IPSPS

,

IZOHE)

DESCRIPTION:

This subroutine generates the solution which corresponds to prescriptive

compliance to the Life Safety Cede. If the prescriptive solution has bee:

excluded from consideration as a viable alternative, then control is

returned to the MAIN program. If not, then a solution is generated for

later use as a baseline against which the design class if i cations can be

ranked

.

CALLED BY:

V .

CALLS: *»e

COMMONS REFERENCED:

MESSAGES SEN ERA "ED:

^
PROGRAM SUMMARY SHEET

SUBROUTINE NAME: PRTBAC — PRinT BACk

CALL STATEMENT: PRTBAC ( HBLDG , ASTAR

)

DESCRIPTION:

This subroutine prints an address label for the run which follows. It

also serves as a separator between runs for different facilities. It is

called immediately after reading in the facility ID, contact person and

facility address contained in matrix HBLDG.

CALLED BY: MAIN

CALLS: NONE

COMMONS REFERENCED:

NONE

MESSAGES GENERATED: NONE

32
PROGRAM SUMMARY SHEET

SUBROUTINE NAME: PRTZON — PRinT fire ZONe

CALL STATEMENT:

PRTZON( ISRT , IT4S , IT4B , IT8 , ITECT , Z , HLAB

)

%

DESCRIPTION:

This subroutine is entered only after all three sets of alternate

solutions have been generated. The subroutine first prints a brief

summary of the zone. The solutions are then printed out by design

classification ranked by retrofit cost. Those solutions which do not fit

a design classification are printed out in the following order:

1. strategies with no deficiencies in hazardous areas;

2. strategies with a single deficiency in hazardous areas, and;

3. strategies with a double deficiency in hazardous areas.

In order to uniquely identify each solution, the output state for each

building safety feature is printed under the respective column heading.

The surplus associated with each performance requirement is then printed

under the headings SI, S2 , S3, SG. The last column contains the estimate

retrofit cost.

CALLED BY: MAIN

CALLS: none

COMMONS REFERENCED:

NONE

MESSAGES GENERATED: NONE

33
PROGRAM SUMMARY SHEET

SUBROUTINE NAME: RVSMPX — Revised SiMPleX

CALL STATEMENT:

RVSMPX( A,MA , B ,MB ,MT , NT ,L , X, TOLP , INV , KQP)

DESCRIPTION:

This subroutine solves for the maximum value of a linear objective

function subject to a set of linear constraints. Since the objective

function is a linear combination of the state variables and the negative

of the state transition costs, maximizing it is equivalent to minimizing

the expected compliance cost. The problem consists of thirteen

generalized upper bound constraints and four performance constraints

(containment, extinguishment, people movement, and general). The problem

is solved through the use of the revised simplex algorithm. The subroutine

is entered from each of the four stages in the optimization loop of the

MAIN program.

1. Each time data on a new fire zone has been input.

2. From the first state forcing loop.

3. From the second state forcing loop.

4. From the third state forcing loop.

If the us"er options 'CHANGE' or 'REQUIR' are exercised, stages 1 through

4 will be repeated.

CALLED BY: MAIN

CALLS: NONE

COMMONS REFERENCED:

NONE

MESSAGES GENERATED: See Attachment

84
PROGRAM SUMMARY SHEET (ATTACHMENT)

SUBROUTINE NAME : RVSMPX

MESSAGES GENERATED:

System error - Computational impossibility.

Epsilon = Capital epsilon = Non-zero entries are effectively equal to zero.

Minimum pivot was at iteration

Error - The problem is infeasible. Infeasibility indicated during

re-inversion of the basis matrix.

Real objective function =

Warning — Small pivot element at interation of Phase

Pivot =

Error — The variables specified as comprising an intial solution do not form

a basic feasible solution.

End of phase . Objective function = There were iterations.

Phase Iteration . Pivot = . Objective function = . entered the basis left.

Error — The problem is infeasible. The constraints associated with the

artifical variables below are inconsistent. If none appear, numerical

difficulties hve been encountered. The largest entry in the objective

function row is

85
PROGRAM SUMMARY SHEET (ATTACHMENT)

SUBROUTINE NAME: RVSMPX

MESSAGES GENERATED (CONTINUED):

Error — The problem is unbounded. The variable X(-) can assume an arbitrarly

large value, thereby yielding an arbitrarily large value of the objective

function.

The error was detected at iteration — of phase . At that time the

objective function value was and the following variables were basic.

Warning — Computational inconsistency indicated at end of phase 1. The

algorithm will continue with phase 2 but the user is advised to criticize the

results

.

At least one element of the right hand side column is less than zero. Subroutine terminates.

86
PROGRAM SUMMARY SHEET

SUBROUTINE NAME: SEARCH — SEARCH for next building

CALL STATEMENT:

SEARCH

DESCRIPTION:

This subroutine is entered in two ways:

1. If an error in the runstream was encountered; and

2. If the output of the revised simplex routine was other than

normal

.

The subroutine is designed to read until the last entry for the building

where the problem was encountered is reached. It will then return contrc L to the MAIN program and look for the inputs for the next building . If

there are no other buildings the run will be terminated.

MAIN

CALLED BY:

CALLS:

N0NE

COMMONS REFERENCED: NONE \

MESSAGES GENERATED:

The values on card after the error are:

87
PROGRAM SUMMARY SHEET

SUBROUTINE NAME: SRTSOL — SoRT SOLutions

CALL STATEMENT:

SRTSOL( IPAC , IRT , IEC 1

, IECT , L , X2

)

DESCRIPTION:

This subroutine is entered only after all three sets of alternate

solutions for each fire zone have been generated. The variable X2, the

bound on the objective function is used as the bound on retrofit cost wher

beginning a sort. The subroutine first ranks each compliance strategy

within a given design class by retrofit cost. Solutions which do not

belong to a design classification are then ranked in the following order:

1. Strategies with no deficiencies in hazardous areas;

2. Strategies with a single deficiency in hazardous areas, and;

3. Stragegies with a double deficiency in hazardous areas. All solutions once sorted are stored in the ISRT matrix.

CALLED BY: MAIN

CALLS: NONE

COMMONS REFERENCED:

NONE

MESSAGES GENERATED: NONE

88
PROGRAM SUMMARY SHEET

SUBROUTINE NAME: STKSOL — STacK SOLutions

CALL STATEMENT:

i STKSOL ( ISRT , ISTK, IPAC , IEC1 , C ,KPRES , IPRES)

DESCRIPTION:

This subroutine is entered only after all three sets of alternate

solutions for each fire zone have been generated, sorted and printed.

The solutions associated with each design class are screened and the one with the lowest retrofit cost is saved. These solutions are used later in

subroutine PRBLDG as a means of synthesizing a retrofit strategy for the

entire building. Prior to leaving this subroutine the ISRT and IPAC

matrices and reinitialized.

CALLED BY: MAIN

CALLS: none

COMMONS REFERENCED:

NONE

MESSAGES GENERATED: N0NE

89
PROGRAM SUMMARY SHEET

' SUBROUTINE NAME: TNPSOL — Test aNd Pack SOLutions

CALL STATEMENT:

TNPSOL( IPAC , IT4S , L , Y , I STAT , IFLOR , IZONE

)

DESCRIPTION:

This subroutine is entered each time a new solution has been generated

and integerized. Upon entry, the Y vector contains the integerized

solution to the problem being solved. The entries in the Y vector are then examined one at a time and packed into the L vector. The L vector

is then used to determine the state number for each building safety

feature. The state numbers are then loaded into the ISTAT vector. The

resultant state numbers are then checked against the entries in the IPAC

matrix. If the same solution has already been found, the current one is

discarded and control is returned to the INTSOL routine. If a distinct

solution results, then a new row of IPAC is opened up and the solution is

stored in it. The value of the objective function, floor and zone IDs and

any score surpluses are also stored in that row of the IPAC matrix.

CALLED BY: INTSOL

CALLS: NONE

COMMONS REFERENCED:

NONE

MESSAGES GENERATED: NONE

90
REFERENCES

American National Standards Institute, American National Standard Programming

Language FORTRAN , ANSI X3 . 9-1978, New York, 1978.

Chapman, R.E., A Cost-Conscious Guide to Fire Safety in Health Care

Facilities, National Bureau of Standards, NBSIR 82-2600, Washington, D.C.,

1982.

Chapman, R.E. and W.G. Hall, User’s Manual for the Fire Safety Evaluation

System Cost Minimizer Computer Program , National Bureau of Standards, NBSIR

(in preparation), Washington, D.C.

Gass, S.I., Linear Programming: Methods and Applications (New York, McGraw

Hill Book Company, 1975).

Hall, W.G., R.H.F. Jackson and P.B. Saunders, The National Bureau of Standards

Linear and Quadratic Programming Subroutines , National Bureau of Standards,

Report 10695, Washington, D.C., 1972.

National Bureau of Standards , Computer Model Documentation Guide , NBS Special

Publication 500-73, Washington, D.C., 1981.

National Bureau of Standards, Guidelines for Documentation of Computer

Programs and Automated Data Systems, FIPS Publication 38, Washington, D.C.,

1976.

National Fire Protection Association, Code for Safety to Life from Fire in

Buildings and Structures , NFPA 101-1981, Quincy, Mass., 1981.

Nelson, H.E., and A.J. Shibe, A System for Fire Safety Evaluation of Health

Care Facilities , National Bureau of Standards, NBSIR 78-1555, Washington,

D.C., 1980.

Saunders, P.B., editor, Selected Assessment Strategies Applied to Short-Term

Energy Models, National 3ureau of Standards, NBSIR 83-2672, Washington, D.C.,

1983.

91

FEDERAL INFORMATION PROCESSING STANDARD SOFTWARE SUMMARY

Mo. Day

ftraprTl"9

iu Software date

Yr. Mo. Day

05. Software title FIRE SAFETY EVALUATION SYSTEM COST MINIMIZER (FSESCM)

mxE 07. Internal Software ID NA

nfi. Short title

oiTioftware type

Automated Data n System M Computer Program

n Subroutine/Module

09. Processing mode

| | Interactive S Batch

| | Combination

10. Application are General Computer Systems Management/

Q Support/ Utility Q Business

Scientific/Engineering Q Process Control

| ] Bibliographic/Textual

| ] Other

a Specific Fire Safety in Health

Care Facilities

Tfsubmitting organization and address

Operations Research Division

Center for Applied Mathematics

National Bureau of Standards

Washington, D. C. 20234

12. Technical contact(s) and phone

Robert E. Chapman (301) 921-3855

William G. Hall (301) 921-3855

_

This program minimizes the cost to hospitals and nursing homes of complying with the

Life Safety Code. The model uses the Fire Safety Evaluation System developed oy the

_ renter for Fire Research at the National Bureau of Standards as a means for identiryxng

alternatives to prescriptive compliance to the Life Safety Code. A linear programming

algorithm is then used to define compliance strategies which, for a given set Oi

constraints, are optimal in terms of minimum cost.

14. Keywords

codes ; building economics; economic analysis; fire safety; health care

facilities; hospitals; life safety; mathematical programming; nursing homes; renovation.

15. Computer manufr and model

Sperry Univac

19. Computer memory requirements

.ess than 256 K. Bytes

16. Computer operating system

1100/82

17. Programing language(s)

FORTRAN 77

18. Number of source program state- ments APPX 4000

20. Tape drives Tjqv/Trpq

(9 Track 1600

or 6350 FPI)

21. Disk/Drum units 22. Terminals

23. Other operational requirements

24. Software availability

Available Limited ra

, 25. Documentation availability

In-house only Available Inadequate

! 5 C

In-house only

26. FOR SUBMITTING ORGANIZATION USE

185-101
'

.

-
HBS-1 14A IREV. 2 -ao

U.S. OEPT. OF COMM.

BIBLIOGRAPHIC DATA

SHEET (See instructions)

1. PUBLICATION OR

REPORT NO.

NBSIR 83-2749

2. Performing Organ. Report NoJ 3. Publication Oate

July 1983

4. TITLE AND SUBTITLE

PROGRAMMER'S MANUAL FOR THE FIRE SAFETY EVALUATION SYSTEM COST MINIMIZER COMPUTER

PROGRAM

5. AUTHOR(S)

Robert E. Chapman and William G. Hall

6. PERFORMING ORGAN I ZATION (If joint or other than N B S, see in struct ion s)

NATIONAL BUREAU OF STANDARDS

DEPARTMENT OF COMMERCE

WASHINGTON, D.C. 20234

7. Contract/Grant No.

3. Type of Report & Period CovereO

9. SPONSORING ORGANIZATION NAME AND COMPLETE ADORESS (Street. City. State, ZIP)

Center for Fire Research Department of Health and Human Services

National Engineering Laboratory Washington, DC 20201

National Bureau of Standards

Washington, DC 20234

10. SUPPLEMENTARY NOTES

[~X~I Document describes a computer program; SF-185, FIPS Software Summary, is attached.

11. A8STRACT (A 200-word or less factual summary of most significant information. If document includes a significant

bibliography or literature survey, mention it here)

The Fire Safety Evaluation System Cost Minimi zer (FSESCM) computer program integrates

engineering and economic considerations with a linear programming algorithm which

permits the least-cost means of upgrading health care facilities to compliance with

the Life Safety Code to be identified. A mathematical discussion of the application

problem is used to introduce the basic philosophy behind the computer program. Each

routine is described with emphasis on such topics as: (1) purpose; (2) calling

sequence; (3) common blocks used; and (4) reports produced. A series of descriptive

tables and a glossary are used to define all reports and variables. A discussion

of test results and provisions for updating or modifying the source code are also

given. The program is written in FORTRAN and complies with the ANSI X3. 9-1978

software standard.

12. KEY WORDS (Six to twelve entries; alphabetical order; capitalize only proper names; and separate key «eras oy semicolon s) Building codes; building economics; economic analysis; fire safety; health care

facilities; hospitals; life safety; mathematical programming; nursing homes;

renovation.

13. AVAILABILITY

Uni imi ted

j , For Official Distribution, Do Not Release to NTIS

I Order From Suoerintendent of Documents, U.S. Government Printing Office, Washington, D.C.

' 1 20402.

pT| Order From National Technical Information Service (NTIS), Springfield, VA. 22161

14. NO. OF

PRINTED PAGES

98

IS. Price

311.50

USCOMM-CC «043-=90


cffi