[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

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



Bryan Butler writes:

> 
> 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.).

I agree completely.

1) The aips++ consortium has invested something like 150 person-years
developing the aips++ class library for the processing of radio astronomy
data from visibilities to images. Even if extensive tuning and modification
of this library is necessary to meet ALMA requirements, the time spent will
be far less than would be required to do the equivalent in some
3rd party package.

However, once images exist, then indeed one should be able to transport
them into other packages for further viewing / analysis. Already the
offline document has this requirement in a rather fuzzy form - OL-7.1-R5.2.
If it becomes apparent over then next few years than some particular
commercial package with its own data format is particularly suited
for the analysis of astronomical images, then we could consider outputting
data in that format as an additional option.

Tony
-- 
Tony Willis

Internet  :   Tony.Willis@hia.nrc.ca  
Snailnet  :   Dominion Radio Astrophysical Observatory
              P.O. Box 248, Penticton, BC, Canada V2A 6K3
BC Tel net:   (250) 493-2277    Faxnet    :   (250) 493-7767
voicemailnet: (250) 490-4343    Localnet  :   ext 343