TABLE OF CONTENTS:
The GCN system has been modified to incorporate the distribution of the Swift-BAT "sub_sub_threshold" and "known source" notice types. BAT routinely makes images over various integration times and then scans those images looking for peaks in the image domain. These images are requested by two different activities within BAT: (a) when a rate trigger has been satisfied (and needs an image check), and (b) every 64-sec, 320-sec, and full observation (1-43 min) (aka the BAT image_trigger). When peaks are found, they are compared to the on-board catalog. When there is a location match, they are called 'known' sources. When there is no match, they are called unknown sources. The significance of the peak in the image can be above threshold (>6.5 sigma, aka a "burst" or "transient) or below the threshold (aka a "failed" trigger, ie these Sub_Sub_Threshold events).
The table below shows the naming convention for the four scenarios of being above/below the threshold and matching/not-matching sources in the on-board catalog.
SIGNIF | MATCH NO-MATCH
-------+-------------------------------
<6.5 | Known Sub_Sub_Threshold
>6.5 | Known Burst
So these two new Notice types are taking the "failed" peaks
and turning them into a distributed product (for both the failed rate triggers
and for the failed peaks in the image trigger images). And while we are at it,
Swift is also making available the known-source detections from all those images.
There is no distinction above/below threshold for known-source detections;
if the position of the peak in the image matches the location of a known-source
then it is put into the Known notice type.
The Sub_Sub_Threshold notices can be used:
1) by robotic telescopes to take data on these locations
on the remote chance that an optical counterpart can be detected.
2) to correlate with other existing databases of "trigger" and "event"
information from other instruments (ground- & space-based, above & below their thresholds).
It is hard to understand a use-case scenario for the Known notices,
but they were processed into GCN Notices just in case somebody can make use of them
(it was only a small additional effort while the Sub_Sub's were being implemented).
There will be about 1000 Sub_Sub_Threshold notices per day and about 1000 Known source notices per day. Since they show up at GCN in groups of ~150 after each telemetry downlink pass, they are distributed with 2-sec intervals between each socket packet to limit the load impact on the GCN computer and on the recipients.
Both of these types come from automated ground-based processing after every telemetry downlink, so the time delays will be 1-8 hours. (These failed triggers and image-domain scans are not sent down the real-time TDRSS channel -- too much bandwidth would be used.)
The location uncertainties are in the 1-4 arcmin range (radius, 90% containment; the range depends on significance), but the Error field in the Notice will always be listed as 4 arcmin (just like the current above-threshold "Burst" notices have a fixed 3-arcmin location uncertainty).
The trigger time listed in these notices can be off by +/- 320 msec for events that have a trigger integration duration less than 64 msec. This has to do with the way that the flight software is optimized for execution speed for evaluating trigger criteria. There is an additional +/- 20 msec of uncertainty in applying the UT Correction Factor. Note that both of these uncertainties can be reduced by off-line/ground processing, but for these automated notices, these large uncertainties exist. This is important if you are using these SubSub triggers for temporal correlations with other data sets. You need to start with your temporal acceptance window be at least +/- 340 msec, then if you get a correlation, it can be refined by using the ground-processed version of that trigger.
The range in significances for the Sub_Sub_Threshold goes from 3.8 sigma
to 6.5 sigma. The lower limit is established by BAT flight software;
the s/w can not be chasing after 100's of 3-sigma fluctuations in the images.
The upper limit is established by what has been previously defined as a successful
trigger even, ie a "burst" (or other hard x-ray transient).
The histogram on the left shows the detection significances (units are sigma, 0-8) for ~8 a day's worth of peaks in the image domain (total count = 8689) that did not match anything in the on-board catalog. The shape of this distribution is determied by the exponential shape on the low side due to the fllight software-applied thereshold at ~4.3 sigma and the exponential shape of (approximately) guassian noise on the high side. There is a small number of events with significances greater than 6.5 sigma; these are real GRB detections. The histogram on the right shows the detection significance (units are sigma, 0-40) of peaks in the image domain (total count = 8883) that matched sources in the on-board catalog. The distribution goes below the nominal 6.5-sigma cut applied by the flight s/w because (a) the 6.5 cut is applied to the first step (by FFT) in peak significance determination, but the step-2 signifiance (back-project) is plotted, and (b) sometimes a random noise fluctuation matches the location of a source in the catalog. (The peak around 20-sigma is due to the Crab.)
Because the threshold have been lowered to 3.8 sigma, the probability that a given Sub_Sub_Threshold 'peak' is a real astrophysical source is very low. The real above-threshold events (>6.5 sigma) are included in this stream (ie one in 2or3 thousand notices) and their confidence level is >99%. For the Known notices, the confidence level is be very high (>99%).
Given the semi-real-time nature of the data stream used to extract these events, the data set is not complete and there are duplications. About 1-2% are missing of both the Sub_Sub's and the Known's. And there are about 5-10% duplications. (A more complete data set can be obtained by using the ground-processed Image_Report FITS files. If there is sufficient interest, this improved data set (ie 100% complete and no duplicates) can be implemented to produce "processed" versions of these "raw" Sub_Sub and Known notices. There would be an additional hour delay using this data product.)
WHO CAN RECEIVE THESE NOTICE TYPES
These two notice types are restricted to socket-based recipients only; they are NOT available to email-based recipients. This is because of the sizable load-factor emailing a large number of these notices to a (potentially) large number of recipients. Only robotic telescopes can make use of these in an automated process, and any human-based activity would have time delays comparable to the 1-8 hour built-in delay. If humans want to do correlative activities, they can (a) pull the archived copies, or (b) they can request a socket-based entry (say using socket_demo for the GCN-original 160-byte binary packet format, or xml_socket_demo or voevent_client_demo for the VOEvent XML messages.
All the normal GCN filtering functions are applicable, but given the special nature of these two Notices types, the only functions that are valid are: type, sky location (celestial, galactic, & ecliptic coord systems), location uncertainty, intensity, significance, time-of-day window.
These GCN/Sift_BAT_Sub_Sub_Threshold and _Known Notices are archived on the GCN webpage:
Sub_Sub/Known Archive page.
They will be bundled into daily files and posted shortly after every UT midnight.
Given the variations of telemtry downlinks, each file will contain 18 to 30 hours
of Notices. This single archive page contains links for both types on each day.
The columns in the archive files (pages) are:
See swift_sub_sub_col_labels.txt
More information about Swift in general can be found at: Swift.
NOT TO BE CONFUSED WITH BAT_SUB_THRESHOLD NOTICE TYPE
This new "sub_sub_threshold" type should not be confused with the "sub_threshold" type (ie only one "sub" in the name). The Sub_Threshold type was introduced a few years back when Swift was attempting to dig a little deeper into distribution of events in Swift-BAT. Back then, an event above 5.6 sigma was allowed to cause Swift to slew to the location so that the XRT and UVOT could make the same follow-up observations they routinely do for the >6.5 sigma triggers. A Sub_Threshold that had an XRT source, got elevated to a normal BAT_POSITION notice and all the standard notice types were created and available for distribution. A Sub_Threshold that did not have an XRT source were just available as the Sub_Threshold series to thse recipients that requested that series. The time delay for this "sub" series was 5-20 minutes. That experiment did not work very well and was discontinued in Swift operations (and therefore not available in the GCN Notice pool). These new Sub_Sub_Threshold (and Known's) are different in that (a) the threshold has been lowered even more to ~3.8 sigma, and (b) they are not real-time (hours instead of minutes).
Each Sub_Sub_Threshold and Known Notice contains the following fields:
NOTICE_TYPE [=140or141]
REF_NUM
RA [deg, J2000]
DEC [deg, J2000]
ERROR [deg]
THETA,PHI within the BAT FoV [deg]
INTENSITY [image_cnts/sec]
SIGNIFICANCE [sigma]
IMAGE_INTEGRATION_TIME [sec]
EVENT_DATE [TJD]
EVENT_TIME [SOD]
SOLN_STATUS [flag_bits]
MISC [flag_bits]
CATALOG_NUMBER (only for the Known's)
The details of the socket packet contents can be found at:
socket packet reference doc.