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

["Wim Brouw" <Wim.Brouw@atnf.CSIRO.AU>]

Mel,


At Thu, 23 Aug 2001 11:03:56 -0700 (PDT) mel wright 456 wrote:
 > 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.

This is certainly not true for most procedures and telescopes nowadays that
need a dynamic range of more than 20dB. Since the early 1980's deconvolution,
especially for mosaicing and the lower frequencies (with many sources) and
polarisation work, econvolution algorithms have been iterating between uv and
image plane.

Groeten,

Wim Brouw







 > 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,e
tc]
 > > > >    
 > > > > 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