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?).
Using the almaImageCube Command
Much like the almaRestore command line interface, this is simply a wrapper around a direct launch of the 'basic' workflow (i.e. a version of the OUS processing workflow which stops after CASA completes, instead of preparing the results for external delivery), 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: In the versions of AAT/PPI after 3.6, it is no longer required to specify the nmtest/dsoc-test profiles with the -P option anymore. The limitation of the underlying messaging software has been accounted for in our software after that point.
Unlike the restore workflow, you need to provide the cube's imaging parameters in JSON a file, as well as the MOUS UID. Because of the flexibility provided by the pipeline's template, the file should contain a JSON Array, with each element containing the parameters for a single cube. All requested cubes are then written into the PPR processing procedure.
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 json file used for initial testing of the workflow. It requests/defines a single cube in the array. JSON was chosen to make the passage of a complex set of parameters easier on the AAT/PPI UI when we come to full integration of the workflow .
The frequency units could be given in various units (GHz/MHz/kHz as appropriate), and the start & width parameters can be given in terms of velocities if desired. Be sure to provide the units in the parameter, however, as these values are being placed straight into the PPR. The unit flexibility is possible because the workflow has been relieved of the necessity of looking up the spectral window value. Many of the convenience features (automatic look-up of the spectral window #, parameter limit checking, etc) are not part of the workflow itself, and will be integrated into the UI.
Typical Use Case:
In most instances, imaging testing will be taking place in the 'test' environment, and thus the relevant command line will be:
/lustre/naasc/web/almapipe/workflows/naasc-test/almaImageCube /path/to/my/parameters.json my_mous_uid
will get the workflow proceeding, and report back the working directory location after it is created. The default version of CASA can be changed by editing the value of the parameter "edu.nrao.archive.workflow.config.CasaVersions.homeForAlmaRestore" in the naasc-test.properties file.
Use in the (sometimes unstable) development environment:
When it is necessary to perform testing on the 'development' environment, change the path used for the command to:
/lustre/naasc/web/almapipe/workflows/vatest/almaImageCube /path/to/my/parameters.json my_mous_uid
The fallback CASA version is then the one in the vatest.properties file.
Parameters to use:
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.
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.