EPA-600/3-82-059
PB82-237033
Maintenance and Testing of Hydrological
Simulation Program—FORTRAN (HSPF)
Hydrocorap, Inc.
Mountain View, CA
Prepared for
Environmental Research Lab
Athens, GA
May 82
U.S. DEPARTMENT OF COMMERCE
National Technical Information Service
-------
EPA 600/3-82-059
May 1982
PBS2-237033
MAINTENANCE AND TESTING
OF HYDROLOGICAL SIMULATION PROGRAM—FORTRAN (HSPF)
by
Robert C. Johanson and David Kliewer
Hydrocomp, Inc.
Mountain View, California 94040
Contract No. 68-01-5801
Project Officer
Thomas 0. Barnwell, Jr.
Technology Development and Applications Branch
Environmental Research Laboratory
Athens, Georgia 30613
.or,t:.j prctoct!on Agency
• • '"- ;- ...:.. m fitroet
,.. :,-;o, iinr;o!s 60604
ENVIRONMENTAL RESEARCH LABORATORY
OFFICE OF RESEARCH AND DEVELOPMENT
U.S. ENVIRONMENTAL PROTECTION AGENCY
ATHENS, GEORGIA 30613
REPRODUCED BY
NATIONAL TECHNICAL
INFORMATION SERVICE
US. DEPARTMENT OF COMMERCE
SPRINGFIELD. V«. Z2ISI
-------
J,S- Environment:-! ^ctecticn
-------
TECHNICAL REPORT DATA
(Please read Instructions on the reverse before completing/
1. REPORT NO.
EPA-600/3-82-059
ORD Report
3. RECIPIENT'S ACCESSION-NO.
23703
4. TITLE AND SUBTITLE
Maintenance and Testing of Hydrological Simulation
Program—FORTRAN (HSPF)
5. REPORT DATE
Mav 1982
6. PERFORMING ORGANIZATION CODE
7. AUTHOR(S)
Robert C. Johanson and David Kliewer
8. PERFORMING ORGANIZATION REPORT NO.
9. PERFORMING ORGANIZATION NAME AND ADDRESS
Hydrocomp, Inc.
201 San Antonio Circle
Mountain View, California 94040
10. PROGRAM ELEMENT NO.
AARB1A
11. CONTRACT/GRANT NO.
68-01-5801
12. SPONSORING AGENCY NAME AND ADDRESS
Environmental Research Laboratory—Athens GA
Office of Research and Development
U.S. Environmental Protection Agency
Athens, Georgia 30613
13. TYPE OF, HE PCU1T. AI
Final, 3/79-
RIOD COVERED
14. SPONSORING AGENCY CODE
EPA/600/01
15. SUPPLEMENTARY NOTES
16. ABSTRACT
The Hydrological Simulation Program—FORTRAN is a mathematical model that
simulates hydrology and water quality in natural and man-made water systems. This
report describes the work involved in maintaining and testing HSPF over a one-year
period following its initial development An account is given of the chronology of
major events during the maintenance work. The testing included work with hypo-
thetical data and checks against outputs produced by three predecessor models,
the ARM, NPS, and HSP-QUALITY models. Through this process it was determined that
the HSPF model functioned as designed.
KEY WORDS AND DOCUMENT ANALYSIS
DESCRIPTORS
b.lDENTIFIERS/OPEN ENDED TERMS C. COSATI Field/Group
18. DISTRIBUTION STATEMENT
RELEASE TO PUBLIC
19. SECURITY CLASS (This Report/
UNCLASSIFIED
21. NO. OF PAGES
92
20. SECURITY CLASS (This page 1
UNCLASSIFIED
22. PRICE
EPA Form 2220-1 (9-73)
-------
DISCLAIMER
This report has been reviewed by the Environmental Research Laboratory, U.S.
Environmental Protection Agency, Athens, Georgia ,and approved for
publication. Approval does not signify that the contents necessarily
reflect the views and policies of the U.S. Environmental Protection Agency,
nor does mention of trade names or commercial products constitute
endorsement or recommendation for use.
ii
-------
FOREWORD
As environmental controls become more costly to implement and the
penalties of judgment errors become more severe, environmental quality
management requires more efficient analytical tools based on greater know-
ledge of the environmental phenomena to be managed. As part of this
Laboratory's research on the occurrence, movement, transformation, impact,
and control of environmental contaminants, the Technology Development and
Applications Branch develops management and engineering tools to help pol-
lution control officials achieve water quality goals through watershed
management.
The development and application of mathematical models to simulate the
movement of pollutants through a watershed and thus to anticipate environ-
mental problems has been the subject of intensive EPA research for several
years. The most recent advance in this modeling approach is the Hydrological
Simulation Program—FORTRAN (HSPF), which uses digital computers to simulate
hydrology and water quality in natural and man-made water systems. HSPF is
designed for easy application to most watersheds using existing meteorologic
and hydrologic data. Although data requirements are extensive and running
costs are signinicant, HSPF is thought to be the most accurate and appropri-
ate management tool presently available for the continuous simulation of
hydrology and water quality in watersheds.
David W. Duttweiler
Director
Environmental Research Laboratory
Athens, Georgia
iii
-------
ABSTRACT
The Hydrological Simulation Program—FORTRAN (HSPF) is a mathematical
model that simulates hydrology and water quality in natural and man-made water
systems. This report describes the work involved in maintaining and testing
HSPF over a period of one year following its initial development. An account
is given of the chronology of major events during the maintenance work. One
of the major lessons learned was that the preparation of a new release of the
code and documentation is more costly than first expected. The testing in-
cluded work with hypothetical data and checks against outputs produced by
three predecessor models, the ARM, NPS, and HSP-QUALITY models. Through this
process, it was determined that the HSPF model functioned as designed.
This report was submitted in partial fulfillment of Contract No.
68-01-5801 by Hydrocomp, Inc., under the sponsorship of the U.S. Environmental
Protection Agency. This report covers the period March 1979 to June 1980,
and work was completed as of June 1980.
iv
-------
CONTENTS
Foreword iii
Abstract lv
Figures vi
1.0 Introduction 1
2.0 Conclusions 3
3-0 Recommendations 6
4.0 Maintenance Experience g
4.1 Scope of Maintenance Work 8
4.2 New Installations 8
4.3 Bug Correction 11
4.4 New Releases 13
4.5 Software Extension 17
5.0 Testing 20
5.1 Purpose and Scope of Testing 20
5.2 Tests Using Hypothetical Data 21
5-3 Tests on Data from the Occoquan Basin 23
5.4 Tests on Data from the MSU Watershed 44
6.0 References 82
-------
LIST OF FIGURES
FIGURE NO. PAGE
1 Map Showing Sub-basins Included in 24
Occoquan basin
2 Simulated Outflow From Subbasin 4 28
(Occoquan)
3 Simulated Concentration of P04 in Outflow 29
From Subbasin 4 (Occoquan)
4 Simulated Concentration of Organic N in 30
Outflow From Subbasin 4 (Occoquan)
5 Simulated Outflow from Reach 50 (Occoquan) 33
6 Simulated Temperature in Reach 50 34
(Occoquan)
7 Simulated Concentration of DO in Reach 40 35
(Occoquan) - Preliminary Run
8 Simulated Concentration of Phytoplankton 36
in Reach 50 (Occoquan)
9 Simulated Concentration of P04 in Reach 50 37
(Occoquan)
10 Cross Section for Reach 50 (Reservoir) 38
11 Simulated Ammonia Concentration in Reach 50 39
(Occoquan), with Adjusted Phytoplankton
Growth
12 Simulated Concentration of P04 in Reach 50 40
(Occoquan), with Adjusted Phytoplankton
Growth
13 P6 Watershed, East Lansing, Michigan **5
(0.8 ha)
14 Structure Chart of the Previous Land-Segment 48
Application Module
vi
-------
15 Simulated Snowpack, P6 Watershed 50
16 Precipitation and Simulated E-T, P6 53
Watershed
17 Simulated Runoff and Sediment Yield, 54
P6 Watershed
18 Simulated Surface Runoff and Interflow Outflow, 55
P6 Watershed
19 Simulated Runoff and Sediment Loss for Storm of 57
August 13, 1974 - P6 Watershed
20 Simulated Runoff and Sediment Loss for Storm of 58
August 27, 1974 - P6 Watershed
21 Simulated Storage of Atraqine in the Surface 61
and Upper Layers, P6 Watershed
22 Simulated Removal of Atraqine - P6 Watershed 62
23 Simulated Removal of Paraquat - P6 Watershed 63
24 Simulated Removal of Paraquat on Sediment - 64
PT Watershed
25 Nutrient Transformations in the ARM Model 67
26 Simulated Removal of Nitrogen - P6 Watershed 69
27 Simulated Removal of Phosphate in Solution - 70
P6 Watershed
28 Simulated Total Removal of Nitrogen for Storm 71
of August 13, 197t - P6 Watershed
29 Simulated Removal of NH4, for Storm of 72
August 13, 1974 - P6 Watershed
30 Simulated Removal of Nitrate, for Storm of 73
August 13, 1974 - P6 Watershed
31 Simulated Removal of Phosphate for Storm of 74
August 13, 1974 - P6 Watershed
32 Simulated Removal of Total N for Storm of 75
August 27, 1974 - P6 Watershed
vii
-------
33 Simulated Removal of NH4 and P04 for Storm • . . 76
of August 27, 1974 - P6 Watershed
34 Runoff Simulated by HSPF for Storm of 79
August 13, 1974 - P6 Watershed
viii
-------
1.0 INTRODUCTION
The purpose of the work described in this report was to maintain and test
the Hydrological Simulation Program-FORTRAN (HSPF), which had previously
been developed under EPA sponsorship.
HSPF is a mathematical model for simulating the hydrologic and water quality
processed in and under the land surfaces of a watershed and in the
associated streams and lakes. The roots of HSPF go back to the famous
Stanford Watershed Model (Crawford and Linsley 1966), which was one of the
first rainfall-runoff computer models and was developed under National
Science Foundation sponsorship. Many newer models have been developed from
it; among the best known is the Hydrocomp Simulation Program (Hydrocomp Inc.
1969), which incorporated a sophisticated time series management system.
Hydrocomp also developed a water quality model (Hydrocomp Inc. 1977) which
simulates the accumulation of constituents on a watershed surface, their
washoff into streams and lakes and the biochemical transformations that
occur in such water bodies.
The "Lands" section of the Stanford Watershed Model was also used as the
basis for the Agricultural Runoff Management (ARM) Model (Crawford and
Donigian 1973, Donigian and Crawford 1976 a, and Donigian et al 1977) which
was sponsored by the U.S. EPA through the Environmental Research Laboratory
in Athens, Georgia. It simulates sediment production, as well as the
behavior of pesticides and nutrients, on agricultural lands. The U.S. EPA
also sponsored the development of the Non-Point Source (NFS) Model (Donigian
and Crawford 1976 b) which simulates the washoff of constituents from land
surfaces by relations with washed off sediment.
Although all the above models originated from the Stanford Watershed Model,
they have each undergone develpment in their own specialized directions.
Each one is a powerful tool for use in its area of specialization, but it is
-------
not easy to use them together in situations where their combined strength is
required. With the goal of overcoming this problem, the Environmental
Research Laboratory (ERL) in Athens, Georgia sponsored the development of a
"comprehensive package for the simulation of watershed hydrology and water
quality", which later became known as HSPF. The objective was to
incorporate the capabilities of all of the above models in a single,
consistently designed set of well-documented software, written as far as
possible in ANSI FORTRAN (1966 Version). This was part of the ERL's program
to develop engineering tools to help pollution control officials achieve
water quality goals through watershed management.
Work on the development of HSPF, under Grant No. R804971-01, started in
November 1976 and ended in Novenber 1978. In February 1979 the go-ahead was
received to commence work on the present maintenance and testing contract.
This work culminated with the issue of Release 5 of the code (in February
1980), a revised User's Manual (Johanson, et. al. 1979) and this report.
-------
2.0 CONCLUSIONS
Our conclusions relating to the maintenance phase of this project are:
1. The care which went into the design, coding, and documentation
of the HSPF software is paying off; it is relatively easy
for a well-trained person to maintain. Bugs have usually been
easy to locate and to fix. It has also been easy to add new
modules, as envisaged in the design.
2. Implementation on a wide variety of machines is more difficult
than originally envisaged. This is due principally to two
factors:
a. The sheer size of the system, which makes it impossible to
implement on certain machines and/or operating systems
(e.g., PDP11 with IAS).
b. The use of half-word integers. This extension to ANSI
FORTRAN is not implemented on some widely used machines.
In retrospect, we believe this extension should not have
been used.
3- We have been able to maintain high standards in:
a. Keeping the code consistent with the principle of
Structured Programming Technology.
b. Keeping the documentation and other associated datasets
consistent with the code.
-------
This consistency was quite costly, since the logistics of
maintaining a large system, with 500 subroutines and s user's
manual of 650 pages, are quite complex. It required continuous
effort and great attention to detail.
4. In the future, as the number of users increases, most of the
maintenance work will consist of:
a. Answering questions while users are still installing or
becoming accustomed to HSPF. Many users are likely
to have initial difficulties, particularly if they
have not attended a workshop. Most of these calls will
not involve bugs in the code.
b. Updating of code, documentation, and associated datasets,
(i.e., New Releases), if significant alterations or
enhancements are made to the system.
c. Communication of information to users, through a monthly
or quarterly circular.
5- Because of the great flexibility of HSPF and the fact that it
makes extensive use of disc input/output, it takes more computer
time (and dollars) than did its predecessor models.
6. It was wise to restrain wholesale distribution of the system
until the testing work was complete.
Our conclusions relating to the testing phase of this work are:
-------
1. HSPF has been put through a comprehensive set of tests and found
to correctly implement the algorithms described in the User's
Manual. It is ready for public distribution.
2. Where it was checked against its predecessor models, HSPF
produced similar output, with these notable exceptions:
a. Simulation of nutrient behavior in pervious land
segments (PERLND module) did not agree with the
results produced by the ARM model. This is
attributable to:
(i) Intermittent calculation of reaction fluxes in
ARM Model runs
(ii) Problems inherent in having a thin surface layer,
with moisture storage dependent only on overland
flow depth (a feature of both ARM and HSPF)
b. Simulation of phytoplankton in streams and reservoirs.
Because HSPF and HSP-QUALITY use different definitions of
"water body depth" in the light extinction equation, they
produce radically different light-limiting phytoplankton
growth rates.
-------
3.0 RECOMMENDATIONS
1. The EPA should publicize the HSPF system, stressing its great
flexibility in operation and its many other unique features, many of
which are not obvious to a casual user. This publicity could include
partial or full sponsorship of additional workshops, for new or
experienced users.
2. The EPA should continue to support the program through:
a. Help for new users who are experiencing difficulty in installing or
understanding the system.
b. Maintenance of "official" and "development" versions of the code,
documentation, and associated datasets.
c. Correction of bugs reported by users, periodic reporting of such
information and production of new releases when necessary.
3- The EPA should consider sponsoring some further development of the
model:
a. Elimination of half-word integers, to make it easier to install on a
variety of machines.
b. Development of a special version for large-memory installations,
designed to minimize disc input/output and associated costs.
c. Improved trapping of user's errors, by the Run Interpreter.
d. A study of the feasibility of having a dynamically varying internal
time step for certain processes - fine when there is rapid
-------
variation, coarse when there is not. This would save computer time.
4. Two problems in the agricultural chemical simulation system of the
PERLND module need to be solved:
a. The MSTLAY section needs to be reformulated, so that the system will
give results that are not a direct function of the time step, thus
freeing this part of HSPF from the 5 and 15 minute time steps to
which it (and ARM) is limited.
b. The problems posed by the use of a thin surface layer, with moisture
storage totally dependent on overland flow depth, must be overcome.
5. A short series of tests designed to check the following should be
considered:
a. The effect of varying the internal time step.
b. The effect of varying the number of "areal-source blocks" in the
PERLND module.
-------
4.0 MAINTENANCE EXPERIENCE
4.1 SCOPE OF MAINTENANCE WORK
The EPA set out its requirements for this task in its "request for proposal"
(RFP), issued in January 1979- In our proposal (February 1979) we responded
to these points and expanded on them. Later, there was some further
negotiation on the items to be included in the maintenance and the testing
tasks. The maintenance work was finally divided into four principal
categories:
1. New Installations. For services to be provided, at EPA's request, in
setting up the HSPF system on other computer installations.
2. Bug Correction. For work involved in correcting errors found in the
code.
3- New Releases. For work involved in producing new versions of the code
(incorporating the latest updates) and associated revisions to the
documentation.
4. Software Extension. For work involving the addition of new capabilities
to the package.
4.2 NEW INSTALLATIONS
When this contract commenced it was envisioned that HSPF would be
distributed quite widely while the testing work was still in progress and
that Hydrocomp would provide some assistance in installing HSPF at other
computer centers, as part of this contract. It was stipulated that the
service was to be provided only to public agencies or their consultants, at
-------
the request of EPA, and that the total time spent was not to exceed two
weeks.
As work progressed, the dangers involved in distributing a relatively
untested set of code became apparent and EPA wisely decided to limit
distribution until the testing work was complete. As a result, Hydrocomp
has provided assistance to only two organizations as part of this contract:
1. ERL-Athens. When this project commenced, we sent a copy of the FORTRAN
code to ERL Athens, for possible installation on their PDP11 system. As
expected, the FORTRAN language used on our HP3000 machine was easy to
adapt to the PDP11 installation, but the program was too large to be
handled by the operating system available there. And, since it was not
practical to install an alternative operating system, EPA needed a
version of the code which could run on the IBM370 system provided by its
computing vendor in Washington, D.C. This need coincided with a similar
request from a different client. Thus, an IBM version of the code
(called Release 3) was produced during May and June 1979, and sent to
ERL-Athens in July, where it was installed with little difficulty.
2. By November, 1979 Release 4 of the code was available. At EPA's
request, we supplied a copy to their contractors for the Iowa field
evaluation program. They installed it without difficulty at Stanford
University and forwarded a copy to ERL-Athens.
In February 1980 the final release of the code and documentation was
available. A copy was sent to the Project Officer for installation at EPA,
and for general distribution.
During the past year we have also distributed copies of the code to some
other clients, by private arrangements. Some private arrangements for
maintenance and applications assistance have also been made. This work has
-------
benefited the present contract because experience gained in these situations
has made possible some improvements to the whole HSPF package.
Although only two "new installations" were serviced under this contract
during the past year, the need for this kind of assistance will almost
certainly increase in the future, and we believe EPA should continue to
provide some such service. Based on our experience thus far, with public
and private distribution, most users do not require extensive help if they
are installing HSPF on a type of system on which it has already been checked
out (HP3000, IBM360 or 370). A few phone calls are usually all that is
necessary.
In this connection, EPA should consider sponsoring some work to make HSPF
available on a wider range of machines:
1. Elimination of the use of half-word integers. In retrospect, we can see
that their use has not been beneficial; adaptation of HSPF to systems
like UNIVAC 1100, CDC, and Honeywell would be greatly assisted if
half-word integers were eliminated.
2. Development of a version tailored for larger machines. At present, the
COMMON block is of limited size, to permit the system to operate on
smaller machines. By enlarging the COMMON block, the frequency of disc
input/output could be considerably reduced. This would greatly assist
users who presently find HSPF too expensive to run because of disc I/O
charges.
10
-------
4.3 BUG CORRECTION
This subtask covered the work involved in fixing errors reported by users.
Typically, when a user experienced a problem, we would first have to check
whether the problem was due to a bug or to an error in the way he had set up
his input. If a bug was found, the FORTRAN code was suitably altered, the
affected subprogram(s) recompiled and the entire system relinked. Any
associated alterations to the pseudo code and User's Manual were noted, but
their implementation was deferred until a sufficient number of changes had
been accumulated to warrant the issue of a new release of the system
(covered under "New Releases" subtask).
Because initial distribution of the program was limited, the vast majority
of bugs were reported by Hydrocomp employees who were working on the testing
phase of this project and a variety of other projects which made use of
HSPF. However, some bugs were first discovered by other users.
The rate at which bugs were found decreased with time, as expected.
Initially, we projected that there would not be a corresponding decline in
the rate of expenditure on this subtask because the bugs would become
progressively more subtle and difficult to fix. However, this was not the
case. In general, the later bugs have been no more difficult to locate and
fix than were the earlier ones. Thus, the effort expended on this subtask
did decrease progressively, from eleven person-days in April '79 to six in
June, and 1.5 in November. It should be noted that this experience applies
primarily to bugs reported within our own organization. It is not
applicable to problems encountered by other users because:
11
-------
1. It can be quite difficult to obtain sufficient information from the user
to judge whether the problem is of his own making or is, indeed, due to
a bug in the program.
2. The bug might be specific to a certain version of the program- For
example, we had at least one problem reported to us which occurred only
on the IBM version of the code. It took some time and effort to
diagnose and correct the problem, since we:
a) had to obtain copies of the user's input (on tape)
b) first tried running it on our installation, and found no problem
c) switched to an IBM installation, and diagnosed the problem there
We mention the above points because they are especially relevant to future
maintenance sponsored by EPA. It will often be difficult to determine
whether a user's problem is due to an error in the code and, if so, to
locate it, fix it, and notify all other affected users of the problem.
In retrospect, we can see that it was wise to limit the circulation of the
model until the completion of testing. If EPA had not done so, much effort
would have been expended in dealing with problems encountered by users
working with partially tested code. As it happened, most of the problems
were found by users in our own organization, and could be quickly dealt with
because communication was quick and complete.
The RFP for this contract (and our proposal) envisaged the production of a
monthly circular to inform users of bugs (and work-arounds for them, where
possible). Because of the limited circulation of HSPF during this project,
the circular was not necessary. However, in the future a monthly (or
12
-------
perhaps quarterly) circular would serve a useful purpose.
4.4 NEW RELEASES
General Approach
Our approach to this work is similar to that adopted by most computer
companies who support software. It starts with the premise that the
computer code will evolve, as bugs are fixed, new options added, etc. It is
also presumed that the documentation should be kept consistent with the
code.
Obviously, it is not economical to issue a new copy of the code and
documentation every time a change is made. Rather, one should accumulate
(and test) the changes until enough have been collected to justify the issue
of & new "release" of the code. To do this effectively, the maintainer must
keep at least two versions of the code on his computer system:
1. The latest official release. This would be the version normally sent to
any user who requests a copy of the software.
2. A "development version". This version includes all updates and
extensions made since the last release, and is normally only used within
the maintainer1s organization, to collect and test the updates.
A parallel system is used to keep the documentation in step with the code.
Between issues of official releases, users should be notified of any
significant problems in the latest official version via a newsletter or
circular.
13
-------
Mechanism Used to Generate a New Release
Whenever we decided to issue a new release, the following steps were
involved:
1. All files containing FORTRAN code, load modules, etc., in the
"development" state were now designated the new "official" version and
given a new release number. The old version was purged.
2. Many associated datasets, containing the documentation, pseudo code,
data structures, sample JCL, etc. had to be updated. While the new
version was under development, the updates to these files had simply
been marked on listings - now all the updates were actually performed.
3. New and/or updated pages for the User's Manual were prepared, as well as
an "Errata Sheet" containing minor changes that did not warrant reissue
of an entire page.
4. All new and revised datasets were copied to tape, to provide a backup.
5. An "IBM version master tape" was created, by running a program that
automatically generated IBM FORTRAN from HP3000 FORTRAN.
History of Activities
As soon as work on this contract started in February 1979, there was intense
activity on the testing and development of the HSPF system. As a result,
the System Documentation which had been produced in December 1978 soon
lagged far behind the state of the FORTRAN code and became out of date.
Then, from May through August, attention was shifted away from the testing
and debugging work, so that the documentation could be completely revised.
(This work proceeded simultaneously with the development of the IBM version
14
-------
of the code.) With the concurrence of the Project Officer, it was decided
to divide the documentation into two publications:
1. The User's Manual (650 pages). This would contain all the information
that a user would normally require and would be printed and distributed
by EPA.
2. The Programmer's Supplement. This would contain additional
documentation, such as the pseudo code and data structures, which would
be useful to those who need to understand the inner workings of HSPF or
who need to modify or extend it. For the sake of economy, it was decided
not to print this information but to circulate it on magnetic tape with
the source code and other associated datasets.
This extensive overhaul of the documentation and the development of the IBM
version culminated in the issue of Release 3 of the code and documentation,
dated September 1979. The originals for the User's Manual were sent to EPA
so that arrangements for printing could be put in hand while the development
and testing continued.
The next release was issued in November 1979- It included the new utility
modules (DISPLY, DURANL, AND GENER), which had been developed during
September and October as part of the "Software Extension" subtask. It was
issued to provide the EPA, its contractors, and Hydrocomp clients with an
updated interim version of the code, seeing that the final release was only
due for issue in February 1980.
Release 5 was issued in February. Tapes containing the source code,
Programmer's Supplement, and all associated datasets were sent to the
Project Offier. These were the principal deliverable items in this
contract. Updates for the User's Manual were also sent.
15
-------
Summary and Conclusions
In retrospect, it seems we were right to issue three new releases during the
course of the project. The model was undergoing relatively rapid change
through this development and testing period, so each release did contain a
very significant quantity of different material to the previous one. From
now on, the frequency should be far lower because we know the code and
documentation are thoroughly checked out and very reliable. We suggest that
EPA might issue a new release once or twice per year and handle changes in
the interim by circulating notices to users wherever necessary. However, if
significant alterations or additions to the program are planned, the
frequency of new releases would need to be higher.
The main surprise in doing this work was the high cost of preparing and
maintaining good quality documentation. In our proposal, "New Releases" was
scheduled to take about 12$ of the total maintenance effort. The actual
cost was about 50$. The ratio is likely to remain at about this level in
the future because of the logistical problems involved when there are many
users, on different computer systems, to be serviced (we include the cost of
preparing the periodic newsletter in this estimate).
The high cost of keeping good, consistent master copies of code and
documentation probably accounts for the fact that engineering programs are
often not well documented and that no official copy is kept—users are left
to fend for themselves. This is, indeed, an alternative philosophy of
software "maintenance" and distribution. But we believe that EPA should
plan to support an official copy.
16
-------
H.5 SOFTWARE EXTENSION
HSPF was designed so that new or alternative operating modules could be
added to the system with relatively little difficulty, provided the person
doing the work has a thorough grasp of the basic design. There are several
advantages to this aspect of the design:
1. New operating modules can send output to, or get input from, any of the
existing operating modules in HSPF—the user does not have to write any
"interfacing" software to achieve this.
2. The new modules can communicate with an HSPF.Time Series Store, via the
existing Time Series Management System (TSGET and TSPUT modules), and
thus instantly gain the advantages provided by it, such as:
a. automatic conversion of time step between the operating modules and
the TSS, where necessary.
b. the ability to read time series placed into the Time Series Store
(TSS) by another module, and vice versa.
c. the use of compressed storage of data in the TSS.
Some of the innovative design features of HSPF were expensive to provide but
we expected that the flexibility that they brought would soon justify the
investment. Thus, in our proposal for this contract, we suggested that for
a modest additional investment some utility modules could be added, which
would greatly enhance the power of the entire system.
The utility modules added to HSPF were:
17
-------
1. PLTGEN. This module accepts one or more time series as inputs and
generates a "plot file", in which the data are recorded sequentially.
This file is then read by a stand-alone program which translates the
information into commands which drive a plotter. Thus, any time series
of recorded or computed data can be plotted individually or in concert
with several others.
2. DISPLY. This module permits any time series to be displayed in a neatly
formatted table, at any of the HSPF-supported time steps. Day, month,
and annual totals, averages, etc. can also be included in the tabular
layouts.
3. DUFANL. This module performs a variety of statistical analyses on a
time series. The simplest option produces a cumulative frequency
distribution of the time series. But it can also determine the
frequency of excursions (of specified durations) above or below preset
levels. This option can be used to answer a question such as "How often
does the concentration of constituent X exceed Y mg/1 for Z or more
consecutive time steps?
4. GENER. This module is used to generate a time series from one or two
others. For example, it can produce a series C whose values are the
natural log of those in the input time series A. Or, it can produce a
time series C whose values are the product of those in two input time
series A and B. This latter option could be used to compute the flow of
a constituent (in load units) given the two time series of flow of water
and constituent concentration. Altogether the GENER module provides for
14 different transformations.
The total cost of the software extension work was $17,000; only about $4,000
per module. We believe that this low cost does validate our contention that
the design of the system makes it easy to integrate new operating modules
18
-------
into HSPF. One "outside" user has added yet another utility module; also
with very little effort.
19
-------
5.0 TESTING
5.1 PURPOSE AND SCOPE OF TESTING
The purpose of this testing work was to check that the HSPF code correctly
implemented the modeling algorithms outlined in the User's Manual. The
algorithms are, for the most part, similar to those embodied in the
predecessor models, but the manner in which they are included in HSPF is
very different, since it has a radically different structure compared with
its forebears. Thus, most of the testing consisted in comparing the output
produced by HSPF against that produced by the ARM, NFS, and HSP-QUALITY
models, given identical inputs. We reasoned that, if the outputs were
close, the old and new models agreed with each other and, most likely, they
both correctly implemented the modeling algorithms. But, if they differed
substantially, there was a possibility that HSPF was in error, and the
difference must be investigated.
This was a different approach to that usually taken in testing work where
model output is compared against observed data. We reasoned that the
predecessor models had already been checked in this way (e.g., Donigian and
Crawford 1976 b, Donigian et. al. 1977). Thus, in the first instance, HSPF
should be tested by checking its consistency with these models. Later, any
features of HSPF which are not present in the predecessor models, or which
have been intentionally implemented differently, could be tested in the
usual way.
The testing work was in three phases:
20
-------
1. Tests using hypothetical data. In this work the modules were set up to
operate in hypothetical situations. This usually involved the use of
simple input time series and parameter sets. The simulation output was
checked against manual calculations.
2. Tests on data from the Occoquan basin, Virginia. In 1977, Hydrocomp
developed the Occoquan Basin Computer Model (Hydrocomp 1978) for the
Northern Virginia Planning District Commission (NVPDC). It incorporates
the Nonpoint Source (NFS) model and the HSP-QUALITY model, plus some
extensions. Since the algorithms in HSPF and the Occoquan Basin
Computer Model are, for the most part, similar and, since NVPDC had
performed extensive simulation work on the Occoquan Basin, their data
set was an obvious choice for testing HSPF.
3- Tests on data from Michigan State University watershed P6. In 1977, we
completed a project for EPA which involved the refinement and testing of
the ARM model (Donigian et. al. 1977). Part of this work used data
which Michigan State University (MSU) had collected on their P6 test
watershed, and involved the testing of the snowmelt and agricultural
chemical sections of the ARM model. This dataset was also included in
the HSPF testing because the simulations performed on the Occoquan by
NVPDC did not include snowmelt and the detailed simulation of pesticides
and nutrients. Thus the MSU dataset filled a large gap which would
otherwise have been present in our testing work.
5.2 TESTS USING HYPOTHETICAL DATA
When this contract commenced on February 20, 1979, the HSPF system was
practically complete, but bugs prevented some areas of the code from
operating or caused them to give incorrect results. The first task was to
bring the entire package to the point where it could operate successfully
and to ensure, as far as possible, that the results produced were
21
-------
reasonable. To do this, a succession of at least 13 different test inputs
was created, each designed to exercise a different area of the code. Using
these, we steadily worked our way through the PERLND, IMPLND, and RCHRES
modules. We would attempt to run a test dataset, fix any bugs which
prevented execution and, once it successfully executed, check that the
results were reasonable. Then we would move on to the next test. This
process took place during March and April 1979- By April 15 all the HSPF
code was executable.
A variety of checks were performed on the results obtained from these tests:
1. Many module sections provide an internal check, by computing a
"continuity error" for each printout interval. We would examine these
errors and check that they were less than 1 part in 10,000.
2. Where possible, we would check model output against a hand calculation.
For example, the first RCHRES test run involved a stagnant water body
2.5 ft. deep and 1 acre in extent. We checked the behavior of the HYDR
section of the module by ensuring that it gave the intended zero outflow
and that all state variables (e.g., depth, durface area) remained
constant, including the requirement that they not oscillate. The water
temperature calculation was checked by supplying constant meteorologic
data and checking that the temperature built up smoothly from the
initial value to an equilibrium value. The equilibrium temperature was
checked by manually evaluating all heat exchange components (long wave,
short wave, etc.) at that temperature and ensuring that the resultant
heat flux was zero.
The simulation of certain reactions was checked by first setting the
reaction rate to zero and ensuring that the constituent was conserved.
Then, we would assign a non-zero value and check that the transformation
22
-------
rate was close to that predicted by hand calculation.
These tests were very useful. They were easy to set up and permitted many
aspects of the model to be checked very quickly. Several of these early
test setups are now used, in slightly modified form, to demonstrate HSPF in
our workshop sessions.
5.3 TESTS ON DATA FROM THE OCCOQUAN BASIN
Introduction
The Northern Virginia Planning District Commission (NVPDC) kindly cooperated
in this work by supplying us with all needed data, including their
simulation inputs and outputs recorded on magnetic tape. The Occoquan basin
(Figure 1) has been subdivided for modeling purposes into 15 "subbasins" and
a similar number of stream and reservoir "reaches". Early in the testing
work we realized that, conceptually, all the subbasins and reaches were
identical. That is, they all involved simulation of the same sets of
constituents using the same methods. Thus, when simulating them, the same
set of code is executed for each one; only the numerical values are
different. The implication for the testing work is that any differences
between the HSPF and Occoquan Basin Computer Model (OBCM) code would
probably be equally apparent in their outputs for all subbasins or reaches.
There was, thus, not much to be gained by including the whole set of
subbasins and reaches in the tests. The output for each subbasin or reach
could be expected to tell much the same story. Therefore, with the
concurrence of the Project Officer, we decided to focus attention on Broad
Run (subbasins 4, 5, and 7). If we had included a greater area, the cost of
manipulating the data would have risen proportionately, but there would not
have been a significant increase in the payoff.
23
-------
0
•<
o
IB
C
K
c
H -i
tr.
3 c
C c
C
v.
3
Mra^*™" <*£
H <
Ol W
24
-------
Method
The testing sequence followed the logical pattern present in HSPF and
predecessor models:
1. Simulate the land segments. Compare the runoff and constituent washoff
calculated by NFS and HSPF. When the sources of any obvious differences
have been tracked down, modify the HSPF code and/or the input and rerun.
Repeat until the agreement is good. Store outputs from the
land-segments on disc, for input to the RCHRES system.
2. Repeat the process for the stream and reservoir system.
Simulation of Land Segments
The NVPDC had divided each sub-basin into five land use classes:
Forest/Idle Agriculture, cropping Agriculture, pasture Urban,
residential Urban, "employment"
Each land use was further subdivided into a pervious and impervious
fraction, as permitted by the NFS model. This subdivision presented us with
a problem in constructing an HSPF input which was strictly equivalent to
that for NPS. In HSPF, a land segment is regarded as an area which is
really homogeneous not only with respect to hydrological behavior, but also
with respect to land use, constituent potency factors, etc. In designing
the model it was reasoned that different land use will, in general, be
associated with different hydrological behavior and, thus, should be
represented by different land segments. Thus, in HSPF, each subbasin in the
Occoquan had to be represented by not one, but five, pervious land segments.
Furthermore, HSPF treats impervious areas as logically distinct from
pervious areas, and simulates them with a separate module (IMPLND). Thus,
25
-------
the impervious fraction of each land use area identified in NFS had to be
simulated in HSPF with its own impervious land segment.
The overall result was that a subbasin which could be simulated with one
land segment in the NFS model had to be represented by ten land segments in
HSPF, to obtain an exactly equivalent input. Inevitably, this made the HSPF
User's Control Input rather cumbersome and resulted in much lower execution
efficiency than would have been obtained had we segmented the subbasins in a
manner more appropriate to HSPF.
The testing proceeded as follows:
1. The runoff of water, and the washoff of each constituent, as computed by
NFS for each subbasin, had been written to disc.
2. The corresponding values for the HSPF simulation were found by combining
the washoff from each of the ten land segments, in proportion to the
area of each, and writing the result to disc.
3- The outputs were compared by plotting them together (using the PLTGEN
module) and making a visual comparison. A quantitative comparison could
also be made by comparing the printed outputs.
U. By examining the nature of discrepancies between the two outputs, we
could usually identify the cause. Most often it was a problem in the
HSPF input stream. For example, we initially used the same sediment
accumulation rates in HSPF as had been used in NFS. After noticing that
the HSPF model accumulated sediment more rapidly than did NFS, we
realized that NFS only performs accumulation on a "non-rain day",
whereas HSPF does it every day. One must therefore adjust downward the
accumulation rate supplied to HSPF to get an input exactly equivalent to
that for NFS. But not all differences in model output were attributable
26
-------
to this kind of problem. Some did uncover bugs in the HSPF code and, in
one instance, in the NFS code.
The process of tracking down problems was laborious but, in the end,
excellent agreement between the two sets of output was obtained. Figures 2
through U show typical results.
Figure 2 shows that the hydrologic outputs of HSPF and NFS are practically
identical. Figures 3 and t show the simulated concentration of P04 and
oranic N in the outflow from subbasin 4. For both constituents, the model
inputs specified a constant "background" value for the concentration of the
substance in groundwater and interflow outflow. Thus, the curves of
concentration versus time can only depart from the background value when
surface runoff is occurring; a relatively rare occurrence. The resulting
spikes can be above or below the background value, depending on whether the
simulated concentration in the surface runoff is greater than or less than
the background value (in general, this is a function of the intensity of
surface runoff).
The agreement between the results from the two models (Figures 3 and U) is
good. The only obvious discrepancy is a small difference in the background
concentrations. This is due to data roundoff. The values simulated by the
NFS model were stored in an HSP OSFILE on an IBM system. A copy was sent to
us. We translated the data so that they could be read into an HSPF Time
Series Store on our HP3000 computer. Some data roundoff occurred in the
process of making the transfer.
Simulation of the Stream Channel/Reservoir System
The setup used to represent the Broad Run stream channels and reservoir in
HSPF was similar to that used by NVPDC (Figure 1). That is, the principal
channels in subbasin 4 were represented by a single free flowing reach (40),
27
-------
01
O 01
a > o
t-l -U
01 3 *J
T-l O C 01
0) j .c
ty 01
4J (B
1
8
J^>
D
CO
O
H
O
H
3
en
CN
O
)—I
fe
28
-------
U-
>/"> 0-
Q- tfi
Z I
I
fO
r
m
r^
a
o
o
CJ
o
M
PC
O
ej
ft.
O
M
O
P-4
f=,
O
H
Z
o
o
Q
H
|
2
00
en
in
q
o
(I/8m) -
o
29
-------
vrt Q-
o.
z x
T~T
\n
(O
1-
CP
LL
-------
those in subbasin 5 by a reservoir (50) and those in subbasin 7 by two free
flowing reaches (65 and 70).
Designing an HSPF input sequence which represented the channel/reservoir
system in a manner exactly equivalent to the HSP-QUALITY model presented
problems because:
1. There are many parameters and initial values that must be supplied when
doing a water quality run, and the names and definitions of some have
changed between HSP-QUALITY and HSPF.
2. HSP-QUALITY represents every reach (including reservoirs) with a
trapezoidal cross section. Quantities such as benthal releases are
computed using the "bottom area" (length times bottom width). On the
other hand, HSPF makes no assumptions about the nature of the cross
section and computes benthal releases using an area equal to the surface
area. This makes it impossible to get identical results with the two
models. However, by adjustment of appropriate parameters, the model
outputs can usually be made very similar.
The method used to test the RCHRES module was basically similar to that used
to check the land segment simulations:
1. When staff at the NVPDC did the HSP-QUALITY runs, the model wrote to
disc the simulated flow rates and constituent concentrations for each
reach, on a continuous basis with an hourly time step. These data were
transferred to our HP3000 system and were, thus, available for
comparison with the corresponding HSPF outputs.
31
-------
2. The HSPF model was set up to also write its output for each RCHRES to
disc (in the Time Series Store).
3- The outputs were compared by plotting them together, and by checking the
printed output produced by both models.
4. As before, we could usually identify a problem by observing the nature
of the differences between pairs of plotted time series. Usually, it
was some value in the user's Control Input which needed adjustment; the
problems involved in setting up exactly equivalent inputs have already
been discussed. However, this testing work did uncover some bugs in the
code and one large discrepancy attributable to a difference in "model
convention" (discussed later).
Typical results of this work are shown in Figures 5 thorugh 12. Figure 5
shows that, again, excellent agreement between the hydrologic outputs from
the two models was obtained. The simulated water temperatures (Figure 6)
were also very similar. Figure 7 has been included to illustrate how the
plots were used in some cases to trace bugs in the code. We found that the
simulated DO levels agreed well, except that HSPF never permitted the
concentration to rise above 12.5 mg/1. An investigation quickly revealed
that the maximum allowable concentration was correctly set at the start of
the run, to 25% supersaturation, but it was not being updated as the run
progressed, in response to changes in water temperature. The bug was easily
removed.
The simulation of phytoplankton (Figure 8) was not as easy to reconcile.
During October 1973, HSP-QUALITY simulated practically zero growth in RCHRES
50, with the population in the reservoir declining steadily as a result of
sinking, respiration, and death of the algae. On the other hand, HSPF
simulated very substantial growth in the populaton, until the nutrient
supply was exhausted about the middle of the month (Figure 9). Note that
32
-------
500i—
4SO-
400
350
300-
250-
200
ISO
100
50
HSP-Q
HSPF
Note: Where there is •
no dashed line,
curves are coincident
(this applies to
all plots)
2 \ '2
1974
' fe '7 'a 3 »0
FIGURE 5 SIMULATED OUTFLOW FROM REACH 50 (OCCOQUAN)
33
-------
o-
O
U
u
o
*•—'
o
fcj
q
H
S
w
-------
s
2
c-
o
o
o
o
u
<
w
o
a
o
o
O
;s
o
u
o
w
H
<
a!
g
35
-------
o
o
u
o
I "•
a. cu
X X
I
cO
r-
cn
o
o
Q
W
H
in
co
o
M
fn
(•[/Sri) V TT^M
-------
CO
Is-
2
u
4)
I
6
I
0
u
o
5
o
•"-s :
<3 c
p o
1 I
•3T1
o
d
c
g
-------
o
a!
H
CO
W
o
M
O
OT
cn
co
O
at
u
38
-------
X
I
I
o-
o
o
CJ
o
o
m
U
<:
w
§
H "
H H
<: 3
CS O
H &
7-. U
«
O Z
3 O
O H
O W
O O
Is
5
Q
\fl
frt
O
en
O
ni
o
o
(-[/Sui) -
39
-------
?u.
Q. 0-
vn vr>
X X
CP
00
5
CJ
o
O ~
PH E-i
fc O
O Cd
^ a
o z
M O
H H
o o
2 H
-
r- UK
0"> PJ
— o
W G
H Cd
5 =
M O
to <
O
CD
O
O
(I/Sin) -
40
-------
nitrate was affected in the same way as POM, although the plot for nitrate
is not shown. After the middle of the month a nutrient limited growth
condition was reached; the polulation was still declining at the end of the
month.
The cause of the phytoplankton discrepancy was difficult to locate. After
exhaustive investigations the presence of a difference in the inputs was
ruled out, as was the possibiity of a bug in the code. Eventually, we
realized that it was due to a "small" difference in the way the two models
view the world. The formula used in both models to estimate the light
available for phytoplankton growth is:
»
PHYLIT = INLIT e - 2
where INLIT is the light available at the water surface
(Langleys/min)
EXTCO is the light extinction coefficient (per foot)
Depth is the water body depth, in feet
Thus, it is assumed that light is extinguished (absorbed) with depth
according to an exponential law. To get an estimate of the mean intensity
of light in the water body, PHYLIT is estimated using one-half the water
body depth. The difference between the two models is the value used for
"depth". HSP-QUALITY requires the user to represent all reaches and
reservoirs with a uniform trapezoidal cross section and "floodplain" of
constant slope (Figure 10). To calculate light extinction, it uses the
"full depth" of the water body (35 feet for RCHRES 50, when water is at
spillway level). On the other hand, HSPF uses the "mean depth" (cross
section area/topwidth); for RCHRES 50, this is only 23.5 feet when the water
is at spillway level. Note that the two depths can only be the same for
water bodies with vertical walls.
41
-------
When plugged into the above equation, these two numbers make a tremendous
difference. For example, at 10 a.m. on October 1, 1973:
HSP-Q: PHYLIT = 0.582 e ~°-2814 * 35/2
= 0.0040 Ly/min
HSPF: PHYLIT = 0.582 e -°-284 * 23-5/2
= 0.021 Ly/min
In this typical case, a mere difference in the way depth is defined leads to
a fivefold difference in light available for phytoplankton growth!
Because we consider the HSPF definition of depth as good as, if not better
than, that used in HSP-QUALITY, we do not regard this as a program error.
Nevertheless, to permit the best possible comparison of all other aspects of
HSPF and HSP-QUALITY output, we proceeded to devise a set of adjusted HSPF
input parameters which would give the same growth rate as HSP-QUALITY (this
input dataset was called RCHFAKE). To achieve this, we had to change the
base extinction coefficient and the Michaelis-Mentan light limited growth
parameter. With this done, the HSPF and HSP-QUALITY phytoplankton
simulations agreed exactly, confirming that there was no other factor
contributing to the problem.
With the above adjustments, great differences in simulation of other
constituents that are affected by phytoplankton (potential P, organic N,
NH3, DO, N03 and POU) were eliminated or reduced. Figure 11 shows the
simulation of ammonia in reach 50: the outputs from the two models agree
quite well. This agreement is typical of that for most constituents.
42
-------
There were still some residual problems, however. The worst case was that
for POU (Figure 12). The situation was carefully investigated. We found no
error in the HSPF parameter set or the code. Then we performed a P04 mass
balance calculation on the HSP-QUALITY and HSPF runs. We worked backwards:
from the outputs produced by each model, we deduced what the input of P04
should have been and then compared this with the actual input to reach 50,
as reported in the HSPF run (HSP-QUALITY does not report this information).
In the case of HSPF the results were consistent: in the case of HSPQ they
wre not. Thus, although we were not able to pinpoint the problem, we did
conclude that the HSPF POM simulation was consistent. The problem probably
is that the inflow of P04 to reach 50 was not exactly the same for the HSPQ
and HSPF runs. Data roundoff which incurred when time series were
transferred from an HSPQ OSFILE to an HSPF TSS (discussed earlier), could
have been the cause.
There was another feature of Figure 12 which concerned us. The difference
between HSPF and HSPQ output appears constant from November 1973 through May
1, 197^. But during May 1974 it increases and then again holds constant.
This feature was also present in the simulations of N03 and DO. We were not
able to find a definite reason for this but, again, concluded that it was
probably due to the two models not being supplied with identical input time
series. Note again that the continuity check for P04 indicated no problem
in the HSPF simulation.
Summary
As a result of this work, we concluded that the following parts of the
HSPF code had been adequately tested:
SECTION COMMENTS
PERLND MODULE
PWATER with NBLKS=1, DELT=15 minutes
SEDMNT
43
-------
PWTGAS
PQUAL
IMPLND MODULE
IWATER with DELT=15 min
SOLIDS
IWTGAS
IQUAL
RCHRES MODULE
HYDR
ADCALC
HTRCH
OXRX
NUTRX
PLANK only phytoplankton was simulated; no zooplankton
or benthic algae.
5.4 TESTS ON DATA FROM THE MICHIGAN STATE UNIVERSITY WATERSHED (P6)
Introduction
When this model testing program was devised, we realized that the data
obtained for the Occoquan Basin would not suffice to exercise all the
simulation algorithms in HSPF. In particular, no snow accumulation and melt
simulation was done on the Occoquan, nor were the detailed pesticide and
nutrient simulation capabilities of the ARM Model applied there. Thus, it
was decided also to use data from P6 watershed in East Lansing, Michigan.
P6 is one of two watersheds in a data gathering program carried on by
Michigan State University under EPA sponsorship (Figure 13)- It was one of
the watersheds used to test the ARM Model. The data collection program, the
watershed characteristics and the ARM Model test results have been described
44
-------
270.5
0 10 20 METERS
DRAINAGE PATTERN
CONTOUR LINES
IMETERS ABOVE M.S.L.
SAMPLING STATION
FIGURE 13 P6 Watershed, East Lansing, Michigan (0.8 ha)
45
-------
in two EPA publications (Donigian and Crawford, 1976 a, and Donigian et.
al., 1977).
The P6 watershed is small (0.8 ha) and agricultural. Thus, for simulation
using ARM or HSPF, none of it was considered impervious and no channel
system was modeled. To make an HSPF simulation which was equivalent to an
ARM run, the watershed was represented by a single, pervious land segment.
It follows that this test program only exercised code in the PERLND module;
in particular, those sections of PERLND which incorporate the features of
the ARM Model:
Section SNOW - simulates accumulation and removal of
a snowpack
Section PWATER - simulates the water budget in a pervious
land-segment
Section SEDMNT - simulates the detachment and washoff of
sediment
Section PSTEMP - simulates soil temperature
Section PEST - simulates pesticide behavior
Section NITR - simulates nitrogen behavior
Section PHOS - simulates phosphorus behavior
Section TRACER - simulates a tracer (conservative) substance
-------
Method
One useful feature of the HSPF-system is that the various sections of an
application module can be selectively activated. Thus, with the PERLND
module (Figure 14), you can start by running section SNOW only. When you
are satisfied with its behavior you can also turn on Section PWATER and
check it out. This permits "incremental" calibration or testing of the
module which is a useful feature, because you do not have to waste time
simulating a section until all those sections which affect it are checked
out. We used this technique; the various sections of PERLND were tested in
"left-to-right" sequence (Figure 14).
First, the meteorological input time series (precip., PET, Temp., etc.) for
P6 were converted to HSPF format and read into a TSS. Then, for each
section tested:
1. The ARM Model input parameters and initial conditions, as well as the
corresponding output, were obtained. In most cases, we were able to
make use of the printouts from runs made when ARM was being tested.
However, we sometimes found the (monthly) output summaries provided too
little information to track down the cause of an HSPF/ARM difference,
and we had to make special short ARM runs and print at a daily, or even
hourly, interval.
2. HSPF was run with a corresponding input stream. Monthly summaries, as
well as detailed information for selected events, were displayed.
47
-------
P5
HI
f
•- - 1"
^ o o
i f> -t-
pi
1M
ti c o
£ o c
•*-
« 5
O -2
3 c *
" £ v °
o o o —
.*-
U * *i
4f Q. 7;
9-«
£ "c —
Jig 5
3 ?•! *
w t
" o 2- -a
i-sl
CK
S!
S
411=
|
1^2 J
I JiJSl
ili
r-l
T
33
n
o
s
2
O
M
H
O
O
fcj
I
a
E-
O
as
H
u
g
H
en
O
l—I
fa
48
-------
3. The results were compared and the causes of observed differences were
found. This step took more time than it did with the Occoquan data
because we could not produce the HSPF vs. ARM plots by machine. The ARM
results were on printouts, not on disc, so they had to be manually
plotted. A master copy of each plot was prepared, with the ARM output
on it, and the output from each succeeding HSPF run was plotted on a
copy of this master.
4. Changes were made to the HSPF input or code and then the process was
repeated.
Simulation of Snow Accumulation and Melt (Section SNOW)
Figure 15 shows the snowpack simulations produced by ARM and HSPF for
Nov/Dec 197^. In general, the agreement is good, but there are significant
differences. These were investigated. When precipitation occurred on
November 5, the ARM model interpolated (from daily max/min values) an air
temperature slightly below that required to form snow (TSNOW); hence the
simulation "produced" snow, which melted by November 9. However, the
interpolation algorithm used in HSPF gave a slightly higher temperature and,
thus, the pecipitation was simulated as rain, not snow. In such a marginal
situation, the true air temperature was probably significantly different
from the values used by both models, so had about the same probability of
being right (or wrong).
Most of the other discrepancies are attributable to the fact that CLDF (a
cloud cover factor) is updated irregularly in the ARM model, instead of each
time step, as in HSPF. This affects the simulated radiation energy balance
because ARM can simulate a high rate of longwave energy loss, corresponding
to clear sky conditions, during which it also simulates snowfall, a
coincidence which appears physically impossible. This problem accounts for
the differences in model behavior on November 29 and December 15, 23, and
49
-------
J^
f
"-^^•y
J(
\
~?
^-—,
li
1 . | . . , . , . . -r, f ,-,-,-,_,.,.
S 10 15 2O
December
1-8
u.
0.
u
Si
£
ro
,»
ci
O
o
50
-------
30, which are cumulative in effect. We believe that the HSPF code more
closely represents the natural process.
Simulation of Water Budget and Sediment Yield (Sections PWATER and SEDMNT)
Sections PWATER and SEDMNT had been checked out when performing tests on the
Occoquan basin data. However, there were two substantial differences
between those tests and the application to watershed P6:
1. On the Occoquan, the time step was 15 mins.; on P6 it was 5 mins.
2. The ARM Model subdivides a land-segment into 5 "areal source-zones"
(Donigian and Crawford, 1976 a); the HSP and NPS models do not use this
feature—they use only one areal source-zone. In HSPF, the user can set
the number of source-zones, called "blocks", to any number from 1
through 5. The value selected does affect the hydrologic response to
some extent. Thus, when using HSPF to replicate the NPS model
simulation of the Occoquan, we set NBLKS=1. When reproducing the ARM
Model simulation of P6, we set it to 5-
The tests on the Occoquan and P6 data, therefore, tested different aspects
of model sections PWATER and SEDMNT.
As with the testing described earlier, most of the work in reconciling
differences betwen ARM and HSPF output did not result in updates to the HSPF
code, but in changes to the HSPF input stream to make it exactly equivalent
to the ARM input. As before, this work was not easy because some of the
differences between HSPF and ARM inputs are quite subtle. For example, ARM
allows the user to specify a set of 12 monthly values for the fraction of
ground which is covered (COVPMO), but it only requires a single value for
the interception storage capacity (EXPM). This is actually the maximum
storage capacity, corresponding to maximum cover; the program automatically
51
-------
adjusts the interception storage capacity continuously by prorating it
according to the amount of cover. It is easy for the user to forget that
this is happening. In HSPF, on the other hand, the user must explicitly
specify whether cover and/or interception storage capacity are to vary
through the year. If either quantity does vary, he must supply 12 monthly
values for it. There is no automatic connection between the seasonal
variations in ground cover and interception storage capacity. Our own
misunderstanding of this difference between the models costs several days
effort.
The precipitation and E-T simulated by the two models are shown in Figure
16. Although the meteorological input time series were identical, the
precipitation values for November and December differ because the two models
did not always agree on the assignment of precipitation as snow or rain.
When it is treated as snow the "snow catch factor" (1.4) is applied to
recorded precipitation to estimate actual snowfall. Hence the small
differences in those months.
The E-T simulated by both models agrees closely, indicating that the
hydrologic response of the two is very similar. This is confirmed in Figure
17, which indicates that the monthly values of simulated runoff plus
groundwater recharge are close, with the exception of November. Figure 18
shows the components of runoff; surface runoff and interflow. Again,
agreement is close except in the months of November and December. The
anomaly in these winter months was investigated and found to be due to a
convention implemented in the HSPF code, whereby snowmelt was accumulated
until it reached a value of 0.01 inches, and was then suddenly released onto
the land surface. ARM released the melt water gradually, as melt took place.
This seemingly small difference between the models was responsible for the
very different simulated outflows when snowmelt occurred; HSPF produced more
runoff because it released the melt-water in sudden "bursts" which did not
infiltrate and too much ran off. The problem was corrected by modifying the
52
-------
2
I
6
d
fa
Pu
ts
D
VD
CU
f- i
Oil W
8
Q
2
z
o
I—I
H
H
M
P-.
(-(
O
O
T—i
W
O
H-l
fa
(V
(UTBJ + wous) '
53
-------
Q
Z
o
2^- li,
C/3
o d
z
o
P6 WATERSHED
o
<*- W
"^ i I
§
s
M
C
w
en
O
z
-------
*
Q
O
(ssqour)
g
W
I
fa
E-i
g
Pi
PJ
H
2:
. < <9 f
o o O c
(saqour) jjounj
3
>n
§
W
fa
ai
a
w
3
W
O
55
-------
HSPF code to release melted snow more gradually, which eliminated the large
November and December differences in Figures 17 and 18. The graph of
monthly sediment yield (Figure 17), shows generally close agreement between
the two models. The discrepancy in the values for November was fixed by the
measure described above.
The simulated runoff and sediment yield for two storm events, those of
August 13 and 27, 197**, are shown in Figures 19 and 20. Agreement is very
good, except for small discrepancies in the first peak of each event. On
August 13, HSPF gave a lower value, on August 27 a higher value. The
difference is probably due to the two models having slightly different
moisture in the upper zone (OZS) at the start of each event, but we don't
have sufficient printout to prove this.
Simulation of Pesticide Behavior (Section PEST)
The processes which affect agricultural chemicals, as simulated in the ARM
and HSPF models, fall into two categories: advectlon and reaction.
Advection is the transport of chemicals over the soil surface or through the
soil. In our models the land-segment is viewed as having four "layers":
surface, upper, lower, and groundwater (Donigian and Crawford, 1976 a;
Johanson et. al., 1979). Soluble chemicals are transported by water between
these layers, which have storages associated with them. Also, the soluble
chemical moves from one or more of these storages to the stream channel
(with surface runoff, interflow or groundwater outflow) or to deep
groundwater. Insoluble chemicals can only be washed to the stream system
from the surface layer of the soil. In HSPF, advection of soluble chemicals
is governed by section MSTLAY of the PERLND module. It uses the results
produced in the water budget calculations (Section PWATER) to estimate the
fraction of stored soluble chemical that will leave each storage along each
flow path, in each time step.
56
-------
u.
a
a:
<.
N
CO
8 «-
^ ^ s
2 o en-
:*7 «- —••
ssof rjuanrrpag
§
d
q
ti
o
d
I
8
o
o
O
O
O
O
H
CO
O
(••H
CO
CT
O
Q
H fcl
O H
W
-------
o
o
8
N O
ssoj
B
s
o
- GO
h- «5
-------
"Reaction" refers to the transformations that a chemical undergoes as a
result of physico - chemical processes. In ARM and HSPF two processes are
considered for pesticides:
1. Adsorption/desorption. This is the movement of ions between the
dissolved state and the "adsorption sites" provided by fine sediment
particles. ARM and HSPF use a "Freundlich isotherm" (Donigian and
Crawford, 1976 a) to simulate the process. Either a single-valued or
non-single-valued isotherm may be used. In these tests the latter
method was used.
2. Degradation. This term includes volatilization and degradation due to
microbial action. It is handled with a first-order equation, using a
degradation constant input by the user.
In nature, advection and reaction take place simultaneously and continuously
in time and space. In most models, including ARM and HSPF, the processes
must be separated and discretized.
In ARM, the sequence of operations for pesticides is:
1. React in the surface layer
2. Advect from the surface layer
3- React in the upper layer
4. Advect from the upper layer
etc.
In each time step, the model first performs reactions, assuming the solution
and adsorbed phases of the pesticide reach equilibrium instantaneously.
Then it assumes no further reacting takes place, while it simulates
advection for the time step.
59
-------
HSPF also first reacts pesticides and then advects them but performs
reactions in all layers before starting with the advection.
For nutrients, the models sequence these operations differently. This will
be discussed later. At this stage it suffices to note that the sequencing,
although it is only a detail of model construction and not a fundamental
consideration, can have a dramatic effect on the results produced. This
will be demonstrated later.
The results obtained for pesticide simulation are shown in Figures 21
through 2U. The tests covered two pesticides, atrazine and paraquat.
Atrazine exists in significant quantities in both the adsorbed and dissolved
states but paraquat is so highly adsorbed that it exists and moves almost
entirely on sediment.
Figure 21 shows that the simulated storages of atrazine in the surface and
upper layers agree quite well, for the two models. Atrazine was applied to
the watershed on May 21 (3.52 Ib/acre) and November 8 (2.68 Ib/ac). After
each application, degradation destroyed 5% per day, so that the storage
decreased rapidly. The simulated removal of atrazine (Figure 22) also shows
this effect; removal declines rapidly after the time of application.
The apparent difference in atrazine removed on sediment (Figure 22) is not
real, because the output from the ARM run was only reported to 3 decimal
places. The higher total removal simulated by HSPF for May 197*1 is probably
due to the slightly different way in which the various reaction and
advection operations are sequenced and represented in the two models. The
higher removal reported by HPSF is consistent with the lower value that it
reports for the storage of atrazine at the end of May 1971* (Figure 21).
The removals of paraquat simulated by the two models agree quite closely
(Figures 23 and 24). This is quite understandable. Paraquat is so highly
60
-------
o o
(3B/
H en
t/) ctj
W
a >•
w
M CU
C/} t~^
o
i—t
b.
61
-------
i
•S
T
i
d
2
O
T
8
8
o
o
0
cr>
p
w
W
H
I
w
I
O
W
Pi
2
^u
M
CO
UO
62
-------
.02.5-
.020-
2
o
H
.015-
.oio4
.005-1
O ARM
E3 HSPF
VA'J'J'ASO NO
1974
FIGURE 23 SIMULATED REMOVAL OF PARAQUAT - P6 WATERSHED
63
-------
1.0
0.9
0.8
ao
a)
s
•H
T3
o
§
ad
0.5
(X4
0.1
Ofl
7:00
8:00
Time
FIGURE 24 SIMULATED REMOVAL OF PARAQUAT ON
SEDIMENT - FT WATERSHED
64
-------
adsorbed, that almost all removal occurs on sediment. Thus, the two
simulations must agree about as closely as the corresponding simulation of
sediment removal.
When this testing work commenced, HSPF performed all the advection in a
land-segment before the reactions were simulated. We found it impossible to
closely reproduce the ARM Model results with this arrangement; for example,
the atrazine storages at the end of May 1974 were (Ib/ac):
ARM HSPF
SURFACE LAYER
UPPER LAYER
0.55
1-35
0.8
1.0
Obviously HSPF simulated much less percolation from the surface to the upper
layer. We concluded that this could be entirely due to the different
sequencing of advection and reaction in the two models. So the HSPF code
was altered, to make its sequence coincide as closely as possible with ARM
and, as expected, the differences practically disappeared. This result
illustrates the point made earlier, that choice of conventions (e.g., advect
then react, vs. react then advect) can have a substantial effect on the
results produced by a model. The effect could be even larger than that
produced by a change in algorithm, such as a switch from the single-valued
to non-single-valued Freundlich isotherm.
Simulation of Nutrients (Sections NITR and PHOS)
The introductory comments, made in discussing the simulation of pesticide,
are also applicable to nutrients. The principal differences between the
65
-------
simulation of pesticides and nutrients are:
1. A greater number of chemical species are simulated in the case of
nutrients. Figure 25 shows the various forms of nitrogen and phosphorus
represented in the ARM and HSPF models, and the associated reactions:
nitrite and nitrate are combined; N02+N03 is increased by nitrification
of dissolved NH4, and decreased by denitrification, plant uptake and,
possibly immobilization to the organic form. Ammonia can undergo
adsorption and desorption, and the dissolved form can interact with
organic N through the ammonification and immobilization reaction paths.
Phosphate adsorption and desorption is simulated. The dissolved
phosphate can also be affected by plant uptake and interaction with the
organic form (mobilization and immobilization).
These reactions take place in all four soil layers, and are simulated
using first-order temperature corrected reaction rates. Any reaction
path can effectively be eliminated by assigning a zero reaction rate to
it.
2. As a consequence of the above, nutrient simulation involves advection of
several substances. The dissolved materials, which must be advected
over and through the soil, are:
N02+N03
NH4-Solution
POM-Soiution
In addition, washoff of the following particulate forms (associated with
sediment) occurs from the surface layer:
NHM-Adsorbed
Organic N
66
-------
N2
PLNT-N
KD
KPL
NO2+NO3
NH4-A
KSA
K1
NH4 -S
KAM
KIM
ORG-N
KKIM
A. Nitrogen transformations in ARM model
PINT -P
PO4-A
KPL
PO4- S
KIM
i ' —
KM
ORG-P
B. Phosphorus transformations in ARM model
FIGURE 25 Nutrient transformations in the ARM model
67
-------
POU-Adsorbed
Organic P
3. In both ARM and HSPF, the nutrient advection/reaction sequencing is
different to that for pesticides. For nutrients, advection is performed
every time step, starting at the surface and proceeding down to the
groundwater layer. Reactions in each layer are calculated after
advection is complete. In ARM there is a further complication;
transformations due to reaction are performed intermittently. For
example, the user can specify that this be done every 10 time steps.
HSPF simulates reaction transformations every time step, but the user
can specity how often the reaction rate should be recomputed.
The difference in the way advection and reaction flux calculations are
sequenced does have significant effect on the nutrient simulation
results; this is discussed later.
Although the nitrogen, phosphorus and tracer sections of module PERLND can
be simulated independently, the results will all be discussed together.
Figures 26 through 33 are a representative sample of the results obtained
from the nutrient test runs.
Figure 26 shows that the quantity of sediment-associated NH4 removal,
simulated by the two models, agrees quite closely. The fact that this was
also true for other forms of sediment-associated nutrients is confirmed by
Figures 28, 29, 31, 32, and 33, which show the quantities removed in the
storms of August 13, and 27, 1971*. The reason for the good agreement is
simple: both models gave very similar results for the simulation of
sediment (accumulation, detachment and removal). Also, they agreed closely
on the total amount of sediment-associated nutrients (organic and adsorbed)
present in the surface layer. Since these are the only factors that govern
the removal of sediment-associated nutrients, agreement between results from
68
-------
«p
O
CD
-i
d
(DB/q~[) uo^^n^os up paAoraaa
2 co
< S3
CP
D
w
H
vO
z
w
o
s
UJ
o
s
•o N —
<=! O o
O
o
o
s
C3
W
H
CM
W
^uaarrpss uo
69
-------
o
(S
O
o
-------
(-
•n
CP
2
o
H
a
w
o
§
H O
M W
to ix!
o w
<«
O
a
O
H
O
W
gs
oo
CN
(UTUI 5/qi) auaiafpas uo
71
-------
_Q
X O
o
f-
8
8
$
CO C< -T ° *>
0. 0 ° 0
(UTUI £/q~[) uotrjnjos UT -[BAoma-g
'
.§
»- -
*)
f
•**->
* i
w
€
P
?
5?
CO
-f-
«1
3
CT
3
<
g
C/3
BJ
£
•s
w
Q
W
O5
CS
ta
H
CN
Cd
B!
3
O
72
-------
.04-
•S .os
o
o
tn
.01
\_
Remova
>
S
• \
/
W.U 1 1 1 I 1 I
5:40 t'.OO T.OO 7*O
FIGURE 30
13,
SI1-IULATED REMOVAL OF NITRATE, FOR STORM OF
AUGUST 13, 1974 - P6 WATERSHED
73
-------
S
8
o
in
o
o
8
q ">
6
o
H
°s£££$£So3 I
3 0 Q 9 § Q Q Q o • 0 C
•* ^r^
i "> "T en
3 3 -
-C -+-
i
f- 9
-------
o
o
• o
O
q
(ITfUl
°. o.
UT
<3
6
N
•f
6
O
(UTU1
o*
o
8
K
8
d
uo xBA°ui3'a
o
en
c
p <
ft
a
H
< E-
75
-------
g
o
H
CO
r «o
q o
(mm g/q-[)
rt ' ~ ' <
p • • i u
> irt fD Oi O
o f '-- a 3
:}U3tiiTp3S uo ^od 1° XBAoraa^
^1— z on
£ {-^ < C*
-£ +- A IX "^
41 •> 23
£ ^
r IT ° o S
U
I-
O r-
8
co <
9
b
q p
(ujra g/qi) uoT3n-[os trc
o
O
jo
76
-------
the two models is assured.
In the case of dissolved constituents the story is, unfortunately, not as
happy or as simple. Figures 26 through 33 show that there were often quite
significant differences in output from the two models. Perhaps the most
striking examples are the simulated removal of NH4 in solution, for the
storms of August 13 and 27, 1971* (Figures 29 and 33).
In both cases ARM predicted initially high rates of removal, which rapidly
tapered off. On the other hand, HSPF produced double-peaked curves. We
attribute this difference to the fact that ARM performs reactions
intermittently, in this case, every 12 time steps (i.e., once/hour). At the
start of the storms (6 a.m. in both cases) there was an ample supply of NH4
in solution because an hour's worth of ammonification of organic N and
desorption of adsorbed N had just been computed and the resulting fluxes
added to the solution NHU (Figure 25). Then, advection steadily removed the
dissolved chemical during the storm and, because no replenishment due to
reactions was computed until an hour later, the second peak flow rate
(Figures 19 and 27) did not result in an associated peak in removal of
dissolved NH4 (Figures 29 and 33). On the other hand, HSPF simulated both
advection and reaction in each time step (although the reaction rates were
altered only once per hour) so the exhaustion problem did not occur. Note
that, for both storms, the general shape of the curve computed by HSPF is
closer to that of the observed data than that produced by ARM. (By suitable
adjustment of parameters, the HSPF outputs could be made to agree even
better with the observations). Thus, we conclude that the continuous
simulation of reaction fluxes (in HSPF) does result in a significant
improvement over results obtained with ARM. Note that an ARM user can
specify that reactions be computed more often, so this problem can be
overcome.
77
-------
We have already described how both models first advect material, between and
out of the soil layers, and then simulate reactions within each layer (with
the proviso that ARM usually handles reactions intermittently). Now,
consider the behavior of the surface layer, which is usually regarded as
very thin (in this case 0.125 in.). Because it is so thin, almost all the
solutes present in it at the start of a time step will be advected down to
the upper layer within that time step, in any significant storm. Usually,
relatively small quantities are removed by surface runoff although, in HSPF,
the ratio of percolation to surface runoff removal can be adjusted using the
"surface layer percolation factor." If this adjustment is not made, most of
the removal to the stream will be through the interflow path, which is the
outlet from the upper layer. This can be seen in Figures 28 through 31 in
which the graphs showing removal of nutrients in solution, as simulated by
HSPF for the storm of August 13, 19T1*, reflect the shape of the interflow,
rather than the surface runoff, curve (Figure 31*) • However, the observed
data, also plotted in these figures, are much closer to the shape of the
surface runoff hydrograph than the interflow hydrograph (Figure 34)• This
problem affects both the ARM and HSPF models. It is recommended that one or
both of the following measures be taken to overcome it:
78
-------
en
o
cd
o
tn
13
0)
4-J
CB
4» .03
00
00
CO
X
0)
3
o
07-
.01
0.0-1
fe'.OO
T.OO
Interflow
Total
r.oo
FIGURE 34 RUNOFF SIMULATED BY HSPF FOR STORK 05
AUGUST 13, 1974 - P6 WATERSHED
79
-------
1 . Make the surface layer thicker, of the order of 1 to 4 inches. This
should be coupled with a change to the code, to make the surface layer
moisture storage a function not only of overland flow storage (as at
present) but also of the upper zone storage. Indeed, it might be
advisable to combine the present surface and upper layers into a single
layer having two outflow paths — surface runoff and interflow. When this
change is made, it should be coupled with some other changes to the
MSTLAY Section of HSPF, designed to relax the present requirement that
simulation of agricultural chemicals be limited to time steps of 5 or 15
minutes.
2. Use the surface layer percolation factor to promote more washoff of
dissolved chemicals with surface runoff, rather than have them percolate
vertically.
One further point. It was noticed that both the ARM and HSPF models
simulated zero plant uptake of N and P from the surface layer. This is also
a consequence of the thin surface layer. The only source of plant N (in
ARM) is N03 (Figure 25). And, the only way N03 appears in the surface layer
is:
1 . by direct application
2. by oxidation of dissolved
Since, during a storm, most of the dissolved NH4 and N03 is flushed down to
the upper layer in a single time step, the quantities which reside in the
surface layer are typically quite small. This is especially true for N03,
because it is derived from oxidation of NH4 which is itself subject to heavy
flushing. Only a small quantity of NHU is usually available for oxidation
and, when it is converted to N03, it is again subject to heavy flushing in
the next time step. The typical concentration of N03 in the surface layer
80
-------
is, thus, even less than that for dissolved
These factors account for the negligible plant uptake of N03 and POU from
the surface layer. The ARM and HSPF models cannot maintain significant
quantities of N03 and dissolved PO1) in the surface layer, and there cannot
be plant uptake if there are no available nutrients.
Again, it seems that the cure to the problem lies in thickening the surface
layer or in combining it with the upper layer.
Conclusion
From the tests conducted using data from the P6 watrshed, we concluded that
the following sections of the HSPF PERLND module do correctly implement the
algorithms, as described in the User's Manual:
SNOW
PWATER, with NBLKS=5 and DELT=5 minutes
SEDMNT
PSTEMP
MSTLAY
PEST
NITR
PHOS
TRACER
The testing program did, however, raise questions about the adequacy of the
way the near-surface region of the soil is simulated, in both the HSPF and
ARM models.
81
-------
6.0 REFERENCES
Crawford, N.H., and A.S. Donigian, Jr. 1973. Pesticide Transport and Runoff
Model for Agricultural Lands. Office of Research and Development, U.S. EPA,
Washington D.C. EPA 660/2-7^-013. 211 p.
Crawford, N.H., and R.K. Linsley. 1966. Digital Simulation in Hydrology:
Stanford Watershed Model IV. Department of Civil Engineering, Stanford
University. Stanford, California. Technical Report No. 39- 210 p.
Donigian, A.S., Jr., D.C. Beyerlein, H.H. Davis, Jr., and N.H. Crawford.
1977. Agricultural Runoff Management (ARM) Model Version III: Refinement
and Testing. Environmental Research Laboratory, Athens, Georgia.
EPA-600-13-77-098. 293 P-
Donigian. A.S., Jr., and N.H. Crawford. 1976 a. Modeling Pesticides and
Nutrients on Agricultural Lands. Environmental Research Laboratory, Athens,
Georgia. EPA 600/2-7-76-043- 317 p.
Donigian, A.S., Jr., and N.H. Crawford. 1976 b. Modeling Nonpoint Pollution
from the Land Surface. Environmental Research Laboratory, Athens, Georgia.
EPA 600/3-76-083. 280 p.
Hydrocomp Inc. 1969. Hydrocomp Simulation Programming: Operations Manual.
Palo Alto, California.
Hydrocomp Inc. 1977. Hydrocomp Water-Quality Operations Manual. Palo Alto,
California.
Hydrocomp Inc. 1978. The Occoquan Basin Computer Model. Calibration,
Verification and User's Manual. Northern Virginia Planning District
Comission. Falls Church, Virginia.
82
-------
Johanson R.C., J.C. Imhoff, and H.H. Davis, Jr., 1979- User's Manual for
the Hydrological Simulation Program-FORTRAN (HSPF). Environmental Research
Laboratory, Athens, Georgia. In press. 650 p.
83
------- |