IVOA Web>VirtualTelescopeConfiguration (2005-10-06, GerardLemson)

Use case: Virtual Telescope configuration

Description

This use case describes a distributed workflow where an astronomer aims to reproduce an observation by combining appropriate simulations, visualisation services and virtual telescopes altogether mimicking the real observational configuration. This real observational configuration is assumed to consist of a source, emitting photons, possible foregrounds affecting the photon properties/distribution and a telescope.

Principal actor

Astronomer (user)

Other actors

simulator (provider)
virtual telescope creator (provider)
foreground modeler (provider)

Flow of events

See the attached diagram for an illustration of the work and data flow.

An astronomer (the user) has an observation available that (s)he wishes to analyse using simulations of objects of the same class as was observed. The observation can be an optical or X-Ray image, a spectrum, anything for which simulations and visualisation services are available.
The observation has IVOA compatible metadata attached to it. Examples are metadata describing the telescope configuration and a characterization of the observation as well as of the subject of the observation.
The user queries an IVOA compatible registry for simulations that might be compatible with the observed object and which have service attached to it that can visualise the simulation.
The registry needs to be able to compare metadata from the observation to ...
... metadata from the registered simulations. To compare the metadata of the simulation to that of the observation provides requirements to the data modeling efforst for both Observation and Simulation.
The registry provides 0,1, more links to services that can visualise simulations. These services are shielded by a standarized interface that hides the implementation from the user and is free of any telescope or other
The service must produce a result that can be ingested by further services (Foreground and Virtual Telescope). This result must therefore follow a standardized specification/data structure. The idea is that this data structure is what different services need to be able to produce and/or ingest and should therefore be free of any of the different participating services' implementation details. In accordance with what happens in the real world being modeled by this workflow (object producing photons traversing a foreground being observed by a telescope), we propose that this data object describe photons in some way. Maybe a datacube (x/y/energy), maybe a list of photons (for high energy observations for example). For the time being we will refer to this data objects as the pre-observation image (POI).
The POI is intercepted by what for now we will call a foreground (also obtained from querying a registry, not shown in diagram, not explicitly described in this work flow). The foreground influences the POI, absorbing part of the photons, reddening maybe lensing, but produces ...
... another POI.
This POI is observed by a virtual telescope service (again, obtained from registry...), which is ...
being configured using the meta data of the real observation.
The result is a mock image in a format similar to the original observation because of which it becomes easy for the user to ...
... compare the original to the mock image and possibly start the cycle again if the comparison is not to his/her liking. We do not here assume that the comparison is performed using VO applications.

End result

A mock image based on models which include all desired phenomena: physics, foregrounds, optical distortions etc, in a form that can directly be compared to a corresponding observational image.

Requirements on IVOA working goups

G&WS: provide infrastructure for supporting such a workflow
DM/DAL?: provide definition of "interoperable" dataset (POI) for the services mentioned above
Registry: allow publication of service types required for this use case.

Originally sent by G. Lemson 20 2005
Last modified: G. Lemson - 2 Oct 2005

Please add comments below. This area should be used for refinement of the above document. If you want to ask questions or start a dialogue with the author, please use the theory mailing list.

The virtual-telescope service would be tightly coupled to the instrument configuration. It might require subtle tuning to match exactly the real observation. We should consider whether we prefer a small set of virtual telescopes in which the VO user does a lot of the configuration or a wider set of specialized virtual telescopes, each preconfigured for an instrument by the observatory supplying the physical instrument.

-- GuyRixon - 04 Oct 2005