Use case: Virtual Telescope configuration

Description

Principal actor

Other actors

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

Flow of events

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.

End result

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

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

• Illustration of the use case:
  

Use case: Virtual Telescope configuration

Description

Principal actor

Other actors

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

Flow of events

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.

End result

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

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

<-- 

 

 

 Set ALLOWTOPICRENAME = TWikiAdminGroup
 
 
-->

• Illustration of the use case:
  

Use case: Virtual Telescope configuration

Description

Principal actor

Other actors

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

Flow of events

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.

End result

Requirements

<-- 

 

 

 Set ALLOWTOPICRENAME = TWikiAdminGroup
 
 
-->

• Illustration of the use case: