RE: [alma-sw-ssr] Offline Requirements v3.1

["Tim Cornwell" <tcornwel@nrao.edu>]

> Most image analysis packages have a module which can be executed:
> CONVOLVE(image, beam, method, output_image)
> 
> 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.
> 

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