AVODemo Technical Meeting
ESO (Garching), 11 Sep 2002
Notes

SED Plot

WP2 + WP5 (or WP4)

This will be part of the baseline demo.

The SED plot is a way of displaying on-screen a frequency/intensity diagram, based on the intensities of a particular location on all the slices in the frequency cube. Some kind of reverse interaction would be useful - ie, if the user clicks on a plotted point, the entries in the Aladdin tables are highlighted.

The user interface will be driven by the user of Aladdin for the Demo. Hopefully it will be useable afterwards. A general plot utility is being developed in India which might be used. ESO intend to write the SED plotter as a separate "bean", with interface to Aladdin.

Input: either:

a) a list of objects that occur at a particular spot, taken from catalogues. Each object comes from a different catalogue, so the data available for each object is likely to be different, and some information may be present in some catalogues but not others. The group expects VOTable to be used, with an Addada (?) parser. The sources may be existing 'precooked', some may be re-extracted. The table should include frequency widths. Allow for 100s of cube slices.

b) A list of pixel values at each image slice of a particular spot, taken from images.

Presumably (?) Aladdin is the tool that will combine the images or catalogues into the SED inputs.

NB - How to calibrate the fluxes? Some way to allow for aperture. How to cope with resolution problems (ie, several objects being seen as one at low resolutions)?

--> There will need to be a Transformation tool (part of Aladdin) to normalise fluxes (is this technically possible?), co-ordinates, etc. For Demo, parameters for this will come from the chosen catalogues (these are well-defined). But re-extracted stuff won't have this (?) natuarally, Converting this will be up to the Aladdin team/scientists as long as we (Astrogrid) provide a fully functional SExtractor. or should we have to take information from the original data set and pass it to the VOTable output, even if it is not required by SExtractor? eg bandwidth, aperture, mag limits?

NB - VOTable is a simple representation of 2d tables. How will it cope with the different structures of each object in (a) above?

Are these object catalogues or wavelength catalogues. Wavelengths cannot be fully described by UCDS just now which implies that it will have to be a wavelength catalogue. However presumably there will need to an ontological (?!) way of describing wavelengths, perhaps with a UCD stem?

Running issue: Balance effort between getting the Demo right, and producing long-lived tools

Actions: Get some requirements written down and publicised. Action: Work out requirements for input information; 'minimum' UCDs, (presumably) units. Action: need to define an interface between plotter and Aladdin (such 'plugins' already exist).

Goods data

(Luiz) GOODS data will be publicised in time for testing, and we will use the same data source for the demo. There appears to be a call for putting this test data locally on the demo machine.

At the moment it is published in COE projection, but can access TAN projection. Looks like TAN is the preferred standard for future.

How is the data accessed?

Always some problems co-ordinating astrometry (positioning related to well-known reference stars) for different wavelengths.

Luiz strongly recommends only building SEDs from mosaiced images if they include weight maps. Some images (esp WFI) have been mosaiced and include weight maps (as MEFs) .

Jens has tools to create cropped images (cutouts) from images - Jens reckons this can be served to the internet reasonably easily. Runs off existing database, but the tools may be available for a general cutout service.

Luiz is happy to include a FITS -> VOTable converter, so the data is returned in VOTable format, if we provide one.

Contact for ICE, incl Sofie: Luiz and Remmkopf

Anita: Only public radio data available for southern field is low resolution. Could possibly get access to other areas just for the demo.

Francoise is managing the interface between Aladdin and data sets. What will it be? Should we be involved?

Bijoui <--- where did this come from in my notes?!

Upgrading Aladdin

The core capability - filtering on tables, etc - has been checked for feasibility.

The SExtractor and Aladdin development teams will communicate directly to define the interfaces between the two apps. The current Aladdin website includes information on how services can be published for Aladdin. Francoise Bonnarel is the contact for this. Essentially it is an ASU-compatible query, a URI with ?ra=Xxx;Dec=Xxx, etc, returning a FITS file or whatever Vizier can accept at the moment. For the demo, Aladdin will accept VOTables.

Re-extraction (WP4)

Aim

• Technology
  • Web Service (simplistic grid service)
  • Java
  • SOAP
  • VOTable
• Science:
  • Investigate individual areas
  • Find low flux objects
  • Later: extract initial catalogues off new images

It appears from discussions on the other work packages above that we will need to provide data as part of the ACE results that might not be required by SExtractor. For example, co-ordinate zeroing, flux scaling, apertures, etc.

A 'cutout service' will not be provided for the Demo - GOODS will provide some sort of 'cropped image' directly from its data.

Does current version of SExtractor take MEFs? Unless we do otherwise, that is what will be provided.

*Inputs*
The term 'Parameters' here is used to describe any name/value(s) pair - eg image locations, tempalte locations, extraction parameter, output description (including the list of output columns)

• (Optional template parameters) - Original SExtractor ASCII, two files: parameters and output columns
• (Optional template parameters) - XML form
• Parameters to override template
• Image file
• Optional Master image file (objects located on this, flux measured on imagefile) eg chi-squared images..
• Optional wieght map
• Optional mask image

Return

• VOTable
• Image file ?
• Parameters used (as an XML file suitable for using as an input template)

One comment was it would be very sensible to return the version number of the SEXtractor application being used along with the results. Other similar characteristics might be included as part of the VOTable header? Or as part of a wrapper result XML doc?

We (I) shall talk with Francoise to set up the interfaces, and discuss how to implement a UI class for specifying parameters. It seems to make sense that we provide both sides of the interface with them using a simple Java Bean to access the ACE service.

They have a meeting in Strasbourg 30th Sep/1 Oct to discuss interoperability issues; this might be very useful from a general AstroGrid point of view.

General Demo

There is still some discussion as to how the demonstrator will be deployed; whether as a distributed running system, or with most facilities available 'locally'. Factors include (in no particular order):

• Effort required - it's easier to use systems as they are at the moment (eg GOODS data from its currently served location)
• Bandwidth/performance - we want the demo to look reasonably fast, and locally served data and applications will be faster
• Bandwidth available at Jodrell Bank
• Demonstration - we should be demonstrating how the system will work (ie should be semi-distributed)
• Reliability - locally self-contained demo systems are easier to maintain once setup, and are not prone to badly co-ordinated outside influences (such as downtime on a remote site). Similarly problems with a service can be more easily reolved if it is local.

AVO wikki

A new website is being created for the VO project, called http://www.eurovo.org. It will have a wikki, and this should include requirements documents. These will become very important as we define interfaces, both for checking that the interfaces are acceptable and complete, but also to ensure no activities are 'falling between stools'.

The wikki service is a Twikki server, so it should be possible to link easily with the Astrogrid one.

Document formats are largely doc & pdf at the moment, but users are encouraged to use multi-platform HTML. If their browsers don't keep crashing.... grrr...

Summary Issues

Flux normalisation between wavelengths. How?

Astrometry/Common co-ordinates between wavelengths. How?

Representing data. We could do with thinking not only about the format (VOTable sufficient for all solutions?) but also the content; what minimum data items must be included in a catalogue, re-extracted or precooked, for the SED to do its task. For us, that means that we may have to get extra information from the data sets to put in our re-extracted catalogue, even if this data is not required by SExtractor.

How do Luiz & Jens publicise their data - how to query, can you get originals (not just mosaics). What metadata is available (apertures, etc)

-- MartinHill, 13 Sep