ctools

Apparently the loading of the Calbb mission “cta” happens in GCTAResponseIrf. An alternative would be to create all caldb entries under the mission name “cta”. The folder structure could then e.g. be: $CALDB/data/cta/hess/bcf/zenith75_az0/
This would make the input parameter “instrument” obsolete, implying a very simple parameter interface.

In the long run (or even short run?) we would like to add the IRFs directly to the event files as the IRFs change quickly. We won’t thus use CALDB anymore.

Note also that the CALDB structure is well defined: http://heasarc.gsfc.nasa.gov/docs/heasarc/caldb/docs/memos/cal_gen_91_001/cal_gen_91_001.html.

Specifically, the path is

$CALDB/data/<mission>/<instrument>/<class>

Loading of the IRF happens indeed in GCTAResponseIrf using a hard wired cta:

        // Set calibration database
        GCaldb caldb;
        if (gammalib::dir_exists(xml_caldb)) {
            caldb.rootdir(xml_caldb);
        }
        else {
            caldb.open("cta", xml_caldb);
        }
        this->caldb(caldb);

We could add an optional parameter mission (or maybe better observatory to be more explicit) that if not given is set to CTA. This should enable handling the following structure:

$CALDB/data/hess/bcf/zenith75_az0/

Thanks for the feedback. I agree that bundling the IRFs to the events is definitely the way to go.
The use case for this feature is only for simulations using ctobssim. A user might want to simulate e.g. 50 hours of HESS observations of a certain detector configuration (zenith, azimuth, muon efficiency, ... ) at a certain sky coordinate. How will this be accommodated if we don’t use caldb anymore?
Currently the user has to provide an inobs XML file for non-CTA simulations. However, the observation times, pointing etc are already provided in this container. Therefore it is kind of a hack to modify these values in the event list’s FITS header by hand.

So $CALDB/data/cta/hess/bcf/zenith75_az0/ is not a valid CALDB name.

For the moment we have $CALDB/data/cta/prod2/bcf/South_50h/, which looks quite similar to me (or am I missing something?). Instead of passing caldb=prod2 and irfs=South_50h to ctobssim, the user could pass e.g. caldb=hess and irfs=zenith75.
But I agree that this might not be ideal and as you say it might violate the caldb scheme. If we did it as you proposed above, we would need to add a hidden parameter observatory to ctobssim, right?

Would you propose to continue implementing this tool or what would be the plan for the use case I described above?

You are right, mistake is on my side. So this looks fine.

Also here we would also need:
- a unit test
- a reference manual page

Can you add this?