ctools

1. “SUB” - subtracts the model map from the data map
2. “SUBDIV” - subtracts the model map from the data map and divides the result by the model map
3. “SUBDIVSQRT” - subtracts the model map from the data map and divides the result by the square root of the model map

I did a quick test by passing an optimised GObservations-object, which worked fine.

I also sometimes stumbled upon this SWIG problem in the past (my fault I did not report). Returning just a copy of the objects was the easiest workaround in most cases. Good to open a new issue on that.

Thanks for integrating csresmap.
I realised that we can also easily derive an excess map (which is very common in VHE astronomy) with that tool. We just have to use the algorithm “SUB” and remove all GModelSky instances from the model container before. However, this feature is currently quite hidden and I was wondering how we could advertise this possibility to the user.
In addition, do we need any other algorithms to be implemented?

Mayer Michael wrote:

I also sometimes stumbled upon this SWIG problem in the past (my fault I did not report). Returning just a copy of the objects was the easiest workaround in most cases. Good to open a new issue on that.

Thanks for integrating csresmap.
I realised that we can also easily derive an excess map (which is very common in VHE astronomy) with that tool. We just have to use the algorithm “SUB” and remove all GModelSky instances from the model container before. However, this feature is currently quite hidden and I was wondering how we could advertise this possibility to the user.

Interesting idea. For the moment I would tend to create a new script for that although this duplicates some code. By the way: I added recently a ctool base class to ctools which is in the src/support folder and which provides common features to all tools. This allowed to reduce the code duplication in the existing ctools. They now all derive from ctool.

We should do the same for the cscripts, but I had not yet the time to look into that. We can also put common script code into a module to reduce code duplication, if necessary. This may become more and more important as the code base is growing.

In addition, do we need any other algorithms to be implemented?

csresmap shows the spatial residuals, but we may also want to see the spectral residuals.

Interesting idea. For the moment I would tend to create a new script for that although this duplicates some code. By the way: I added recently a ctool base class to ctools which is in the src/support folder and which provides common features to all tools. This allowed to reduce the code duplication in the existing ctools. They now all derive from ctool.

Yes, I saw that and like the idea of the ctool base class. It especially helps with handling/loading the observations and models.

We should do the same for the cscripts, but I had not yet the time to look into that. We can also put common script code into a module to reduce code duplication, if necessary. This may become more and more important as the code base is growing.

I might check the available cscripts sometime the next week to find out what code could be shared. Having a general cscript, as well sounds like a good idea.

csresmap shows the spatial residuals, but we may also want to see the spectral residuals.

I agree. Wouldn’t such functionality however be better placed in the spectrum code in obsutils? Since spectrum points are probably a commonly requested feature, we might also think about putting their computation into a cscript - csspecpoints?

Mayer Michael wrote:

Interesting idea. For the moment I would tend to create a new script for that although this duplicates some code. By the way: I added recently a ctool base class to ctools which is in the src/support folder and which provides common features to all tools. This allowed to reduce the code duplication in the existing ctools. They now all derive from ctool.

Yes, I saw that and like the idea of the ctool base class. It especially helps with handling/loading the observations and models.

We should do the same for the cscripts, but I had not yet the time to look into that. We can also put common script code into a module to reduce code duplication, if necessary. This may become more and more important as the code base is growing.

I might check the available cscripts sometime the next week to find out what code could be shared. Having a general cscript, as well sounds like a good idea.

Indeed. We may see whether cscript should derive from ctool or directly from GBase. If possible, ctool would probably appropriate. The ctool base class has in fact a Python interface hence we may use it directly in cscripts base class. We could even add Python specific stuff in the interface if needed, which then would avoid to create a specific cscript class.

csresmap shows the spatial residuals, but we may also want to see the spectral residuals.

I agree. Wouldn’t such functionality however be better placed in the spectrum code in obsutils? Since spectrum points are probably a commonly requested feature, we might also think about putting their computation into a cscript - csspecpoints?

What about csspectrum? I would argue that having points is implicit for a spectrum.

I agree very much to add csspectrum. I guess before that we might need to add ctupperlimit (see also #1263), which can be called for every energy bin (or only if the TS is less than a certain value).