Tomoe Note 009: Results of transient search on eight nights

Michael Richmond
Mar 15, 2017

Executive Summary

I searched through data from all 8 chips during the entire night runs of eight nights, between 20160315 and 20160414. Using one particular set of rules and parameters, I calculated the "control times" for the images, and searched for transients with durations of 1.5 - 10 seconds. After examining candidates by eye, I found no real transients, but did notice one moving object.

Please read Tech Note 008 for details on some steps below, as the search method was the same.


Processing the data

I followed the methods described in earlier Tech Notes to process the data, starting with the raw "composite" FITS files, and ending with calibrated lists of stars. Using the machine pmdata, it takes very roughly 24 hours to process completely one night's data from 8 chips.

Once the data has been processed into the calibrated star lists and other files, it can be searched for transients within about 10 minutes; it takes another 10-20 minutes to check the resulting candidates by eye. I have written scripts to facilitate all these steps, including (as you will see in links below) creating tables with the properties and images of each candidate.

Please remember that the methods I am using explicitly will NOT detect single-frame events. In order to find such very brief flashes, one would have to write a new piece of software which would start with the calibrated starlists from each individual image and look through them. I have not done that yet.


Control times

In order to place limits on the rate of transient objects, one needs to know the combination of area and time covered by a search. I have chosen to use the units:



   "control time"  =  (area in square degrees) * (time in seconds)

Thus, an area of 1 square degree, monitored continuously for one hour, would yield a "control time" of 3600 sq.deg.*sec.

A critical factor in these calculations is the limiting faintness, which describes the faintest object which could have been discovered. In the case of a brief transient, this is better described as a fluence, rather than as the typical flux limit. Fluence is simply the integral of flux over time; it can be expressed as energy received within a certain area, or as the number of photons detected within a certain area.

In the case of this Tomoe data, each image has an exposure time of 0.5 seconds, and my search parameters required that an object appear in at least 3 images. Thus, the minimum fluence an object must have can be calculated as follows:

  1. determine the limiting magnitude m for an image
  2. convert that limiting magnitude to flux f
  3. multiply the flux by 0.5, to get energy per area E during a single image
  4. multiply by 3, since we require 3 detections

In other words,



   Fluence limit F(min)  =   f * (exptime) * (min_det)

 where

                 -0.4*m      (          -6                   )
         f  =  10         *  ( 3.16 x 10      erg/cm.sq.-sec )
                             (                               )

The second term in the lower equation is the zeropoint of the V-band magnitude scale: the flux corresponding to a star of magnitude V=0.

How to determine the limiting magnitude of each image? I used a single value for all the images in a single chunk (360 images over 3 minutes), defining it using the magnitude at which stars were detected in 50% of the images; see Tech Note 4 for examples.

Now, it is easy to see very bright transients: they will appear even if there are light clouds. But faint transients will be detected only when conditions are very good. We can therefore expect quite different "control times" for different choices of minimum Fluence.

For ease of discussion, I chose 4 minimum Fluence values, corresponding to the Fluence provided by stars of various magnitudes during a 1-second exposure. It will be useful to use this term when comparing to other searches, which will typically quote a magnitude limit during one of their own much longer exposures.

Here are the total control times for these choices of limiting Fluence.



        Summed "control times", 
           in units of (square degrees * seconds)
 
                  limiting mag in a 1-second exposure
  Night         V=13      V=14      V=15      V=16
  -----------------------------------------------------
 20160315      49,357    49,357    49,357    43,685

 20160316      40,520    40,520    38,834    33,083 

 20160317      43,984    43,741    41,077    32,671

 20160330      30,133    29,292    25,108    19,253

 20160408      33,068    31,919    28,311    23,028       (*) bad chunk

 20160409      30,015    29,298    25,848    10,807

 20160411      36,771    34,252    28,888    14,843

 20160414      28,216    25,715    20,015       128


   total      292,069   284,100   257,441   177,502
  -----------------------------------------------------

(*) On the night of 20160408, one set of chunks, number 010727x, contained bogus data in most of the images; some rectangular blocks of pixel data looked like real sky, but other rectangular blocks were black or empty. The method I used to search for bad data did not disqualify the chunks, so they were originally included in the transient search, creating hundreds of false candidates, and adding to the control time for the night. I removed all candidates from the bad chunks, leaving 7 good candidates; I multiplied the control times by 0.94, since this one time period represented 8/151 of all the otherwise good chunks.

Note that the total control time combined for these eight nights, with 8 chips, is close to a single square degree, monitored continuously for 3*24 hours (which would be 259,200 sq.deg-sec).


Overall properties of the two nights

Below are animated GIFs showing the overall properties of each night. The figures cycle through the measurements from all 8 chips, and repeat endlessly.

The night of 20160315 was a good one. The sky was a bit bright early, but otherwise, very good conditions.

The night of 20160316 had high sky values at the start, and perhaps brief clouds, but was otherwise pretty good.

The night of 20160317 had very high sky values in the first half, and a short period of clouds. Much of the data for chip 7 failed to process normally.

The night of 20160330 was short, and conditions (sky brightness and seeing) turned bad in the second half.

The night of 20160330 was short, and conditions (sky brightness and seeing) turned bad in the second half.

The night of 20160408 was a good one.

The night of 20160409 wasn't bad, but suffered from some light clouds.

The night of 20160411 was pretty good: the seeing wasn't very good at the start and end, but most of the night was nice.

The night of 20160414 was not as nice. Clouds were present in the middle of the night, so few stars were measured during that time.


Tables of candidate objects, with pictures

You can find tables listing the candidates for each night, with numerical values of RA, Dec, mag, etc., and pictures of the objects, at the following links. Each candidate has little pictures of it showing the image before it was detected, all the images in which it was detected, and finally the image after it was detected. So, a transient found in 4 images will have 6 pictures: (1 before, 4 detections, 1 after).

Here are the parameters used to select these candidates:

Using these parameters, I found



   night        candidates        notes
 -------------------------------------------------------
  20160315          3            
  20160316          2            

  20160317          7            
  20160330          2            moving object (see note below)

  20160408          7            after discarding chunks 010727x
  20160409         16

  20160411          4              
  20160414         16
 -------------------------------------------------------

I inspected all the candidates by eye. Most of them were real, faint stars, present in Digitized Sky Survey images and big catalogs. A few were relatively bright stars which, in bad seeing, were occasionally detected at a large enough offset from their usual position that the software counted it as a "new star."

On the night of 20160330, both of the 2 candidate transient objects were created by a single moving object. It moved from west to east at a speed of very roughly 5 arcsec per second, which puts it somewhere around geosynchronous orbit. Over a short path, the motion had components 1.6 arcsec/sec west, 5.0 arcsec/sec south. It was detected at roughly mag 17.9, as an "object" in frames 142-147, and then again as a different "object" in frames 187-190.

The fact that this object did appear in the list of candidates, and that I noticed it as NOT an ordinary, constant star when comparing it to the Digitized Sky Survey, is an indication that my methods to find transients are working -- to some degree.