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 workflow. This capability will operate only upon a single Virtual Spectral Window of a single restorable MOUS for the early stages of SRDP. Eventually the results, if deemed appropriate, will be made part of the archive (stored in which NGAS servers?).
The Parameter Space
The Optimized Imaging system will work with the existing spectral information provided 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.
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:
- The name(s) of the fields to be imaged
- The number assigned to the Virtual Spectral Window (from the set associated with that MOUS)
- The rest frequency for the Cube, with unit string attached (Hz, kHz, MHz, GHz)
- The cube's minimum frequency, with unit string attached
- The channel width for the cube, with unit string attached
- 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 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.
Using the almaImageCube Command
Much like the almaRestore command line interface, this is simply a wrapper around a direct launch of the basic workflow (just up through the CASA step), and provides the location of the working directory once it is created. It has the same options for overriding the default CAPO value for the CASA to use (currently /home/casa/packages/RHEL6/prerelease/casa-prerelease-5.5.0-140) and the option to have an email sent when the workflow completes.
Note: It shouldn't be necessary to specify the nmtest/dsoc-test profiles with -P anymore, as the issue which necessitated that has been worked around within the messaging code.
As before, specify the MOUS UID, but the parameters are specified in JSON format in a file. For instance:
[
{
"field": "NGC1333_IRAS_4A",
"spw": 25,
"restfreq": "140839502000.0Hz",
"start": "140827765374.83334Hz",
"width": "117366.25166666666Hz",
"nchan": 160
}
]
This is the content of the uid___A001_X133d_X1e64.json file used for initial testing of the workflow. This is the format in which the I expect the front-end will pass the values. The frequency units could be given in other units now (GHz/MHz/kHz as appropriate), as the workflow has been relieved of the necessity of looking up the spectral window value. These numbers are left over from before that decision was made.
The actual command line:
almaImageCube uid___A001_X133d_X1e64.json uid://A001/X133d/X1e64
will get the workflow proceeding. This particular case took a few hours (~4) to process.
This command line interface is meant for initial expert use for testing purposes, and thus omits several of the utility features which will be incorporated into the user interface. Multiple uses cases can be found on John's test sheet.