CTA Science Scenario Template to help for CTA Top Level Use
Case definition
1. Title​
: (e.g. “Observe a distant AGN”, “survey the galactic plane”, etc.​
) 2. Version: ​
(e.g. v0, v1 etc.) 3. Assigned To: ​
PHYS people responsible for this use case, software engineers that will follow for the preparation of this scenario and will write the formal use case 4. Observing Strategy Description of the strategy to reach the proposal science goals. e.g. queued, ToO, and e.g. single target (wobble mode)/ survey. Why is this use case of interest? Which targets? How can you use CTA telescopes and instruments to address this science case? What would you expect to get from the observations? Priorities? 5. Observing Program preparation
Observing Program = Observing Strategy + Observing mode(s) Would you have a Target selection tool (direct access to NED, SIMBAD, coordinate systems etc)? Would be better to have already defined configurations templates? The same for the camera) (e.g.) ▪ Templates are always welcome ▪ Simulation tools (see former section) are very useful ▪ We do not need calibration simulation tools for the Camera ▪ Other Do you need simulations tools for this use case e.g. to decide which would be the best array configuration for this use case?). Do you need to reconsider the strategy of your program based on the preliminary results of the observation? e.g. ▪ e.g. this use case requires an almost real­time analysis. ▪ It could be very useful for ToO observations triggered by other facilities MW (to external observatories/experiments) and new observing mode (if needed, e.g. to repoint the Array for serendipitous discovery): Do you send automatic alert for unusual behaviors of targets or serendipity detection of flaring source? (e.g. Yes! How? Why? No) 5.1 Observing modes Provide a list of observing modes​
(e.g. Observing mode #1, Observing mode #2). ​
Observing mode definition: 1. Array: ​
N / S / both 2. Pointing_Coordinate_System​
: ​
Ra­Dec / Alt­Az / Gal 3. Nominal_Pointing: pointing coordinates for each target and a field that describes the expected target size (a radius or region­of­interest definition). 4. Pointing_Mode​
: ​
parallel (=0) / convergent (<0) / divergent (>0) 5. Requested_Telescopes​
: number of LST / MST / SST telescopes requested for the run. Or full array, sub­system, sub­arrays. 6. Minimal_Telescopes​
: minimum number of LST / MST / SST telescopes required for the run; the run will not be executed unless these telescopes can be provided 7. Minimal_Sky_Quality: ​
perfect / good / marginal​
. Specifying atmospheric quality (transmission); the run will not be executed unless these conditions are met. 8. NSB_Range: ​
minimal / up to 5 x minimal (~1/2 moon) / any​
. Minimum and maximum allowed NSB, mainly due to the moon; the run will not be executed unless these conditions are met. There may be technical reasons to have a non­zero minimal value (off­runs for high NSB regions, technical studies, etc). 9. Zenith_Range: minimum and maximum allowable zenith angle during the run; the run will not be executed unless this condition is met. 10. Precision_Pointing: conditions enabling highest pointing precision (low wind, low temperature gradient); the run will not be executed unless these conditions are met. 11. Allowed_Time_Range(s): Observation time and epoch. Table of observing windows when the observations are allowed (by default the full year, but for multi­wavelength campaigns or periodic sources may be more specific). For ToO observations: max duration of an observation, maximum time delay. 12. Priority 6. Observing Program execution
Imagine having a full control of the array and describe (step by step) the operation to be done to acquire the data you need using an ideal array of telescopes and camera. Define a sequence of steps (main scenario + action to be taken in case of failure) Which data you consider important to be collect during a run dedicated to this use case in order to describe your science data: • Hardware characteristics: e.g., the type of the telescope/camera combination, and the characteristics of camera • Configuration of the array: e.g., the location of the telescopes, observing modes etc. • Telescope tracking: e.g., the pointing direction, etc. • Target: e.g., the position etc. • Monitored data: e.g., system temperatures and weather information • Overall project: e.g., the observer’s name • Post­processing: e.g., calibration data etc. What feedback do you need to receive after the end of each of your scheduled observation? 6.1 Main scenario
A list of steps. 6.2 Failures
Exception conditions and reactions to failures. In case of failures​
, what do you think should be done if the pointing or tracking accuracy of one or more telescopes degrades, or the sky condition changes during the exposure? (e.g. interrupt observations etc.) (e.g. ● observations may proceed with a “flag” raised or they should be interrupted ● Other specifications 6.3 Analysis
Define which analysis tools and analysis methods do you need. 6.4 Data products
Define the expected data products. 7. Further Information
Additional information for this use case, e.g. ● Questions for other WP in order to get more information o on telescopes, Camera o Software o Operations o Other specify ● General Comments ● Other 8. Open points
Open points For discussion and to produce a new version of the Use Case.