NATL INST. OF STAND & TECH NIST

AlllDb D317m

PUBUCATIONS

REFERENCE NBSIR 77-1307

A Review of Computer

Software Applicable to the

Ml US Program

William L Carroll

John R. Schaefgen, Jr.

Center for Building Technology

Institute for Applied Technology

National Bureau of Standards

Washington, D C 20234

October 1977

MODULAR INTEGRATED

mius UTILITY SYSTEMS

improving community utility services by supplying

electricity, healing, cooling, and water/ processing

liquid and solid wastes/ conserving energy and

natural resources/ minimizing environmental impact

Prepared for U.S. Department of Housing and Urban Development

Division of Energy. Building Technology and Standards

{CO Office of Policy Development and Research

•U5tp Washington, D.C. 20410

NBSIR 77-1307

A REVIEW OF COMPUTER

SOFTWARE APPLICABLE TO THE

MIUS PROGRAM

William L Carroll

John R. Schaefgen, Jr.

Center for Building Technology

Institute for Applied Technology

National Bureau of Standards

Washington, D.C. 20234

October 1977

Prepared for U.S. Department of Housing and Urban Developnnent

Division of Energy, Building Technology and Standards

Office of Policy Development and Research

Washington, D.C. 20410

U.S. DEPARTMENT OF COMMERCE, Juanita M. Kreps, Secretary

Dr. Sidney Herman, Under Secretary

Jordan J. Baruch. Assistant Secretary for Science and Technology

NATIONAL BUREAU OF STANDARDS, Ernest Ambler. Acting Director

A REVIEW OF COMPUTER SOFTWARE

APPLICABLE TO THE MIUS

PROGRAM

William L. Carroll and John R. Schaefgen, Jr.

Center for Building Technology

Institute for Applied Technology

National Bureau of Standards

Washington, D.C. 20234

ABSTRACT

Thirteen computer programs are examined for potential application to the Modular Integrated Utility System (MIUS) program. The

software programs considered calculate all or partial combinations of:

heating and cooling loads, simulation of physical systems to determine

the energy requirements necessary to satisfy those loads, prediction of

optimal operation schedules and associated costs, and accomplishment of

full life-cycle economic analyses. A set of criteria for evaluation of

this software is presented. Information regarding the programs, obtained

from user manuals and a series of seminar presentations, is collected and

systematically summarized in a standardized foirmat using information

available as of June 1974. An evaluative summary of each program as of

that date is given. Program comparison activities are discussed and

evaluated. Conclusions regarding applicability, validity, and utility of

the programs are reached. Recommendations are made concerning future

software development and utilization.

Keywords: Computer programs; cooling; energy analysis; financial analysis; heating; load calculation; MIUS; modular integrated

utility system; simulation; utility services

i
FOREWORD

The Department of Housing and Urban Development (HUD) is

conducting the Modular Integrated Utility System (MIUS) Program devoted to development and demonstration of the technical, economic,

and institutional advantages of integrating the systems for providing

all or several of the utility services for a community. The utility

services include electric power, heating and cooling, potable water,

liquid waste treatment, and solid waste management. The objective of

the MIUS concept is to provide the desired utility services consistent

with reduced use of critical natural resources, protection of the

environment, and minimized cost. The program goal is to foster, by

effective development and demonstration, early implementation of the

integi-ated utility system concept by the organization, private or

public, selected by a given coramiinity to provide its utilities.

Under HUD direction several agencies have participated in the

HUD-MIUS Program, including the Energy Research and Development Administration (ERDA) ; the Departments of Defense (DOD) ; Health, Education and

Welfare (HEW) ; and Interior (DDI) ; the Environmental Protection Agency

(EPA); the National Aeronautics and Space Administration (NASA); and the

National Bureau of Standards (NBS)

This publication is one of a series developed under the HUDMIUS Program and is intended to further a particular aspect of the

program goals.
Drafts of technical documents are reviewed by the agencies

participating in the HUD-MIUS Program. Coiiiraents are assembled into a

Coordinated Technical Reviev, The draft of this publication received

such a review and all comments were resolved.

iii
Table of Contents

Page

List of Figures v

1. Introduction 1

2. Evaluation Criteria 3

3. Program Data and Evaluations 8

3.1 Heating-Cooling Calculation III (HCC-III) 12

3.2 Trane Air Conditioning Economics Program (TRACE) . . 15

3.3 Computerized Evaluation of Energy Requirements,

Equipment Selection, and Economic Comparison

for Building Systems (E-CUBE) 19

3.4 Energy System Analysis Series 23

3.5 National Bureau of Standards Load Determination

Program (NBSLD) 27

3.6 The Meriwether Energy System Analysis Serles/NBSLD

Hybrid (NBSRFM) 31

3.7 Computer Program for Analysis of Energy Utilization

in Postal Facilities (TACS) , et al 34

3.8 Alternate Choice Comparison for Energy System

Selection (AXCESS) 39

3.9 TACS/Lokraanheklm/AXCESS Hybrid 43

3.10 Oak Ridge National Laboratory (ORNL) BIN Program . . 46

3.11 ORNL 1973 MIUS Comparative Energy Analysis Program . 51

3.12 Energy Systems Optimization Program (ESOP) 56

3.13 MIUS Systems Improved Numerical Differencing

Analyzer (SINDA) Models 62

4. Program Comparison Activities 68

5. Conclusions and Recommendations 75

6. References 88

7 . Acknowledgement 91

iv
List of Figures

1. NBSLD Progreun Sequence

2. ORNL 1973 MIUS Comparative Energy Analysis Program

Simulation Configuration

3. ESOP Program Sequence

V

1. Introduction

In the conceptual development and technology evaluation phase

of the multi-agency HUD-MIUS Program, the use of computerized calculation procedures by several of the participating agencies started early

and played an important role in analyses ranging from site load determination, to determination of overall soundness of different concepts

and technologies, to detailed evaluation of total MIUS designs. The

NASA and ORNL developed computer programs to estimate building thermal

loads and the subsequent required energy input to various plant configurations which satisfy those thermal loads. At the request of HUD, the NBS

team of the HUD-MIUS Program examined the various calculational procedures

in use for soundness of approach, and for compatibility of efforts of

the different agencies. In addition, some commercially available software

was examined in order to determine if there were any programs which

could be of use. This report describes the information derived from

the effort, and results in a series of recommendations to the HUD

Program Manager both as to those programs best able to satisfy present

MIUS" needs and to what additional computer program development is needed

for future work.

All programs were evaluated with respect to their potential

contribution to the generation and evaluation of MIUS designs in the

demonstration and follow-on phases of the MIUS effort. The program

descriptions and evaluations are based in part on training courses

presented by program developers and in part on published descriptive

material concerning the programs.

1
The reader is cautioned that computer programs are constantly

evolving. The descriptions and evaluations which follow are based on

the information available as of June 1974. Changes which have been made

to several of the programs since that date are not addressed.

This evaluation gives consideration to some past comparison

activities and summarizes their findings. It is noted that there are

no publicly available evaluations of program accuracy, only evaluations

of relative agreement between programs. Three of the comparisons were

carried out by government agencies participating in the MIUS effort.

Several conclusions are reached concerning MIUS needs for

computer support. Recommendations are made for implementation of

specific computer programs which come closest to satisfying the identif3 ed MIUS needs. Due to the simulation flexibility required for MIUS

studies, only programs for which the plant systems simulation package

was available to participating agencies in source language form could

be recommended. - •

This report of the evaluation effort is presented with the

intention that the program description data, evaluative summaries,

comparison activities and conclusions will assist in subsequent MIUS

efforts for the design and energy analysis of community energy systems.

2
2. Evaluation Criteria

A particular perspective was established from which all of the

computer programs described herein were examined in forming an evaluation.

Applicability and usefulness in furthering MIUS project goals were a

primary concern. In addition, the validity or quality of the consitutent

algorithms was examined to the degree possible without actual lineby-line algorithmic analysis. This examination was based on available program documentation, training seminars, and oral and written

communication with the authors of the computer programs. Although previously initiated comparison test case activities are discussed and

evaluated in Section 4 of this report, no specific test-case comparisons

were Involved in the present effort.

To best accomplish this effort, a set of evaluation criteria were

developed by which the characteristics and capabilities of each program

were systematically examined. These criteria are divided into four

general categories: a) applicability to the MIUS effort; b) simulation

adequacy; c) user factors of the programs; d) implicit simulation bias.

The first area of concern is that of program applicability, i.e.

does a given program or software system calculate something that is

needed in a MIUS analysis. Determination of technical and economic

feasibility is necessary for survival of the MIUS concept. The early

efforts of the MIUS program were largely directed to this end. Critical

to achieving this determination is the ability to predict, either in an

absolute or in a comparative sense (the Importance of the distinction

between these will be discussed in connection with the next general

3
area), the energy utilization or economics or both of a MIUS configuration

which satisfies a given set of utility demands. It is important that

comparative information on energy utilization and economics is sufficient

to enable determination of an optimum configuration (this is likely to

involve several iterations) and also to allow comparison with conventional

utility systeiiiri satisfying the same demands. The determination of the

various utility demands as a function of time for a given site application

is an activity peripheral to the MIUS program scope. However, it is

necessary that MIUS staff be capable of determining utility services

demands, even though work in this area does not directly support the

HUD-MIUS program objective to evaluate alternative methods of satisfying

these demands. A clear distinction must be made between the study of

factors in the end-use structures which affect the utility services

demands, and the factors which affect MIUS performance in satisfying

those demands. A software system which proposes to do energy analyses,

but primarily concerns itself with analysis of in-building energy transfer

systems, and only secondarily with the types of energy transfer systems

that occur in a MIUS plant configuration, is of limited use to the MIUS

effort for either conceptual or design evaluation. However, MIUS design

optimization is enhanced by an accurate calculation of site utility

loads, and for this reason computer programs which accomplish this are

considered in this report.

A second general area of evaluative concern is the nature and

adequacy of the simulations, or mathematical models, that lie at the

core of the different analyses. This concern is related to quantifying

the concept of the accuracy, or reliability of a calculated result and
is particularly important in the case of the energy performance aspects

the MIUS. A mathematical model of a complex configuration such as the

MIUS is obtained by examining its constituent parts, developing separate

models for each of those parts, and then combining the individual models

in an appropriate logical configuration that matches the hardware interconnections of the real system. In principle, if the mathematical

model (assuming no errors in concept) is created in enough detail, it

can come arbitrarily close to simulating the behavior of the real system

of interest. In practice, limitations of cost and effort involved in

obtaining a perfectly accurate simulation model are great, and simplifying

assumptions are introduced that also have the effect of decreasing the

accuracy. The question then is to determine the amount of accuracy

needed in a model that is sufficient to satisfy the needs of the user.

In the case of MIUS energy performance simulation, there is in fact not

a single answer to this question, since there are differing needs. To

determine comparative performance either for feasibility or optimization

studies, a simple steady-state or equilibrium model will siffice. For

the case where an estimate of absolute performance is needed, or where a

question of control stability under certain conditions of demand and

response must to be answered, a more complicated model which simulates

transient response has to be incorporated. For the programs discussed

in this report, the adequacy of the simulation will be considered in

light of the use for which the program is intended.

The third general area of evaluation centers around the various

aspects that become important in utilization of a program and may be

called "user factors." These depend strongly on who the user is - in

5
this case, primarily the professional technical staffs of the agency

participants who are involved in performing calculations for the MIUS

effort. They are generally knowledgeable in the hardware engineering

aspects, in the various concepts of performance simulation and programming techniques, and are using computer programs as research and development tools. To this type of user, flexibility and adaptability of a

program to a wide range of problems are more important than clear input

or output which appeals to the non-technical user who occasionally

purchases the services of a commercially available program. Another

aspect of importance is the logical structure of the program. One that

is constructed in logical modules is more accessible to evaluation, debugging, and alteration; and to the addition of increased capabilities at

some future date as the need arises. In the case of programs (commercial or

otherwise) developed elsewhere, documentation quality is of great

importance, as is availability. For those commercial programs that

might be of use, cost and ownership are both important considerations,

the latter being by far the most important. It is imperative that

agency users know exactly how a program arrives at a solution in order

to determine to their own satisfaction that a valid procedure is being

used. It i;:, this single factor more than anything else that leads to a

general recommeadation against the use of proprietary software even for

those programs that have good reputations.

The fourth area, which is related to the preceding discussion, is

the concern that commercial programs may be biased in such a way as to

systematically favor particular configurations over others. This idea

of built-in bias is a very difficult one to assess. Even though they

6
are very complex, no evidence of favoritism of one type of system over

another has been found In the algorithms that have been examined. On

the other hand, the complexity of the program itself can be used as a

subtle tool for bias by making it more difficult to analyze some configurations than others. This tends to discourage a complete examination of

the widest range of systems that could be considered for a given application, and Instead concentrates the analysis of those types of systems

that the owner/supplier of the program wants his client to see. In

terms of motive, one would not expect this to be a problem with all of

the commercial programs, but only with those developed and marketed by

interests that use the program as a tool to "market" certain types of

systems. In those latter cases if the program can be examined in detail,

this type of bias can be guarded against. Even if the program cannot

be examined in detail, user control over specification of the system

configuration which is to be analyzed still affords some protection.

In summary, the four areas discussed above form the basic criteria

against which the programs selected for this study were reviewed. They

can be stated as applicability, simulation adequacy and comprehensiveness,

user factors and implicit bias. As will be described in more detail in

the next section of this report, the description of each program is

broken down into categories and is concluded by an evaluative summary.

The evaluative summary for each program consists of a discussion of the

program characteristics evaluated with respect to the criteria discussed

above. The systematic description format provides an effective way of

presenting the information about program characteristics in order to

aid in the evaluation of each program.

7
3" Program Data and Evaluations

In order to aid in systematic individual analyses relative

to the previously described criteria and in comparison of the programs

that were studied, a set of 21 characteristics were devised. Descriptions

of each of the programs studied were made in terms of these standard

characteristics. Individual agencies were requested to accomplish this

task for programs they developed, while NBS completed the summaries for

the commercial programs. The characteristics tended to fall naturally

into three broad categories. The first deals with administrative items

such as source(s), availability, cost and other characteristics of

immediate interest to a potential user of a software system. The

second category contains characteristics related to the computational

aspects of the system, such as the types of calculations made, inputs,

outputs, and the logical structure of the system. The third category

is associated with detailed technical characteristics of the software

itself, such as the source language, the hardware on which it is

currently implemented, responsibility for maintenance and updating

of the software and so forth. Detailed descriptions of each of the 21

characteristics follow:

Administrative Category

1. Abstract

A short summary of software system (program) capabilities.

2. Author (s) : Person (s) who developed the software, if known, or known

' contact (e) who are technically very familiar with the

software contents.

8
3 . Owner (s)

Person (organization) who has ownership rights over the software

system.

4 . Availability :

How easy (or difficult) is it to obtain the system, or the use

of the computational services provided by this system (program)

5. Cost :

The expense of obtaining the system itself, or obtaining the use of the system, in arbitrary units (e.g. $/"run", $/minute)

It is recognized that the pertinent quantity to be used will be

different, depending on whether the program is proprietary or not.

It should be noted that purchase and use costs are quite different

and serve different purposes. Also, use costs alone can vary

widely even for the same program depending on individually

negotiated contracting arrangements. Additional information

on program costs is given in reference [1].*

6. Human Factors :

Amount and difficulty of input preparation required. Clarity

of the output.

7 . Turnaround :

Time required to get results from the time input sheets are

filled out. User procedures required for processing.

8 . Documentation :

Identification, availability, and a short content summary

of documentation available for the software system (program).

Computational Category

9 . Scope :

From a technical point of view the most important category

in this outline, A summary statement of what the system can

do and how it achieves this.

10. Output :

Quantities presented on the final printout. This may include

echoes of input data as well as calculated results. Availability

of options on output completeness.

^Numbers in brackets indicate references listed at end of text.

9
11. Input :

Input quantities necessary to do an analysis. How few? How many?

Availability of default options if partial input is desired.

12. Logical Structure :

The logical flow of the system elements.

13. Flexibility ;

The range of applicability of the system.

14. Interfacing :

Identification of complementary, independently developed systems

for which software linkages to this system exist.

15. Limitations :

Explicit and/or implicit limitations in the ability of the system

to produce useful results. One type of limitation may be, typically,

a limited range of applicability, another type would be questionable

or simplistic model of a physical process.

Sof tware/Hardward Technical '

1 6 . Source Language :

e.g. ASA Fortran, PL/1, and so forth.

17. Hardward Implementation :

Known hardware environments on which the software system (program)

is operational.

18. Portability :

Difficulty Involved in transferring this system (program) from

one hardware environment to another.

19 . Diagnostics :

Completeness and scope of system (program) in monitoring itself

(i.e. detecting internally developed faults) and in protecting

against improper (inapplicable) use.

20 . Maintenance ;

Person or organization responsible for maintaining the software.

10
21. Adaptability/Expandability :

Ease (or difficulty) of implementing changes or additions to the

software, if it were desired to modify the present scope of

the system.

Data on the surveyed programs follows the above format. The

characteristics are not universally applicable to the programs considered.

In the case of proprietary programs, information pertinent to many

characteristics is often not available.

Based on the presented data for each program, the actual evaluative

process was conducted systematically and with respect to the criteria

described in i lie last section. An evaluative summary follows the data for

each program as the twenty-second item. The summaries are based on the

program characteristics as delineated in the categories. The evaluation is

with respect to the criteria described in the previous section of this

report. These suiranaries by their nature highlight the most significant

findings and do not in some cases describe the complete evaluation process.

11
3.1 Heating-Cooling Calculation III (HCC-III)

1. Abstract

;

A computerized procedure for calculating design heating

and cooling loads for buildings in accordance with American

Society of Heating, Refrigeration and Air Conditioning Engineers

(ASHRAE) methodology

.

2. Author (s)

:

Unknown

3. Owner (s)

:

Automatic Procedures for Engineering Consultants, Inc. (APEC)

Suite M- 15

Grant-Deneau Tower

4th and Ludlow Streets

Dayton, Ohio 45402

4. Availability;

Available to members of APEC as a user service.

5. Cost

:

APEC membership fee is required. There is also a service

charge related to amount of program use.

6. Human Factors;

Unknown

7. Turnaround

:

Unknown

12
8. Documentation;

User's guide, which is available at a cost of $25, states the

program operation, engineering, technical aspects,

appendix, references and complete instructions.

9. Scope

The program is design oriented and lends itself to energy

analysis studies only by way of definition of peak load

conditions. Load calculations are performed on a room-byroom basis. Solar load calculations consider latitude,

longitude, daylight saving time factors, atmospheric

clearness, ground reflectivity, color and shading devices.

Cooling calculations are performed for each of 2A hours and

radiant load components are time averaged in accordance

with building mass.

Design goals are to provide, for any designated geographical

area and weather system, an hour-by-hour evaluation of the

interrelating effects of various interior conditions, timevariable interior load producing sources, and building

environmental surfaces, in order to determine peak load

conditions, calculate cfm quantities, and arrive at actual

system loads for the project and its various sub-parts.

10. Output:

Complete breakdown of all input factors, and cooling and

heating peak load components.

11. Input

Room data for each master room indicating room dimensions,

type number and count or dimensions of all exposed surfaces,

and quantities of internal load producing items as well as any special override factors involved.

12. Logical Structure:

Unknown

13. Flexibility:

Not Obtained

14. Interfacing:

Unknown

13
15. Limitations

;

Primary limitations derive from the relatively small

IBM/1130/8K single disk computer configuration for which

the program was actually written, and are related to project

size.

16. Source Language:

Fortran IV

17. Hardware Implementation:

IBM/1130 Systems (8K CORE, 1132 printer)

18. Portability:

Unknown

19. Diagnostics

;

Unknown

20. Maintenance

:

By Owner

21. Adaptability/Expandability

:

Unknown

22c Evaluative Summary;

The major limitations of HCC-III in usefulness to the MIUS

technical effort are related to its proprietary nature and scope.

Only a computational service based on the program is available,

and not the program itself. The resultant inability to verify or adapt progreun algorithms greatly decreases its usefulness as a research tool for MIUS. Its only potential use would be in a situation where it had computational capabilities not otherwise

available in a non-priprietary program in the possession of the

MIUS technical staff. Since its scope is limited to the

calculation of peak heating and cooling loads only, this is not

the case.

Ik
3.2 Trane Air Conditioning Economics Program (TRACE)

1. Abstract ; This program computes energy loads, fuel requirements, and

heating/cooling system costs for different building and

mechanical system design alternatives up to a maximum of four

per run, and compares the results.

2. Author (s) : Unknown

3. Owner ( s

)

: The Trane Company

LaCrosse, Wisconsin

U . Availability : Proprietary; used through Trane engineering representatives.

Information regarding program use is available from Trane local

offices

5. Cost : $800/r\in (four building/system design alternatives).

6 . Human Factors : One input manual is completed per rxm from project design information. Assistance is available from Trane, and the input

and users manuals also contain clear and complete detailed

information. Estimated input preparation time is 3 man-days.

Completed input manual is sent to home office for key pmching

of input data and computer batch processing. Output is returned

by mail.

7 . Turnaround : Approximately one week per manual; limited by mails and Trane

keypunch in addition to computer turnaround time.

8 . Documentation : Documentation manual [2] and input manual [3] are available

on request from TRAJ^E.

9 - Scope : Loads : Actual weather data for one year are condensed by a special procedure into 12 "typical days", one for each

calendar month in the year. Each of these typical days consists of a 2U-hoiar profile. These are in turn used, along

with recommended ASHRAE procedures (1967) [h] for heating and

cooling space load calculations. Base loads are included by

separate schedules. Simulation: Eleven common air-side systems

are simulated (see item 13), primary equipment is

15
simulated by energy performance curves that are functions o the demanded output of the equipment. Performance curves

can be supplied by user, or in the case of some equipment models predetermined performance curves can be accessed

(mostly Trane equipment models). Financial Analysis:

Computes annual o\ming and operating costs for each

alternative and between alternatives. Computes incremental

payback, and present value rate of return.

10. Output

;

Design values, monthly fuel usage (water, electricity, etc.)

economic input echo, PITI, depreciation (tax and book), cash

flow, P + L, present worth of total owning and operating

costs; comparison basis P + L, cash flow, cumulative cash flow,

and discounted cash flows to equity and first cost.

11. Input

;

Room design conditions; base utilities (per schedule); lights,

people, and miscellaneous (per zone per schedule), glass,

wall, shading for external zones; economic input (installed

. costs, maintenance cost, depreciation, mortgage life, and so forth), rate structures: air side input (type, economizer,

usage schedule, etc.); equipment type code and number of units.

12. Logical Structure:

Program is in 5 blocks which run sequentially, generating

Internal files to feed the next program. Weather data and

equipment performance are read from tapes.

13. Flexibility;

A maximum of four alternative schemes can be analyzed per

run. A maximum of ten base and auxiliary load schedules

can be input per alternative. Each alternative can have up

to 20 thermal zones and one or two air-side systems specified.

The following air-side systems are simulated:

a. High velocity variable air volume.

b. Low velocity variable air volume.

c. Double duct

d. Multizone

e. Terminal reheat

16
f. Packaged terminal air conditioner.

g. Hydronic heat pump.

h. Fan coil.

i. Induction,

j. Radiation

k. Variable temperature constant volume.

14. Interfacing;

The program does not presently interface with any other

software systems.

15. Limitations:

No simulations exist for T/E plants or bulk thermal storage

devices. Due to the remote batch processing procedure,

no mid-stream evaluation is possible.

16. Source Language;

Fortran

17. Hardware Inplementation;

Unknown

18. Portability;

Unknown

19. Diagnostics:

Unknown

20. Maintenance:

Maintenance by The Trane Company at times unknown.

21. Adaptability/Expandability

There is no option for anyone outside of the Trane Company

to adapt or expand the program. Trane plans to include

other equipment (e.g. other manufacturers and T/E models)

at some indefinite time in the future.

22. Evaluative Suimnary:

TRACE is one of five commercial computerized systems considered

in this report which accomplishes a multi-step total project

analysis consisting of loads determination, mechanical equipment simulation, resultant energy requirements determination,

and a comparative economics analysis between alternative

systems. Because of the batch mode of processing, the output

of one analysis section is automatically input into the

subsequent one. Therefore no midstream evaluation of partial

results is possible. The period of performance analysis is

usually taken to be one year.

IT
Load calculation procedures follow ASHRA.E recommended

procedures (196T) [^]. Although weather data is input

for the whole year (876O hours), the program calculates

from this data twelve "typical weather days" (each with

values for 2k hours), one for each calendar month. All

subsequent monthly energy requirements are based on use

of the same "typical weather day" profile for a whole

month. Building loads based on this type of calculation

are less suitable for determining a prediction of actual

energy performance than they are for determining comparative

energy performance of different mechanical systems (or the

same system controlled in different ways), for the same building configuration.

All simulations of air-side systems and mechanical equipment

performance are of an equilibrium nature. Part load

performance ciorves for equipment can be either input by

the user, or by user option, some are available on computer

files.* A wide range of total system configurations can be

simulated by utilizing appropriate individual simulations.

Separate scheduling of different types of base and

auxiliary loads allows for close reproduction of actual

situation. Total energy plant configurations and thermal

storage devices are not simulated.

The prime limitation with respect to MIUS use of this program is its proprietary nature. It is, as a result, not

subject to verification of the exact nature and validity of

its algorithms by detailed analysis of the software. In

addition, the cost of use as a service precludes its use

as a research tool, where many computer runs are often

necessary to complete a specific project need.

^Mostly Trane equipment
3.3 Computerized Evaluation of Energy Requirements, Equipment Selection,

and Economic Comparison for Building Systems (E-CUBE)

1. Abstract:

For a zone or a building energy system: estimates hourly,

monthly and annual energy requirements, determines the

energy consumption of various types of systems which may

be used to meet those energy requirements, compares total

owning and operating costs of the various systems being

considered.

2. Author ( s )

Contact for Technical Matters:

W.E.Evers, Jr.

Laclede Gas Company

St. Louis, Missoiiri

3. Owner ( s

)

: American Gas Association (AGA)

1515 Wilson Blvd.

Arlington, Virginia 22209

k . Availability : Software is proprietary; purchase of the computational

service only is available, either directly through the CDC

CYBERNET Network, or through selected local gas utilities.

Previous accounting and billing procedures have to be

arranged before the service can be used. User information

is available from AGA.

5. Cost:

Approximately $50 for a complete analysis including

economic comparison (a maximum of four alternate systems

may be considered for a given building).

6. Human Factors:

Engineering knowledge necessary to complete input data

forms, which are preformatted and come with instructions

for us e

7- Turnaround : Depends on mode of access . Terminal response would make

this mode inherently much faster than batch processing mode.

8. Documentation : A copyrighted, complete users input instruction manual is

available [5]. The introduction contains short qualitative

descriptions of the logical structure of the programs and

their interrelationships.

19
9. Scope

;

a. Energy Requirements Program: From design point

values for thermal and base electric loads, calculates

hourly loads for a weather year by scaling according

to variations in dry bulb and dew point temperatures,

solar radiation, and cloud cover. Building use and

operation schedules can account for thermostat setback or system shutdown. Building thermal storage

and delay effects are considered. Simultaneous

heating/cooling requirements can be accounted for.

b. Equipment Selection and Energy Consumption Program:

. Calculates actual energy required by equipment to

meet energy requirements calculated in (a) . Up to

four different plant systems can be evaluated in

each run.

c. Economic Comparison Program: Rate of return calculation performed for each plant system analyzed

in (b) is examined comparatively.

10. Output

;

a. A tape with hourly thermal and electrical loads; a printout of peak heating, cooling, electrical, and

process loads for each month and the time that they

occurred, cumulative values of loads.

b. Printout of monthly summary of gas, fuel, electricity

consumed; peak electric demand; number of operating

hours for each generator and chiller; evaluation of

thermal energy usage.

c. Relative to the cheapest first-cost system, the

following differences: annual interest, taxable

income, annual tax, after taxes cash flow, net cash

flow.

11. Input

:

a. Design point (peak) loads and base electric loads,

weather data, solar data, occupancy profiles, system

operating schedules, setback schedules, lighting

and process load profiles.

b. Fuel heating values, system characteristics, generator

schedule, chiller schedule, equipment performance

data.

c. Initial and operating cost data, tax rates, interest

rates, depreciation rates, irregular annual operating

cost data.

12. Logical Structure:

Modular.

13. Flexlbi lity

:

This program contains

simulate five general

five subroutines which are used

types of system configurations.

20

to

The
detailed performance of any chosen configuration is variable

due to user control of specific equipment performance curves. The five configurations are:

a. Total Energy System with Boilers,

"b. Total Energy System with Direct Fired Heater.

c. Conventional System with Boiler.

d. Conventional System with Direct Fired Heater.

e. All Electric System.

14. Interfacing;

Not Known

15. Limitations

Limited as to the maximum number of input schedules and

air-side simulation systems. Limited to a maximum of

four alternatives per run.

16. Source Language;

Fortran

17. Hardware Implementation;

CDC 6600

la. Portability:

Not Known

19. Diagnostics

Not Known

20. Maintenance

By Owner

21. Adaptabili ty /Expandability

Unknown

22. Evaluative Summary;

This program is another which falls in the category of

offering a complete energy analysis of a single or multi-building project, from building loads to mechanical

systems energy requirement simulation, to utility costs

based on those requirements, to economic comparisons

between alternate configurations. The period of performance

analysis is usually taken to be one year. Thermal load

calculations are done on an hourly basis for this entire

period. Transmission loads are obtained by scaling, according

to weather conditions, from peak load values and their

associated weather conditions, which must be supplied to the

program. Loads based on this type of calculation are less

suitable fof prediction of actual energy performance than they are for determining comparative energy performance of alternate

21
systems. In fact, with the number of system simulations

(all steady state, equilibrium type) limited to five con- figurations (for which different performance data may be

supplied each time a run is made) the program is mostly

limited to the comparison of various total energy configurations to conventional systems, which was the primary

reason for its development by GATE.-

The basic limitation with respect to the use of this

program for the MIUS effort is its proprietary nature, for the same reasons that were discussed in the previous evaluative

summary.

'22
The Meriwether Energy System Analysis Series

1. Abstract

Calculates building loads, simulate air side systems, determine

J energy requirements for mechanical and electrical components

for every hour of the year and make annual suimnary. Also

performs economic analysis of various systems.

2. Author (s)

Ross F. Meriwether

3. Owner (s)

Ross F. Meriwether & Associates, Inc.

1600 N.E. Loop AlO

San Antonio, Texas 73209

A. Availability;

Computer Science Corporation

INFONET System,

University Computing System

Time sharing as well as batch modes.

5. Cost;

Depending upon the extent of analysis, it could be as small as $10/run or as large as $750/run.

6. Human Factors;

Ne^d comprehensive knowledge of air-side systems, not too

easy to use otherwise. It is important that the user understand the computer system simulations.

Approximately one hour is required for data preparation

and key punch per zone.

7. Turnaround;

1/2 to 1 minute computer execution time per zone per

weather year.

8. Documentation

No algorithm ever published, since software is proprietary.

A user's manual, available only from the program owner, has

Instructions which are complete, however.

9. Scope

The heating and cooling load calculation is similar to Carrier

manual method. Air-side system simulation includes terminal

reheat, induction fan coil, dual duct, VAV and VAT. It can handle gas, oil, electric, total energy, and heat pump systems.

Hot water thermal storage can also be simulated. Utility cost

analysis and economic comparison programs are quite comprehensive.

23
10. Output;

Detailed output as well as selective and simpler output are possible. Monthly summary, annual summary, space summary and

system summary are available for energy consumption as well

as for the demand.

11. Input

:

Building data is very simple but system data, and operational

data are very detailed. Approximately 30 data sheets are

attached in the user's manual.

12. Logical Structure;

Five main programs, which each utilize numerous specialized

subroutines, are run sequentially to accomplish a complete

analysis. The names of these program blocks are descriptive

of their functions .

a. Energy Requirements Estimate (ERE)

b. Total Coincident Requirement (TCR)

c. Equipment Energy Consumption (EEC/A, B)

d. Monthly Utility Costs (MUC)

e. Economic Comparison of Systems (ECS)

13. Flexibility:

Equipment and air-handling systems configurations are variable

because separate types of equipment have separate simulations

which can be linked in many possible ways. The air-handling

system simulations available are;

a. No excess cooling or reheating, demand coil

leaving temperatures.

b. Terminal reheat with scheduled (or fixed) cold

coil discharge temperature during cooling.

c. Terminal reheat with scheduled (or fixed) cold

coil discharge temperature during cooling or heating.

d. Induction or fan-coil type system with scheduled

primary air temperature.

e. Terminal reheat with cold coil discharge temperature

set by maximum demand of any section.

f. Dual-duct or multi-zone with scheduled (or fixed)

hot and cold deck temperatures.

g. Dual-duct or multi-zone with deck temperatures set

by greatest demand.

h. Variable volume system for solar and internal

loads, with separate single-duct system to offset

transmission.

i. Standard variable volume system.

lA . Interfacing

;

It has been interfaced with NBSLD and is being interfaced with

the TAGS program at the Dept. of Public Works of Canada. (See

NBSRFM data form)

.

2k
15. Limitations;

Although the system simulation Is very comprehensive for the

conventional system analysis, the program may need Improvement

for the accurate temperature simulation of heavy structures,

residential buildings and other non-conventional buildings.

T/E type systems are not simulated per se , but can be

"constructed" from the individual element simulations. The

system Is limited as to the maximum number of building

auxiliary load schedules and system simulations, even though

the total number of configurations available is large.

16. Source Language;

Relocatable files on INFONET-UNIVAC. Source language is

Fortran.

17. Hardware Implementation;

Unlvac 1108 System

18. Portability;

It Is on time sharing files.

19. Diagnostics

Diagnostics are very comprehensive and complete.

20. Maintenance

R . F . Meriwether

21. Adaptability/Expandability;

Unknown

22. Evaluative Summary;

This program series is another of those that fall in the

class which offers a complete energy analysis of a single

or multi-building project, from loads determination to

energy requirements simulations of building air-side systems

and plant equipment systems, to utility costs estimates

based on those requirements, to economic comparisons between

alternative candidate configurations. In this series midstream evaluation of results is possible. The period of

performance analysis is usually taken to be one year. Thermal

load calculations are done on an hourly basis for this period.

In this particular case, the transmission loads are calculated

by scaling, according to weather conditions, from peak values

and associated weather conditions, both of which are supplied

to the program. Building loads based on this type of calculation

are less suitable for prediction of actual energy performance

than they are for determining comparative energy performance

of different mechanical systems (or the same system controlled

in different ways), for the same building. All simulations

of air-side systems and mechanical equipment energy performance are of a steady-state, energy balance nature.

25

National Bureau of Standards Load Determination Program (NBSLD)

1. Abstract

This program determines building heating and cooling loads

and variations of the interior environment, based on actual

weather data, on an hour-by-hour basis. It was developed

as a research tool to aid in the thermal design of buildings.

2. Author (s)

Dr. Tamami Kusuda

Thermal Engineering Systems Section

Center for Building Technology, NBS

Washington, D.C. 20234

3. Owner (s)

Public (U.S. Gk)vernment)

4. Availability;

Symbolic source decks or tapes (in either BCD or ASCII coding)

available on request for the cost of production. Available to

all Federal government workers through the Computer Sciences

Corporation INFONET system under GSA contract. Further availability details can be obtained from the author.

5. Cost;

Depends on costs charged by a particular computer center.

Execution time is 4 minutes per zone per typical weather

year, on the UNIVAC 1108, EXEC- 8 system at NBS.

6. Human Factor;

Input data form available and although straight forward

to prepare, it is detailed. Output has option of either

abbreviated or detailed printout, it can also be written

on magnetic tape for later use.

7. Turnaround

Processing at NBS is done in batch or time-sharing mode.

It takes about one hour to keypunch data for the first zone

in a building, additional zones are 10 minutes each. For

execution time see Item 5.

8. Documental ion : A user's manual is available as an NBS Building Science

Series publication. Contents include description of

program, listing of completed program, and algorithms

of the main program and subroutines [6].

27
9. Scope;

The program will compute the following:

a. Design loads based on a design weather cycle.

b. Hour-by-hour loads based on actual weather data

of any locality, for a fixed room temperature

or a fixed range of room temperature fluctuation.

c. Hour-by-hour loads based on actual weather data

using the ASHRAE "weighting factor method".

d. Room temperature hour-by-hour fluctuation when limited

or no heating (and/or cooling) are supplied, and a nonzero load is computed.

10. Output:

a. Abbreviated: Response factprs for walls; daily maximum

and total cooling and/or heating loads; hour of occurance

for maximum load.

b. Detailed: Input data, response factors for walls,

hourly dry and wet bulb temperature (outside) , hourly

inside dry bulb temperature, hourly cooling and/or

heating load, and daily maximum and total loads.

11. Input

;

a. Schedules of lighting, equipment, and occupant

loads, and their respective maximum values.

b. Locality data (longitude, latitude, weather data

tape, time zone, etc).

c. Wall construction data (number of layers, thermophysical

properties of each layer).

d. Building, zone, or room dimensional data.

12 . Logical Structure:

Two main programs:

a. Main program to decode the weather tape from

WeaMier Bureau into binary code and put onto

tape.

b. Main program for NBSLD with approximately 35

subroutines connected to the main program or with each other (See Figure 1) .

13. Flex ibility:

The two main programs above can either be run separately, or

run together with (a) followed by (b) . Any type of building

with known construction and internal heat generation can be

analyzed,

14. Interfacing

:

Has been interfaced with Ross Meriwether's system simulation

and economic programs package directly (see following NBSRFM form).

Also could be used as input for any specially written individual

system simulation program.

28
15. Limitations

a. Apply to any building under Item 9 above, types

(a) and (c).

b. Apply to any building which can be divided into

rectangular shaped zones for item 9, types (b) and

(d).

c. Cannot simulate partial exterior shading from adjacent

buildings, trees, hills.

d. Calculates space loads only, does not have air-side

or plant system energy simulations as an integral

part (but see item. 14)

16. Source Language:

Fortran V

17. Hardware Implementation;

Main program for load computation can be used on any computer

system with a core memory larger than 50,000 words, or less

if overlay or segmentation capability is available in the

system. Main program for decoding the Weather Bureau type can

be used only on Univac System.

18. Portability;

Program can be copied into BCD code on another tape and

recompiled by other system's Fortran compiler.

19. Diagnostics

These are of a limited and basic nature.

20. Maintenance;

Dr. T. Kusuda is responsible for the updating of the program

with the assistance of Messrs. J. Hill, S. Liu, and J. Barnett

of NBS.

21. Adaptability/Expandability

Modification of the program (main or subroutines) for a particular application with special requirements is

straightforward.

22. Evaluative Summary:

NBSLD was specifically developed as a research tool which,

when properly applied, can accurately predict the thermal

loads and interior space conditions of a wide variety of

building design configurations. It computes loads and interior

space temperatures on an hourly basis, usually for a complete

weather year (but can be for any part thereof), using actual

weather data. In order to be able to simulate the greatest

possible number of building design configurations, the thermal

response properties of the building structure itself are calculated from a detailed description of the thermophysical

properties of the structural components and also individual

details of the construction.

2?
External effects such as solar loading and air infiltration

are correctly accounted for. One shortcoming in

the technical aspects of the load calculations done by NBSLD

is the inability to account for shading by objects external

to the building itself, such as trees or other buildings.

This last factor could result in a major overestimate in the

cooling load, for example, of a tall building which, during

sometime period each day is largely in the shade of an adjacent building. In the hands of a knowledgeable user who

is aware of this limitation, misapplication of the program

could be avoided.

There is a trade-off that is made in achieving great flexibility

in application: The amount of data required for computation is

greater than for other programs. Therefore, the amount of user effort necessary to assemble and input this data, and the

associated probability of some error in so doing is correspondingly greater. Another factor associated with the program

complexity is the greater amount of computer execution time

required, compared to other programs. There is no .significant

resultant effect, in terms of human factors, however, when

computer execution time is on the order of minutes instead of sec onds. However y the aspect of the increased execution time that

would be significant to some users would be the related cost of

such a system.

The effect of the increased execution time on computer costs

is for the most part not significant to MIUS agency users who

would implement NBSLD on their own systems.

The lack of energy requirement simulations for building

mechanical systems and plant equipment is the major limitation

of NBSLD in terms of its usefulness to the MIUS effort. In

principle, the development of the NBSLD/Meriwether Energy

System Analysis Series hybrid shows that this limitation can be overcome. In practice, however, that hybrid (see the

related Evaluative Summary) is probably not the best final

solution.

As a system standing by itself, the primary value of NBSLD

to MIUS is the capability it can provide for the reliable

verification of building thermal loads for specific designs.

This capability may well be necessary in the evaluation process

for MIUS demonstration proposals. In any use of NBSLD by the

MIUS effort, the assistance of its author in guaranteeing

its proper application would be available.

30
rhe Meriwether Energy System Analysis Series/NBSLD Hybrid (NBSRFM)

1. Abstract

This hybrid combines the load calculation capabilities of

NBSLD with the system simulation capabilities of the

' Meriwether Energy System Analysis Series.

2. Author (s) ; Ross. F. Meriwether

T. Kusuda (NBS)

3. Owner (s)

Ross F. Meriwether & Associates, Inc.

1600 N. E. Loop 410

San Antonio, Texas 78209

4. Availability;

Computer Sciences Corporation INFONET System (time sharing

mode). Contact owner for information.

5. Cost;

By special arrangement for long term use contracts by

government agencies. Similar to costs of Meriwether

Analysis alone on a per run basis.

6 - Human Factors;

See NBSLD, Meriwether sections of this report.

7. Turnaround

Approximately the sum of turnarounds for each program

system separately.

8. Documentation

The separate user manuals are sufficient for use of the

hybrid system, with additional information available from the

owner.

9. Scope

The hybrid combines the capabilities of the separate

constituents

10. Output

A combination of the outputs of NBSLD and the Meriwether

Analysis Series.

11. Input

The sum of inputs required for each of the programs

separately, except that weather and building thermal

property data are not repeated.

31
12. Logical Structure : NBSLD replaces the load estimation function that is a normal part of the Meriwether system.

13. Flexibility : Combines the NBSLD abilities to calculate loads for a

•wide range of building configurations with the flexibility

of the Meriwether air-side and equipment simulations.

ih . Interfacing : The necessary software linkage to accomplish the

hybridization exists and is debugged.

15 . Limitations

:

Same as for each system separately.

16. Source Language : Fortran. Relocatable Files on the INFONET-Univac system.

IT- Hardware Implementation:

Univac 1108

18. Portability : Unknown

19. Diagnostics : Comprehensive

20. Maintenance : R.F.Meriwether

T.Kusuda

21 . Adaptabl lity/Expandability : Software modifications would be technically straight

forward

.

22 . Evaluative Summary : Conceptually, the linkage of the two program series that

comprise this hybrid combines the complementary capabilities

of both into a single entity, with a concomitant increase in

total computational power and flexibility. In particular,

substitution of the more sophisticated and accurate NBSLD

in place of the Meriwether load estimating procediire improves

the capability for performing predictive analyses of actual

energy performances which is a more difficult task than determination of an optimum configuration by the comparative

analysis of several alternatives. Along with the increased

capability obtained from hybridization, however, there is a related increase in effort and difficulty in its use, which is

approximately the sum of the efforts for each of the programs

when used individually.

32
This hybrid also occupies a unique position regarding its

ownership status and consequent availability. Because one of

the constituents of the hybrid is proprietary, the whole is

in effect controlled by the owner of that constituent. IL

therefore suffers (in terms of usefulness to MIUS) from the same shortcomings of any such program; verification of program

validity by direct examination of the software is not possible,

and any computational services of the hybrid must be purchased.

The government contract with the owner of the Energy Systems

Analysis Series (Meriwether) under which the hybrid was first

made operational has since expired. A need to make the hybrid

available for MIUS analysis would require new contractual

arrangements with the owner. Because of the problems associated

with lack of access for program verification, if a definite

need is found for a substantial amount of this sort of

wide-scope computational analysis, it would probably be more

advantageous for the MIUS effort to obtain or develop a set

of non-proprietary system simulations to link up to NBSLD. It

should be noted that at this time, none of the existing

government developed MIUS type simulations have the conf igurational

flexibility of this hybrid.

33
Computer Program for Analysis of Energy Utilization in Postal

Facilities (TAGS), et al.

1. Abstract

;

This program series has evolved over a period of several

years. There are four identifiable versions of it, named

as follows:

a. Version I - Computer Program for Analysis of

Energy Utilization in Postal Facilities.

b. Version II - Unknovm

c. Version III - Unknown

d. Version IV - Energy Utilization Analysis of Buildings

Computer Program.

All versions calculate heating/cooling loads and simulate

air-side and primary systems on an hourly basis. All versions

have a separate subprogram which performs an economic analysis

of alternatives.

2. Author (s) ; Met in Lokmanhekim, et al.

3. Owner (s)

:

a. Version I - Public (U.S. Government)

b. Version II - General American Research Division (GARD) of

General American Transportation Corp. (GATX)

Niles, Illinois

c. Version III - Hittman Associates, Columbia, Maryland

d. Version IV - Metin Lokmanhekim

Ellicott City, Maryland 21043

4. Availability;

a. Version I - GARD/GATX will provide a Fortran source

listing on magnetic tape. The source listing is also

informally available on request from several user government agencies.

b. Version 11 - Proprietary

c. Version III - Proprietary

d. Version IV - The source deck, binary, or computational

services are all available from Metin Lokmanhekim.

5. Cost:

a. Version I - Source tape from GARD/GATX

about $675. Source tape from government agencies at cost.

Cost per run depends on user facilities.

b. Version II - Unknown

c. Version III - Unknown

d. Version IV - By negotiation.

6. Human Factors:

a. Version I and II - Input data is required zone by zone. Detailed input requires knowledge of building geometry

3h
and shading and takes about four days per run for

the familiar user,

b. Versions III and IV - Data may be input in blocks and zone by zone. Buildings described in detail require

» two days of input data preparation by an experienced user. Rough estimates of energy consumption using block

inputs only require four hours.

7. Turnaround

Depends on user facilities; for block input on Version IV,

turnaround is about two days.

8. Documentation

A user's manual for Version I only [7 ].

9. Scope

All versions calculate heating/cooling loads and simulate

air-side and primary systems on an hourly basis. Later versions

provide more equipment simulations, utilize the building

response factors in the load calculations and permit internal

temperature variation. Version I calculates the response

factors. All versions include a separate subprogram which

performs an economic analysis of alternatives.

10. Output

a. Version I - Building heating and cooling load design

hours; maximum and minimum heating and cooling loads

by zone; wall and roof specif icatiop ; sensible, latent,

lighting, and electrical loads by zone; plots of the

thermal load on a daily, weekly, monthly, or yearly

basis; edited thermal loads set up for simulation;

air-side system ratings and zone air flows; summary

of equipment sizes; monthly energy requirements by

energy type; monthly plant water requirements, input

economics echo; and annualized owning and operating costs.

b.' Versions II, III, and IV - Similar output.

11. Input

a. Version I - Hourly weather data (dry - and wet-bulb

temperatures, cloud amount and type, wind velocity,

and atmospheric pressure), latitude, longitude, time

zone, infiltration, load, various schedules, surface

coordinates and descriptions for each surface bounding

or shading a zone, number and type of plots, design

set points of equipment, type of air-side systems,

energy types, types of chillers; capital and operating

costs, interest rate, lifetime, and purchased energy

rates.

35
b. Version II and III - Unknown

c. Version IV - Building data can be input in blocks

instead of surfaces zone by zone; surface descriptions

do not require layer U-values; a greater choice of

equipment simulations is offered; temperature schedules

are permitted; parametric design evaluation requires

a card change.

12. Logical Structure:

a. Version I - Seven subprograms run in series .

b. Versions II and III - Unknown

c. Version IV - Four subprograms; loads, temperature

variation, systems simulation, and economics.

13. Flexibility;

a. Version I - The program can handle very detailed

building information.

Air-side systems are single zone, multi-zone, dual

duct, single zone reheat, unit ventilator, unit heater,

and floor panel heating. Five types of chillers and

four energy sources are allowed. No part-load curves are permitted.

b. Versions II - Unknown

c. version lii - unknown

d. Version IV - In addition to the above, two- and

four-pipe fan coil units, through-the-wall units,

split system, and varying volume with time can be

simulated.

14 . Interfacing

:

Versions I and IV thermal load outputs can be read into

the AXCESS program.

15. Limitations:

a. Version I cannot simulate a T/E plant using turbines

or anything but steam-based cooling, nor can it

simulate fan coil and induction units.

b. Version IV cannot simulate induction units and has the same limited simulations of T/E systems.

16. Source Language;

All versions are written in Fortran IV. Version IV is also

available in Control Data Fortran.

17 . Hardware Implementation:

All versions are operational on IBM 360 and 370 series, CDC

3600,64601, 6600 and 7600 series, and Univac 1108. The weather

decoding subroutines is machine dependent on these machines.

36
18. Portability;

The program is very portable due its wide application base

and the fact that everything but the weather decoding routine

is non-machine dependent.

19. Diagnostics:

a. Version I - None

b. Version II - Unknown

c. Version III - Unknown

d. Version IV - Coded printouts but no accompanying

manual; logical errors cause abortion of run.

20. Maintenance;

a. Version I - None

b. Version II - Unknown

c. Version III - Unknown

d. Version IV - By Metin Lokmanhekim

21. Adaptability/Expandability

a. Version I - The source listing may be expanded by the

user.

b. Versions II and III - Potential unknown.

•c. Version IV - By user if source has been obtained;

• by Metin Lokmanhekim if negotiated.

An expanded simulation base is not difficult to achieve due

to modular program construction.

22. Evaluative Summary:

All versions of this program offer a complete energy analysis

of a single or multi-building project, including load

determinations, air-side system simulations, plant equipment

simulations, and annualized owning and operating costs. A

modular series program structure permits midstream evaluation

of results. The period of analysis is usually one year.

All calculations are performed on an hourly basis in an equilibrium or steady-state simulation. The thermal loads

are actually computed from building thermal properties, not

scaled as in the Meriwether program series. Tiuilding loads based on these calculations are suitable for prediction of actual energy

performance. Simulations of a total energy plant are limited

to engines with steam recovery for either absorption or steam

turbine centrifugal chillers. Equipment is sized on the basis

of the peak hourly heating and cooling loads, and no part-load

efficiencies may be input.

The preparation of input material is difficult and time consuming

for all but the single block analysis, requiring a two to four

day effort by competent and knowledgeable engineers. The com- plexity of the input process increases the probability of

input errors. The block input option which permits quick

37
parametric analysis in the conceptual design is only

available with Versions III and IV. In Version I, response

factors are calculated from surface descriptions by methods

comparable to those used in NBSLD. The internal temperature

set-point may be varied only in Version IV. The number of

equipment simulations of Version 1 is limited, but expansion of

this section is not difficult.

Versions II, III, and IV are proprietary, and suffer the same

disadvantages for MIUS use mentioned previously. The source

deck of Version I is presently in the possession of

several participating agency teams, and though the source

deck of Version IV is available, it would have to be

purchased. The excellent thermal load calculational procedures

of this program and limited equipment energy simulation base

make it a prime candidate for either marriage to a program

with a strong and flexible simulation base, or for use by

itself with the development of the most likely MIUS plant

equipment simulations.

38
Alternate Choice Comparison for Energy System Selection (AXCESS)

1. Abstract

The AXCESS Energy Analysis Computer Program provides

estimates of the comparative energy uses of alternate methods

of meeting the energy requirements of buildings or processes,

and an economic analysis of the alternatives.

2. Author (s)

For technical matters contact:

Edward Douglass

Computer Applications

Edison Electric Institute

3. Owner (s)

Edison Electric Institute

90 Park Avenue

New York, New York 10016

4. Availability:

The AXCESS program was released to investor owned electric

utilities through a nationwide series of user training

programs beginning in November 1972. Each of these companies

has been furnished with a program source deck, user's manual

sample problem and help in achieving implementation on its own computer AXCESS is also available to these utilities

through a remote service bureau. Under similar conditions,

it has also been made available to MIUS agency participants.

5. Cost:

Depends on user system.

6. Human Factors:

Relatively large time and effort requirements for preparation.

One run batch for entire energy analysis.

7 . Turnaround : Depends on user system.

8. Documentation

a. Engineering Analysis :Users manual [g] and a programmer

manual [9] are available on request.

b. Financial Analysis: Users manual [10] and a programmer

manual [11] are available on request.

9. Scope:

The program uses standard engineering principles but bases

all its calculations on input, so that as the quality of

input increases, so will the quality of the output. It is

well, however, to remember that the program's purpose is to

provide a comparison of alternate designs and the results for

each scheme have much more validity when reviewed in relation

to each other. 39
The submetering capability allows the calculation of actual

demand contributions of incremental loads to the total permitting alternate fuel source capability within one scheme.

10. Output;

a. Hourly meter reading: usage and demand.

b. Hourly deficit or excess KW and KWH if the T/E

' scheme satisfies the load first.

c. Day by day meter readings: ase and demand.

d. Time of day of occurrence of maximum meter reading.

e. Total Btu heat rejected from all chillers, by month.

f. . Monthly excess/deficit of heat.

g. Annual excess/deficit of heat.

h. Net Present Value or Internal Rate of Return.

11. Input

;

a. Project Description data including building operation

schedules.

b. Base load items of usage including usage profiles and

special period profiles.

c. Waste heat utilization-item usage.

d. Heating/cooling load data.

e. Space type data.

f. Zone description data.

g. On-site generation system performance.

h. Terminal and primary system descrirition incluriinp;

waste heat utilization and dual fuel operation

description.

1. Meter description and fuel codes,

j. Capital costs.

k. Maintenance and operating costs.

1. Tax rate.

12. Logical Structure;

Single run with all parameters input at start, modular

program structure .

13. Flexibility:

For the same building, with the same usage, the program

permits simultaneous comparison of up to six alternate methods

of meeting the energy requirements. Such things as the HVAC

system and the lighting levels may vary among these six

"schemes", while the building occupancy pattern is assumed

to be the same for each scheme. The air-handling and plant

system simulations available are;

a. Dual Duct.

b. Multi-Zone

c. Single Zone Reheat

d. 100% Variable Volume

e. Variable Volume with Reheat

f. Celling Induction

ha
g. Heating and Ventilating

h. 2-Pipe Induction

i. 4-Pipe Induction

j . 2-Pipe Fan Coil

k. 2-Pipe Unit Ventilator

1. 4-Pipe Fan Coil

m. 4-Pipe Unit Ventilator

n. Unitary Cooling Units with Separate Heating

o. Unitary Heat Pumps

p. Boilers

q. Furnace

r. Refrigeration

s. Simultaneous Heat Pumps

t. Changeover Heat Pumps

u. On-Site Generation-KW Balance

V. On-Site Generation-Thermal Balance

14. Interfacing;

Presently interfaced with TAGS (Version I) and the Lokmanhekim

revision (Version IV) of the Lokmanhekim series.

15. Limitations;

This is a tool that enables the designer to make a comparison of various designs, not to generate a design.

While the program makes some normal design assumptions in

the event of a missine inmit. it alwavR rpnl1As^s f^e^don as input.

16. Source Language;

Fortran

17. Hardware Implementation;

IBM 360 and Univac 1108.

18. Portability;

Moderately Portable

19. Diagnostics

None

20. Maint enance

Software revision notices sent to holders of software by owner.

21. Adaptability/Expandability ; Since the Fortran source program deck is available and

because of the modular structure of the software, expansion

and adaptation of the program to model MIUS designs is

possible.

41
22. Evaluative Summary;

This program series offers a complete energy analysis of a single or multi-building project, including load determinations,

air-side system simulations, plant equipment simulations, and

annualized owning and operating costs. The series consists

of a complex energy analysis program and an independent short

financial analysis program. Midstream evaluation is not

possible in either program. The period of analysis Is usually

one year.

The thermal load calculations and complete energy analysis

are accomplished each hour before proceeding to the next

hour. Therefore the program will not size the plant equipment

and base part-load efficiencies on that size. All calculations

assume steady-state or equilibrium conditions. As in the

Meriwether program series, the thermal loads are scaled based

on design loads and design weather conditions. Building loads

based on these calculations are suitable for comparison of

alternatives, but not for prediction of actual energy performance. Response factors may be input (from another, program) or default values for light, medium and heavy construction

may be utilized.

The air-side and plant systems simulation package is one of the

most complete of the program series surveyed. Addition or adaptation of equipment simulations is facilitated by the

modular package structure. Estimated equipment size is a required input for part-load performance curves. If the

demand exceeds capacity, the design efficiency will be used.

The preparation of input material requires experience and time; one to three days for experienced engineers. The complexity

of the input process increases the probability of input errors

or meaningless final product. A block input option is available which simplifies the input process for conceptual design

evaluation.

Though this program is proprietary, the source deck is available to EEI member utilities and MIUS participants at a reasonable charge. The strong and flexible simulation base of

this program and the ease of block input for conceptual design

analysis made it a prime candidate for MIUS use. It will provide

an excellent base for simulation of a MIUS. For a detailed

predictive evaluation of energy requirements at a specific site,

this program is a prime candidate for marriage to a program

with detailed thermal load calculational procedures.

h2
3.9 TACS/Lokmanheklm/AXCESS

1. Abstract

In Version I, the thermal loads computed by the TAGS program

are input to the energy systems simulation subprogram of

AXCESS. In Version II, the thermal loads computed by the

Energy Utilization Analysis of Buildings Computer Program are

Input to the energy systems simulation subprogram of AXCESS.

2. Author (s)

Authorship of the individual programs has been previously

mentioned. The interface in Version I is a part of the

AXCESS program. The interface in Version II was written by

Metin Lokmanhekim.

3. Owner (s)

Ownership of the individual programs has been previously

mentioned. The interface in Version II is owned by

Southern California Edison.

4. Availability;

As previously mentioned, except that the interface in Version

II is also proprietary.

5. Cost;

As previously mentioned for the individual programs.

6. Human Factors:

As previously mentioned for the individual programs.

7. Turnaround

Depends on user facilities.

8. Documentation

Version I - The interface mechanics are in the AXCESS documentation.

Version II - Interface documentation unknown.

9. Scope

Version I - The thermal loads computed by the Computer Program

for Analysis of Energy Utilization in Postal Facilities are

input to the energy systems simulation subprogram of AXCESS.

Version II - The thermal loads computed by the Energy Utilization

Analysis of Buildings Computer Program are input to the energy

systems simulation subprogram of AXCESS.

h3
10. Output;

As previously mentioned for the individual programs.

11. Input

;

As previously mentioned for the individual programs.

12. Logical Structure;

Thermal loads from either program mentioned above are input

to the energy systems simulation subprogram of AXCESS. The

AXCESS structure is followed from there.

13. Flexibility;

Either version of this hybrid provides excellent program

flexibility. Both versions offer a great number of energy

systems simulations. Version I precedes the simulation with

a detailed calculation of loads. Version II permits block

analysis of conceptual designs and facilitates the parametric

analysis of changes.

14. Interfacing;

These hybrid programs are based on interfaces.

15. Limitations;

These hybrid programs suffer the limitations previously

mentioned, of those portions of the individual programs

which are used in the hybrid.

16. Source Language

:

As previously mentioned for the individual programs.

17. Hardware Implementation;

As previously mentioned for the individual programs.

18. Portability:

As previously mentioned for the individual programs.

19. Diagnostics

:

As previously mentioned for the individual programs.

20. Maintenance:

As previously mentioned for the individual programs, with

maintenance of the interface in Version II by Metin Lokmanhekim.

21. Adaptability/Expandability

:

As previously mentioned for the individual programs.

1 I
Evaluative Sunnnary ; These hybrid programs provide the greatest flexibility of any

computer program series investigated. For MIUS use the thermal

load calculation procedures provide a predictive accuracy

comparable to that of NBSLD. Either version of this hybrid can

account for the effects of shade on thermal loads. Version II

provides the flexibility in user input and system simulation

which facilitates parametric analysis of different conceptual

designs. Version I is not proprietary and could be implemented

with a minimum of effort since both constituent programs are in

the possession of agency participants, and AXCESS can be easily

modified to create the necessary linkage. Although version

II is proprietary, a source deck, including the interface could

be purchased. The two versions of this program and NBSRFM

provide greater configurational flexibility than any of the

existing MIUS type simulations developed by the government.

h5

9. Scope;

The BIN program analyzes the modular integrated utility system

shown diagrairanatically in Figure 2

It computes and compares the fuel requirements for this system

with the fuel requirements of a conventional system when used to

supply identical electrical, domestic hot water, space heating,

and air conditioning loads to consumer models. The BIN program

uses as part of the input data the outputs of the sub-programs

HEATEN, C00LEN, or S0LAIR. The HEATEN program estimates the

space heating energy requirements of the consumer. The C00LEN

and/or S0LAIR programs are used to estimate the consumer space

cooling energy requirements. These sub-programs utilize temperature frequency occurrence (bin) data from Chapter 6 of the Air

Force Manual AFM-88-8 [16 ) or as compiled from National Weather

Records Center Data.

10. Output

The BIN program presenfs the results of the analysis for each

month of the year by means of several tables.

Consumer loads.

System loads at the central equipment building.

Required makeup by auxiliary boiler and

engine waste heat unused.

Air conditioning load to motor-compressor

and absorption chiller.

Total electrical load on engine generator.

Fuel requirements for the T/E system.

Total conventional system loads.

Fuel requirements for the conventional system.

Comparison of T/E system fuel consumption with

conventional system fuel consumption.

11. Input

Fifteen (15) data statements are required for the BIN program

including the following input quantities:

a. Number of consumer dwelling units.

b. Yearly hot water heating load.

c. Yearly electrical load.

d. Hot and cold water pipe line transmission loss.

e. Quantity of refuse burned in auxiliairy

incinerator-boiler, if any.

f. Heat content of refuse.

g. Factor to allow for added fuel for complete

combustion.

h. Consumer complex auxiliary electric load.

i. Monthly central equipment building auxiliary

electric load.

j. Monthly space heating load (output of HEATEN program),

k. Monthly electricity usage as percent of total

yearly load.

^7

a. Table 1:

b. Table 2:

c. Table 3:

d. Table 4:

e. Table 5:

f. Table 6:

g> Table 7:

h. Table 8:

1. Table 9:
1. Monthly air conditioning load (output of C00IjEN or S0LAIR program),

m. Monthly domestic hot water usage as percent of total

yearly load.

n. Monthly celling on beneficial use of waste heat,

o. Efficiency of motor compressor refrigeration system,

p. Efficiency of engine-generator for electrical load,

q. Type of fuel burned in engine and auxiliary boiler,

r. Efficiency of auxiliary boiler in total energy system,

s. Heating value of fuel.

t. Monthly axrxlliary electric load for conventional system,

u. Efficiency of boiler for space and hot water

heating in conventional system.

V. Central station plant efficiency in conventional system,

w. Heating value of fuel used in conventional system.

12 . Logical Structure : The complete system consists of several independent programs

(HEATEN, C00LEW, or S0LAIR) which must be run to compute

the space heating and space cooling energy requirements.

The outputs of these programs are then used as input to the

main BIN program, which consists of approximately 200

statements.

13. Flexibility : Although the programs are specifically designed to analyze

a total energy system similar to Figure 7 and compare its

fuel requirements to a conventional system, the programs

can also be used to analyze variations of the total energy

system by assuming appropriate values for the program input

parameters. The programs have been applied to:

a. A total energy system in which all electricity,

space heating and cooling, and domestic hot water

are supplied to the consumer from an equipment

building located on-site.

b. A T/E sysgem similar to A except that the entire

cooling capacity is provided by absorption refrigeration

system chillers.

c. The HEATEN and C00LEN programs can be applied to the

analysis of conventional heat pump systems.

d. A conventional district system in which electricity

is purchased from a regional utility system.

e. A T/E system in which a part of the fuel burned in

the auxiliary boiler consists of solid wastes.

f. Various sensitivity studies in which the effect of

varying different input parameters on fuel consumption

can be analyzed.

1^+ . Interfacing : The BIN, HEATEN, C00LEN, and S0LAIR programs are all written

in BASIC language for the time-sharing PDP-10 computer at

1+8
ORNL.

15. Limitations

The following quotation presents several limitations of the

"bin" method for estimating heating and cooling load energy

requirements [17]:

"While the basic bin method provides for load calculations

at various temperatures and at some variation in operating

conditions, it still assumes that internal load and solar

radiation load are constant during the operating period

covered by the temperature bins. This drawback can be overcome somewhat by establishing temperature bins on 5 F deg

and 1-hr increments instead of 8-hr increments. This would

allow the internal load to be varied each hour of the day

and matched to the solar load for that hour. However, this

does not permit various types of occupancy and operational

days during the month. Other factors which the bin method

Is not able to accommodate are latent heat load variations

and the effect of heat storage and release during periods

of setback or shutoff . A computerized version of the bin

method permits the use of small increments and many sets of

operating over the degree-day method or equivalent full-load

hours methods."

16. Source Language:

BASIC

17. Hardware Implementation:

PDP-10 at ORNL

18. Portability:

Punched tapes can be prepared of the programs and used

wherever there is a compatible time-sharing computer system.

19. Diagnostics

Errors in command, compilation of data, or in execution

are recognized and the appropriate diagnostic message

is Immediately typed out by BASIC.

20. Maintenance

The maintenance of the software is done by the author of

the various programs (C. L. Segaser) and changes in the

programs are made as necessary.

21. Adaptability/Expandability;

Changes or additions to the software in BASIC are easily

accomplished by simply changing or deleting statements and

adding additional statements as required.

^9
Evaluative Summary:

The ORNL BIN Program was an early development at that agency

for the purpose of comparative energy performance evaluation

of MIUS utility delivery configurations versus conventional

configurations. Since that time an hourly analysis program

(described in the following section) , with more sophisticated

and accurate load determination procedures and some improvements

and additions to the steady-state energy simulations has been

developed by ORNL. Because of this subsequent development,

the BIN program has been effectively superseded.

50
3.11 ORNL 1973 MIUS Comparative Energy Analysis Program

1. Abstract : Uses hourly weather tapes, generalized building description

data, hourly consumption data on electricity and water, desired

indoor temperature and humidity schedules, and machinery performance data to calculate relative space heating and cooling

loads, heating and chilling coil loads, fuel requirements and

components thereof for different MIUS applications compared to

conventional systems on an hourly, monthly, or annual basis.

Uses algorithms in 1972 ( ASHRAE Fundamentals Handbook [l8].

2. Author (s)

John V. Wilson,

Oak Ridge National Laboratory,

Oak Ridge, Tennessee

FTS (615) 483-7622 or (615) 483-8611, ext. 3-7622.

3. Ovner(s)

Public domain.

4. Availability

Although this program was intended solely for internal use

and is not formally documented, all or part will be

made available upon request if approved by the sponsor

(HUD-MIUS project).

5. Cost;

Cost of obtaining cards or tape is only service charge for

copying and mailing - estimated $25 or less depending on material desired. Run time is 6 seconds per weather year per

Building type on IBM 360/91, or 30 seconds per weather year

per building type on IBM 360/75. Consulting services for running

the program could probably be arranged.

6. Human Factors;

Each building type requires two cards of general data

such as areas, four cards of heat transfer functions

selected from ASHRAE tables, and 22 cards with hourly

schedules for occupancy, water use, electricity use,

etc. As many as 15 building types may be included.

Three additional cards containing holiday designations,

machinery data, and solid waste burning data for the

project as a whole are also needed.

Output is labelled only enough for internal use, and

is frequently changed for requirements of the occasion.

More output is printed than is normally required for

any one specific study or application.

7. Turnaround

For internal use results are normally available in less

than one working day. Jobs can be submitted by messenger
service, remote terminal, or teletype.

8. Documentation : No user's manual is available or planned. A program description is given in Appendix B of reference [19]. Since the

program closely follows the ASHRAE Fundamentals Handbook for

most of its length, a user possessing that handbook should have

little difficulty following the calculations.

9. Scope : This computer program is intended for use in calciilating relative

energy and fuel requirements for different utility systems

and development projects being studied in the HUD-MIUS

project. For each conceptual type of building, space

heating and cooling requirements are calculated hourly using

weather data from tapes and building data and occupancy or usage schedules provided as input data. The algorithms in

the 1972 ASHRAE Fundamentals Handbook are used [18]. From

these requirements and the temperature control schedule the

heating or cooling coil loads are calculated. From these in

turn the hourly operating requirements for an engine generator,

an auxiliary boiler (which may burn solid waste), an air

conditioner of either absorption or motor-driven type, and

for heat rejection are calculated. Finally, the fuel requirements

ror eacn nour are caxcuiacea. ttesuxcs are summea ana printed for selected time periods.

10. Output

:

Input data are echoed with terse identifications. Some or all of the following are output for intervals selected by

user:

a. Electric load.

b. Space heating load. ; c. Space cooling load.

d. Hot water heating load.

e. Heater coil load. 1

> f. Chiller coil load.

g. Absorption chiller Btu.

h. Motor-compressor chiller KWH.

i. Total generator load KWH.

j- Auxiliary boiler Btu.

k. Heat rejected Btu.

1. Fuel used.

Components of the space heating load owing to transmission,

ventilation, electric usage, occupants, solar radiation,

and humidity control may be printed if desired. Various

other outputs are printed from time to time for specific

investigations by program changes.

52
11. Input

For each building type the input data are: a. Floor area and

associated heat transfer function coefficients, b. Roof

area and associated heat transfer function coefficients, c. Window area and associated area and heat transfer coefficient.

Hourly schedules for both "occupied" and "unoccupied" status

for each of the following:

a. Shading coefficient.

b. Inside temperature.

c. Inside humidity.

d. Occupancy.

e. Hot water heating.

f. Interior electricity.

g. External auxiliary electricity.

h. Ventilation/infiltration.

For the whole system data include:

a. Holiday schedule.

b. Machinery capacities and

c. Solid waste burning data.

d. Latitude and longitude.

e. Various option selectors

efficiencies

and calculational controls.

12. Logical Structure;

Program consists of one main" program of about 350 Fortran

statements and twelve specialized sub-routines, plus standard

library functions. The whole comprises about 1000 cards.

The main program is very simple logically but is long because

of various tallies and sums that are zeroed, incremented, and

printed, and because it prints some of the input echo and some

of the final output.

13. Flexibility:

The system can handle a MIUS or a total energy system

or a conventional system consisting of up to 15 types

of buildings. The user will have to interpret the

printed output in various different ways,, however, to

achieve these results.

14. Interfacing:

Most of the specialized subroutines could probably be

used almost unchanged in a merger with another system.

Probably at least half of the main program would have

to be completely rewritten.

53
15. Limitations

;

The program provides only a simplified model of a conceptual type of building. The program does not calculate heat

transfer function coefficients from basic materials properties

data as NBSLD does, but rather must have these coefficients

provided in the input data. The program does not include models

of different ventilation systems.

16. Source Language;

IBM Fortran IV

17. Hardware Implementation;

IBM 360/75 and 360/91.

18. Portability;

In principle, it should be easy to convert this program

to ASA Fortran or Fortran V, since Fortran IV is

supposedly a subset of Fortran V. No doubt some problems

would arise in handling format statements owing to

different word lengths in different computers, and owing

to some variations in names of library functions.

19. Diagnostics

:

: No significant diagnostics are provided.

20. Maintenance;

The author is using the program frequently, and changes

and updates it frequently as various new demands arise.

21. Adaptability/Expandability

;

The program logic is comparatively simple and changes/additions

should be no more difficult than for the typical Fortran

program.

22. Evaluative Summary;

The ORNL 1973 MIUS program is one of four programs

discussed in this report which were developed specifically

around a MIUS type of enerey performance simulation. Its

purpose has been for comparative analysis of different systems

based on energy requirements. At this time, no economic analysis is performed. Program content consists

of a building loads determination, and a subsequent

steady-state energy requirements simulation for a typical

MIUS plant configuration. Building thermal loads are calculated

on an hour-by-hour basis and are based closely on procedures

recommended in the 1972 ASHRAE Handbook of Fundamentals [18].

Base and auxiliary loads, including thermal requirements

for hot water heating are calculated according to input

schedules. Building orientations, for purposes of solar

loading calculations, are set up in a fixed manner, for

both single and multi-building configurations, and can be

changed only by internal modification of the program itself.

Because of the lack of energy performance
simulations for air-side systems, the program cannot model, in

the same building in the same hour, simultaneous heating and cooling loads. It can model simultaneous heating and cooling loads

only in different buildings in a particular hour. In a given

building, it can accoimt for a change from heating to cooling (or

vice-versa) from one hour to the next. This limits program

analysis capability mostly to hypothetical building project

configurations, since it could not correctly model many existing

types. All these considerations suggest that the lodds produced by this program are limited in suitability to comparative

analyses of plant systems designed to satisfy these loads, and

not actual, realistic predictions of actual performance. It

sho\ild be noted that ORNL has mentioned this point in a description of the program [19]. In the present program then, the

model assumes that the total building thermal loads are fomd each

hour, and with a correction estimate for distribution losses, are applied directly as the necessary thermal energy requirements

that the plant system must modify. The ORNL program energy

system simulation, to which the loads are applied, consists

of only one typical MIUS configuration: a total energy plant

with addditional features of incineration heat recovery and

thermal storage, feeding a district heating and cooling system

(Figure 2 and reference [20]). Any alteration in this simulation

would have to be accomplished by internal program modification.

There is thus a resultant lack of user flexibility in the application

of this program. The energy performance simulation is of a steady-state, equilibrium nature, and calculations are made

on the same hourly basis as the thermal loads supplied to the

plant. Energy conversion models used for plant equipment in

the simulation, except for the heat recovery power generation,

uses fixed conversion efficiencies, which are less adequate

than models which employ part load performance data for

equipment. The resultant simplicity of this simulation

compared to the complex performance of real equipment makes

this energy simulation less suitable for prediction of

actual performance than for comparative analyses.

On the basis of the preceding discussion, the ORNL 1973 MIUS

program seems to be best suited for conceptual level estimates

of comparative energy feasibility of a MIUS configuration with

different performance factors. It would be most suitable to

compare these results with similar calculations for a con- ventional utility configuration responding to the same demands, something which is not done automatically. This

program, in its present form, could not be expected to accurately

predict, on a reliably consistent basis, actual energy

performance of a variety of real systems, due to the limitations

discussed above. It is therefore of little use in the evaluation

of real system designs. At this time, no economic analysis

is performed.

55

,1
3.12 Energy Systems Optimization Program (ESOP)

1.

2.

3.

h,

5.

6.

T.

8.

9.

Abstract : The ESOP was written primarily for the purpose of predicting

energy consumption of a MIUS system, including solid waste,

water treatment, power generation, and comfort conditioning.

Author ( s )

:

The Urban Systems Project Office, Johnson Space Center, NASA

and the Lockheed Electronics Com.pany

Allen E.Brandli, USPO-JSC, Technical Monitor

Owner ( s )

:

National Aeronautics and Space Administration

Availability : National Aeronautics and Space Administration

Urban Systems Project Office

Johnson Space Center, Houston, Texas

Cost : Unknown

Hioman Factors : Variable input options are possible. Those parameters not

input are assumed to be zero. There is a total of less

than 100 parameters in the input list covering all phases

of MIUS siraiilation. Output is straightforward and easy to

read.

Tiornaround : This is dependent upon the computer system to be used. A

general estimate is on the order of one to several minutes

for the time required to run a job for a complete weather

year, on a Univac 1108 Exec 8 System.

Documentation : Detailed Users Manual is available from owners [2l].

Scope : The ESOP provides for analysis of energy reclamation systems

only i.e., the use or recycling of process material products

such as solid waste is not included in the simulation. ESOP

predicts hourly, daily, monthly, seasonal, and yearly

operational characteristics for any or all of thirty different MIUS configurations.

ESOP has the capability of analyzing two types of MIUS; a diesel/

turbine prime mover system and a steam power plant (boiler)

prime mover system. Hhe selection of system type analysis

is a user option. Both systems use the same solid
waste disposal system options.

10. Output

The output from ESOP is fixed and in sufficient detail to

allow for analyses and comparisons as required. Output

categories include:

a. An echo of input data.

b. Recovered heat and operating dollar values for

waste, processing.

c. Daily profiles for hot water, space heating,

and space cooling demand.

d. Fuel requirements and cost for conventional system

(seasonal and yearly)

e. Fuel requirements for MIUS option considered

(seasonal and yearly)

f. Hourly thermal storage, if applicable

11. Input

Input is straightforward and logical. There are approximately

100 parameters of which some 2A are required for input. The

namelist option, defined under FORTRAN V, is used to input

all data to ESOP. Five namelists are required input for

each data case. Descriptions of these five namelists

follow:

a. WASTE - Namelist WASTE contains input variables which

define the amount of waste to be disposed of, the

waste, heating value, the quality of the waste, the

cost of the required fuel, capacity of the incinerator

unit, the total quantity of recovered waste, and

the waste heat usage profile.

b. PYRINC - Namelist PYRINC contains input variables

which define the operating characteristics of the

pyrolysis process and heat recovery efficiencies

of both the incineration and pyrolysis processes.

c. INPUT - Namelist INPUT contains variables which

define the construction of the building to be analyzed,

the number of buildings, number of apartments in each

building, the hot water heating demand per building,

and a cloud factor which is not used in the analysis

at present.

d. ENVRHR - Namelist ENVRHR contains input variables

which define twenty-four hour profiles of; inside and

outside dry bulb temperatures and air enthalpies,

domestic and auxiliary electric demands, occupancy,

hot water usage, apartment ventilation rates, window

shade factor, direct solar radiation through windows,

window heat gain (convection and radiation) , and

"eq*iivalent temperature differentials" for the building

roof and walls.

57
e. CONST - Namelist CONST contains input variables which

define diesel and turbine rated loads, a generator

rated load (for the Waukesha 500 KW diesel system)

,

boiler efficiencies (for both 24 and 12 mode systems),

coefficients of performance for air conditioning

systems, percentage absorption/compression for the

fixed ratio mode, boiler operating characteristics

(for the steam power plant), program logic flags

for season, prime mover system, and low grade heat

utilization selection, low grade heat recovery and

usage characteristics, and water cooling tower

operating characteristics.

Logical Structure:

ESOP consists of 5 general analytical components covering

waste disposal, heating/cooling loads determination, power

generation and a conventional utility system, plus other

processing/interpolativetype subroutines. The overall

structure of ESOP is shown in Figure 3. The five major

components are:

a. Solid Waste Disposal Subroutine (SWDP)

:

SWDP calculates operating parameters =ind daily total

energy input required for three types of solid waste

disposal systems; incineration, pyrolysis, and

combination incineration/pyrolysis . Process byproduct

and recoverable waste energy are also calculated.

b. Generator Subroutine (GENRAT)

:

GENRAT calculates the hourly energy requirements for

specific prime mover/ generator units as a function of

input electrical load demands. It also computes

the hourly rate of waste heat energy that is recovered

or recoverable from prime mover heat exchanger systems

c. HEAIR:

HEAIR calculates the heating and cooling loads on a specific building with given internal and external

environmental conditions for each hour of a 24-hour

day.

d. CONVEN:

This subroutine calculates the hourly energy requirements for a conventional utility power

system to meet the total system load demands. The

configuration is composed of a boiler system identical

to MIUS and a commercial electrical power generating

source operating at a constant 30% efficiency level

for delivered power. Only compression type air conditioning is utilized and no waste heat energy is

utilized or recovered. Daily, monthly, and seasonal

energy requirements are calculated for comparison with

MIUS energy requirements.

58
e. STEAM:

This subroutine calculates the energy requirements and

operational characteristics of a MlUS-type steam power

plant. Four configurations are available as options.

13. Flexibility;

The ESOP will operate with a minimal number of input terms

being specified, thus sufficing for a preliminary design.

On the other hand, it will accommodate quite detailed input

information to suffice as a more thorough design tool. The

number of configurations simulated through various combinations

of individual equipment simulations are 24 for diesel/turbine

prime mover MIUS designs, 12 for steam power plant MIUS

designs, and one conventional utility delivery design

(described above under 12d) . Detailed lists of all these

configurations are presented in the ESOP user's manual [21].

14. Interfacing;

The ESOP is an "open" program and is written in such a manner

as to easily allow modification of either input to or output

from it to accommodate an interfacing with many other type

programs as desired.

15. Limitations

There are presently hardware/equipment simulation limitations

in the ESOP, however, the capabilities can be easily expanded.

Comparisons can be made only on an energy consumption basis

and not on a dollar basis since there are no economic criteria

considered in ESOP. Separate parts do not operate independently, and no midstream evaluation is possible. There are

no building air-side simulations, and there is not a capability

to account for simultaneous heating and cooling loads. Only

four 24-hour weather days are analyzed (one for each season)

instead of the 365 days accomplished for a true hourly

.calculation for loads.

16. Source Language:

The source language of ESOP is Fortran V.

17 . Hardware Implementation;

It has been implemented on Univac equipment under both

EXEC II and EXEC VIII.

*

18. Portability:

ESOP is hardware independent, within the limitations of

Fortran compiler variability.

19. Diagnostics : There are no printed diagnostics as such. Standard UNIVAC

systems diagnostics are available, but printing is suppressed

in ordinary use.

59
20. Maintenance

:

Maintenance of ESOP will be handled by the authors.

21. Adaptability/Expandability

:

ESOP can be readily changed or adapted to virtually any

operation desired.

22. Evaluative Summary;

The NASA ESOP program system is one of four programs

described in this report which was specifically developed

to simulate the energy performance of typical MIUS configurations,

and to compare that performance with a conventional utility

system satisfying the same loads. At this time, no comparative

economic analysis is available as part of the system. The

various subprograms calculate building loads and subsequently

accomplish, a steady-state energy requirements simulation

of several MIUS configurations and a conventional one. Building thermal load calculations are based on 1965 ASHRAE

recommended procedures [22] and utilize Trane solar data [23].

This method is based on finding a hypothetical "equivalent

temperature difference" which yields a calculated fictitious

transmission thermal load which is equal to the real thermal

load due to all the various possible sources of effects:

transmission, radiation, solar loading, building heat storage,

ventilation, etc. Subsequent ASHRAE recommendations [l8 ] have largely superseded this method. Base and auxiliary

loads, including thermal requirements for hot water heating,

are calculated from input schedules. A shortcoming of these

schedules is their lack of ability to account for variations

,

. in occupancy and activity patterns caused by weekends and

holidays. The schedules are assumed to be the same for all

days of the year. The loads calculated are on an hour-by-hour

basis. However, this is only done for four 24-hour v;eather

profiles representing seasonal average characteristics. The

subsequent loads obtained from these four seasonal days, are then multiplied by monthly and seasonal time durations to

get related energy consumptions for those time periods.

Thus, the calculation is not truly and hour-by-hour analysis

for the whole year. In fact, it makes little sense to calculate

a monthly energy consumption based on the properties of a seasonally average day. In addition, because of the lack of

energy performance simulations for air-side systems, the

program cannot account for the existence of simultaneous

heating and cooling loads. This limits program analysis

capability mostly to hypotheical building project configurations,

since it cannot model the many existing building types that do

present simultaneous loads. All these considerations suggest

that the loads produced by this program are limited in suitability to comparative analyses of the plant systems designed

to satisfy the loads, and not actual, realistic predictions

of actual p.'^r f ormance . It should be noted tliat a recognition

- of this limitation by the developers of the program system

60
is implicit in the title chosen: "Energy Systems Optimization

Program."

The energy requirements simulations include a total of thirty

six variations of possible MIUS configurations which differ

as to the combinations of the various individual thermal

processes: solid waste processing, power generation, and

energy supply for heating and cooling. All simulations are

of the steady state, energy balance type, and are done on

the same hourly basis as the load calculations. There is a mix of both fixed conversion efficiencies in some processes,

and part-load performance curves in others (e.g. power generation).

In particular, it is possible to input an hour-by-hour COP

profile for a chiller system, but since chiller COP usually

correlates with the amount of the load, it is not clear what

the hourly profile flexibility accomplishes. There is a pyrolysis simulation available in this program, a feature

available nowhere else at this time. It is not clear, however,

whether the assumption that byproduct gas created by this

process should be sold for an operating dollar credit takes the

best advantage of the integration possibilities of such a subsystem into a total MIUS configuration. In particular the

possibility of recycling this gas as a MIUS fuel for an energy

"credit" should be examined. The power generation subroutine

simulates the performance characteristics of six prime-movers

alternatives, four of which are diesel engines, and two of which

are turbines. It should be noted that of the four diesel

performance simulations, two of them are for models produced

by a company which has now ceased operations (Nordberg) . The

resultant overall nature of the simulation available indicates

that this program system is best suited for conceptual level

estimates of comparative energy feasibility of the various

configurations simulated for a particular set of site loads,

both with respect to alternative MIUS configurations, and with

respect to the one conventional configuration which is simulated.

This program, in its present form, could not be expected to

accurately predict, on a reliably consistent basis the actual

energy performance of many real systems, due to the limitations

discussed above.

61
3.13 MIUS SINDA Models

1. Abstract

:

Two MIUS simulation models have been developed for operation

on the Systems Improved Numerical Differencing Analyzer

(SINDA) program. SINDA is a program capable of performing

transient or steady-state analyses on any system which may

be represented in lumped parameter fashion (nodalized) and

whose operation is governed by diffusion equations. The

program was initially designed for thermal analysis of

spacecraft structures, but is not limited to that field.

One of the two MIUS models developed for operation on the

SINDA program describes a MIUS equipment configuration

which was designed for the 648-unit garden apartment trade

study. The second was developed to simulate the MIUS Integration and Subsystems Test (MIST) hardware configuration,

which is at NASA-Johnson Space Center, Houston, Texas.

2 . Author (s)

:

a. SINDA Program: TRW Systems, Inc., and NASA Johnson

Space Center (JSC) , Structures and Mechanics

Division.

b. MIUS SINDA Models: TRW Systems, Inc., The Boeing

Company, and NASA, JSC, Urban Systems Project

Office CUSPO).

3 . Owner (s) : a. SINDA: Public (U.S. Government)

b. MIUS SINDA Models: Public (U.S. Government)

4 . Availability

:

a. SINDA - available through R. L. Dotts at NASA-JSC.

b. MIUS Models - available through USPO.

5. Cost:

Operation cost is very model dependent and is a function

of the type of analysis (steady-state, transient, etc.),

time steps required to force mathematical stability because

of physical properties of MIUS components, etc. The

cost of performing specific analyses with the program is

largely dependent upon the extent of modifications required

for the particular MIUS configuration to be considered.

Minor modifications can be accomplished quite readily in

approximately one man-week.

Typical execution times for the current model configuration

on the Univac 1110 Exec VIII system at JSC are less than one minute per day of real-time plus approximately two minutes

for editing and compliation. Costs would be dependent on

the particular computation center where the system is implemented.

62
Human Factors:

Preparation of input data and changes to the model are fairly

easy if the user is familiar with the SINDA program and

Fortran. Output is completely flexible and is controlled

by the user either through the use of SINDA output subroutines

or user-written output formats.

The MIUS model is not easy to use and modify due to its

complexity and flexibility. However, a familiarization

with the SINDA program and Fortran will enable the user to

tailor the program to a wide vareity of applications.

Turnaround

Turnaround at the JSC computing facility varies from

approximately 2-3 hours to 2-3 days depending primarily on availability of hardware, when processing is done in batch

mode.

Documentation : The SINDA program has been dociimented with a user's manual

[2Aj, and an engineering program manual [25] which have

been published and are available.

Scope

One current MIUS model was developed specifically to simulate

a 648-unit garden apartment MIUS. This model currently predicts

flow rates and temperatures throughout the system, and from

those predictions derives fuel consumption, energy losses,

equipment operation schedules, etc. The second model simulates

the behavior of similar physical parameters for the MIST hardware model, which is constructed at NASA-USPO. The models are truly applicable only to the particular MIUS configurations

simulated; however, modifications will allow analysis of a fairly wide variety of MIUS configurations and/or control

techniques

• Output

For both models the user has complete control over all output

through the use of either standard SINDA output routines or through his own Fortran statements. Any or all output is

available at any time during the solution or at any time

interval. The models output all temperatures and flow rates

as well as several parameters which define the particular

system operation at hourly intervals. Also available are seasonal and yearly totals of several system parameters such

63
as fuel consumption.

Due to the detailed nature of the models, the output is currently

quite lengthy and requires a familiarity with the models and

their nodalization for meaningful interpretation.

11. Input

:

The current MIUS models are retained on magnetic tape at the

JSC computer facility. Thus, to execute them, the only input

required is an appropriate set of system control cards and

SINDA control cards necessary to load and compile and appropriate

model from tape. Parameters such as load profiles, equipment

performance curves, temperature profiles, etc. , may be input

as required by modifying the stored data through standard

editing procedures. Input to the SINDA program to define each

complete model includes a description of all nodes and conductors

(for the RC network system simulation procedure) , thermal

sources, solution sequence and technique desired, and special

purpose user-supplied subroutines required, and output logic

desired.

The garden apartment model will accept magnetic tape input of

building loads from the Post Office program.

12. Logical Structure:

The SINDA progr^ is composed on three primary sections:

(a) A preprocessor which compiles, sorts, and stores all

input data, user supplied logic, and order of solution.

(b) Standard solution routines which are called upon to

solve the network constructed by the preprocessor.

(c) A large library of optional subroutines which are available to perform a wide variety of special purpose

functions input/output control, mathematical manipulations,

etc.

Both of the MIUS models have been developed as an application

of the SINDA logical structure.

13. Flexibility:

The SINDA program is extremely flexible for analysis of any

system which can be represented by a lumped parameter (nodal)

network governed by diffusion equations. The existing SINDA

subroutine library is quite comprehensive and can be supplemented

with user-supplied subroutines.

The current MIUS models are also somewhat flexible, as long as major changes from the programmed physical configurations are

not required. A wide variety of MIUS analyses may be readily

performed with only minor variations in the model.

bk
Ultimate flexibility is limited only by resources available

for new model development within the framework of the SINDA

system and computer hardware limitations.

14. Interfacing:

Numerous interfaces between SINDA and other software systems

have been accomplished, and the extent of required modifications

is a function of the particular application. The MIUS garden

apartment model has been interfaced with the Post Office program

to provide automated input of MIUS thermal loads.

15. Limitations

The limitations of the SINDA program for MIUS modelling is

dependent primarily upon the abilities of the user and the

resources available for model development. The effort required

to accomplish major modifications in the model makes detailed

analyses of different physical configurations impractical in

short periods of time. Another limitation in the use of the

SINDA program is the degree of familiarity with SINDA required

for effective use of the program.

The limitations of the existing MIUS models include largely

those of the SINDA program. The existing models include

representations of diesel and gas turbine-driven generators,

absorption and compression chillers, boilers, incinerators,

distribution piping, heat exchangers, and rairly extensive

control logic. Currently, the models contain only thermal

networks integrated with fluid flow. No pressure networks

are included. The HVAC loads are assumed to be concentrated

at one central heat exchanger rather than from individual

sources. No air side simulation is included. Simulation of

waste water treatment equipment is limited to the EPA sewage

plant design program and is not integrated with the remaining

MIUS equipment. Currently, no heat storage equipment is

simulated. The items listed can be added to the model with

a relatively minor effort in most cases.

16. Source Language:

The SINDA source language is primarily Fortran V, although

a small amount of SLEUTH machine language is used, which is

machine dependent.

17. Hardware Implementation:

The MIUS model is operational on JSC's Univac 1108, 1106, and

1110 under Exec II and Exec VIII monitor systems. SINDA is

also operational on CDC 6600, IBM 360/370 and others.

18. Portability:

SINDA is fairly hardware dependent and often requires a relatively large effort to change environments. However,

several vor-sions of the program are available, and once it

is operational in a given environment, only minor modifications,

if any should be required to operate the MIUS models.

65
19. Diagnostics

;

SINDA diagnostics and modeling aids are quite good. A few

special diagnostics have been added through user input for

the MIUS models.

20. Maintenance

;

SINDA - Robert L. Dotts, Johnson Space Center

i MIUS models - Urban Systems Project. Office, Johnson

Space Center

21. Adaptability /Expandability

:

Changes to the SINDA program usually require a very thorough

knowledge of the program and a fairly large effort. Special

purpose subroutines can be easily formatted for standard

SINDA calling sequences and added to a special source tape.

Variations on the MIUS models could be greatly expanded within

the SINDA framework and are limited only by familiarity with

SINDA and computer hardware limitations. The current models

can be expanded considerably with no hardware problems on the

^ JSC Univac 1110 Exec VIII system.

22. Evaluative Summary:

The application of the SINDA program to the two model simulations discussed in this section constitute the only programs

developed for MIUS simulations which have the capability of

accomplishing true transient simulations ot the various energy

conversion processes. To date, however, only steady-state

simulations have been performed, and the transient simulation

capabilities have not been utilized. Compared to other

programs discussed in this report, the SINDA models require

a greater amount of effort to accomplish a simulation. In

addition, although SINDA is very flexible itself, each of the

actual simulation models developed are fixed in configuration.

Any change in a model involves actual changes to the software

itself; it is not possible under user control by simple changes

of input data cards. In a sense, in fact, most of the input

for a simulation is built in to the program itself. This

difficulty of input also leads to an increased possibility

of error, an example of which is examined in a discussion

of the ESOP/MIUS SINDA garden apartment simulation in the next

section. In view of the fact that the amount of effort involved

In developing an operational simulation model with SINDA is so much greater than for the other programs discussed in this

report, and because of the effort involved in modifying

simulations, it is being misapplied in performing steady-state

analyses, and should be used only when the transient analysis

capabilities are utilized. It is hoped that, particularly in

the case of the MIUS SINDA model, the transient analysis

capability will be employed.

66
In that application, it will probably be of benefit in

systematically examining transient behavior, and should be

able to indicate methods of optimizing overall performance

through proper design of control processes. It is in areas

such as this, where the unique transient simulation capabilities

of this system can be utilized, that use and further development

of simulation models based on SINDA are justified.

1

67
h. Program Comparison Activities

Many others have previously recognized the need for validation

of program predictions, with respect to actual performance, and for

inter comparison with each other. A number of program comparison

activities have heen carried out, four of which are described below,

along with comments regarding the pertinence of their findings to the

MIUS effort.

A. Boeing-Lockheed MIUS Simulation Program Correlation (SINDA/ESOP)

In a supporting effort to NASA-USPO, the Boeing Corporation

compared the calcialated annual electrical and fuel energy requirements using the SINDA and ESOP programs for an early version of

the NASA 6^8-unit garden apartment configuration using typical

weather conditions for Houston, Texas and Seattle, Washington.

In both cases, the operation logic of the MIUS system consisted of

generating the required electrical power and utilizing the waste

heat in the most efficient manner to satisfy the hot water and

domestic heating and cooling demands. The ESOP and SINDA simulations

are different in both the simulation models and in calculational

logic, leading to different and non-comparable methods of describing

component and subsystem interfaces and operational interactions in

each of the programs. Thus the only two calculated parameters that

could be directly compared were the annual electrical power and

fuel consumptions for the modelled configuration. Results showed

annual electrical and fuel consiamption agreements of about 3% and

5^ respectively for Houston and about 1% and ^% respectively for

Seattle

.

68
ESOP/Meriwether /E-CUBE

NASA USPO has also accomplished a comparison of their internally developed ESOP program and the commercially available

services of the E-CUBE and Meriwether programs. This comparison

was limited to predicted heating and cooling energy requirements for

the Park Towers South Office Biiilding model used in the NASA-USPO

Office Building Trade Study. The weather data used was based on

four typical seasonal days for Houston, Texas which was input

directly to ESOP. The seasonal days were modified to simulate the

full year of weather data necessary for E-CUBE and Meriweater

analyses. An important variable was cloud cover, which ranged from

none to "full", and was handled differently by each program.

Variations in the predicted heating energy requirements between the

other two programs, with ESOP results as a reference, ranged from

22% lower to l6^ higher depending on the cloud cover parameter.

The analagous variations in the cooling energy requirements ranged

from "jio lower to \Q% higher than the ESOP results as a reference

base. A comparison of electricity and fuel requirements was not made

due to ESOP program limitations. Since no actual building energy

consumption data was available, it was not possible to determine

which of the programs wo\ild have made the best actual prediction

of enegy performance. The activity was therefore a comparative one,

based on examining consistency of results for the different programs.

69
ASHRAE "Project Crosscheck"

In 1967 ASHRAE established a task group to investigate and

propose improved methods for estimating the energy requirements for

heating and cooling biaildings. This task group decided that it

wovild be beneficial to compare several computer-based algorithms

that had been developed. In what was to become the first phase of

"Project Crosscheck", five different programs attempted to predict

the heating and cooling loads of a hypothetical 20 story building

assTjming five independent zones. The five participants were:

1. Alabama Power Company

2. American Electric Power Service Corporation

3. Ross F. Meriwether and Associates, Inc.

h. Texas Electric Service Corporation

5. Westinghouse Electric Company, Inc.

Plots of the results showed that all five participants foiond

essentially the same variations in loads with weather conditions,

e.g. the magnitude of the worst case exterior zone monthly heating

and cooling loads were within a bandwidth of 19% and lh%, about

the means respectively. These bandwidths were both on the south

face indicating differences in the treatment of solar load. The

maximiiiti differentiation of + 100^ from the mean occurred in the

core zone of the building.

The ASHRAE Task Group was later given formal standing as

Technical Committee 1.5 Computer Applications. This committee

realized a need not only for the evaluation of precision, as

TO
shown in Phase I, but also for an evaluation of program accuracy.

Under funding from the National Science Foundation, Ohio State

University (OSU) had instrumented the Law Center on the OSU campus

in Columbus, Ohio. The data obtained included heating and cooling

power requirements (not loads) and weather data in addition to an

extremely accurate model of the building system. The committee

decided to compare the various cvirrent computer programs using

Columbus, Ohio weather data to the OSU model using the same weather

data [26 ]• The following participants are involved in Phase II:

1. Ross Meriwether and Associates (represented by the Dept.

of Public Works, Canada)

2. Electric Energy Association

3. Texas Electric Service

k. American Electric Power Service Corporation

The result of this effort is described in [27 ].

NBSLD/E-CUBE Omaha High-Rise Comparison

At the request of HUD, an analysis of building energy (natural

gas and electricity) consiamption for a selected typical weather

year was conducted by NBS on Kay-Jay Towers, a 12 story, ll8-unit

apartment building in Omaha, Nebraska, using the computer program

NBSLD and a simple building system simulation program developed

for this particular building [28]. The purpose of this effort was

to compare the NBSLD results both with similar results calc\ilated

by the Northern Natural Gas Company using the E-CUBE program and

with actual metered 5-year average energy consiomption data which

71
was available. Both programs used the same zone configurations in

the thermal modelling of the building and simialated the same mechanical and air handling aspects of the building plant. Both employed actual equipment and building operating schedules and indoor

environmental conditions. While NBSLD accounted explicitly for

the effects of air infiltration on space thermal loads, the data

input to E-CUBE did not.

Although there were wide monthly discrepancies in energy use predictions by both programs compared to the metered data, the annual

consumption totals for both programs nevertheless agreed with the

actual use to within one percent for natural gas and a few percent

for electricity. It is unclear at the present time how these re-i

suits are to be interpreted, but they do raise the important

question of how E-CUBE came so close to the actual consumption

while neglecting the large effects of air infiltration throughout

the analysis year.

None of the above activities has produced a comprehensive

validation or comparison of energy analysis computer programs. The

most notable reason for their failure was the use of incorrect comparison

methodologies. They were all "one-point" comparisons, in the sense that

a given applicational ("site") situation was picked, which in t^lrn

determined the utility loads to be satisfied, and the system energy

performance was then calculated by the different computer programs

72
involved in the comparison. The results were then examined for the

quality of the agreement among themselves. There are two shortcomings

to this approach. First, unless there is also measured performance

data available for a real system reacting to the same loads (and which

the computerized systems must stimulate) then there is no way of knowing

whether the computer predicted results are in fact accurate or not.

Ml that can be determined is how well the results of the different

programs agree or disagree among themselves. Of all the comparison

activities that have been \indertaken, only the NBSLD/E-CUBE comparison

on the Omaha building also had actual energy consumption data available,

and the orientation of that whole effort was to examine the energy

requirements of a particular building, not a utility supply system.

The second deficiency with this "one-point" test methodology is an

inability to provide the data base for comparison of optional energy

systems. A meaningful comparative test among programs should be designed in a way that determines whether or not the programs come to the

same relative conclusions, i.e. that they agree on the optimal utility

system configuration for a given set of loads. To accomplish this, a

set of several configurations or a continuous variation over a range of

configurational performance parameters need to be simulated by each of

the programs being compared. In response to a given set of loads, the

performance simulations of the whole set of configurations should then

be carried out by the participating programs. Finally, the results should

be compared to see whether or not the programs ail predict the same

relative performance (including the "optimized configuration") for the

range of configurations simulated. Ttiis is the kind of interprogram

73
test that has meaning for the comparative types of simulation programs,

not the single-point comparison. The above considerations apply to

both building load determinations and energy systems simulation.

A more recent report describing a comparison of selected programs

on several building types Is presented in reference [1]. This study

gives a particularly valuable description of the differences in user

factors for the programs involved.

Ik
5. Conclusions and RecoxnmencSatlcns

Diiring the course of this study, a clearer definition of MIUS

requirements for computer progreim capability was formed, and is summarized in this section of the report. This definition vas the result of

interaction between initial software utilization plans and this analysis

of the actual capabilities of available software. Six areas of analysis

which require the use of computer programs are identified below.

Conclusions regarding the adequacy of programs described earlier in

this report and recommendations for additional development are

discussed in the context of these six areas.

A. Equilibrium Comparative Analysis

The first area of analysis requiring computer assistance

is the comparison of alternative MIUS and conventional plant

configurations with respect to energy performance using

simplified steady-state energy balance simulations. This

capability is necesaary to determine the optimal plant which

will satisfy given site utility loads. This capability will be

used throughout additional conceptual studies, demonstration

evaluation, and as the core of a later "MIUS Optimizer".

It is clear that the NASA ESOP and ORNL 1973 Comparative

Energy Analysis programs, which include simulations of likely

MIUS configurations, are the most applicable existing programs.

Close followers are the commercial AXCESS program and the TACS/

AXCESS hybrid. Because of their non-proprietarity , availability,

75
flexibility, and quality, as discussed in the appropriate

evaluative summaries, these last two programs have the greatest

present value to MIUS of the commercial programs considered in

this study. All of the programs mentioned here are flexible,

and do not have the limitations inherent in proprietary programs. The implementation of these programs on participating

agency computers would make them cost-effective as research

tools. In addition, the modular structure of these programs

lends them especially well to being modified in response to

changing or increased interest in the future.

It is possible then to conclude that with the capability

represented by the various programs in the possession of the

agencies, and the level of simulation detail they contain, there

exists a comparative energy analysis capability suitable for the

needs of the MIUS effort. However, implementation of AXCESS and

the TACS/AXCESS hybrid on a participating agency computer is yet

to be accomplished. It is recommended that implementation of

these programs be pursued, or alternatively that a new program

be developed with similar or better capabilities. In addition,

a multi-point comparison should be conducted between these programs to determine if they agree on relative performance of the

system configurations that are simulated. The test should be

based on a "typical" application with several regional weather

data sets and a set of loads from a probable development configuration, for example, the NASA Community Study, or the ORNL

Live Model Study.

76
B. Economics

The second area of analysis requiring computer assistance

is the economic comparison of alternative MIUS and conventional

plant configurations. This requirement parallels that of the

energy feasibility analysis described above. Several of the

complete energy analysis program series studies include an

economic analysis of alternatives. It should be added that

while the economic comparison exists as a set of computational

algorithms, the economic data base necessary to do actual

comparisons for real systems at this time appears to be incomplete and not in a form amenable to automatic accessing by

a computerized comparative system.

C. Transient Response

The third need for computer assistance is in the development of more sophisticated transient MIUS simulation models.

These are needed to provide improved conceptual optimization,

accvirate plant performance predictions, and cost effective

control schemes. The models will be used in conjimction with MIUS

demonstration to predict and validate the best control system

methodologies

77
While the present level of detail of the simulations may be

adequate for comparative performance evaluations, it is not

possible to also conclude, however, how accurate the simulations

are in the prediction of the actual performance of a given MIUS

configuration. At this time there is no data to conclusively

confirm or deny the simulation adequacy under these circumstances.

Greatly simplifying assvmiptions are inherent in the equilibriimi

type of model. Even if they allow for thermal capacities in the

form of storage and losses they do not allow for the actual

effect of a real control system on the time-response of the MIUS

to time-varying loads. This immediately leads one to consider

such a model suspect in its prediction of actual perfonnance,

unless it is proven by actual testing to be adequate. What is

then first needed is a real system from which actual performance

can be measured, and which can also be modeled on the computer.

In this way the present simulation programs can have their

absolute performance predictions compared against the measured

data. Candidate systems for this comparison activity are the

NASA/MIST facility and the HUD Jersey City Operation BREAKTHROUGH

instrumented Total Energy plant. If a simulation model is proven

to be inadequate, then steps should be taken to devise those

necessary models which are in fact adequate for an actual performance simulation. Before undertaking the major development

of new simulation models, the alternative benefits to be derived

from generation of a reliable performance data base shoiild be

78
considered. Any simiilation is, at best, as acciarate as the

equipment performance data it utilizes. If the present data

hase can support a higher level of simulation, and this additional level of complexity is necessary to adequately predict actual

performance, then such a development should be initiated. It is

felt the first area of development, with the greatest immediate

benefit would be an attempt to obtain better models of how the

control systems at the component, subsystem and system level

actually cause a MIUS configuration to respond to a particular

time dependent utility load variation. At the present time,

only the NASA developed SINDA MIUS models have the potential

for this type of analysis in the public domains.

D. Building Energy Requirements

The fourth area of analysis requires the ability to

accurately determine building thermal loads and energy requirements.

Valid building loads and energy requirements are essential for

plant optimization and accurate prediction of site energy requirements at a particular site. A program of this type will be used

to translate MIUS site characteristics into plant requirements.

Four program series have strong capabilities in this area, and

others are presently under development. NBSLD, through probably

the most accurate and flexible building load calculation program,

and in fact developed as a research tool, lacks air-side

mechanical systems and equipment simulation. A final comment on
the relative importance of loads calculations, air-side systems

simulations, and plant equipment simulations is in order. In

any program series which has all of these capabilities , it

is probably not cost effective to finance development of new

software which leads to a significantly greater level of

sophistication in any one of these areas. The need for loads

calculation and air-side system simulation capabilities is

adequately satisfied by the program series discussed above.

It is recommended that agency participants utilize the above

program series in calculation of site energy requirements.

ii'S Digital Control

The fifth area of analysis requiring computer assistance

is the development of the actual monitoring and control algorithms

for digital computer control of a MIUS. These evolving

algorithms will be the product of the knowledge gained from the

sim\ilation programs described above, and from operating experience

80
at early demonstration sites. Although no existing algorithms

were located in this study. Numerous commercial firms and

government agencies have a demonstrated capability in this area.

The NASA SINDA MIST model has the potential for providing

useful information. In addition, the instrumented Operation

BREAKTHROUGH Jersey City, MIUS demonstration will provide

valuable experience in this area.

Optimization

The ultimate need for computer assistance is in producing a user-oriented "MIUS Optimizer". This program will be

a commercial tool for automatic comparison of alternative MIUS

designs. It will enable MIUS designers to select the best

configuration for the site under consideration. The purpose

of this development is to provide increased incentive for

commercial implementation of the MIUS concept by making it

possible to easily produce good designs. The next section outlines ciirrent developments in this area.

Current Developments (1977)

Two programs are currently being developed for communityoriented energy analysis which will have significant impact on

satisfying needs identified in areas A, B, and F as outlined

above. Complete descriptions of these programs are not available at this time, but the following summaries are included to

81
indicate their scope.

Analysis of Advanced Coal-Using Communities (ACUCS)

.

The overall objective of the ERDA-sponsored ACUCS program is the

development of practical alternative systems for communities use that

will utilize coal in a clean and efficient way. This would lessen

the dependence of the community on oil and gas and facilitate the

utilization of traditionally wasted heat to satisfy some community

energy requirements. Three major programmatic activities are evaluation and characterization of technologies needed for coal-based

systems, collection and evaluation of community load data, and the

development of computerized system design methods.

The purpose of the computer model will be to provide good community energy system designs over the widest possible choice of

central system configurations and end-use fuel allocations. The

synthesis/optimization program is designed to analyze all types of

technologies and to consider all types of fuel-service assignments.

The results are at a generic process level (e.g. low pressure coal

pyrolysis). Consequently the program is expected to be used for

preliminary design by planners and design engineers.

The design program will be a mathematical optimization model that

determines the minimm cost energy system (or other measure of

effectiveness) that satisfies the energy needs of a conununlty. T^e

program requires as input the description of a set of generic central

conversion processes along with a physical description of a community

and its energy needs stated as service demands, i.e., BTU's for

heating, cooling, etc. The program determines the following (optimal)

82
system configuration, parameters, and operating characteristics;

° the number of each type of central conversion

device to install in the commionity;

° the allocation of fuels to user demands, i.e.,

gas for heating, electricity for cooling.

These allocations can he different for different

geographical areas and different economic sectors.

Thus the heating in an area near the central

plant may be provided by thermal heat while areas

farther from the central plant may be served with

gas heating systems

° the number and type of storage device to be installed;

° the operating levels of each conversion process

and storage device for each time period in the

year being modeled;

° the overall system efficiency;

° individual process efficiencies;

° initial investment costs, yearly maintenance costs,

and yearly fuel costs;

° related system measurements such as land area required, water resources required, pollution levels,

etc

83
i

,

.. Input requirements will include, but not be limited to the

following:

^ General community characteristics (e.g. , available

land, zoning, and buildings)

° Service (e.g., space heating) and/or energy (e.g.,

electricity) demands

, _ ° Weather profile

. ° Time horizon

° Financial limitations

° Types of coal available

° Air and water pollution limits

" Reliability standards

° Characteristics of existing equipment

° Limitations on equipment to be considered

Output options and results of analysis will include:

° Selection of generic processes for fuel conversion

and storage at central and secondary sites within

the commmity.

Identification of community zones and fuel types

distributed to each.

° Assignment of fuels to end-use service demands by

conununity zone and building type.

8h
Advanced Technology-Mix Energy System Program (ATMES)

The ERDA-sponsored ATMES Program, managed by Argonne National

Laboratory, is concerned with development and evaluation of central

energy supply systems for commianities . Existing and emerging

technologies are being scanned for their potential application in

such systems, and the most promising design concepts are evaluated

in detail. It is anticipated that a large number of different system configurations will have to be considered and therefore a highly

flexible and modular computerized energy modeling program is needed

to aid the design team. Strong emphasis is also placed on short

run times and ease-of-use.

The program will simulate the quasi-steady state operation of a

user-defined component configuration for a selected period of time,

generally in hourly increments. Plant operation will be simulated

in accordance with one of the following:

a. User-defined operating rules.

b. Weighted resource energy minimization.

c. Operating and maintenance cost minimization.

A library of component subroutines will be provied with the

program and will contain performance and economic data for various

central plant components. This library will be updated as new data

and components are evaluated. Component subroutines will be readily

modifiable by the program user.

The executive program will process the input data utilizing the

default dictionary to generate a standard file, analyze the information flow in the system and decide on the order in which the components

85
have to be simulated. The prograjn will then simulate the operation

of the plant and calculate fuel inputs for time increments requested

hy the user. A novel optimization algorithm was developed which

can "operate" the plant to minimize fuel input or costs. This will

represent a significant improvement over simple simulation and will

indicate the capabilities or limitations of the system when operated

according to the optimal strategy. An economic analysis will evaluate initial, operational, and life-cycle costs of the plant. It

could be run independently of the simulation portion of the program.

The input into the program will consist of two parts:

a. Description of the plant configuration, operating procedures, reports required, etc., given

in the System Definition and Control Language

(SDCL).

b. A file containing community energy requirements to be supplied by the plant (generally

in hourly increments), e.g., electricity, hot

water, steam, chilled water, etc., and other

variables, such as weather. The structure of

this file can be specified in the SDCL.

The basic output of the program will consist of the following

elements:

a. Amounts of fuel input into the plant during time

intervals specified by the user.

b. Plant outputs, distinguishing between outputs used

to satisfy community demand and those produced for
sale to other users outside the community.

Information on plant operation. For example,

statistics of equipment usage (possibly in a form

of a load diiration curve), and operating

strategies used by the optimization feature of

the program.

Results of economic analysis, i.e., first, O&M, an

life-cycle costs of the plant.

87
6. References

1. Michaud, Cooley, Hallberg, Erlckson and Associates, Inc., Consulting

Engineers, "Evaluation of Computerized Energy Programs for the

Calculation of Energy Use in New and Existing Buildings", prepared

for State of Minnesota Energy Agency and Federal Energy Administration,

October, 1975.

2 . Trane Air Conditioning Economics Documentation Manual , The Trane

Company, LaCrosse, Wisconsin, 1972.

3. Program Input: Trane Air Conditioning Economics , The Trane Company,

LaCrosse, Wisconsin, 1972.

4. ASHRAE Handbook of Fundamentals , "Load Calculations", Section IV,

American Society of Heating, Refrigerating and Air Conditioning

Engineers, Inc., New York, N.Y., 1967.

5. E-CUBE: Program Input Instruction Manual , Gate Information Center,

Southwest Research Institute, San Antonio, Texas, October, 1971.

6 . NBSLD, The Computer Program for Heating and Cooling Loads in Buildings , National Bureau of Standards Building Science Series 69, July, 1976.

7 . Computer Program for Analysis of Energy Utilization in Postal

Facilities , Volume I User's Manual, U.S. Post Office Department,

Washington, D.C.

8 . The Engineering Costs Section of AXCESS: Alternate Choice Comparison

for Energy System Selection , Electric Energy Association, New York,

New York (undated)

.

9 . Program Description Manual for AXCESS: Alternate Choice Comparison

for Energy System Selection , Version 1, Level 0, Electric Energy

Association, New York, N.Y., January, 1972.

10. The Financial Analysis Section of Alternate Choice Comparison for

Energy System Selection, EEA Pub. No. 70TM501, Electric Energy

Association, New York, N.Y. , (undated).

11 . "FINANS" Financial Analysis Program: Alternate Choice Comparison

for Energy System Selection , Version 1, Level 0, Electric Energy

Association, New York, N.Y. , June 1972.

12. W.J. Boegly, et al . , "Initial Comparisons of Modular-Sized Integrated

Utility Systems and Conventional Systems", Oak Ridge National

Laboratory unpublished report ORNL-HUD-MIUS-6 , June, 1972.

13. C.L. Segaser, "Computer Program for the Thermodynamic Analysis of

a Total Energy System", Oak Ridge National Laboratory unpublished

memorandum report, September 14, 1972.
14. C.L. Segaser, "HEATEN Computer Program for Estimating Residential

Space Heating Energy Requirements", Oak Ridge National Laboratory

unpublished memorandum report, September 22, 1972.

15. C.L. Segaser, "S0LAIR Computer Program for Estimating Residential

Cooling Energy Requirements, Oak Ridge National Laboratory

unpublished memorandum report, September 21, 1972.

16. Air Force, Army, and Navy Manual , AFM-88-8, Chapter 6, "Engineering

Weather Data", pp. 348, 349, June 1967.

17. ASHRAE Handbook and Product Directory; 1973 Systems , Chapter 43,

"Energy Estimating Methods", p. 43.13, American Society of Heating,

Refrigerating and Air Conditioning Engineers, New York, New York

1973.

18. ASHRAE Handbook of Fundamentals , Section IV, "Load Calculations",

American Society of Heating, Refrigerating and Air Conditioning

Engineers, Inc., New York, New York, 1972.

19. C.L. Segaser and W. R.Mixon, "MIUS Systems Analysis - Thermal

Energy Storage and Solid Waste Incineration", Oak Ridge National

Laboratory report ORNL-HUD-MIUS-26 , July, 1976.

20. C.L. Segaser, "A Preliminary Investigation of the Effect on Fuel

Consumption of Reclaiming Heat From Incineration of Refuse in a MIUS", Oak Ridge National Laboratory unpublished memorandum

report ORNL-HUD-MlUS-6, Addendum III, March, 1973.

21. S.L.Ferden, et al . , "Energy Systems Optimization Program (ESOP)

User's Guide", Lockheed Electronics Company, Inc., Houston

Aerospace Systems Division, Houston, Texas, Technical Memorandum

TM-3031, May, 1973.

22. ASHRAE Guide and Data Book: Fundamentals and Equipment for 1965

and 1966 , Section IV, "Calculations", American Society of

Heating, Refrigerating and Air Conditioning Engineers, Inc.,

New York, New York, 1965.

23. Trane Solar Tables for Heating Calculations , The Trane Company,

La Crosse, Wisconsin, 1966.

24. J.P.Smith, SINDA User's Manual , TRW Systems, Inc., Report No.

14690-HUUi-RO-OO, April, 1971.

25. I'. Isbimoto and L.C. Fink. SINDA Engineering-Program Manual , TRW Systems, Inc., Report No. 14b90-HOU2-RO-00 , June, 1971.

89
26. A Field Study of Load Profiles and Energy Requirements for Heating

and Cooling System Selected for the Field Validation T^st , ASHRAE

Symposium Bulletin No. 72-2, American Society of Heating,

Refrigerating and Air Conditioning Engineers, New York, New York,

1972.

27. G.A. Reeves, et al., "Crosschecking Energy Analysis Procedures

and Standardizing Weather Input", pp. 323-331, ASHRAE Transactions,

Vol. 82, part 1, 1976.

28. J. Barnett and S. Liu, "Comparison of Computer-Predicted and

Observed Energy Uses In a Multi-Family High-Rlse Apartment

Building", NBSIR 76-1177, May, 1977.

90
7. Acknowledgements

The authors wish to gratefully acknowledge the invaluable

assistance of L.F. Bate in the collection and preparation of information

on several of the programs which are discussed in this report . In

addition, the assistance of V.A. Rabl of Argonne National Laboratory

in supplying current (1977) summary information on the ACUCS and ATMES

program development activities is also gratefully acknowledged.

91

room cycle

day cycle

hour cycle

INTERNAL LOAD AND OPERATING SCHEDULE

WALLS, ROOF AND FLOOR DATA

T

building cycle | CONDUCTION TRANSFER^FUNCTIONS

BUILDING DATA

ROOF SURFACE DATA

INTERIOR SURFACE HEAT TRANSFER COEFFICIENTS

INTERIOR SURFACE RADIATION EXCHANGE FACTORS

i

WEATHER DATA

HOLIDAY, WEEKENDS DETERMINATION

DAYLIGHT SAVING TIME INDICATOR

CLOUDLESS SKY SOLAR RADIATION

SUN-LIT AREA DETERMINATION

ft^ CLOUD COVER MODIFICATION

ON SOLAR HEAT GAIN AND SOLAR INTENSITY

* AIR INFILTRATION

OUTSIDE SURFACE HEAT TRANSFER COEFFICIENT

* OUTSIDE SURFACE TEMPERATURE AND HEAT FLOW

ATTIC TEMPERATURE

INSIDE SURFACE TEMPERATURE AND HEAT FLOW

COOLING LOAD OR THE ROOM TEMPERATURE

OUTPUT TABLE

1 SYSTEM SIMULATION i L_ _l

Figure 1 MBSLD Frogram Sequence

t
J

.41 (
CO>—J<Z<<zoCO<

UJCO

O<LUto

00

Of3

UJ >o<

UJX

FLOAT RATIO

FIXED RATIO

ABSORB A/C

SEASONAL OUTPUT

YEARLY OUTPUT

a.O <

to

>-<z<I <zoto<UJto

I—X

UJZ

00oo

00
Y

\

'l
NBS-I 14A (REV. 7-73)

U.S. DEPT. OF COMM. BIBLIOGRAPHIC DATA

SHEET

1. PUBLICATION OR REPORT NO. WBSIR 77-1307

2. Gov't Accession

No.

3. Recipient's Accession No.

4. TITLE AND SUBTITLE

A Review of Computer Software Applicable to the MIUS Program

5. Publication Date October 1977

6. Performing Organization Code

7. AUTHOR(S)

William L. Carroll and John R, Schaefgen, Jr.

8. Performing Organ. Report No.

9. PERFORMING ORGANIZATION NAME AND ADDRESS

NATIONAL BUREAU OF STANDARDS

DEPARTMENT OF COMMERCE

WASHINGTON, D.C. 20234

10. Project/Task/Work Unit No. U6573T3

11. Contract/Grant No.

12. Sponsoring Organization Name and Complete Address (Street, City, State, ZIP)

Office of Policy Development and Research

Department of Housing and Urban Development

Washington, D. C. 20UlO

13. Type of Report & Period Covered

Final

14. Sponsoring Agency Code

15. SUPPLEMENTARY NOTES

16. ABSTRACT (A 200-word or less factual summary of most si^ificant information. If document includes a significant

bibliograptiy or literature survey, mention it here.) Thirteen computer programs are examined for potential application to the Modular

Integrated Utility System (MIUS) program. The software programs considered calculate

all or partial combinations of: heating and cooling loads, simulation of physical

systems to determine the energy requirements necessary to satisfy those loads,

prediction of optimal operation schedules and associated costs, and accomplishment

of full life-cycle economic analyses. A set of criteria for evaluation of this

software is presented. Information regarding the programs, obtained from user manuals and a series of seminar presentations, is collected and systematically

summarized in a standardized formal using information available as of June, 197U,

An evaluation siammary of each program as of that date is given. Program comparison

activities are discussed and evaluated. Conclusions regarding applicability, validity

and utility of programs are reached. Recommendations are made concerning future

software development and utilization.

17. KEY WORDS (six to twelve entries; alphabetical order: capitalize only the first letter of the first key word unless a proper name; separated by semicolons) Computer programs; cooling; energy analysis; financial

analysis; heating; load calculation; MIUS; modular integrated utility system;

simulation; utility services

18. AVAILABILITY Unlimited

I

[ For Official Distribution. Do Not Release to NTIS

I I Order From Sup. of Doc, U.S. Government Printing Office Washington, D.C. 20402, SD Cat. No. C13

19. SECURITY CLASS

(THIS REPORT)

UNCLASSIFIED

[X] Order F rom National Technical Information Service (NTIS)

Springfield, Virginia 22151

20. SECURITY CLASS

(THIS PAGE)

UNCLASSIFIED

21. NO. OF PAGES

101

22. Price

$6.50

USCOMM.DC 29042-P74
I fI
t\I