PROGRAMS AND PLANS--Office of Surface Water Policy on Shift Adjustment Application and Computation of Records Using ADAPS
In Reply Refer To January 11, 1988
WGS-Mail Stop 415
OFFICE OF SURFACE WATER TECHNICAL MEMORANDUM NO. 88.03
Subject: PROGRAMS AND PLANS--Office of Surface Water Policy on Shift
Adjustment Application and Computation of
Records Using ADAPS
The latest report of the ADAPS Technical Review Committee was distributed by
electronic mail through the Regional Surface Water Specialists on about
November 10, 1987. The purpose of this memorandum is to distribute a paper
copy of the report and to make certain recommendations concerning the policy
of the Office of Surface Water (OSW) for use in computing records.
The ADAPS review committee spent considerable time discussing problems in
specifying and applying time- and stage-shift adjustments using ADAPS. The
committee's report includes lengthy and detailed explanations of interactions,
interdependencies, and hierarchies of the application of ADAPS time-shift and
ADAPS stage-shift specifications. The committee emphasizes that thorough
understanding and constant attention to these concepts are essential for
correct intermingling of ADAPS time shifts and ADAPS stage shifts.
The review committee also points out, however, that the ADAPS shift-by-stage
procedure is in fact general enough to accommodate shifting by time alone. As
explained in the ADAPS Users Guide, paragraph 3.8.2, the shift-by-stage proce-
dure in fact distributes shifts on the basis of both stage and time. Thus, as
explained in the committee report, shifts by time can be applied by using a
constant stage-shift-variation diagram at each end of the time interval for
which time shifts are desired. That is, at the beginning of the time
interval, insert a stage-shift-variation diagram with shift values that are
constant for all stages and equal to the shift desired for that time.
Likewise, at the end of the time interval, insert a stage-shift-variation
diagram with shifts that are constant for all stages and equal to the shift
desired at the end of the time interval. These two variation diagrams will
then be prorated by time and produce results just as a traditional time shift
would. For example, the following entries under the ADAPS stage-shift menu
option would cause a straight-line time proration of shifts from -0.10 foot at
the start of October 1 to +0.30 foot at the end of October 15, independent of
stage:
Gage Gage Gage
Date Time height Shift height Shift height Shift
10/01 0001 .01 -.10 .02 -.10 .03 -0.10
10/15 2400 .01 .30 .02 .30 .03 0.30
This would be equivalent to the corresponding time-only shift, but simpler and
more trouble free to apply, inasmuch as NULL periods and shift hierarchies
need not be considered.
OFFICE OF SURFACE WATER TECHNICAL MEMORANDUM NO. 88.03 2
The committee feels strongly that this method of time shifting should be used
in preference to the method currently provided in ADAPS because it can be
worked in easily with stage shifting, and without the need to be concerned
with NULL periods. It is recognized that this procedure requires a few more
keystrokes than are needed to define a single time-shift record. This
disadvantage is more than offset, however, by savings of keystrokes and
computer dialog needed to ensure proper coordination of time shifts and stage
shifts kept in separate files and by savings of time in checking, reviewing,
and correcting errors in shift applications.
It is therefore the policy of the OSW that all shift adjustments in ADAPS be
specified by means of the shift-by-stage procedure described above. The
shift-by-time menu options of ADAPS (PR-6, HT-2, etc.) are not to be used to
specify shift adjustments. We have requested that in future versions of ADAPS
the concept of a NULL period be eliminated and that both time shifts and stage
shifts be implemented by means of uniform and consistent menu options and
shift-file records. The revised program will require only one shift value
when time shifts are specified.
With regard to other problems identified by the review team, the recommended
interim actions are to be observed until the problem is solved by a future
release of the ADAPS code. A list of solved problems will be provided with
future releases of the code.
The committee has observed that an understanding of how ADAPS works is
absolutely essential for its successful use. ADAPS is different from ADR and
WATSTORE. Training is a must. If training is desired, please contact your
Regional Surface Water Specialist.
Finally, we have been informed that all Districts must convert to this version
of ADAPS (version 85.4, August 1987) as soon as possible. A direct conversion
from ADR or DISTDAHS to the next version of ADAPS (presently scheduled for
release in February or March 1988) will not be possible because of changes in
the ADAPS unit-values file structure. The file-conversion software for the
new ADAPS release will require that the data already be in ADAPS 85.4 format.
The work of all of the members of the ADAPS review committee is appreciated.
Verne R. Schneider
Chief, Office of Surface Water
Attachment
WRD DISTRIBUTION: PO (without attachment), SL
NOTES FROM THE ADAPS TECHNICAL REVIEW COMMITTEE MEETING OF
OCTOBER 21-23, 1987, DORAVILLE, GEORGIA
A meeting of the ADAPS Technical Review Committee was held on October 21-23,
1987, at the Georgia District Office, Doraville, Georgia. The following
members of the committee were present:
Neil Stuthmann, Office of Scientific Information Management
Bill Kirby, Office of Surface Water
Bob Faye, Office of Ground Water
Jim Schornick, Office of Quality Water
Vernon Sauer, Southeastern Region, Chairman
Pat Simmons, New York
Tim Hale, Georgia
Larry Hubbard, Oregon
Bernie Massey, Texas
The purpose of the meeting was to review the latest version of ADAPS, and
especially address the reported problems being encountered by the field. In
addition, there were several carry-over items from the Austin meeting which
were discussed. Recommendations and proposed action regarding many of the
problems and further work needed are described in the following notes.
Neil Stuthmann reviewed the current status of converting to ADAPS as reported
to him as of the last two months. Following is a summary of his report:
16 sites have converted and are computing records with ADAPS
These sites have discontinued use of DISDAHS and the ADR
system.
10 sites have converted and are computing records with ADAPS, but are
also running DISDAHS and the ADR system simultaneously.
2 sites have converted, but present operation is not sure.
11 sites are in the process of converting.
3 sites are testing the conversion results.
6 sites have not responded.
A fairly large list of problems have been reported from the use of ADAPS.
These are documented in various places including the ADAPS continuum, a list
provided by Neil Stuthmann, a list provided by Tim Stamey as a result of two
training sessions held in Tampa Florida, memorandum from the New Jersey
District regarding some serious conversion problems, and a memorandum from Ron
Shields of the Montana District.
The problems ranged from very minor, inconvenience bugs, to some very serious
problems that need immediate attention. The committee considered all of the
problems, and made recommendations as appropriate. These are listed below in
the order which they came up in the meeting.
1. PROBLEM: Application of shifts are sometimes different in ADAPS from the
way they were applied in the ADR system. This especially causes problems when
data that were brought into ADAPS from the ADR system are recomputed from
stored values of input parameters, shifts, datum corrections, and ratings.
RECOMMENDATION: The committee spent considerable time discussing this
problem. It was the unanimous opinion of the committee members that there is
nothing inherently wrong with ADAPS shifting routines. The concepts of
shifting are identical in the ADR system and in ADAPS. The specifications for
applying these concepts are, however, somewhat different in the two systems,
and consequently differences will sometimes occur when a direct conversion is
made without adjusting the ADR system shifts.
The following paragraphs will briefly describe the shifting procedures used in
ADAPS, with particular emphasis on the differences between ADAPS and the ADR
system. More complete descriptions of the ADAPS procedures are given in the
latest "ADAPS USER'S MANUAL", dated August 1987. In particular, the user
should refer primarily to clause 3.8 of the Users Manual. Additional
information regarding input and output of the shifts can be found in clauses
7.6, 7.7, 14.2, 14.3, and 14.5.
A few definitions are especially important for the user to understand before
using the shift routines of ADAPS. These are: (1) NULL period, (2) NO SHIFT,
(3) ZERO SHIFT, (4) TIME SHIFT, and (5) STAGE SHIFT.
(1) NULL PERIOD.-As defined in ADAPS, a NULL period is the time period between
two "zero" shift values in the shift value file. It is very important to
understand this concept, because there are times when a NULL period must
be created so that other aspects of the shift routines will work
properly. The aspects of shifting that depend on NULL periods will be
explained further in later parts of these notes.
(2) NO SHIFT.-A "NO SHIFT" period is essentially the same as a NULL period,
provided of course, that no shift values have been defined for the NULL
period. In other words, if no shift values are given in the shift value
file during a defined NULL period, the primary computations will use the
rating curve directly, and there will be nothing shown on the primary
output under the column headed "shifts".
(3) ZERO SHIFT.-A zero shift is a defined shift value of "zero" and is treated
in ADAPS just as any other positive or negative shift value would be. In
ADAPS it is very important to understand the distinction between a "NO
SHIFT" and a "ZERO SHIFT". A zero shift will be treated as a shift even
though the final results when applied to the rating curve will be the
same as it would for a "NO SHIFT" or "NULL" period. For one thing, the
interpolation routine will apply to zero shifts. Also, a zero will be
printed on the primary output for times when zero shifts apply, as
opposed to nothing being shown for "no shift" periods.
(4) TIME SHIFT.-A time shift in the traditional sense is the method of
applying shifts by linear interpolation between two shift values during a
specified period of time. No consideration is given to stage during
traditional time shifting.
(5) STAGE SHIFT.-Stage shifts are applied according to a defined relation
between shifts and stage, commonly referred to as a stage-shift-variation
diagram (also known as V-diagrams). The stage-shift-variation diagrams
can be varied by linear interpolation over a specified period of time.
The basic concepts of time shifts and stage shifts are identical between ADAPS
and the ADR system. The differences between the two systems, and the reasons
why different results sometime occurs, relate to changes in the file
structures of the two systems, and to different rules of application in the
two systems. In ADAPS, the traditional time shifts are in a separate, and
independent, file from the stage shifts. They are therefore applied
independently of one another, however a hierarchy has been established that
says "if both a time shift and a stage shift have been defined for the same
time period, the stage shift will take precedence and the time shift will not
be used". Also, both of the files have been established as continuous files,
and as a result, once a shift value has been entered in the file it will be
continued in use until it is either changed to another value, or a null period
is defined.
Traditional time shifts can only be applied during NULL stage-shift periods.
If stage shifts have never been used at a station, then the entire period is
considered NULL and time shifts can be applied at any time without fear that
they will be ignored. However, once a stage shift has been entered, it will
take precedence because of the hierarchy rule, and from that time forward NULL
periods must be specifically defined for any time period where time shifts are
desired, or where "no shifts" are desired. These rules apply to adjacent
water years as well, because the shifting will continue across water year
boundaries.
An alternate way of applying time shifts is possible without the need for null
periods. This can be done by using a constant stage-shift-variation diagram
at each end of the time interval for which time shifts are desired. That is,
at the beginning of the time interval insert a stage-shift-variation diagram
with a constant shift value for all stages that is equal to the time shift
desired for that time. Likewise at the end of the time interval insert a
stage-shift-variation diagram with a constant shift for all stages that is
equal to the time shift desired at the end of the time interval. These two
variation diagrams will then be prorated by time and produce results just as a
traditional time shift would. The committee feels strongly that this method
should be used in preference to the traditional method because it can be
worked in easily with stage shifting, and without the need to be concerned
with NULL periods.
ADAPS shifting procedures do not allow additive time and stage shifts, as was
possible in the ADR system. Such a procedure presupposes that a shift can be
separated into two components, one of which applies with stage, the other with
time. This is a difficult concept to comprehend and is probably not a
desirable feature. The user could, however, apply this concept by adding a
constant value to the stage-shift-variation diagram. Even though this is
possible within ADAPS, it is not recommended.
When applying shifts, the hydrographer must always examine the previous shifts
in the files because the last used shift will affect the period between the
date of that shift and the current shift, unless alternate shifts, or a NULL
period, are defined for the intervening period. It is very important that
this "continuous" nature of the shift files be understood and remembered at
all times.
It is recommended that a utility program be written that will take the time-
shift and stage-shift values from the interim ADR system files, convert them
to equivalent ADAPS-compatible shifts and store the values in the appropriate
ADAPS files. This utility program should be made available to all Water
Resources Division offices which have or plan to have ADAPS capability.
2. PROBLEM: There is a potential for corrupting the daily values that have
been transferred from the ADR system to ADAPS. This can occur when ADAPS is
used to recompute unit-values data (discharge, gage height, or other
parameter) that had been computed by the ADR system in previous water years
even if they are flagged "final". The problem arises from a combination of
circumstances, including some legitimate differences between ADAPS and ADR
(explained above), some deficiencies in the shift-file conversion software,
and a serious bug in the ADAPS file-writing software.
RECOMMENDATION: Computed unit values (of say, discharge) were not stored in
the ADR system. At present, if you want to obtain these values you must do a
primary computation using the stored values of shifts, datum corrections,
ratings, and input unit values. The primary computation also computes daily
values, and will attempt to store these daily values. Several problems can
result from the "recomputation". It should be noted that daily values
converted from the ADR system can be retrieved with ADAPS without problem. It
is only when computed unit values are needed that the problem occurs. At this
time, the only method to insure that shifts and datum corrections are
converted properly is to do a manual review, and to make manual revisions so
that the shift and datum corrections will conform to ADAPS specifications.
Particular attention should be paid to water year boundaries, because the ADR-
ADAPS conversion assumes that shifts and datum corrections at the beginning of
a water year are equal to the values at the end of the previous year.
Records that are recomputed with improperly converted shifts and datum
corrections will, of course, yield incorrect unit and daily values. This can
lead to corruption of the stored daily values because of the following:
(1) The ADAPS primary computation procedure always attempts to store daily
values.
(2) The ADAPS file-writing routines do not properly inspect and honor the
"final" flags on daily values records.
(3) The ADAPS record-protection mechanism does not provide protection for all
the data elements that, taken together, define the daily values records.
Specifically, ratings, shifts, datum corrections, and input unit values
that were used to compute a "final" record can be altered to be
inconsistent with the "final" record.
The preceding paragraphs explain the origin and circumstances that could lead
to corruption of finalized historical records. Several ADAPS software changes
are needed to deal with these problems, and the most important of these that
need immediate attention is the provision that "final" flags be properly
observed and honored. This correction is, in fact, being made and tested at
this time.
Other software changes regarding the conversion process will be made, either
directly in the ADAPS software, or as auxiliary utility programs. However,
these will take more time, and in the interim guidance is needed on how to
protect the integrity of the final records.
Specific guidelines which should be implemented immediately are as follows:
(1) The records residing in WATSTORE are the official records and constitute
the U.S. Geological Survey's national repository of water data. To
protect the integrity of these data, it is recommended that, until
further notice, there SHOULD BE NO UPLOADING OF DAILY VALUES TO THE
WATSTORE SYSTEM. Districts should take the necessary steps to prevent
records from being either automatically or manually uploaded to the
WATSTORE system.
(2) Make a complete backup of the ADAPS daily values file immediately after
the conversion from the ADR system to ADAPS. To the best of our
knowledge these daily values are converted correctly. The problems occur
after the conversion when "recomputations" are made.
(3) Before doing any recomputation of historical unit values data that were
converted from the ADR system to ADAPS, do a careful review of shift and
datum corrections for the time period being recomputed. Revise shift and
datum corrections, as necessary, to conform to ADAPS specifications.
Prepare a written statement (signed and dated) documenting the review and
any changes made. This statement should be filed in the official station
file.
(4) Before doing the recomputation, obtain a printed copy of the daily values
tables for the affected time period. Even better would be obtain a
printed copy of all daily values tables for the entire period that was
converted from the ADR system to ADAPS. These copies can be identified
as the correct daily values "before recomputation" and serve as a basis
for comparison of any future recomputations. These listings should also
be signed, dated, and filed in the official station file.
(5) After doing the unit values recomputation, obtain another daily values
table and compare it carefully and completely with the original listing
obtained in item 3 above. Identify and resolve any discrepancies. Make
appropriate corrections so that daily values compare. Occasional
rounding differences, and differences caused by minor interpolation
differences can generally be ignored, but should be noted on the printout
for future reference. Again, document this comparison, sign and date it,
and file it. NOTE: It may be possible to make the comparison more easily
by using a routine such as the PRIMOS CMPF utility.
(6) Daily values recomputed after the ADR-ADAPS conversion should not be
uploaded to the WATSTORE files on the AMDAHL mainframe computer in
Reston, as stated in item (1) of these guidelines.
(7) Current records (i.e., those not yet finalized or uploaded to WATSTORE)
computed by ADAPS should be reviewed carefully, especially in regard to
the shift and datum procedures, before finalizing. Again, these records
should not be uploaded to the WATSTORE system until notice is received
that correction software has been completed and tested, and that it is
safe to resume the uploading process.
3. PROBLEM: When the time difference between two successive input values is
equal to or greater than the test difference, the daily value will be computed
and displayed on the primary sheet, but will not be stored. Likewise, volume
calculations will be made and displayed. Should we be displaying the daily
values on the primary if they are not being stored? Should the volume
calculations be displayed if daily values are not stored?
RECOMMENDATION: The daily values should be computed and displayed on the
primary, but an appropriate flag should be provided so the analyst will be
aware that the time limit between input readings was exceeded. The volume
calculations should also be displayed with the same flag. None of the daily
values should be stored.
4. PROBLEM: If a period of previously computed record is edited and one or
more days of input values are deleted (i.e., set to "missing"), a
recomputation of this period will retain the original daily values for the
deleted day(s). In other words, a day reset to "missing" does not set the
daily values for that day to "missing".
RECOMMENDATION: It is recommended that the ADAPS software be changed so that
each time a primary computation is performed, all unprotected daily values are
automatically deleted before the computations are made.
5. PROBLEM: If daily values have been write-protected and a recomputation of
those values is made, the write-protected values are retained and are
displayed on the primary output. The recomputed daily values are not
displayed on the primary.
RECOMMENDATION: The recomputed daily values should be printed and flagged on
the primary output. The flag should state that daily values are not stored
because the daily values file contains previously write-protected values.
6. PROBLEM: If a rating is exceeded (either end) during a day's computations,
the daily values are computed, displayed, and stored. The unit values during
the period of rating exceedance are set to null, are not stored, and are
ignored by the daily value computations.
RECOMMENDATION: There are a number of different types of ratings in ADAPS,
but the same basic rules should be observed for all. That is, that no
computations should be made for values outside the limits of the rating, and
no values should be printed or stored for the days when a rating is exceeded.
An appropriate flag should occur on these days so the analyst can take
necessary actions to extrapolate, or not extrapolate, depending on his
judgement. Extrapolations should be made by the analyst, not by the computer.
For certain ratings, such as a stage-discharge rating, it would be appropriate
to establish the lower limit of discharge equal to zero. This would only
apply to ratings where it is not possible to have negative values. For such
ratings, a value of zero would be used anytime the input value (plus datum and
shift corrections) was below the zero point of the rating. Other ratings, such
as velocity ratings, where negative values may be entirely appropriate should
not have the zero limitation imposed, but should provide a warning flag
anytime the lower limit is exceeded. Computations should not be made,
displayed, or stored for these types of ratings if the lower limit is
exceeded. The present version of ADAPS apparently imposes the lower limit of
zero for all ratings. This should be selectively changed according to the
type of rating.
7. PROBLEM: ADAPS currently computes daily values from the unrounded computed
unit values. The daily value is then rounded and stored. Unit values are
stored unrounded. Unit values tables are printed as rounded values. This can
result in discrepancies when comparing totals or averages computed from UV
tables with those in the daily values files. This has also resulted in
discrepancies between ADR system values and ADAPS values, because ADR system
daily values were stored unrounded.
RECOMMENDATION: The committee concluded that unit values should be stored
unrounded, and daily values should be stored as rounded. This is how the
system currently works, therefore no changes are needed. In regard to the
conversion from the ADR system to ADAPS, Neil Stuthmann reported that a
program is presently being written to take care of the differences
encountered.
8. The handling of missing values in records where interpolated values are
used in the computation procedures (such as velocity/deflection and slope
stations) was discussed. The program currently does not interpolate a data
value if either adjacent value is missing. The committee concluded this is a
proper procedure and no problem exists. Additional questions about missing
data will, however, be discussed in following items.
9. PROBLEM: When a unit value does not coincide with midnight, the program
will interpolate a value for midnight from the adjacent readings. This
interpolated value is used for the computation of daily values, but is not
stored. When this happens, no time check is made between the last value of
previous day and the first value of the current day.
RECOMMENDATION: The program should be changed so the time interval check is
made before the midnight reading is interpolated. If the time interval
between the last reading of the previous day and the first reading of the
current day exceeds the specified time interval check, then appropriate flags
should occur on both days.
10. PROBLEM: There was considerable discussion about a number of definitions
and policy questions as they relate to electronic handling of data. For
instance, what is "original" data, "raw" data, edited unit values, computed
unit values, etc. What should be done with temporary storage files? What kind
of audit trail should be stored?
RECOMMENDATION: The committee deferred any recommendations regarding these
items until policy decisions can be made. There is a WRD memo which covers
some of these questions, but additional work will be needed.
11. PROBLEM: What are "missing" data, and how does ADAPS treat these data?
RECOMMENDATION: The committee defined three situations where warning flags
should be displayed by ADAPS, and recommends that changes be made to ADAPS to
accommodate these situations:
(1) No data recorded.-This would be any situation where data were expected,
but because of some malfunction of equipment there were no data recorded.
In these cases, an appropriate flag should be displayed, "a"=No Data
Recorded.
(2) Bad data recorded.-This would be a situation where erroneous data were
recorded (i.e., the float settled on mud in the well and the outside
stage went below the level of mud, thereby resulting in readings that do
not represent the stage in the stream). An appropriate flag should be
displayed, "b"=erroneous data recorded.
(3) Data affected by backwater, ice, etc.-This would be a situation where the
stage (or other parameter) recorded is correct, but because of a some
irregular condition the rating is severely affected and may not be
applicable. An appropriate flag should be displayed, "c"=data affected
by backwater, ice, etc.
12. PROBLEM: For sites having more than one gage, such as slope stations and
velocity/deflection stations, ADAPS applies the "time interval" check to only
the base gage. The time interval check is made after interpolation is
performed to produce "time aligned" data, and is therefore made on all unit
data, including the interpolated values. (1) Should the time interval check
be made of the auxiliary gages as well as the base gage? and (2) should the
time interval check be made with interpolated values included?
RECOMMENDATION: It was concluded that time interval checks should be made on
the base gage and all auxiliary gages. It was also concluded that time
interval checks should be made only on original data, and should not include
interpolated data. These changes should be made to ADAPS. When setting up the
site and DD files for a station where auxiliary gages are included, the value
of the "time interval" check is defined only for the base gage. It will be
appropriate to use this value for all gages, and no changes are needed to
ADAPS in this regard.
13. PROBLEM: ADAPS currently stores unrounded rating input values just as
they are entered by the user. The points are echoed back to the user as
rounded values. This sometimes causes confusion because the user may see a
number with fewer significant figures than the one he entered. Should this
procedure be retained or should input values be rounded before storing?
RECOMMENDATION: It is recommended that rating input values should be rounded
to "expanded" precision and stored as rounded values. Computations will use
the rounded values, and rounded values will be displayed to the user. For
discharges, the following table lists rounding specifications:
SIGNIFICANT FIGURES FOR DISCHARGE
DISCHARGE DISCHARGE DAILY RATING TABLE RATING TABLE
RANGE MEASUREMENT VALUE (STANDARD) (EXPANDED)
<0.01 variable variable 0 1
0.01-0.1 1 1 1 2
0.1-1 2 2 2 3
1-10 3 2 2 4
10-100 3 2 3 4
>100 3 3 3 4
For discharges, expanded rounding equals discharge measurement rounding plus 1.
All other parameters will use standard rounding plus 1 for expanded rounding.
14. PROBLEM: Some rainfall stations have a fluid reservoir which is filled by
the field person each time the gage is serviced. When the data are processed,
this positive increase in dial reading is interpreted as rainfall. Should
ADAPS contain a procedure to automatically account for this?
RECOMMENDATION: The committee viewed this as an operations problem, and did
not recommend any changes to ADAPS. One solution would be for the field
person to reset the dial to zero each time water is added to the reservoir.
Another solution is to apply a correction constant to the data during
processing.
15. PROBLEM: Secondary screening codes (flags) are currently carried forward
to the computed unit values for deflection/velocity and slope stations.
Should this be done?
RECOMMENDATION: Flags should be carried forward to the computed unit values.
No change necessary.
16. PROBLEM: A rating curve plotting program is currently available for use
on the PRIME, but not in ADAPS. The is the Colorado District program
developed by Ed Wilson. Should this plotting program be made a part of ADAPS?
RECOMMENDATION: The committee did not make a recommendation on this item. If
users are interested in obtaining the program, they should contact Neil
Stuthmann or Ed Wilson. Comments are welcome regarding your experience with
this program, or your thoughts as to its inclusion in ADAPS.
17. PROBLEM: When setting up the initial instrument and processor files for a
station (SU 2), if you answer "yes" to store unit values for gage height and
discharge, it shows that it is stored, but later checking of this item will
show it is "not stored". This problem does not seem to occur if another
parameter is not computed from the input parameter (such as a gage height only
site).
RECOMMENDATION: This is a minor inconvenience that can easily be corrected if
the problem is recognized. However, ADAPS should be corrected so the problem
does not occur.
18. PROBLEM: The deletion of a data descriptor file (SU 3) does not delete
the shift, datum, measurement, daily value, or temporary files as it is
supposed to do. It does delete the ratings.
RECOMMENDATION: It is recommended that ADAPS be corrected so that all files
are deleted when the DD file is deleted.
19. PROBLEM: The present version of ADAPS does not allow the user to set up a
site file under SU 1, as was possible in previous versions.
RECOMMENDATION: Neil Stuthmann reported that this option was removed
intentionally. It will be added back when related corrections are made.
20. PROBLEM: The current version of ADAPS does not allow the user to build
station groups as was possible in previous versions.
RECOMMENDATION: This option is now working, but has not been released to the
field. It will be included in the next version of ADAPS.
21. PROBLEM: The shift analysis program (HT 6) prints ***** for the discharge
when it exceeds 9999.
RECOMMENDATION: It is recommended that the size of this field be increased so
that six places are available.
22. PROBLEM: The input of logarithmic rating curve offsets (offset, stage) is
in reverse order from the rating table output where it shows as (stage,
offset). The rating table does not identify which value is the offset and
which is the stage. This is confusing, and a possible source of error.
RECOMMENDATION: It is recommended that the input and output be in the same
order, and that that order be (stage, offset).
23. PROBLEM: The current maximum value of the "time interval" check is 1440
minutes (24 hours). There are situations, such as when once-daily observer
readings are used, that a larger interval is needed.
RECOMMENDATION: It is recommended that the maximum time-interval check be
increased to 2880 minutes (48 hours).
24. PROBLEM: On the primary printout of a gage-height only station, the times
corresponding to the maximum and minimum gage heights are not shown on the
historical primary output.
RECOMMENDATION: It is recommended that an appropriate change be made to ADAPS
to correct this problem.
25. PROBLEM: For a gage-height only site, if there "happens" to be a shift
included in the shift file for the station, ADAPS will apply the shift to the
gage heights. Only datum corrections should be applied to gage-height only
sites.
RECOMMENDATION: It is recommended that the program be changed so time-
variable datum corrections, but not shift corrections, be applied to gage-
height only sites. The committee recognized the need for stage-variable datum
corrections and recommends that future versions of ADAPS include such a
provision to allow gage height record to be corrected by stage (manometers,
surface followers, etc).
26. PROBLEM: There is a need to enter negative values of gage height and
discharge in the measurement listing files (HT 1).
RECOMMENDATION: Future versions should include these options.
27. PROBLEM: Measurement listing files (HT 1) do not allow entry of areas
greater than 99999.
RECOMMENDATION: Future versions should allow entry of six digits to the left
of the decimal for cross-section area.
28. PROBLEM: The shift analysis program (HT 6) will not work for ratings with
multiple offsets.
RECOMMENDATION: It is recommended that this problem be fixed. Also, tests
should be made to be certain that all aspects of the multiple offset rating
work.
29. PROBLEM: When entering the instrument file for a velocity/deflection
station, the parameter code for velocity prints out as 82072 rather than
00055.
RECOMMENDATION: This problem should be corrected.
30. PROBLEM: There is confusion with some people as to the meaning of a
primary record and a work record.
DISCUSSION: The designation of primary and work records is only for
identification purposes, and will not affect any of the computations. Primary
records will automatically be flagged for uploading to the WATSTORE system in
Reston, whereas work records will not. Usually only one record is designated
as primary, but it is permissible for two or more records to be designated
primary (or work) records. These may be the same parameter, for instance an
ADR and DCP both collecting stage data may both be designated primary, or
work.
31. PROBLEM: How does the change from daylight savings time to standard time
work in ADAPS?
DISCUSSION: For DCP stations, this is an automatic feature. An hour is added
(or subtracted) at the appropriate time according to local standards. For
other stations, corrections should be made to local standard time just as we
did prior to ADAPS.
32. PROBLEM: When will the dam program be available?
DISCUSSION: Neil Stuthmann reported that this program has been temporarily
delayed because of other ADAPS problems of higher priority. No estimate was
available for the completion of this program.
33. PROBLEM: Daily values of 1.0 print out as 0 in daily value tables. It
seems that this happens in other instances, not just daily values. The full
extent of this problem is not known.
RECOMMENDATION: It is recommended that this problem be investigated and
corrected.
34. PROBLEM: In the monthly and yearly summaries, runoff values greater than
10 inches are rounded to tenths. They should be rounded to hundredths.
RECOMMENDATION: ADAPS should be changed so that runoff values greater than 10
inches are rounded to hundredths.
35. PROBLEM: In WATPLOT, dates appear on the midnight line instead of the
noon line, when plotting unit values.
RECOMMENDATION: ADAPS should be corrected to show the date at the noon line.
36. PROBLEM: Daily rainfall totals do not include the first increment of
rainfall (between midnight and the succeeding punch).
RECOMMENDATION: Neil Stuthmann reported that this problem has been fixed on
the Reston version of ADAPS but has not yet been distributed to the field.
In addition to the above numbered problems and recommendations, several other
important items were discussed as follows:
Future versions of ADAPS should include the capability to select, lag, add,
and subtract groups of records, as was available in the old AMDAHL records
computation programs.
Gary Rodgers is currently working on a program to enter analog data by
digitizer. No projected completion date is available at this time.
Jim Fulton is working on a program to retrieve unit values in B card format.
This will allow the user to obtain unit values without recomputing them. The
program is complete and is being tested.
The data compression scheme is reported to be working well. There are no
apparent problems with this aspect of ADAPS.
Scott Bartholemew has developed a program to aid in the data management
capabilities of ADAPS, such as defining stations available, period of records
available, type of data available, etc. This will be an interim feature until
NWIS.90 becomes available, at which time NWIS will provide these capabilities.
The ADAPS User's Manual, dated August 1987, is a much improved version from
the one reviewed by the Technical Review Team in Austin.
The next version of ADAPS will be ready about December 1987. The Technical
Review Team agreed to meet as soon thereafter as possible to test this version
before it is released to the field. The team will, in the meantime, develop
test data sets for the purpose of testing future versions of ADAPS. Larry
Hubbard suggested the team meet in Portland, Oregon, for these tests.
Test data sets will be developed for the following types of sites:
(1) Stage only
(2) Stage/discharge
(3) Deflection/velocity/discharge
(4) Stage/Fall/Discharge
(5) Rainfall
(6) Reservoir
(7) Ground-water well
(8) Quality-water monitor
The test data sets may also be useful in discipline reviews to establish
whether or not the local version of ADAPS produces expected answers. It was
also decided some general guidelines for each discipline should be developed
to guide reviewers in reviewing the data computations in a District. Jim
Schornick will discuss this with the Office of Quality Water, and Bob Faye
will do the same in regard to ground-water guidelines and the Office of Ground
Water. Vern Sauer will develop a preliminary set of guidelines for surface
water for discussion at the next meeting.
The next meeting will be in Portland, Oregon, early in the 1988 calendar year.
A firm date will be established as soon as it becomes known when the next
version of ADAPS is ready for testing.
Vernon B. Sauer
Chairman