ctools

So far we have two preparatory scripts that could be extended to deal with the zenith angle dependence:

• examples/make_pointings.py
  • script that generates for some KSPs the pointing sequence and that attributes North and South IRFs
  • generates input ASCII file to csobsdef
• cscripts/csobsdef
  • converts input ASCII file into an observation definition XML file
  • to be used as input to ctobssim for event list generation

A number of questions need to be answered:

Where to implement the zenith angle computation?¶

make_pointings.py is an example script and not a proper cscript, and one may argue that the example script should be limited to defining the pointings and the duration per pointing. However, the actual script assigns the response function of either the North or the South array. This makes sense as the arrays which are to be used are part of the KSP specification.

The csobsdef script just takes the IRF information provided in the ASCII file generated by make_pointings.py and forwards this information to the XML file.

We could enhance csobsdef and implement the zenith angle simulation in the csobsdef script, which would mean that no new script is actually needed to accomplish the task. The csobsdef script would then take the geographical location of the array and compute from this somehow (see below) an appropriate zenith angle, and based on that zenith angle, assigns the appropriate response function and writes the response function information into the XML file.

This would mean that for a KSP that involves both CTA arrays two csobsdef runs would be needed, and an additional csobsmerge (similar to csmodelmerge) would be needed to merge the Southern and the Northern XML files.

How to implement the zenith angle simulation?¶

I think the following options exists:

• implement a scheduler
• draw from a plausible distribution of zenith angles as function of celestial position
• use a typical zenith angle as function of celestial position

Implementing a scheduler is probably a complicated task, but could be envisioned. For the second option one would need to define what plausible means. Distributions could be based on zenith angle distributions for existing observatories (MAGIC for North, H.E.S.S. for South). Using a typical zenith angle is probably the simplest option (could be used as starting point).

How to set the appropriate IRF¶

I think there are two options:

• chose nearest zenith angle IRF (20° or 40°)
• compute intermediate IRFs by interpolation

The first option would lead to a pretty coarse zenith angle dependence. The second option would be more realistic, but if we do this we have to find out how to compute the intermediate zenith angles from the 20° and 40° IRFs. If the second option is chosen, the computation of intermediate IRFs should be probably done by a separate tool, meaning that the problem falls back to choosing the nearest IRF from a now finely sampled IRF grid as function of zenith angle.

One way to deal with the zenith angle computation could be to introduce a visibility cube which is a cube spanned by Right Ascension, Declination and zenith angle, and which gives for a given array location the numbers of hours per year during which a given celestial direction can be seen under a given zenith angle. In that way we would have full flexibility on how the cube will be computed, and csobsdef can simply use for a given celestial pointing direction the corresponding zenith angle profile to infer a typical zenith angle (or something else). Such a cube would also be very useful for observation planning. We could even have cubes derived from observations logs.

This means that a script csviscube (or something like that) would be needed to compute a visibility cube for each array in form of a FITS file. On input, the script would take

• geographic array longitude
• geographic array latitude
• minimum angular distance of sun below horizon
• minimum angular distance from moon (or something that encodes the brightness of the moon, taking care of moon phases)

csviscube would then compute from these quantities the visibility cube.

The above plot (left column) suggests that we may as a simple model implement a zenith angle dependence that is based on the declination of the pointing:

zenith = |declination - geographic latitude|

Of course, this would be the best observation scheduling possible. Reality would be worse.

I looked a bit into how the zenith angle information could be managed by the CALDB.

While writing the zenith angle information in the CAL_CBD column of the index file is easy (and actually now done by csroot2caldb) the information can currently not be exploited because GCaldb does not provide any method to search the calibration database, return information about available IRFs and allow multiple selection criteria to be combined. Since it is not clear whether GCaldb will be used in the long run for CTA, it is maybe not worth to add such methods now for the needs of CTA.

I therefore decided that it is easier to encode the zenith angle selection in the names of the IRFs. This makes also sense since all tools only take the IRF name and not any other information. This means that the zenith angle names are not extracted from the CALDB, but hard coded. This should of course not be done in a cscript, but doing this in make_pointings.py seems ok.

For the moment, the zenith angle is computed from the simple formula

zenith = |declination - geographic latitude|

for each declination.

We may still think of using a visibility cube, and having a cscript that computes the visibility cube is still very valuable.