Update Search Status History Planning Disk Chores Printer Other

The planning and management aids are located here. This is where you can

create a Mattson consensus,
review lost person behavior characteristics,
see the latest initial POAs,
perform a "what if" analysis,
conduct a hypothetical search,
get advice on the allocation of resources,
experiment with cumulative PODs in 3 different ways, and,
get advice on targetted PODs,
read various documents of interest to SAR personnel.

In creating the consensus, you will be asked for seven things.

1.	Whether the current drive and directory is where all the files are to be saved. If not, go to the Disk Chores menu, select the drive and directory you want, and then come back. Each search should be kept either on its own floppy, or in its own subdirectory on a hard drive.
2.	The name of the search. This is for cosmetic and printing purposes only. It can be changed later in the Other menu, under Name Change. Something like "THE SMITH SEARCH, Case 123456" might be appropriate.
3.	The name of the file (no extension) to use for this part of the search. Something like SMITH00 might be appropriate. If the name you choose ends with a number, then, when you later need a new filename, the final number will automatically be bumped by one. Thus, in our example it would automatically select the filename SMITH01.
4.	The number of segments (up to a maximum of 99) IN the search area, EXCLUDING the R.O.W.
5.	The number of respondents (experts) being used for the consensus.
6.	For each expert, the initial POAs for every search segment and for the R.O.W. Each expert can do this in one of two completely different ways: the standard numerical method used for the Mattson consensus, or a new, experimental, method developed by Dan O'Connor, explained below.
7.	Whether you want to enter the acreage of each of the search segments. If you respond "yes", then you will be expected to supply the acreages.

If, under 6 above, the standard numerical method is used then each initial POA must be given as a percentage which, including the R.O.W., must total 100 for each expert. The program checks this. If, however, O'Connor's method is used then each initial POA is given as a letter from A (if very likely) to I (if very unlikely). The computer converts these relative values to numerical values, and then displays them. The expert doesn't have to worry about totalling 100 - the computer does that.

O'Connor's method is as follows.
For each segment the expert selects a letter from A to I according to the table:

Then each letter that the expert has used is assigned a numerical value according to the scheme

Now the expert's total is obtained, and the ratio of the expert's numerically assigned value to the expert's total is that expert's POA for that segment.

An example may clear up any confusion. Imagine that an expert assigns a G to segment 1, an A to segment 2, and a G to the R.O.W. The lowest letter is a G, so we use the third line of the above table. The expert's total will be 9 (7 for the A, and 1 for each G). This expert's POA for segment 1 is 1/9, for segment 2 is 7/9, and for the R.O.W. is 1/9.

This option can be used in two different ways.

1.	To see now where you will be at the end of the next operational period, if the resources currently deployed are unsuccessful. This could be used to plan future operational periods.
2.	To test various scenarios to see which one generates the highest POA for the R.O.W. This could be used to optimize the allocation of resources. For a discussion of this go to the Resource Allocation Advice option.

Because the same resource may have a different POD for each segment, the computer must check every possible case to find the optimum scenario based on this principle. Since this is a VERY lengthy process, we have arbitrarily limited this option. We will NOT perform the analysis if the number of search segments exceeds 10, or the number of resources exceeds 6. Even then, with 10 search segments and 6 resources, there will be a million cases to check. This will take about 2 hours on a 386 machine, 10 hours on an XT machine, and 17 minutes on an AT equipped with an 80287 numeric coprocessor.
Before performing any analysis greater than 1,000 cases, the program checks to see how long your machine takes for that number of cases and then estimates the time needed for your actual scenario.
A reasonable rule of thumb is: "When all else is equal, put the most efficient resource in the segment with the highest POA."

1.	Different teams searching the same segment. This allows you to see how a cumulative POD builds up if different teams search the same segment. After the PODs for each team have been entered the cumulative POD for the segment is displayed. A maximum of 10 teams can be handled this way.
2.	The same team searching the same segment repeatedly, where successive passes are independent of the previous passes. This allows you to see how a cumulative POD builds up if the same team searches the same segment again, and successive passes are independent. An initial POD (the default is zero) and the POD of the current search team are requested. By pressing the RETURN key, the cumulative POD for successive searches by the same team is then displayed, up to a maximum of 30 searches. This assumes that the searches are independent, i.e. the search team POD is independent of time, so that for example, searchers are not influenced by lack of success the previous times, searchers search in a different way from previous times, etc.
3.	The same team searching the same segment repeatedly, where successive passes are dependent on the previous passes. This allows you to see how a cumulative POD builds up if the same team searches the same segment again, and successive passes are dependent. An initial POD (the default is zero) and the POD of the current search team are requested. The factor by which the team's performance degrades between successive searches is also required (0% means no degradation, 100% means complete degradation). By pressing the RETURN key, the cumulative POD for successive searches by the same team is then displayed, up to a maximum of 30 searches. Factors which might cause a team to experience a degradation in this way are searcher fatigue, searcher boredom, searcher prejudice, etc.

These options are for informational and hypothetical scenarios only. The numbers generated here have no effect on the current search.