Handling data cubes in VO

[Anita Richards]

Replying to an older message from Doug:

...
> In a typical scenario, following data discovery a client could download
> a sub-cube for local analysis, probably in some existing VO-enabled tool
> (e.g., several such are in common use within radio astronomy).  Or the
> client could issue a series of requests to dynamically slice the cube, or
> even extract 1D spectra through a synthetic aperture with SSA.
...
> (from me)
>> Datacubes (and higher dimensions) also highlight one of the bees in my 
>> bonnet - in many cases, even for science-ready data, specialised software 
>> will be best for manipulation - both due to the size of the cubes and the 
>> range of ways to handle data.  Hence, as well as data discovery, we may 
>> need software discovery
....
> (from Doug)
> I agree, although the generic data access approach outlined above would
> support much analysis.  I think what you describe here is a distributed
> application.  Part of the application, at least the interactive user
> interface, runs on the user desktop.  The "manipulation" part runs on
> the remote server with high bandwidth access to the data.  This leads to
> the component-framework type of approach.  We capture the functionality
> of parts of the application in reusable components and execute them via
> a distributed execution framework of some sort, supporting either local
> or remote execution of the same components.  (This is what we have been
> discussing in the Opticon context).
I agree - although just to make one thing clear, it is not just a 
data transport issue.  It is also a jargon and specialisation issue. 
Different tools require all sorts of different inputs to produce a 1D 
spectrum with a given aperture, for example.  So far we have put effort 
into trying to make individual tools handle data outside the domain they 
were written for (e.g. radio or x-ray data into specview or SExtractor). 
The approach I am suggesting is that specialised tools live somewhere 
easily accessible to their kind of data but the VO provides a translation 
layer so that the user does not have to learn AIPS, KAPPA.....

> The software discovery bit is merely describing components in the registry.
> This is the easy part.  The hard part is defining the execution framework,
> and container-component interface.
Yes indeed, although that is exactly what we are working on in the 
Euro-VOTech and using the AstroGrid CEA - and it should become easier now 
that service descriptions are being handled more thoroughly by the 
Registry standards.

In fact (digressing even more) the other thing which seems to be helping a 
lot is adoption of python as a common scripting language -
AstroGrid CEA <=> python <=>ParselTongue <=> AIPS seems to work fine, 
including Registry entries etc. - hope to loose it on the world soon! (but 
so far only 2-D).

best wishes

A

- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
Dr. Anita M. S. Richards, AstroGrid Astronomer
MERLIN/VLBI National Facility, University of Manchester, 
Jodrell Bank Observatory, Macclesfield, Cheshire SK11 9DL, U.K. 
tel +44 (0)1477 572683 (direct); 571321 (switchboard); 571618 (fax).