:py:mod:`survey_status`
=======================
.. py:module:: survey_status
.. autoapi-nested-parse::
#!/usr/bin/env python
Module Contents
---------------
Functions
~~~~~~~~~
.. autoapisummary::
survey_status.vprint
survey_status.arg_init
survey_status.dec2deg
survey_status.from_ra_dec_deg
survey_status.get_scan_info_from_ms
survey_status.parset_to_field_table
survey_status.obs_to_field_table
survey_status.save_db
survey_status.get_desc_for_epoch
survey_status.main
Attributes
~~~~~~~~~~
.. autoapisummary::
survey_status.explanation
survey_status.survey_colnames
survey_status.survey_coltypes
survey_status.desc_colnames
survey_status.desc_coltypes
survey_status.states
survey_status.not_observed
survey_status.observed
survey_status.imaged
survey_status.global_verbose
.. py:data:: explanation
:value: Multiline-String
.. raw:: html
Show Value
.. code-block:: python
"""
survey_status.py is the script to keep track of the bookkeeping for ASKAP surveys.
It is a prototype, derived from the equivalent software written for RACS.
----------------------------------------------------------------------
This script initiates the database for an epoch of observations for an ASKAP survey.
It also allows updates to be made with each new observing session.
The life cycle of this database is as follows.
1. Creation from observing parset. This can be done before the observation. The given parset must hold the
full specification of this epoch survey; that is all fields are defined even if only a subset are observed in any
given scheduling block.
2. Add observing information; from the field to SBID mapping provided, the MeasurementSets are read for information
that is added to the database.
3. Add image information.
The database consists of a description table and a set of directories containing other tables. For each survey epoch
there is a row in the description file, and a directory of tables.
In each epoch directory are tables, including:
- field_table : with a row for each field observation (within a single epoch a field observation maybe repeated).
- beam_table : one table for each row in the field_table, each with a row for each beam.
- other tables as needed.
(1) To create a database and initialise the field_table
survey_status.py -s -e -p
(2) To update the database with observation information
survey_status.py -s -e -s
Steps 1 and 2 can be performed with a single execution as
survey_status.py -s -e -p -s
(3) To update the database with image-specific information, selected according to the image_info argument:
M - mosaic image
B - beam images
S - image statistics
A - astrometry (beam-beam)
C - catalogue compare
P - polarization leakage
first csv file to keep track of the observations. This
is run by calling:
survey_status.py -s -e -p -s
- .parset is the parset used to create the observations.
- .csv is the observing record (original from Aidan). However,
easy to re-create. The file needs to be in CSV format and contain the columns:
id,field,selected,scheduled,sbid,observed,processed,quality,casda
For example:
10,RACS_test4_1.05_0805-71A,,,,,,,
100,RACS_test4_1.05_2131-56A,1,1,8676,1,,,
The files created are:
descriptor - created if necessary, appended otherwise; has columns:
EPOCH, OBS_FREQ, FOOTPRINT, PITCH, ROTATION, DURATION, POL_MODE, DB_FILE
data_base directory that contains:
field_data - the master csv file for the bookkeeping with columns:
INDEX, SRC, FIELD_NAME, SBID, SCAN, CAL_SBID, STATE, RA_HMS, DEC_DMS, RA_DEG, DEC_DEG,
GAL_LONG, GAL_LAT, POL_AXIS, SCAN_START, SCAN_LEN, MED_RMS_uJy,
MODE_RMS_uJy, STD_RMS_uJy, MIN_RMS_uJy, MAX_RMS_uJy,
PSF_MAJOR, PSF_MINOR, PSF_ANGLE
beam_data - for each field observation (row in field_data):
BEAM_NUM, DATE, RA_HMS, DEC_DMS, RA_DEG, DEC_DEG, GAL_LONG, GAL_LAT,
PSF_MAJOR, PSF_MINOR, PSF_ANGLE
The last 8 columns will be empty as these fill up after calibration and imaging.
"""
.. raw:: html