Use Cases for Implementation

In order to focus a possible implementation of a system on practical cases, we have listed 6 Use Cases below. The idea is that one would split the implementation into several phases. Each of which will solve one of the use cases.

Quick-look and Trend Analysis Environment (DanielPonz)

Instrument controller or calibration scientist that monitors the behavior of an instrument based on telemetry data received via the control system.

The proposed subsystem performs the following main functions:

• Quick-look analysis of instrument data and
• Statistical analysis on selected sets of instrument parameters to monitor long-term behavior in the performance of the instrument.

Core elements of the prototype could be the standard ESA mission control infrastructure (SCOS-2000), interfacing with the proposed FASE environment either (1) directly, to provide real-time monitoring capabilities by interfacing with the telemetry packets directly, or (2) via an intermediate data distribution facility in near real-time.

The use case could be expanded in the future, including also references to existing subsystems.

Interactive Data Reduction/Analysis (BiancaGarilli)

Our typical use case involves an astronomer who gets raw spectral data, reduces them in a semi-automatic way, and then analyzes them. The practical steps are:

1. get raw data from a remote or local data source;
2. setup reduction pipeline configuration parameters and start the pipeline as a sequence of tasks;
3. verify the reduction quality after each task execution, using graphical tools. Thus, if necessary, the astronomer can change the tasks parameters in order to improve the result quality.
4. forward the final mono-dimensional reduced spectra to redshift computation tool (semi-automatic as well).
5. collect additional photometric magnitudes and spectra in other bands from other data sources;
6. forward all these data to a SED fitting computation tool;
7. store the fitting results in a data storage device (database, files, etc.)
8. display and analyze the SED fitting results with third part tools.

Tasks 1, 5 and 7 can imply VO/Grid access for remote data sources retrieving and storage. Redshift computation (4) and SED fitting computation (6) can can be run locally or dispatched to the Grid or a cluster.

All these tasks imply:

1. Full interoperability between tools and applications;
2. Well defined data models to exchange actual data;
3. Data access standards;
4. Full support to VO services access;
5. Grid/Clusters support;
6. Multilanguage support.

Automated pipeline processing (PrebenGrosbol)

This aims to perform a standard pipeline reduction of a given data set. It corresponds to what most major observatories do on their raw data before the deliever them in (somewhat) reduced form to the users. The steps are:

1. select a set of raw science data
2. determine associated calibration frames
3. perform a set of predefined data reduction steps
4. summarize quality and save reduced frames

On example would be a current VLT pipeline. The use case would take all the actual reduction task from the existing pipeline and only provide a new interface to the environment.

Private data analysis task (PrebenGrosbol)

It concentrates one a small private task which the user wants to apply to a set of data files. The application would be written in C and should be executed either from the shell command line or through a python shell. The base steps are:

1. select a data set (i.e. several separate files)
2. execute a private task on the each of these data files using individual parameters (stored in another data set) for each file
3. save the results in a table and display them

It is assumed that the application already exists. It would have to be modified (hopefully only slightly) to interface to the new environment.

Scalable VO services (DougTody)

Basically what we will do in this use case, is run this "dalserver" code inside a tomcat applications server for the web interface, and have this on the back-end call the scalable framework to compute the virtual data products returned by the service. This will use the Java interface to the execution framework. The execution framework will be used to do things like

• An image service which computes 10000 image cutouts from a survey data collection. A variant on this is a catalog service which optionally compute some user-defined morphology metrics for each cutout.
• A catalog service which runs SExtractor as a parallel application, segmenting a large field into overlapping subregions, and merging the resultant catalogs.
• A combined image and spectral service for accessing large spectral data cubes.

All of these use-cases would be run on a server, small cluster, and on the TeraGrid to demonstrate scalability.

VO client (DougTody)

This use case will implement a Python applications package for VOClient.

-- PrebenGrosbol - 23 Feb 2007
to top