ctools

In general, all parameter names were changed following the proposal in the above link. Still, the cscripts have to be adapted as well (see #1408). I will take care of that.

I recognized that ctselect now had caldb and irf as parameters. Not sure that this tool should have these parameters, it’s just for event selection. Or was this added for save energy threshold selection? (the tool nevertheless seems to work without these parameters, hence I removed them for the moment).

Yes, I guess these parameters are a relic from testing the energy threshold algorithms. Currently, the caldb and irf parameters are not queried at all. Therefore it is good to remove them. There is an exception thrown, however, if usethres="DEFAULT" and no response is given. Accordingly, the threshold algorithm does only work if a full observations xml-file is provided as inobs. I think it should be ok like this.

Mayer Michael wrote:

Yes, I guess these parameters are a relic from testing the energy threshold algorithms. Currently, the caldb and irf parameters are not queried at all. Therefore it is good to remove them. There is an exception thrown, however, if usethres="DEFAULT" and no response is given. Accordingly, the threshold algorithm does only work if a full observations xml-file is provided as inobs. I think it should be ok like this.

I was thinking about this possibility. I’m just somewhat reluctant to ask for response parameters in a tool that just performs event selection. This somehow sounds odd. That’s why my favorite option would be a specific tool that extracts energy thresholds from the response files and puts that into an XML file before running ctselect. I think it would provide a cleaner separation of things.

This is definitely a useful tool.

At some point I was thinking about a GUI (probably based on Python’s TkInter for interoperability) that allows manipulating observation definition XML files. This tool may then allow to scan databases and add additional information to the XML files. Observation selection could then be done by a mouse click (one could even think to select zones graphically from a plot showing the pointing directions of all observations).

Then, we certainly need a tool before ctobssim that allows to setup pointing sequences (something like ctpntsim). This includes taking into account realistic pointing patterns (you cannot point a region that at a given time is below the Earth horizion). Maybe this tools already gets the energy threshold from the response files, but maybe we want another intermediate tool for that so that it can be equally applied to simulated and real data (something like ctengthres or ctethres).

This is definitely a useful tool.

Currently, it is a bit hand-made, with a lot of hard coded values. However, in the long run, there should be no ambiguity about the background model. It should come with the IRF as given. The code in csxmlbuilder is only tested and valid for HESS, but making this background model algorithm part of the IRF directly in the FITS exporters in the HESS Software seems a bit too soon to me. Therefore, I don’t know if it is necessary to create a ctool out of csxmlbuilder. My feeling is to better to keep this specific to H.E.S.S. for the moment. A more generic tool which converts a runlist to an observation and background xml-file might be more useful (taking the background out of the IRF). What do you think?

At some point I was thinking about a GUI (probably based on Python’s TkInter for interoperability) that allows manipulating observation definition XML files. This tool may then allow to scan databases and add additional information to the XML files. Observation selection could then be done by a mouse click (one could even think to select zones graphically from a plot showing the pointing directions of all observations).

Yes, that totally makes sense. For CTA, this should increase the usability a lot. If we want to implement this soon, we probably have to setup such databases for other IACTs?

Then, we certainly need a tool before ctobssim that allows to setup pointing sequences (something like ctpntsim). This includes taking into account realistic pointing patterns (you cannot point a region that at a given time is below the Earth horizion). Maybe this tools already gets the energy threshold from the response files, but maybe we want another intermediate tool for that so that it can be equally applied to simulated and real data (something like ctengthres or ctethres).

I agree that this is necessary. Especially when we move towards pointing tables. I still like the idea to have the energy range definition in the observation xml-file, which then gets applied in ctselect. To have something like ctethres, there has to be a pre-defined algorithm to determine the energy threshold. Often the user has to test different approaches to account for systematic uncertainties.

We may think about removing the axisrot parameter from the tools. This was initially for compliance with Fermi/LAT, but the parameters are not used and supported.

We probably should only keep parameters that are really used for release 1.0 as it’s always easy to add parameters later (but more tricky to remove them).

I fully agree to that. I was further thinking about the edisp parameter. I never tried what happens if it was set to true, but as far as I know energy dispersion computation in ctools is not mature enough, is it?

edisp is in principle working. But this still needs testing.

There will be a student starting to work here at IRAP on the energy dispersion in about one week from now. So I think we should keep this parameter.

edisp is in principle working. But this still needs testing. There will be a student starting to work here at IRAP on the energy dispersion in about one week from now. So I think we should keep this parameter.

Ok great, happy to keep it then.

I think we are fine on the ctools side. The cscripts still have to be adapted to use the new functions from the ctool class (#1408). Concerning the parameter names, however, I don’t see any open issues left there.

yes, looks good.