MONITOR
Users Manual
Software for Estimating
the Power of Population
Monitoring Programs
to Detect Trends
in Plant and Animal
Abundance
Software written by
James P. Gibbs
A WordPerfect 5.1 version of the manual is also available
(MONITOR.WP). (note: Figures and Tables not available in
text version of manual)
This software was programmed in Turbo Pascal 7.0. Numerical
algorithms were taken from: W. H. Press, B. P. Flannery,
S. A. Teukolsky, and W. T. Vetterling, 1990: Numerical recipes
in Pascal, Cambridge University Press, New York. The software
benefited greatly from the technical comments of Clinton
T. Moore of the U.S. Fish and Wildlife Service.
MONITOR version 6.2
15 April 1995
copyright 1995 James P. Gibbs
TABLE OF CONTENTS
- OVERVIEW. . . . . . . . . . . . . . . . . . .
. . . . . .
|
6 |
- MONITOR INPUTS. . . . . . . . . . . . . . . .
. . . . . .
|
8 |
- Number of Plots. . . . . . . . . . . . . . . .
. . .
|
8 |
- Counts/Plot/Survey . . . . . . . . . . . . . .
. . .
|
9 |
- Plot Counts. . . . . . . . . . . . . . . . . .
. .
|
9 |
- Plot Variances . . . . . . . . . . . . . . . .
. . .
|
10 |
- Plot Weights . . . . . . . . . . . . . . . . .
. . .
|
10 |
- Number of Surveys. . . . . . . . . . . . . . .
. . .
|
11 |
- Survey Occasions . . . . . . . . . . . . . . .
. . .
|
12 |
- Trend Type . . . . . . . . . . . . . . . . . .
. . .
|
13 |
- Significance Level . . . . . . . . . . . . . .
. . .
|
14 |
- Number of Tails. . . . . . . . . . . . . . . .
. . .
|
16 |
- Constant Added . . . . . . . . . . . . . . . .
. . .
|
16 |
- Trend Variation. . . . . . . . . . . . . . . .
. . .
|
17 |
- Rounding . . . . . . . . . . . . . . . . . . .
. . .
|
17 |
- Replications . . . . . . . . . . . . . . . . .
. . .
|
18 |
- Trend Coverage . . . . . . . . . . . . . . . .
. . .
|
18 |
- FUNCTION KEYS . . . . . . . . . . . . . . . .
. . . . . .
|
19 |
- Help . . . . . . . . . . . . . . . . . .
. . .
|
19 |
- Run . . . . . . . . . . . . . . . . . .
. . . .
|
19 |
- Results . . . . . . . . . . . . . . . .
. . . .
|
22 |
- Save a MONITOR File . . . . . . . . . .
. . . .
|
23 |
- Load a MONITOR File . . . . . . . . . .
. . . .
|
23 |
- Save Simulation Results . . . . . . . .
. . . .
|
23 |
- Go to DOS . . . . . . . . . . . . . . .
. . . .
|
23 |
- Run Batch File . . . . . . . . . . . . .
. . . .
|
24 |
- Quit . . . . . . . . . . . . . . . . .
. . . .
|
26 |
- EXAMPLES. . . . . . . . . . . . . . . . . . .
. . . . . .
|
27 |
- Single Plot - Black Bears . . . . . . . . . .
. . .
|
27 |
- Multiple Plots - Jack-in-the-pulpits . . . .
. . . .
|
30 |
- Multiple Plots - Virginia Rails. . . . . . .
. . . .
|
34 |
- CALCULATING TEMPORAL VARIANCES IN SAMPLE COUNTS
. . .
|
39 |
- SOME SAMPLE VARIANCES . . . . . . . . . . . .
. . . . . .
|
40 |
- INSTALLATION. . . . . . . . . . . . . . . . .
. . . . . .
|
41 |
- LITERATURE. . . . . . . . . . . . . . . . . .
. . . . . .
|
42 |
OVERVIEW
Estimating temporal trends in plant and animal populations
is a common goal of biologists and managers. Trends are
typically inferred from counts of individuals made on sample
plots over time. Trends represent the sustained patterns
in count data that occur independently of cycles, seasonal
variations, and irregular fluctuations in counts.
A common problem in trend detection is that sources of
"noise" in counts obscure the "signal" associated with ongoing
trends. The probability that a monitoring program will detect
a trend in sample counts when the trend is occurring, despite
the "noise" in the count data, represents its statistical
power. Although statistical power is central to every monitoring
effort, it is rarely assessed. Consequences of ignoring
it include collection of count data insufficient to make
reliable inferences about population trends, and collection
of data in excess of what is needed.
This software estimates the statistical power of population
monitoring programs relative to (1) the number of plots
monitored, (2) the magnitude of counts per plot, (3) count
variation, (4) plot weighting schemes, (5) the duration
of monitoring, (6) the interval of monitoring, (7) the magnitude
and nature of ongoing population trends, (8) the significance
level associated with trend detection, and several other
factors (see Table 1). Because these factors interact in
complex ways to determine the capacity of a monitoring program
to detect trends in populations, such basic questions of
"how many plots should I monitor" or "how often should I
conduct surveys" rarely have intuitive answers. MONITOR
was designed to explore interactions among the many components
of monitoring program and to evaluate how each component
influences the monitoring program's power to detect trends.
To use MONITOR, the user defines the structure of the
monitoring program (for example, the number of plots monitored
and the duration and interval of monitoring) and provides
estimates of the magnitude and variation in counts on each
plot. Much of this information can be derived easily from
some preliminary count data or from data published for populations
or species similar to those targeted for monitoring. MONITOR
then uses Monte Carlo procedures to generate many, simulated
sets of count data based on a monitoring program defined
by the user and sample counts drawn at random from distributions
defined by the user. Through multiple trials, MONITOR evaluates
how often a monitoring program detects trends of varying
strength that actually occur in the count data.
Power of monitoring programs consisting of a single plot
is estimated by determining the proportion of trials a trend
occurring in sample counts on the plot was significantly
different from zero. For monitoring programs consisting
of multiple plots, a "route regression" approach is used,
whereby trends in sample counts are determined for each
plot, and then averaged across plots. The proportion of
trials in which these average trends differed from zero
is used to estimate power. Thus, the power estimate generated
by MONITOR, measured from 0 (low power) to 1 (high power),
indicates how effective a monitoring program is at detecting
trends that might occur in the population being monitored.
MONITOR can thereby serve as a valuable tool for assessing
the effectiveness of existing monitoring programs, and in
designing new ones.
MONITOR INPUTS
Number of Plots
The Number of Plots field requests the number of plots
being monitored. Plots are considered synonymous with samples,
quadrats, routes, transects, or other monitoring units on
which repeated counts of individual plants or animals are
made over time. The maximum number that can be modelled
is 250. Number of plots is an obvious parameter to manipulate
when examining trade-offs between monitoring effort and
statistical power. Multiple plot situations will generally
provide greater power to detect trends than single plot
situations. For multiple plot situations, the software can
be useful for examining trade-offs between effort expended
(number of plots monitored) versus the relative gain in
power to detect trends.
Counts/Plot/Survey
The Counts/plot/survey field requests information on the
number of counts made on each plot on each survey occasion.
For example, if counts are made on each plot twice each
year they are surveyed, then enter 2 for this field. If
counts are made 5 different times each year the plots are
surveyed, then enter 5. For single, annual counts, you would
enter 1. Note that the total number of surveys conducted
(e.g., the total number of years plots were surveyed) and
the actual occasions of those surveys (e.g., on which years
those surveys were conducted) are requested elsewhere (see
Number of Surveys and Survey Occasions) - this field simply
requests the number of times plots are monitored on any
given survey occasion. Increasing numbers of counts per
plot during any given survey occasion yields increasing
power to detect trends.
Plot Counts
This field requests the initial counts observed on each
plot monitored. Initial counts are the average or mean counts
observed on a particular plot, and they serve as the starting
values from which potential trends are projected. The magnitude
of initial plot counts can influence power to detect trends,
particularly declining trends. Manipulating the magnitude
of initial plot counts permits evaluation of the effects
of plot sizes, route lengths, transect widths, listening
intervals, etc., on power to detect trends. For example,
if a mean count x is obtained for a transect of a particular
length, one could explore the effect of doubling the transect's
length, and thereby increasing the initial count from x
to 2x, on power to detect trends in the population.
Plot Variances
This field requests information on the variation observed
in counts on each plot. Specifically, the user provides
an estimate of the standard deviation in mean counts per
plot. This value describes the "spread" of one's counts
about the mean count, and largely determines how much "noise"
will be present in the simulated data.
Repeated counts made on the same plot within the same
season (or over a few, consecutive seasons) are the best
source of values for the standard deviation associated with
initial plot counts. This is because the quantity required
here is an estimate of the temporal variation in counts
on the same plot, not the spatial variation in counts among
plots. In multiple plot situations, spatial variation among
plots is already accounted for by entering different initial
mean counts for each of the plots monitored.
Plot variances are a critical determinant of power to
detect trends. Smaller variances relative to initial counts
increase power to detect trends over proportionately larger
variances. Manipulation of plot variances in MONITOR enables
the user to examine the contribution of various procedures
for the reducing variance in plot counts on the power to
detect trends in the population monitored, for example by
altering plot dimensions, sizes, or sampling locations.
Plot Weights
This field requests information on plot weights. Note
that plot weighting is employed only in situations involving
2 or more plots monitored simultaneously. Plot weights enable
the user to emphasize or diminish the influence of particular
plots on trend estimates. Weights used often reflect the
magnitude of initial counts, count precision, or some combination
of the two. For more information on weighting procedures,
see Sauer and Droege (1990). Equal weights is the default
(1 for all plots) and results in all plots contributing
equally to the average trend estimate.
The procedure used to calculate the weighted mean trend,
w, from the trend estimated on each of several plots is:
äiwixi äiwi,
where wi = the weight for plot i and xi = the sample count
on plot i. Note that weighting schemes will only influence
the estimate of the mean trend, not the estimate of the variance
about the mean trend. Trend variances are not weighted in
MONITOR because there is no satisfactory formula for calculating
the weighted variance that could accommodate the variety of
weighting schemes that might be implemented by different users
of MONITOR.
Number of Surveys
This field requests the number of surveys conducted on
each plot. Up to 100 surveys of each plot can be accommodated.
At least 3 points along a time series of counts are needed
to calculate a trend with linear regression, so number of
surveys must be 3 or more. So, for example, if you planned
to conduct 5 surveys on your plots every other year over
the next 10 years, enter 5 for number of surveys. Similarly,
if you planned 5 surveys every year over the next 5 years,
again enter 5 for number of surveys. Note that the actual
position in time when each of the surveys is conducted is
entered under Survey Occasion.
Survey Occasions
This field requests when each survey is conducted. Note
that any time units can be used (e.g., years, or months,
or weeks, or hours), and that trends are assessed relative
to these time units. Also note that survey occasions can
be whole or fractional. The only restriction is that the
time span between the initiation of monitoring and the last
monitoring interval should not exceed 100. In other words,
because simulation of the monitoring program begins at time
0, the "largest" survey occasion permitted is 100.
An example...if you have conducted surveys on plots annually
for 5 years, enter 5 for number of surveys and then enter
0, 1, 2, 3, & 4 for survey occasions. Trends will consequently
be assessed on a per annum basis. If, however, you are considering
surveying plots twice as intensively for half the duration,
you would again enter the number of surveys as 5, but might
enter survey occasions of 0, 0.5, 1, 1.5, & 2. In this case,
trends are still assessed on a per annum basis. Note that
the initial counts are projected from time 0, not time 1.
Also note that survey occasions do not need to be evenly
spaced, nor entered in any particular order.
Survey occasion is a useful parameter to manipulate when
examining the trade-off between survey effort and power
to detect trends. In particular, conducting surveys every
other or every third interval can sometimes provide a large
reduction in monitoring effort with little sacrifice of
power to detect trends. Length of a count series (duration)
also strongly influences statistical power. In other words,
the farther apart are the first and last survey occasions,
the more likely it is that trends in counts will be detected.
Obviously increasing the number of surveys between the first
and last survey occasion will yield increasing power to
detect trends. Be aware that steep trends coupled with small
initial counts over a long duration will eventually result
in near zero mean counts and a consequent inability to detect
trends.
Trend Type
This field requests information on what type of trend
underlies changes in your counts. Two alternatives are offered:
linear trends and exponential trends. Linear trends are
derived from a linear model that generates normally distributed
random counts each survey occasion (truncated at zero) that
are subsequently analyzed untransformed. Exponential trends
are derived from an exponential model that generates lognormal
sample counts each survey occasion that are log-transformed
prior to the regression analysis.
The results from the two models often are similar. Choose
the linear model if your counts are more or less normally
distributed and if trends in your counts are expected to
be linear in nature. Choose the exponential model if your
counts are log-normally distributed and if trends in the
population monitored are likely exponential in nature. One
practical consideration is that the linear model requires
fewer computations and therefore generates results more
rapidly. These two types of temporal trends that can be
projected from your sample counts are contrasted in Figure
1.
The linear model option uses a normal probability distribution
based on average annual rates of change (R), where R = ((Mean_Count_K
/ Mean_Count_0)1/T) - 1, Mean_Count_K and Mean_Count_0 =
the mean counts at the beginning and end of the monitoring
period, and T is the length of the monitoring period. With
the linear model, Mean_Count_K = (R + 1)T * (Mean_Count_0),
and the mean count at any interval, t, = Mean_Count_0 *
[1 + t {(R + 1)T - 1}/T]. The exponential model generates
lognormal deviates based on mean counts at each interval
(k), such that Mean_Count_K = (Mean_Count_0) * (R + 1)t,
where R is a discrete value (e.g., 0.90, 0.95, ..., 1.05,
1.10).
Significance Level
The significance level, or type I error rate, represents
the threshold at which you consider a trend to be "significant."
The default is the conventional value of 0.05, but any value
between 0 and 1 can be entered, although values from 0.1
(least stringent) to 0.001 (most stringent) are typically
used. There is a direct trade-off between power and significance
level. The more stringent the significance level, the lower
the resulting power estimate.
The significance level to employ depends in part on the
costs inherent in making different types of statistical
errors. If there is a high cost associated with failing
to detect an ongoing trend, then use a stringent significance
value (e.g., 0.01) to generate the power estimates and guide
development of your monitoring program. This might be, for
example, the case in monitoring a population of an endangered
species, for which you want to be confident that you design
a monitoring program that is statistically powerful and
hence has a high likelihood of detecting trends in the population,
should they occur.
Number of Tails
You may choose to test significance of a trend with either
a one- or a two-tailed t-test. With a two-tailed t-test,
the software evaluates whether the population trend merely
differs from zero. With a one-tailed t-test option, the
software tests whether the trend is greater than zero for
positive trends or less than zero for negative trends (trend
assessment in the zero trend scenario is always two-tailed).
Using a one-tailed t-test will increase power estimates
over the two-tailed test, but note that it should be used
only if one has some prior expectation of the direction
of future trends in the population being monitored.
Constant Added
If the exponential model is invoked to simulate count
trends, randomly generated counts will be log-transformed
prior to trend (regression) analysis. This field prompts
the user to provide the constant used in the log-transformation,
log[y + x], where y is the sample count and x is the constant
added. Different values of the constant added (usually 1
to 5) can have a subtle effect on power estimates.
Trend Variation
In multiplot situations, all plots monitored can share
the same given trend, or a particular trend can vary at
random among plots about a given mean trend (trend variation
does not apply to single plot situations). This field requests
information on the degree to which a given trend varies
at random among multiple plots. If you want trends fixed
among multiple plots (perhaps because the degree to which
trends vary among plots is unknown), simply enter a standard
deviation for trend variation of zero (the default). Otherwise,
enter a value for the standard deviation associated with
the mean trend, and the actual trend on an individual plot
will be sampled from a normal distribution.
Note that random variation in trends among plots will
generally reduce power to detect trends. Also note that
mean trends vary over a rather small range (-0.10, -0.05,
-0.03, -0.02, -0.01, 0.00, 0.01, 0.02, 0.03, 0.05, 0.10)
and that trend standard deviations should therefore be sized
accordingly, e.g., a trend standard deviation of 0.1 is
a relatively large value. The maximum permitted value for
the trend standard deviation is 1.
Rounding
This field offers the user the option of generating random
counts as whole (integer) numbers or as decimal numbers.
Population surveys often involve counts of individuals per
plot, and the whole number option may be preferable in such
situations. Surveys involving population indices per unit
area or per unit time might best be simulated using the
decimal counts option. Note that modelling counts as whole
numbers generally reduces power estimates relative modelling
them as decimals, particularly if mean initial counts on
plots are less than 1.
Replications
This field requests the number of iterations to perform
in assessing the power of a monitoring program. Consistent
results are unlikely with under 100 iterations. Up to 10,000
replications can be performed. Note that the number of significant
digits provided for power estimates depends on the number
of iterations performed: 1 digit for < 100 iterations, 2
for 100-999, 3 for 1,000-9,999, and 4 for 10,000.
Trend Coverage
This field enables you to run simulations for a subset
of trend projections (the Partial option), for a complete
set of trend projections (the Complete option), or for a
specific trend (the Specific option). The Partial option
projects the following 11 trends from your initial counts:
-10%, -5%, -3%, -2%, -1%, 0%, 1%, 2%, 3%, 5%, 10%. The Complete
option projects the following 21 trends from your initial
counts: -10%, -9%, -8%, -7%, -6%, -5%, -4%, -3%, - 2%, -1%,
0%, 1%, 2%, 3%, 4%, 5%, 6%, 7%, 8%, 9%, 10%. If you choose
the Specific option, you will be prompted when you begin
the simulation for the specific trend, which should lie
between -10% and 10%. Running specific trends is more time
efficient, and let's you quickly derive a power estimate
for a well-defined monitoring objective, e.g., what is the
probability of detecting a 5% annual population decrease
after 10 years? The software will focus on just the specific
trend that you identify, and provide the power estimate
in a fraction of the time that the partial or complete coverage
options would. Note that the specific trend given should
be on a trend per unit time basis, not an overall trend
basis. You can use Converter to translate between long-term
and short-term trends.
FUNCTION KEYS
Help
Pressing once provides access to a context-sensitive
help file. Pressing twice provides access to the complete
list of help topics available. When viewing the list of
help topics, use , , or the arrow keys
to select a topic. Then press to view the topic.
Note, too, that there are abbreviated, context-sensitive
help messages to assist you that appear in the lower portion
of the screen as you move the cursor around the different
fields on the screen.
Run
Pressing executes simulation of the monitoring program.
A continuously updated screen message informs the user of
the computer's progress. Simulations can be halted by pressing
any key. Power calculations are based on the number of iterations
completed before a key is pressed, or, if the simulation
is run to completion, the number of replications specified.
What is occurring during a simulation is best described
by example. Consider a single plot monitored once each year
over 10 years (see Figure 2, left column). A -5% annual
trend is occurring in counts on this plot, a trend that
you hope your monitoring program is able to detect. In the
first step, a -5% annual trend is extrapolated from the
mean initial count on this plot, whose value in this case
is 10 and whose standard deviation is 2. In Step 2, random
counts are generated each year throughout the survey period.
These random counts are drawn from a distribution whose
mean is equal to the deterministic projection for a particular
year (from Step 1) and whose variance you have provided.
In Step 3, the slope of the trend in the random counts is
determined, and whether the slope differs from zero is tested.
If the slope is different from zero, the ongoing trend established
in Step 1 was successfully detected in the time series of
random counts generated in Step 2. Steps 1 to 3 are subsequently
repeated many times (for as many iterations as you specify).
During some of these trials the ongoing trend may be detected,
and in others it may not. At the end of the simulation,
the power estimate for this trend represents the number
of trials in which the trend was successfully detected divided
by the total number of trials run.
The steps used to estimate power to detect trends in multiple
plot situations are similar to those used in the single
plot situation. For example, consider monitoring 3 plots
once each year over 10 consecutive years. Again, we will
model a -5% annual decline, with initial mean counts of
5, 10, and 15 on plots 1, 2, and 3, respectively, and equal
variances (standard deviations of 2) on all three plots
(see Figure 2, right column). During the first iteration
of the simulation in Step 1, the software projects from
the initial abundance on the first plot a deterministic,
-5%/year trend each year over the 10 year survey period.
It then generates a random count for each survey occasion
drawn from a distribution whose mean is equal to the deterministic
projection for that year and whose variance you specified.
A least-squares regression of the sample counts versus year
is subsequently performed to determine the plot trend. The
same process is repeated for the two remaining plots. The
trends (regression slopes) estimated are then averaged across
the 3 plots. Finally, the probability that the average slope
differed from zero is determined, and whether this probability
is less than or equal to the significance level declared
by the user is recorded. During subsequent iterations, a
new set of 3 plots is simulated in exactly the same manner.
After many such iterations, power of the monitoring program
is estimated as the proportion of iterations that detected
the trends projected in Step 1. This is a version of the
"route regression" approach to assessing trends in multiple
plot situations (see Sauer and Droege 1991).
A trend of zero is included merely to show that, with
adequate replication and sufficiently high initial counts
(and comparable weights and variances in multi-plot situations),
the probability of detecting this non-trend equals the significance
level (type I error rate) specified by the user.
Results
Pressing provides access to tabular and graphical
presentation of the simulation results. Depending on whether
you chose the Partial or Complete trend projection set,
the results screen presents power estimates for each of
the 11 or 21 trends simulated. The power estimate for each
trend equals the proportion of trials that each ongoing
trend was actually detected during the simulation. If trends
were detected every time the sample counts were projected,
then power estimates would equal 1. If they were never detected,
then power estimates would equal 0.
One should generally seek power estimates that exceed
0.80 (Cohen 1977). In other words, a monitoring program
whose power estimates exceeded 0.80 would detect trends,
should they occur, > 80% of the time. You will notice that
obtaining high power values for trends of lower magnitude
(1%, 2%, & 3%) is often difficult. Users will also note
that it is generally easier to detect increasing than decreasing
trends in sample counts. Also included in the results screen
is the total number of counts made during a single, complete
execution of your survey program. This value is included
to provide a simple index to monitoring effort and hence
monitoring cost.
Save a MONITOR File
Pressing enables you to save a set of input data
that defines a particular monitoring program. You are first
asked to provide the name of a data file. All the parameter
values currently active are then output to that file. This
file can later be read into the program through Load a MONITOR
File () to re-run the simulation. Note that this option
saves the simulation parameter values, not the simulation
results. To save simulation results, see Save Simulation
Results ().
Load a MONITOR File
Pressing lets you load a file of input data describing
a particular monitoring program. Note that loading a new
file replaces (erases) the existing set of inputs you are
working with, so you are first prompted as to whether you
really want to load a new file. If you do, the name of the
data file to load is requested, and then retrieval of the
parameter values stored in that file is attempted. If the
data file is not formatted correctly, or is not found, a
warning is given.
Save Simulation Results
Pressing lets you save results from a particular
simulation to an text file. You are prompted for the name
of the output file, as well as a one-line description of
the contents of the file, which is placed on the first line
of the file above the simulation results.
Go to DOS
By pressing the user can access the DOS environment
to search for files, delete files, use another program,
etc. You can either type a single DOS command, or press
to completely enter the DOS environment. If you
go to DOS, remember that to switch back to MONITOR, you
must type "exit" while in DOS. MONITOR uses relatively little
memory, which permits you to access other applications,
such as your word-processor to create a batch file, and
then return to MONITOR.
Run Batch File
By pressing you can run simulations in batch mode.
Batch mode permits you to process multiple input files and
automatically save the simulation results to output files.
In other words, you don't need to interact with the software
to process the files - it is done automatically for you.
All you do is provide, in a so-called "batch file", the
names of the input files to be processed. The main value
of batch processing is that you can run many, time-consuming
simulations in sequence without having to sit around and
wait for each one to reach completion. To run files in batch
mode, you first need to enter the appropriate inputs for
each MONITOR input file and save each file using (Save
a MONITOR file). Next you need to prepare a separate text
file (the "batch file") that contains the names of each
input file that you want to process. The name of each file
should be on a separate line in the batch file. For example,
the following contents of a batch file, if saved in ASCII
or text format, will run the three sample files provided:
bears
rails
jpulpits
Note that the batch file must be in ASCII or text format,
a format that virtually all word-processors and text editors
can save to.
When you press to Run Batch File you are first asked
the name of the batch file containing the names of the input
files that you want to process. Next, MONITOR looks for
the first input file listed in the batch file, reads the
input file into the software, runs the simulation based
on the parameters specified in the input file, and writes
the simulation results to an output file. MONITOR then moves
on to the second input file listed in the batch file, processes
it, outputs the results, and so on, until processing is
complete for all the input files listed in the batch file.
MONITOR automatically outputs the results of the simulation
to a file with the same name as the input file but with
the suffix ".out" attached. So if you have the three input
files "bears1", "bears2", and "bears3" listed in the batch
file, the simulation results will be output to "bears1.out",
"bears2.out", and "bears3.out", respectively. Note that
input files called "bears.1" and "bears.2" would both have
the same output file ("bears.out"), so be sure that you
input files are distinguishable from one another based on
characters that occur before the "." in the file name, not
just on characters that occur after the "." For this reason
"bears1" and "bears2" are preferable to "bears.1" and "bears.2"
as input file names.
There is no limit to the number of files that can be processed
in batch mode. You will find that processing input files
in batch mode is a more efficient use of your time than
running those same files interactively. Batch mode also
makes obtaining power estimates for complicated/extensive
monitoring programs easier because you can run simulations
in batch mode overnight or during some other period when
your computer is free and you are otherwise occupied.
Converter
Converter is a simple sub-program that permits you to
convert a long-term trend to a trend per unit time, which
is the currency of MONITOR. Many users are interested in
estimating power to detect, for example, a 5% trend in a
population over 10 years. Converter simply translates that
trend for you into a per annum trend. For more information,
see the context-sensitive help section in the program.
Quit
Pressing lets you quit MONITOR and return to DOS.
EXAMPLES
Single Plot - Black Bears
The following is an example of an application of MONITOR
to guide the design of a monitoring program consisting of
a single "plot" monitored over time. The application focuses
on a population of Himalayan black bears (Selenarctos thibetanus)
in the Dachigam Wildlife Sanctuary, Kashmir, India. The
bears are a conspicuous inhabitant of the sanctuary, but
little is known of the population's status or trends. Initiation
of a small-scale monitoring program for this population
would be useful, given the multitude of threats now facing
the population.
Throughout most of the year, black bears in Dachigam are
scattered throughout the sanctuary and are very difficult
to count. At certain periods of the year, however, during
the peak fruiting period for local mast-bearing trees, most
bears in the sanctuary travel to a large, central grove
of masting trees to forage. From a particular observation
point, it is possible to get repeatable counts of the number
of bears travelling to and from the grove on any given day.
Not all the bears in the sanctuary visit the grove, and
some are occasionally double counted, so the daily counts
from the observation point represent an index of the bear
population's size, not a true census of the population.
During a single season, 15 separate, day-long counts of
the bears were made, which yielded a average of 15.6 bears
observed per day and an accompanying standard deviation
of 3.6 bears. The following question arose among individuals
concerned about the bear population's status: would allocating
the time of one park warden to count bears on 3 different
days during peak of masting periods each season produce
data useful for monitoring Dachigam's bear population? Specifically,
would this intensity of monitoring effort exerted over a
10 year period be sufficient to detect annual trends (positive
and negative) of at least 3% in the bear population at a
probability of > 0.90?
The inputs for MONITOR are fairly straightforward in this
case. Only a single plot is being monitored, so Number of
Plots is one. Surveys would be conducted every year for
10 years, so the Number of Surveys would be 10, and the
survey occasions would be 0, 1, 2, ..., 7, 8, 9. [Note that
in all simulations, projections start from time 0, not from
time 1]. The guard would devote 3 days per year (= 3 counts
per survey occasion because each year represents one survey
occasion) to day-long bear counts, so Counts/plot/survey
is three. Under Rounding, random counts should be modelled
as whole numbers because integer, not decimal, numbers of
bears are counted each day. A significance of level of 0.05
for trend detection is chosen for this analysis as a compromise
between using an overly liberal value (e.g., 0.1) and an
overly stringent one (e.g., 0.001). These inputs have been
included in the sample file "BEARS".
With Replications set at 500 (to ensure repeatable results)
it is apparent that conducting three counts each year is
inadequate to detect 3% increases or decreases in the bear
population should they occur (see Table 2). With three counts
per year, the probability of detecting a 3% population increase,
when it was actually occurring in the sample counts, was
just 0.65. The probability of detecting a 3% decline when
it was actually occurring in the counts was even lower (0.42).
How can this monitoring program be improved to achieve
the probability desired (> 0.90) for detecting 3% or greater
annual changes in the bear population? Because the bears
can only be counted from one, particular observation point,
the number of "plots" is unfortunately limited to one. With
no great increase in monitoring effort, however, more days
can be devoted to counting bears each year. Increasing the
Counts/plot/year by just two (from three to five), while
leaving all other elements of the monitoring program unchanged,
nearly achieves the monitoring goals for population increases
(power estimate = 0.87, see Table 2), but still fails to
detect 3% population declines with sufficient confidence
(0.61). Finally, increasing the monitoring intensity to
10 counts per year yields a power estimate nearly adequate
for detecting 3% or greater declines (> 0.88) and more than
adequate for detecting 3% of greater population increases
(> 0.99, Table 2).
Multiple Plots - Jack-in-the-pulpits
This example focuses on the jack-in-the-pulpit (Arisaema
triphyllum), a perennial, understory herb of moist forests
in eastern North America. A monitoring program is being
organized for a dense population of jack-in-the-pulpits
isolated within an urban woodlot. The site is set to be
disturbed by construction activities during the first season
of monitoring and researchers hope to monitor for potential
changes in the population in response to this activity.
Only 5 years of funding are available, however, to support
the monitoring program. To examine the response of the jack-in-the-pulpit
population to the disturbance, the minimum number of plots
required to detect various trends in the population, should
they occur, needs to be determined. The primary limitation
here is the short duration of the monitoring program. Over
five years with varying numbers of plots monitored, what
sorts of trends in this population might be reasonably expected
to be detected?
Cursory survey data gathered from this population indicate
that a typical 1-m2 square plot averages about 5.7 mature
plants. Another study of a nearby population of jack-in-the-pulpits
suggests that variation in the number of mature plants occurring
on a given plot over time, measured in terms of the standard
deviation in plants per plot, is about 40.3% of the average
density. Thus, assuming these values are typical of jack-in-the-pulpit
populations in the area, plant densities on the sample plots
in the monitored population, with an average of 5.7 mature
plants per plot, vary over time with a standard deviation
of about 2.3 (that is, 40.3% of 5.7).
To assess the number of plots needed to detect trends
in this population over the 5-year monitoring period, the
following values were input into MONITOR. Counts/plot/year
was set at 1, because the population would be monitored
only once a year. Number of Surveys was set to 5, and Survey
Occasions was set at 0, 1, 2, 3, and 4, because the population
would be sampled once a year every year for five years.
There is no reason to expect that population trends would
be exponential, so the "linear" option on Trend Type was
selected. A standard two-tailed test was chosen under Number
of Tails with a Significance Level of 0.05. Replications
were set at 500, and the "partial" option was chosen in
the Trend Coverage field so that power to detect a subset
of the possible trends could be assessed. The primary parameter
varied in this examination was Number of Plots, which was
varied over the course of 10 separate simulations from 10
plots to 100 plots by units of 10 plots.
Finally, simulations were run in batch mode. To do this,
first a separate input file was created for each variation
on Number of Plots examined (for example, file "JPlots20"
with 20 plots, "JPlots30" with 30 plots, etc.). Next, a
batch file containing the name of each input file name was
created with a word-processor. The Run Batch File command
was then given and the simulation proceeded over the course
of 20 minutes or so.
The results are somewhat striking (Table 3), in so far
as they point to the difficultly of detecting all but the
steepest population trends given the short duration of this
monitoring program. For example, note that even with 80
plots monitored, the probability of detecting a -5% annual
trend barely reaches an acceptable level (0.89). Even the
maximum number of plots that can be monitored (100) offers
little hope of detecting more subtle trends in the population,
should they occur. The researchers should probably ponder
whether it is worth undertaking this monitoring program
given its weak statistical power under even its most optimistic
design. Monitoring duration is simply too short to detect
any subtle response in the jack-in-the-pulpit population
to the disturbance. One further option to explore with MONITOR
would be the effects of changing the size and shape of sample
plots to increase the numbers of plants/plot and reduce
the temporal variance in plants/plot.
Multiple Plots - Virginia Rails
Secretive waterbirds, such as grebes, rails, and bitterns,
are undersampled by all large-scale, call-count surveys
used to monitor trends of bird populations in North America.
This recognition has prompted the development of call-response
surveys, which involve broadcast of tape-recorded calls
from fixed survey points in wetlands, to elicit responses
from waterbirds. Typically surveys are organized along so-called
waterbird "mini- routes", which may consist of 10 fixed
survey points distributed among a single large, or several
small wetlands. The number of responses to broadcast calls
along each miniroute provides the index of abundance used
in monitoring population trends. If a "miniroute" survey
program is initiated to monitor regional waterbird populations,
however, some assurance is needed that a logistically feasible
number of miniroutes surveyed will have a relative high
likelihood of detecting trends in the population, should
they occur.
This example focuses on the Virginia rail (Rallus limicola),
a small waterbird that typically inhabits dense, emergent
vegetation. Virginia rails were detected on 15 waterbird
miniroutes surveyed in Maine during 1989-1990. These miniroutes
were each surveyed six times during the two years of study
to determine how variable Virginia rail responses were along
each miniroute. Average numbers of rails encountered per
broadcast station on each miniroute ranged from 0.13 to
1.10, and the standard deviations in responses on each miniroute
ranged from 0.05 to 0.46 (Table 4). Note that the variance
estimates used here are for variation in counts over time
on the same miniroute, and not spatial variation in counts
among miniroutes.
Assuming that these data are typical, is there a sufficiently
high probability of detecting positive and negative annual
trends of at least 3% over 10 years of monitoring along
these 15 miniroutes? How many times per year should the
miniroutes be surveyed? Finally, can miniroutes be monitored
every other year, thereby reducing monitoring costs, with
no great sacrifice in power to detect trends?
To address these questions in MONITOR, 15 was entered
in the Number of Plots field and data for the mean and variance
in counts on each of the 15 miniroutes listed in Table 4
were input in the Initial Values field. Surveys were run
every year over 10 years, so Number of Surveys was set at
10, and Survey Occasions were set at 0, 1, 2, ..., 9. Note
that response rates are decimal values (responses obtained
per miniroute), so Rounding was set to "decimal". All other
default settings were retained (see sample file "rails").
Replications was set at 100, which you will notice, produced
"noiser" results than the earlier examples that used 500
replications.
Power estimates based on 250 replications indicate that
achieving the goals of the monitoring program (specifically,
a > 90% chance of detecting annual changes of >3% along
15 waterbird miniroutes) are unlikely with single, annual
surveys along these 15 miniroutes (Table 5, column 1). Even
if surveys are conducted twice annually on these miniroutes,
the likelihood of detecting 3% annual trends in the population
is still unacceptably low (Table 5, column 2), although
this situation would be adequate for detecting annual changes
of >5%. With three surveys conducted per miniroute each
year, +3% annual changes could be reliably detected, although
-3% trends are still unacceptably likely to go undetected
(Table 5, Column 3).
Power estimates could be raised substantially by weighting
the contribution of each plot to the overall trend by the
magnitude of counts on each plot (Table 5, Column 4). This
was done by simply substituting a value under Plot Weight
equal to each plot's mean initial count. This often is advisable
in order that population trends on the miniroutes with the
largest rail populations can exert a proportionately greater
influence on the trend estimates.
Finally, to examine the effect of conducting surveys biennially,
rather than annually, Number of Surveys was changed to 5
and Survey Occasions was reset to 0, 2, 4, 6, and 8, while
other inputs were left unchanged. Examination of the power
estimates associated with biennial monitoring (Table 5,
Column 5) indicates that biennial monitoring results in
a substantial drop in power to detect trends, and is therefore
inadvisable.
Further simulations in MONITOR could be used to explore
a variety of possibilities for structuring this monitoring
program, for example, increasing the number of miniroutes
monitored, excluding certain plots and retaining others,
altering the significance levels for trends detection, etc.
CALCULATING TEMPORAL VARIANCES IN SAMPLE COUNTS
An important input for MONITOR is the temporal variance
in counts on sample plots. MONITOR uses the standard deviation
in counts as the variance estimate. The best way to derive
this parameter is through a pilot study or from existing
monitoring programs dealing with those species of concern
to you. If you conduct a pilot study, the problem often
arises of how to estimate the temporal variance in counts
from data collected on a few plots over a short period of
time. Pilot data for estimating the count variances are
usually in short supply, and its useful to pool all the
counts together from different plots to estimate the standard
deviation in counts. However, because different plots typically
have different mean counts (some plots are in good habitat
and hence have high mean counts, others are in poorer habitat
and yield lower mean counts), you should be wary of simply
pooling the counts together to calculate the standard deviation.
Doing so would conflate the two sources of variation in
counts, that is, spatial variation owing to habitat differences
between plots and the temporal variation that occurs on
those plots due to population fluctuations and random error
in your counting methodology. To avoid this problem, one
needs to remove the spatial component of count variation
from your data so that the resulting standard deviation
will reflect mainly the temporal component. A simple way
to do this involves calculating the mean count for each
plot, substracting the appropriate mean from the sample
counts made on each plot, and then pooling all the "de-meaned"
counts together to calculate the standard deviation in counts.
By "de- meaning" the counts and pooling them togther you
remove the spatial component of count variation caused by
habitat differences among plots. The resulting standard
deviation pooled across all data values then reflects predominantly
the temporal component of count variation.
SOME SAMPLE VARIANCES
Here are some examples of count variances from the literature.
It would be useful to compile are list of such variances
for many species to assist users in designing their monitoring
programs. Feel free to send examples from the species you
are dealing with to include in future versions of MONITOR.
Note that the variances are presented here as the standard
deviation as a proportion of the mean count:
sea otter, Enhydra lutris, central California, 0.13 (T.
Gerrodette, Ecology 68:1368).
various whales, world-wide, 0.49 (30 data sets, de la
Mare 1984, Rep. Int. Whal. Commn. 34:657).
Pacific Walrus (Odobenus rosmarus divergens), 0.60 (Hills
and Gilbert, Trans. 59th No. Am. Wildl. & Natur. Resour.
Conf. 1995:201-210).
Broad-winged Hawk, 0.35-1.11, Northern Harrier, 0.24-0.46,
Peregrine falcon, 0.44-0.64, various North American sites
(Titus et al., USFWS Biol. Rep. 90(1):108).
American bittern, 1.67, Sora 0.78, Virginia rail 0.90,
Least Bittern 1.25, Pied-billed Grebe 1.20, all central
Maine (call-response surveys, J. P. Gibbs unpubl. data).
Northern redback salamander, 0.69, New Haven County, Connecticut
(data from 25 pit-fall traps monitored daily over a 3 month
period in 1994 (from J. P. Gibbs, 1995, Ph.D. dissertation,
Yale University).
INSTALLATION
To install and run MONITOR, first make a copy of the MONITOR
distribution disk. To install MONITOR on a fixed ("hard")
disk drive with the drive letter C:, place the MONITOR disk
in drive A:, and type the following series of commands:
c: md \monitor cd \monitor copy a:\*.* c:
This will copy the monitor software (MONITOR.EXE") and the
three sample files ("BEARS", "JPULPITS", and "RAILS"). If
you will run MONITOR from a floppy disk, then put the MONITOR
disk in drive A: and make it the default drive. MONITOR can
be invoked on either the floppy disk or the fixed disk by
entering the command "monitor."
MONITOR assumes that you are using an IBM PC, AT, PS/2,
or true compatible running DOS 2.0 or higher. It requires
215K of RAM. MONITOR automatically detects the monitor connected
to your microcomputer and conducts all screen inputs and
outputs in CRT mode, thereby increasing the speed and flexibility
of screen operations. MONITOR also automatically takes advantage
of a math coprocessor if one is present. These simulations
run substantially faster on microcomputers with math coprocessors.
If you are contemplating evaluating situations with > 25
plots, use of a computer with a math coprocessor installed
is highly recommended. While MONITOR provides no means of
printing results directly from the program, results can
be output to a text file using and then printed using
any word processing program or text editor.
LITERATURE
Cohen, J. 1988. Statistical power analysis for the behavioral
sciences. Academic Press, New York, NY. 474 pp.
de la Mare, W. K. 1984. On the power of catch per unit
effort series to detect declines in whale stocks. Rep. Int.
Whal. Commn. 34:655-61
Edwards, E. F., and P. C. Perkins. 1992. Power to detect
linear trends in dolphin abundance: estimates from tuna-vessel
observer data, 1975-89. Fishery Bulletin 90:625-631.
Gerrodette, T. 1987. A power analysis for detecting trends.
Ecology 68:1364-1372.
Gibbs, J. P., and S. M. Melvin. 1993. Call-response surveys
for monitoring breeding waterbirds. Journal of Wildlife
Management 57:27-34.
Peterman, R. M., and M. J. Bradford. 1987. Statistical
power of trends in fish abundance. Can. J. Fish. Aquat.
Sci. 44:1879-1889.
Sauer, J. R., and S. Droege, editors. 1990. Survey designs
and statistical methods for the estimation of avian population
trends. U.S. Fish and Wildlife Service, Biol. Rep. 90(1).
166 pp.
Taylor, B. L., and T. Gerrodette. 1993. The uses of statistical
power in conservation biology: the vaquita and northern
spotted owl. Conservation Biology 7:489-500.
Send comments or questions to:
James P.Gibbs
Department of Biology, 419 OML
P.O. Box 208140
Yale University
New Haven, Connecticut 06520-8104, USA
or e-mail to:JamesGibbs@aol.com
|