RE: [alma-sw-ssr] Offline and Pipeline Requirements

[mel wright 456 <wright@astron.berkeley.edu>]

The ALMA model is that that all data are pipeline reduced,
including, probably, a deconvolution of the synthesised images.

The best calibration and imaging procedure are more easily
defined by the observing procedure and quality of the data
obtained, and can be optimised in the pipeline processing.
The most appropriate deconvolution is not so clearly defined,
and may need to be done in alternate ways offline.

In some cases, experts may wish to go back and re-process
the uv-data, but I think that most users will not, and that
ALMA will best serve the community by producing images.

The calibration and imaging, of course require the uv-data,
but almost all deconvolution algorithms do not.
I think that the offline package(s) will mostly be used
for analysis and display of sky images from ALMA and other telescopes.
Analysis of the images requires the user to try
deconvolutions with various methods and parameters
to match the structure in the source, compare with
other images, and extract the most information from
the images.

The deconvolution algorithms developed for aperture synthesis
are more generally useful. e.g. Multi-resolution clean can
be used to deconvolve other images with a point-spread function which
has an error beam.

It is in the best interests of ALMA, and science in general,
to make these deconvolution algorithms widely available.

It is a reasonable requirement that the offline software be
re-useable, so that it may be incorporated more easily into other
packages with which the users may be more familiar.

The design should be to avoid making:
> > Shoe-horning such information into another package is hard work."


Melvyn.

> > > Radio astronomers have developed algorithms we could supply:
> > > DECONVOLVE(image, beam, method, output_image)
> > >    
> > > where method= clean[Hogbom,Clark,SDI,mfsclean,MRclean,maxen,maxempty,etc]
> > >    
> > > If these algorithms are written in an modular fashion, it should
> > > not require much extra work to write the code so that
> > > it can be incorporated into and invoked from other packages.
> > > I think it is appropriate to state this as a high priority requirement.
> > >    
> > > The users have probably already imported the
> > > image and beam into their favorite package via FITS.
> > > ALMA could provide them with efficient code to do the appropriate
> > > deconvolution.
> > >
> > >   I agree uv-data is a much harder problem. I see
> > > ALMA as an imaging machine, and most users will not deal with uv-data.
> > > Melvyn

> > Ah yes, BUT many (most) of the imaging and calibration algorithms will require
> > the uv-data. Even the Sault image-plane based mosaicing algorithm requires
> > a fair amount of extra contextual information to be passed on with the images.
> > Shoe-horning such information into another package is hard work.
> >
> > If the deconvolution algorithm is "independent" of knowledge of radio
> > astronomy then another package probably already has it. If not, then
> > exporting the relevant contextual information (e.g. pointing centers
> > for mosaics) is a lot of work for relatively little gain.
> >
> > Taking a slightly different tack, I thought that the ALMA model
> > was that all data are pipeline reduced. Accessing the images
> > can presumably be done from any package so the canonical
> > IR astronomer in your example wouldn't be that interested in
> > e.g. performing a mosaic deconvolution from inside IRAF or whatever.
> >
> > Tim