Page History

...

1. GCN Notices arrive asynchronously via the GCN socket connection.
   • On arrival, each Notice is entered into the GCNNOTICES db table.
   • If the Notice refers to a new GRB, a GRB_ID is assigned, and a new entry in the GRB db table is created.
   • For each new entry in the GRB db table, two flags are set to false (0): L1_DATA_AVAILABLE and ANALYSIS_VERSION. L1_DATA_AVAILABLE is set to true if L1 data are available for the GRB_refinement task and the task has been submitted. ANAYLSIS_VERSION is set to true if the GRB_refinement task has run and if the L1 data are available for the GRB_afterglow task. (The names and conditions for altering fields will need to be reviewed.)
2. When new L1 (FT1/2) data are available, ASP tasks are launched.
   • GRB_blind_search, flareDetection, and PGwave are designed to process each downlink and are launched unconditionally.
   • GRB_refinement, GRB_afterglow, and DRP_monitoring require data from specific data time intervals to be available in order to run.
3. GRB task launcher process and DataCatalog querying
   • In the BlindSearch process, a script (grb_followup.py) is run that queries the GRB db table for entries satisfying two sets of conditions:
     • L1_DATA_AVAILABLE=0: These are GRB candidates that require the GRB_refinement task to be run.
     • L1_DATA_AVAILABLE=1 and ANALYSIS_VERSION=0: These are GRB candidates that have had GRB_refinement task run, but still require GRB_afterglow to be run.
   • Based on the data in those queries, grb_followup.py computes the time intervals to be considered and queries the DataCatalog for the required FT1/2 files.
   • If those files are available, the corresponding tasks are launched.
   • GRB the table entries are updated by the launched tasks.

Individual Task Data Processing

• GRB_blind_search
  1. The DataCatalog is queried for the FT1 file based on DownlinkId.
  2. The GRB_ASP_CONFIG db table is queried for blind search configuration: log-likelihood thresholds, event number partition size, effective deadtime between burst candidates, etc.
  3. The FT1 file is read in and analyzed.
  4. For each GRB candidate:
     • A LatGcnNotice is generated.
     • email notification is sent out
     • If the burst corresponds a burst already in the GCNNOTICES db table (via an algorithm TBD), an entry is made and it is marked as an "UPDATE" (ISUPDATE=1), otherwise it is marked as "NEW" (ISUPDATE=0) and a GRB db table entry is created with the candidate burst parameters (INITIAL_RA, INITIAL_DEC, INITIAL_ERR_RADIUS, MET(=GRB_ID)).
     • grb_followup.py is executed