ASKAP Science Data Processor software - ASKAPsoft Version 0.19.3

Brief description

ASKAPsoft, the ASKAP Science Data Processor, provides data processing functionality, including:

* Calibration
* Spectral line imaging
* Continuum imaging
* Source detection and generation of source catalogs
* Transient detection

ASKAPsoft is developed as a part of the CSIRO Australian Square Kilometre Array Pathfinder (ASKAP) Science Data Processor component. ASKAPsoft is a key component in the ASKAP system. It is the primary software for storing and processing raw data, and initiating the archiving of resulting science data products into the data archive (CASDA).

The processing pipelines within ASKAPsoft are largely written in C++ built on top of casacore and other third party libraries. The software is designed to be parallelised, where possible, for performance.

ASKAPsoft is designed to be built and executed in a standard Unix/Linux environment and core dependencies must be fulfilled by the platform. These include, but are not limited to, a C/C++/Fortran compiler, Make, Python 2.7, Java 7 and MPI. More specific dependencies are downloaded by the ASKAPsoft build system and are installed within the ASKAPsoft development tree. Specific to the Debian platform, after a standard installation of Debian Wheezy (7.x) the following packages will need to be installed with apt-get:

* g++
* gfortran
* openjdk-7-jdk
* python-dev
* flex
* bison
* openmpi-bin
* libopenmpi-dev
* libfreetype6-dev
* libpng12-dev

More information regarding the building, installation and running of the software can be found in the README file in the root of the file structure that forms this collection.

Source code can be accessed via the links in Related Materials section.

-----

A patch release just covering the pipeline scripts. The following bugs
are fixed:

* The number of writers used in the spectral-line imaging when the
askap_imager is used (DO_ALT_IMAGER=true) is now better
described. The input parameter NUM_SPECTRAL_CUBES is now
NUM_SPECTRAL_WRITERS, and the pipeline is better able to handle a
single output (FITS) cube written by multiple writers.
* The running of the validation script after continuum source-finding
now has the $ACES environment variable set correctly. The
validation script requires it to be set, and when it was
not set within a user's environment the script could crash.
* The image-based continuum subtraction script has had two fixes:
- The cube name was being incorrectly set when the single-writer
FITS option was used
- The working directory was the same for all sub-bands for a given
beam. This could cause issues with casa's ipython log file,
resulting in jobs crashing with obscure errors.