Clearing House for Ecology Software Home
Find the software you need
By Subject
Density Estimation
Bioacoustics
Educational
Home Range
Populations
Radio Telemetry
Habitat
General Statisticss
Software from texts
By Operating System
Windows
Mcintosh
Program Language Code
Radio Telemetry
Density Estimation
Educational
Home Range
Populations

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

Copyright ©2004 Illinois Natural History Survey. All rights Reserved.