VirtualTelescopeConfiguration < IVOA

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

<H1>Use case: Virtual Telescope configuration</H1>
<H2>Description</H2>
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. 
---
<H2>Principal actor</H2>
Astronomer (user)
---
<H2>Other actors</H2>
   * simulator (provider)
   * virtual telescope creator (provider)
   * foreground modeler (provider)

---
<H2>Flow of events</H2>
See the attached diagram for an illustration of the work and data flow.
   1 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.
   2 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.
   3 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.
   4 The registry needs to be able to _compare_ metadata from the observation to ...
   5 ... 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_.
   6 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
   7 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).
   8 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 ...
   9 ... another POI.
   10 This POI is observed by a virtual telescope service (again, obtained from registry...), which is ...
   11 being configured using the meta data of the real observation.
   12 The result is a mock image in a format similar to the original observation because of which it becomes easy for the user to ...
   13 ... 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.

---
<H2>End result</H2>
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.

---
<H2>Requirements on IVOA working goups</H2>
   * 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* <br>
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.

-- IVOA.GuyRixon - 04 Oct 2005 

---------------------------------------------------
<br><br><br>
<!--
      * Set ALLOWTOPICRENAME = IVOA.TWikiAdminGroup
-->

   * Illustration of the use case: <br /> <img src="%ATTACHURLPATH%/virtelusecase.jpg" alt="virtelusecase.jpg"  width="955" height="727"  />

Attachments

Topic attachments
I	Attachment	History	Action	Size	Date	Who	Comment
jpg	virtelusecase.jpg	r2 r1	manage	60.8 K	2005-09-22 - 09:53	GerardLemson	Illustration of the use case

Topic revision: r3 - 2005-10-06 - GerardLemson

IVOA

Log in or Register

IVOA.net
Wiki Home
WebChanges
WebTopicList
WebStatistics

Twiki Meta & Help
IVOA
Know
Main
Sandbox
TWiki

TWiki intro
TWiki tutorial
User registration
Notify me

Working Groups

Interest Groups

Time Domain

Committees

Stds&Procs

www.ivoa.net
Documents
Events
Members
XML Schema