This is an overview of how the AAT/PPI handles finding and using ALMA data. 

Data Hunting:

Rawdata Discovery:

AAT/PPI selects the set of data with PASS and SEMIPASS status for QA0, using a combination of data from the tables: AQUA_STATUS_HISTORY, AQUA_V_EXECBLOCK, PIV_SCHED_BLOCK.   The current query is a modification of the one used by the NAASC MAGMA project to provide information about raw data to PIs when requested.

...

• MOUSes with an ARI-L project readme file is rejected.
• MOUSes with additional scripts to facilitate calibration (*scriptFor*Cal*) indicate that the calibration isn't suitable for the PPI and rejected.
  • Note:  The conversion to Workspaces might be able to alleviate this restriction
• MOUSes without any images classified as for science are delayed until the next cycle and checked again.
• MOUSes without any rawdata recorded for them are delayed until the next cycle and checked again.
  • When EBs are ingested, the OUS structure is looked up and persisted to the AAT metadata database

Processing Considerations:

Session Mapping:

In addition to the basic information of EBs and calibration files, there's an additional layer of organizational information required for processing ALMA data via the CASA Pipeline.  The organization of EBs into 'sessions' is required within the ProcessingIntents section of the PPR.  

The best method discovered to date for re-creating the session structure within the MOUS involves collecting data from the tables: Combines  AQUA_EXECBLOCK, AQUA_SESSION, SHIFTLOG_ENTRIES, and BMMV_SCHEDBLOCK in order to get a full listing of all EBs for an MOUS and their associated sessiongenerated a time-ordered list of EBs and their session number.   This allows the creation of a reasonable set of ProcessingIntents entries.


Runtime Data Gathering:

In order to mitigate the the effect of changing information after it has been ingested by the AAT/PPI, the constituent components to facilitate a restore (raw data, calibration files, and session information) are all queried as part of the setup for performing the processing. 

Caveats:

EBs, calibration files, session information all queried at run time to use more up to date information (since alma likes to change things after the fact)

ASA_* tables are known to be unreliable, and reportedly are of questionable reliability.  Those tables are reportedly dropped and rebuilt on an irregular basis. 

Unknown timescale, unknown changes, etc