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

[Bryan Butler <bbutler@cv3.cv.nrao.edu>]

it's fine to do image (or spectral cube) analysis in whatever
package the user wishes to - *after* that image or spectral cube
has been created.  IDL and matlab are very good at this.  i would
not propose that this should not be recommended/supported.
but nothing really needs to be 'spec'ed in this respect does it?
all you have to be able to do is write out a FITS file of your
image/spectral cube.  whether you want to say that the off-line
processing produced specifically for ALMA should *not* have to do 
any type of image/spectral cube analysis (i.e., it is assumed that
it will *always* be done in other software packages) is a different
question...

IDL and matlab (and cohorts) are *not* very good at the creation
of these images/spectral cubes (i.e., they are not good for "various
flavors of deconvolution and mosaicing").  the problem is not that
it cannot be done (see, e.g., the LUCY procedure in IDL, and there
are various implementations in matlab as well - but note that they
all work with the dirty image and beam, not straight from the 
visibilities [a'la the cotton-schwab CLEAN]) - the problem is that
to "provide efficiently coded algorithms", you have to actually 
do alot of work (if it is even possible).  you can, in principle,
provide your own extensions/procs to IDL or matlab which are C
(or C++, probably) code - but they are not easy.  in general, the
add-ons to these packages (which is what you are proposing, essentially)
are just bundled up calls to the package functions themselves,
in which case you are still stuck with the speed issue.  if you want
to code your own very efficient routine to do the entire deconvolution
process that hooks into IDL or matlab, i would guess that this is
a really major software undertaking (more so than making sure it works
properly in AIPS++, e.g.).


	-bryan


On 2001.08.22 11:27 mel wright 456 wrote:
> 
> Mark's and Steve's comments express well what I've been
> hearing from an increasing number of people, who
> will take their data off into a familiar and versatile
> environment to analyse it, whether of not ALMA spends
> $10M writing code. ALMA should look at the total cost here.
> I'm not an IDL or MATLAB person myself, so I have no bias
> there. The performance issue could be addressed by providing
> efficiently coded algorithms like the various flavors of
> deconvolution and mosaicing, which could be used in the
> user's favored package.
> 
> Melvyn
>