FinalDispositionAnalysis
From PTAGISWiki
Overview: Final Disposition Analyzer (FDA) Doug Clough, Synergetics Ver 1.1, 5 Jun 98 Introduction This document presents an overview of the PTAGIS Final Disposition Analyzer (FDA). Underlying database tables, as well as automated and manual processes, are described in relation to existing PTAGIS systems. Essential features of the mechanism for recording a PIT-tag's "final dispositon" are detailed. Relationship with Existing Systems Two categories of information give insight on the "final disposition" of each PIT-tag tracked by the PTAGIS project: (a) Electronically collected interrogation data, obtained primarily from Juvenile Fish Bypass Facilities at dams along the Snake and Columbia Rivers, and (b) Manually collected recapture and mortality data, and facilities operation data, provided by personnel in the field.
As represented by Item 1 in Fig 1 , the PTAGIS Interrogation Data Loader (IDL) retrieves electronically collected PIT-tag interrogation responses from the detection facilities, and stores them in tables within the PTAGIS3 database. Raw data are placed in the obs_data table; other tables store summary information to facilitate report generation. In particular, the obs_site table records information on the earliest and the most recent electronic "sighting" of each tag.
As represented by Items 2 and 3 in the figure, the PTAGIS Field Data Loader (FDL) retrieves manually constructed files listing the PIT-tag id's of deceased fish, and of live fish which have been recaptured and returned to the river. Recapture and mortality data are stored in the recap_data and mort_data tables, respectively.
Item 4 in the figure represents the FDL Disposition Modification Interface (DMI). DMI will provide mechanisms by which information concerning abnormal operating conditions at the detection facilities may be incorporated to augment the electronic records. Occasionally, for example, flow control gates are manually configured to divert all fish back to the river. Depending on the resulting flow path through the facility, tagged fish might still be detected in the transport raceways, giving a false indication that the fish had been transported.
Accordingly, data stored in the event_calendar table may be used to annotate the disp_history records of tags known to have passed through a facility during a period when unusual operating conditions prevented accurate electronic detection of the exit path. Recording Final Dispostion of a PIT-Tag Basically, the job of the Final Disposition Analyzer is twofold: (1) to translate the cryptic, low-level representation of each tag's most recent electronic sighting -- contained in obs_site -- into a person-friendly indication of the manner in which the tag (i.e. "fish") departed the facility: either being returned to the river, or being artificially transported by truck or barge. (2) to augment the electronic record with input provided by field personnel.
As was hinted above, the disp_history table is the focal point of this effort. disp_history records are inserted, updated, and deleted in response to "events" generated by FDA software mechanisms.
In the simplest case, a given PIT-tag has just one disp_history record, inserted in response to an FDA_ObsSite event. A row inserted by an FDA_ObsSite event is never deleted; however, its contents may be updated by subsequent FDA_ObsSite or FDA_DispMod events. The "disp_code" attribute of a disp_history record indicates the final disposition of the associated PIT-tag. In response to FDA_ObsSite events, disp_code may take on values of "UNKN", "RIVER", or "TRANS", as shown in Fig 2 , which presents a state-transition model for the disp_code attribute of disp_history.
Fig 2 shows that disp_code can change back and forth between "UNKN" and "RIVER" in response to FDA_ObsSite events. However, once disp_code is set to "TRANS" -- indicating that the fish has been transported -- further state-changes will not occur without manual intervention. More on that in a moment.
First, please note the circled "A" within the "activity compartment" of the "UNKN" state, in Fig 2. This denotes special processing to be performed when disp_code enters the "UNKN" state. Specifically, referring to Fig 3 , a check must be made to detect and overcome the the effects of "time-reference drift". With present-day hardware, the clocks in all controllers at a site are synchronized. However, in years past, the clocks were not synchronized. It was possible for discrepancies to arise, of great enough magnitude that a tag's time-stamps from an up-stream monitor could be "later" than its time-stamps from a down- stream monitor in the same facility.
Although the obs_site table records the "last" coil at which a given tag was detected at each site, time-stamp anomalies have occasionally resulted in a coil from an "entry" or "internal" monitor being listed, when in fact the tag was detected at one of the exit monitors. Original interrogation data are stored in the obs_data table; the relative locations of all a site's coils, in water-flow sequence, may be retrieved from the site_coil and monitor tables. As shown in Fig 3, this permits retrieval of the "most down-stream sighting" of a given PIT-tag at any site. Accordingly, whenever a a tag's disp_code enters the "UNKN" state, the original obs_data records are consulted. If the "most down-stream sighting" was actually at an exit monitor, the state will be changed from "UNKN" to "RIVER" or "TRANS", as appropriate.
This completes the discussion of disp_code state-changes as a result of FDA_ObsSite events. However, as mentioned above, other states can be achieved through manual intervention, in response to FDA_DispMod events.
As shown, in Fig 4 ,FDA_DispMod events, generated by the FDA Disposition Modification Interface, can replace a disp_code value of "TRANS" (or any other possible disp_code value) with "RIVER?", "TRANS?", or "MORT?", while associating the disp_history record with the event_calendar record which supports or explains this action. If the disp_code value is changed from "TRANS" to anything else, the disp_history record will once again change state in response to FDA_ObsSite events.
If further FDA_ObsSite events are received for a given PIT-tag while its most recent "non-MORT", "non-RECAP" disp_history record is in the "TRANS" state, a new disp_history record will be inserted. This will become the PIT-tag's "active" disp_history record; subsequent FDA_ObsSite events will cause state-changes for the "active" record, but will have no effect on its predecessor(s).
In the discussion so far, we have considered disp_history records generated as a consequence of electronically gathered data. In the most simple case, this is would be the whole story. However, more complex scenarios are not unusual.
As was shown in Fig 1, field personnel manually assemble mortality and recapture files, which are processed by the PTAGIS Field Data Loader. FDA software generates FDA_Mort and FDA_Recap events. For each row inserted into the mort_data or recap_data table, a row with corresponding "disp_code" value is inserted into the disp_history table.
Fig 4 shows that "MORT" and "RECAP" rows undergo no state changes. They are never updated, although they are deleted if the corresponding mort_data or recap_data record is deleted. Reporting of Final Disposition Summarizing the points made above, a given PIT-tag may have several disp_history records: one or more records generated by FDA_ObsSite events, one or more records generated by FDA_Recap events, and one or more -- considering possible errors in the field -- records generated by FDA_Mort events.
Based on the contents of the disp_history table, the FDA Report Generator will assemble both electronically gathered and manually gathered data to provide the most complete indication possible for the final disposition -- "RIVER", "TRANS", "MORT" -- of the requested tag or tags.
