Additional Regression Scripts

CASA Modification Request 4C108, November 2007



1. Introduction

Regression scripts are important for checking the improvements and debugging that are made in casa. Several more scripts should be designed to improve the scope of testing. A few possibilities are suggested.

2. Background

We have a number of existing regressions scripts based on our demo and ALMA test datasets. These can be found in the $AIPSPATH/code/xmlcasa/scripts directory. These have poor coverage of CASA tasks and tools, particularly for functionality that has been developed after the ALMA tests. In addition, the old regression scripts are written in non-standard ways and are difficult to maintain (ie. when changes are made to the tasks or tools) and to read and understand.

This MR fits within the overall goal of improving the regression scripts in CASA. In the previous cycle, the NGC5921 regression was rewritten as a template for the new regressions. In this cycle, we will continue the conversion of regressions (1 additional) and start the expansion of new regressions (1 new), as well an assessment of the current coverage of the package components. In addition, the regression infrastructure will be improved. This work is the basis for future work.

In future cycles, we will focus on the expansion of the coverage. The areas to be covered include (but are not exclusive to):

1. One script should test relatively high dynamic range imaging of at least 1000:1 for a somewhat extended source. Cygnus A is an example.

2. Another script should deal with good quality polarization data for use when polarization calibration is implemented.

3. Another script should provide the basic calibration, self-calibration and imaging of a relatively large data base to check on the performance changes in CASA.

4. Another script should compare the various deconvolution algorithms associated with a wide field.

3. Requirements

There are four main areas in which progress is required. These are at different levels of priority and timescale.

3.1. Conversion and expansion of existing regressions.

Continue converting regressions based upon the previous NGC5921 regression. This is part of ongoing work that will continue during future cycles. For this cycle, the work required is the conversion of the NGC1333 regression script (ngc1333_regression.py). This is a mosaic. Technical consultants for this script are Golap and Myers. Priority: high

3.2. Creation of new regression cases and scripts.

Start the creation of new regression scripts. These should be written in the new standard template, complete with explanatory text. This is part of ongoing work that will continue during future cycles. For this cycle, the work required is an adaptation of the 3C129 (VLA continuum) script that was provided by David Whysong for the December Tutorial (http://casa.nrao.edu/Tutorial/20071204/Scripts/3c129_reduce.py). This case is useful as it contains multi-configuration VLA data from importvla (not uvfits or ms), and is a continuum dataset that should result in an image with moderately high dynamic range (to be quantified as part of the regression). Technical consultants on this script are Whysong and Myers. Priority: medium

3.3. Improvements in regression infrastructure

Make changes in the regression infrastructure (the regression .py template and in the regression_utility.py functions) to improve the capabilities and robustness of the regressions. This is part of ongoing work that will continue during future cycles. For this cycle, the required work consists of working with the system group (in particular Boyd and Darrell) to make the regressions handle any changes in locations of the data repository. Currently, the regression scripts expect the data to be in certain areas, but the user might have installed the data repository somewhere else (if at all). For example, the ngc5921_regression.py expects the data to be in $AIPSPATH/data/demo/NGC5921.fits. Ideally, there should be a mechanism (Python variable? environment variable?) that can be set to indicate where the data repository is, and users should be able to run regressions transparently without editing the scripts. The technical consultants on this target are Waters and Myers. Priority: medium

3.4. Assessment of regression coverage.

Compile a survey of the coverage of the key tasks and tools of the CASA package in the current set of regressions. This information is needed to guide the development and maintainance of future regressions. Ideally this would be in the form of an online resource (e.g. Wiki page) that could be kept up-to-date. The bulk of the work for this target is to be done in the current and in the following cycle. Effort in future cycles would be at a low level in the maintainance of this resource database. Priority: medium to low (can be spread into next cycle)

4. Design

The following plan addresses the Requirements of section 3:

4.1. Conversion and expansion of existing regressions.

4.2. Creation of new regression cases and scripts.

4.3. Improvements in regression infrastructure

In regard to a robust way to locate the data used by regression scripts, I asked Wes, Darrell and Boyd whether $AIPSROOT/data is always defined in an end-user environment (supposing an end-user wishes to run a regression script)? Wes stated that we can assume that $AIPSROOT/data will always be present, but $AIPSROOT/data/regression may not be.

Probably the best that can be done is create a "locate" function in regression_utility.py that looks in a variety of standard places and also utilizes any locate command offered by the OS.

4.4. Assessment of regression coverage.

5. Deployment Checklist

6. Test Plan

6.1 Internal Testing

6.2 Sponsor Testing

The sponsor should help design the regression tests. They need to contain the accounting information and should be robust with respect to minor changes in syntax of casa. No default values should be used.

6.3 Integration/Regression Tests

6.4 Testing for Scientific Validity


Signatures

APPROVED: I acknowledge that my request is fully contained in this MR, and if the CASA development group delivers exactly what I specified, I will be happy.

ACCEPTED: I acknowledge that I have validated the completed code according to the acceptance tests, and I am happy with the results.

Written - - - - -
Checked - - - - -
Approved by Scientific Sponsor - - - - -
Accepted/Delivered by Sponsor - - - - -

Symbols:
  • Use %X% if MR is not complete (will display ALERT!)
  • Use %Y% if MR iscomplete (will display DONE)


Discussion Area

-- NicoleRadziwill - 30 Oct 2007

-- EdFomalont - 01 Nov 2007

-- EdFomalont - 05 Nov 2007

-- EdFomalont - 05 Nov 2007
Topic revision: r8 - 2008-01-29, RaymondRusk
This site is powered by FoswikiCopyright © by the contributing authors. All material on this collaboration platform is the property of the contributing authors.
Ideas, requests, problems regarding NRAO Public Wiki? Send feedback