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. 

...

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.