A starter page for discussion of the SRDP Alma Optimized Imaging capability for the archive.  It will start with some basics about the parameters involved, and how to use the starter command line tool to launch a workflowan imaging workflow (

Also discussed somewhat are the imaging parameters, and what information we have about their limits for contemplation of the prototype UI for the user-facing version of this capability (

Using the almaImageCube Command

...

It is non-trivial to figure out appropriate parameters for a given test run, and the AAT/PPI's metadata database does not (yet) contain any of the information required to perform validation of parameter values.  Due to these issues, it is recommended that you make use of the example uses cases which can be found on John's test sheet.

...

Imaging Parameter

...

Limitations:

The Optimized Imaging system will work with the existing spectral information provided displayed by the ALMA AQ in the Frequency Support column.  This data seems to be derived from the ASA_ENERGY table of the ALMA metadata database, and we will have to harvest information from that table in order for users to reasonable configure their request.  Note that the current discussion is about the low-level parameters provided to the workflow for placement into the PPR.  Further discussions about presentation, units, etc, should be kept to the discussion of the UI portion of this document. to provide appropriate limitations upon user requests.

Each MOUS contains a set of of 'fields' or sources, and a In particular, we'll need the field (or source) names and data pertaining to the set of 'Virtual Spectral Windows' (or 'Science Spectral Windows' for the MOUS.  The entire set of parameters required are:).  Each of the Spectral Windows has some frequency ranges associated with it (both Sky and Rest frequency minimum and maximum values are available), as well as an identifying number which the CASA pipeline requires.  

There are six parameters available for customizing the cube:

1. field:         The name(s) of the fields to be imaged
2. spw:          The number assigned to the Virtual Spectral Window (from the set associated with that MOUS)to be imaged
3. restfreq:   The rest frequency for the Cube, with unit string attached (Hz, kHz, MHz, GHz) 
4. start:         The cube's minimum frequency or relative velocity, with unit string attached
5. width:        The width of a channel width for the cube.  In the same units as the start value, with unit string attached
6. nchan:      The number of channels to create within the cube.

What we have available from ASA_ENERGY are the data:

• ASA_DATASET_ID
  
  • Entries are of the format: {MOUS UID}.source.{Field Name}
• SPW_NUM
• FREQUENCY_MIN
• FREQUENCY_MAX
• REST_FREQUENCY_MIN
• REST_FREQUENCY_MAX
• Among many others...

The field parameter looks to be entirely independent from the spectral information.  Each target appears to share the same set of spectral windows for a MOUS, which means that the user simply selects which of the targets are of interest.  The rest of the parameters are strongly dependent upon one another.

Because many of the Virtual Spectral Windows are disjoint and the initial requirements from SRDP limit cube imaging to a single Virtual Spectral window, I suggest that we generate a type of 'display name' for the user to select the appropriate window (We could use the existing frequency range strings used by the AQ, for instance).  This is consistent with ALMA's practices because the spectral window's identifying number (required by the pipeline) is typically hidden from the users.  Once a particular window is selected, the details of that spectral window can provide boundaries for the UI to check or enforce on the frequency/velocity ranges for all the spectral parameters (i.e. the cube's range of [start, start+(width*nchan)] should fall between the [min, max] range of the spectral, window, for instance). 

So far, the expected additional metadata required for imaging will contain the set of field names, and a set of spectral window information (number and sky frequency min/max to start) associated to an MOUS.  Further required data can be refined as the prototype UI starts to take shape. The reason both sets of frequency bounds are mentioned is that I don't yet know which pair is most relevant.  Reasonable values for parameters 3-6 will fall within the MIN/MAX boundaries defined by ALMA, and parameters 1 and 2 will be members of the set for the given MOUS.