ctools

You may use

obs = GObservations()
...
(some optimization done here)
...
curvature = obs.function().curvature()
covar = curvature.invert()

Let me know if this works for you ...

In the next days, I will upload a csscript doing the butterfly computations. Generally, since the computation is not very time-consuming, we might think about also putting that into ctlike?
The question remains how we want to store the output (ascii, fits, xml, ...)

Mayer Michael wrote:

In the next days, I will upload a csscript doing the butterfly computations. Generally, since the computation is not very time-consuming, we might think about also putting that into ctlike?
The question remains how we want to store the output (ascii, fits, xml, ...)

Great. One point that applies also to TS computation is that for the moment you get the information for all sources. If you deal with several tens of sources (for example in a survey) this may lead to huge computing times. So the question was whether one should be able to select for which sources the TS and/or butterfly computations are done. Should we just start will all sources, and eventually change the philosophy later? Or think immediate how the problem should be dealt with (a special tool or script? selection of the relevant sources in the XML file? other options?)

Concerning the format for butterfly, people were arguing that at this stage brute ASCII (or CSV) would be best.

We could go for a similar feature as for the TS computation, i.e. just turn the butterfly computation on and off via the xml file, for each model individually. Since a butterfly specific to a spectrum, it might look like this in the xml file:

<?xml version="1.0" encoding="UTF-8" standalone="no"?>
<source_library title="source library">
  <source name="CrabNebula" type="PointSource" tscalc="1">
    <spectrum type="PowerLaw" bfcalc="1">
       <parameter name="Prefactor" scale="1.0e-17" value="1.0"  min="1e-10" max="1e6" free="1"/>
       <parameter name="Index"     scale="-1"    value="2.4" min="-5.0"   max="+5.0"   free="1"/>
       <parameter name="Scale"     scale="1e6"   value="1.0"  min="0.0001"  max="10000.0" free="0"/>
    </spectrum>
    <spatialModel type="SkyDirFunction">
      <parameter name="RA"  scale="1.0" value="83.6331" min="83" max="84" free="1"/>
      <parameter name="DEC" scale="1.0" value="22.0145" min="21"  max="23"  free="1"/>
    </spatialModel>
  </source> 
</source_library>

I’m a little hesitant to add too much complexity to the XML file, but I don’t have really arguments, it’s just that I feel that things become a little too complicated. Somehow we are adding for every new computation a new parameter, while the ftool paradigm would be more to add a specific too for a new computation. On the other hand, having a specific tool to compute TS values and butterfly diagrams may be overkill. Having said this, there is maybe an important difference between TS computation and butterfly diagrams: when analysing data, you may often be interest in the TS values of the sources, while creating a butterfly diagram is somehow the last thing you do in an analysis before publishing the results (you may of course use this also during the analysis, but I guess one would rarely make butterfly diagrams for several sources in the field of view). If this is an acceptable argument, having TS computation in ctlike but the butterfly as a specific tool would make probably more sense. ctlike would stay a simple tool that is basically doing just one thing, while ctbutterfly would be an additional tool for a different and specific task. In that case, I would argue for just giving the source name and the result file as parameters to ctbutterfly should be fine.

1. write ctbutterfly, which reoptimises the models to get the covariance matrix
2. store the covariance matrix into a fits file on user’s request (e.g. a hidden parameter in ctlike).

The first option seems more straight forward but might be more time consuming, while the second option saves time by introducing complexity.

I guess that in the long run we will have both options. I had planned since some time to add read() and write() methods to the matrix classes so that the matrix can be stored in a FITS file. This can then be used to store and read back the covariance matrix. In the meanwhile, we may just implement ctbutterfly with model re-optimization. In fact, if the parameters are already optimized it would be sufficient to call the error method as this also computes the covariance matrix. Even this is not really needed, the only thing that is needed is a call to GObservations::likelihood::value() which leads to the computation of the covariance matrix which then can be retrieved using a call to GObservations::likelihood::curvature().

Nice plot. Do you have a small script that uses matplotlib to generate the plot from the ASCII file? Something like show_butterfly.py? We could put this in the examples folder (or we may shift the show scripts to the script folder).

Concerning the documentation, everything is in doc/source which uses a rst-based format for the documentation. There are still some leftovers, such as the old html file describing the tools (they are in doc/source/fhelp. We want to port them to rst in the future, but for the time being you may just drop a ctbutterfly.html there in the same format as the other files. The file needs then to be linked into doc/source/tools_reference.rst.

You can see the resulting documentation on http://cta.irap.omp.eu/ctools/. The documentation gets automatically build after pushing into the devel branch, hence anything you add and that I integrate will show up there immediately (well, a couple of minutes after the push).

You may add some short information to the quick start guide (see the files in doc/source/user_manual/getting_started/quickstart.rst). We also have to think about a tutorial (see the related issue #1348).

I added an example script to plot the butterfly. I further added some documentation. All available on branch 1051-create-ctbutterfly. Since I’ve never written something there, I hope I did not introduce a break when compiling the documentation (at least make doc went fine on my system).

ok great, thanks!