ctools

Some thoughts:
- I think we should support both On and Off regions from files
- I think we should support as input file formats both ds9 reg files and FITS WCS maps (gammalib has already methods to read both, so it’s a piece of cake)

The way I’d do it is to add a second option for the bkgmethod, that would be CUSTOM, in addition to REFLECTED. When the user selects CUSTOM the script would query for the On and Off region files, and pass them to the On/Off constructor.

I checked out the code and run a few test cases.
I could not reproduce the problem with the parameter rad. For me the code runs without querying the parameter when appropriate

$ csphagen prefix=custom bkgmethod=CUSTOM
Input event list or observation definition XML file [obs.xml] 
Binning algorithm (LIN|LOG|FILE) [LOG] 
Lower energy limit (TeV) [0.1] 
Upper energy limit (TeV) [50.] 
Number of energy bins [30.] 
Coordinate system (CEL - celestial, GAL - galactic) (CEL|GAL) [CEL] 
Right Ascension of source region centre (deg) (0-360) [350.85] 
Declination of source region centre (deg) (-90-90) [58.815] 
Source region file (ds9 or FITS WCS) [onoff_on.reg] reflected_on.reg 
Stack multiple observations into single PHA, ARF and RMF files? [yes] 
Output observation definition XML file [onoff_obs.xml] custom_onoff.xml
(ctools) macp0077:classical3 ltibaldo$ ls
csphagen.log            obs.xml
custom_112301_off.reg        onoff_obs.xml
custom_112302_off.reg        reflected_112301_off.reg
custom_on.reg            reflected_112302_off.reg
custom_onoff.xml        reflected_on.reg
custom_stacked_arf.fits        reflected_stacked_arf.fits
custom_stacked_pha_off.fits    reflected_stacked_pha_off.fits
custom_stacked_pha_on.fits    reflected_stacked_pha_on.fits
custom_stacked_rmf.fits        reflected_stacked_rmf.fits

• I see no use case for which the On region may depend on the observation. I’d recommend to always provide it through an input file.
• If the user provides an input On region file, the source direction should be read from the file, without querying the ra and dec parameters
• To me it seems it would be more natural to create and OffRegions attribute for GCTAObservation (or GObservation) at the gammalib level, and then just read it in csphagen, rather than parsing the xml directly in csphagen; any thoughts Jürgen?

Tibaldo Luigi wrote:

...
Some comments on the implementation of the CUSTOM method for your consideration:

• I see no use case for which the On region may depend on the observation. I’d recommend to always provide it through an input file.

I totally agree with you. The intention was to allow the user to keep things together hence inserting on and off regions at the same place in the obs def xml file. Multiple on region definitions would have replaced each other. Nevertheless I see your point that this could be confusing! I removed the support for on regions in the obs def xml file in the latest commit.

• If the user provides an input On region file, the source direction should be read from the file, without querying the ra and dec parameters

The intention to always query the src direction was to keep things general. For the current implementation of gammalib, assuming to be able to read the src direction from the GSkyRegion instances would again restrict them to be GSkyRegionCircle objects. Am I wrong?
Nevertheless, the last commit now supports automatic reading of the src direction from the src region, at least for GSkyRegionCircle objects.

• To me it seems it would be more natural to create and OffRegions attribute for GCTAObservation (or GObservation) at the gammalib level, and then just read it in csphagen, rather than parsing the xml directly in csphagen; any thoughts Jürgen?

Also to me this seems to be a more robust implementation. The question is whether only csphagen will use that parameter and hence whether it’s worth to add this parameter so deep in gammalib.

Thanks Andreas.

Specovius Andreas wrote:

Tibaldo Luigi wrote:

...

• If the user provides an input On region file, the source direction should be read from the file, without querying the ra and dec parameters

The intention to always query the src direction was to keep things general. For the current implementation of gammalib, assuming to be able to read the src direction from the GSkyRegion instances would again restrict them to be GSkyRegionCircle objects. Am I wrong?
Nevertheless, the last commit now supports automatic reading of the src direction from the src region, at least for GSkyRegionCircle objects.

Makes sense, I agree with this solution.

• To me it seems it would be more natural to create and OffRegions attribute for GCTAObservation (or GObservation) at the gammalib level, and then just read it in csphagen, rather than parsing the xml directly in csphagen; any thoughts Jürgen?

Also to me this seems to be a more robust implementation. The question is whether only csphagen will use that parameter and hence whether it’s worth to add this parameter so deep in gammalib.

I’d say Jürgen can judge on this.

Just recognized one issue with my above proposal: the actual code relies on a XML file, while in principle it should be possible to simply pass an observation container to the script without reading any XML file. This means that the off region handling needs to be implemented at the GammaLib level.

I implemented GCTAObservation::off_regions() methods for setting and getting the Off regions. The Off regions will be automatically read from an XML file if the OffRegions parameter exists, and if a CTA observation has Off regions with a non empty filename, it will write the Off regions file name into the XML file.