GammaLib

Oops, I forgot that ctools is CTA-internal, right?
Even though it is GPL, so since I have a copy I’d have the right to make it public???

For now I’ll just try to package gammalib, just wanted to mention that I’m stongly for making ctools public as soon as possible.

Well, I agree that we have to overcome this. I guess the only point was that preliminary CTA response functions are shipped with ctools, and as they are CTA internal, they should not go out. I never understood what the problem is with shipping CTA response functions, any new gamma-ray mission provides response functions to the community.

Anyway, I guess we may replace the actual response functions by a kind of dummy response function, and ship real CTA response functions separately. I see then no reason to make also the ctools public ...

Jürgen Knödlseder wrote:

Well, I agree that we have to overcome this. I guess the only point was that preliminary CTA response functions are shipped with ctools, and as they are CTA internal, they should not go out.
I never understood what the problem is with shipping CTA response functions, any new gamma-ray mission provides response functions to the community.

Anyway, I guess we may replace the actual response functions by a kind of dummy response function, and ship real CTA response functions separately. I see then no reason to make also the ctools public ...

At the moment both the gammalib (gammalib/inst/cta/caldb) and ctools (ctools/caldb) repos contain caldb files.

I can see some advantages of including caldb files in the gammalib and ctools repos:

• No extra download needed for the user.
• Software and caldb versions are linked, because new caldb formats require new software and support for very old caldb formats (e.g. the ones we have now for CTA) will be removed in newer software versions.
• Some unit tests need caldb files.

But I think it would be better to have the caldb files separate from the software repos, for these reasons:

• It would allow us to make ctools public after the next release, every collaboration can decide when / which caldb files to release.
• HESS full caldb is > 1 GB and soon CTA caldb will get large too, so it is not possible to keep it in the code repos in the long run anyways.
• Making it separate now allows us to establish good practices for handling the software vs. caldb version issues and methods to download and store caldb files on end-user machines.
• I think dummy caldb files (either contained in the code repos or created on the user machine by a script) might not be worth the effort in all cases, it’ll be easy to get the real deal with one or two commands.

Christoph Deil wrote:

Jürgen Knödlseder wrote:

Well, I agree that we have to overcome this. I guess the only point was that preliminary CTA response functions are shipped with ctools, and as they are CTA internal, they should not go out.
I never understood what the problem is with shipping CTA response functions, any new gamma-ray mission provides response functions to the community.

Anyway, I guess we may replace the actual response functions by a kind of dummy response function, and ship real CTA response functions separately. I see then no reason to make also the ctools public ...

At the moment both the gammalib (gammalib/inst/cta/caldb) and ctools (ctools/caldb) repos contain caldb files.

You’re absolutely correct. I never found the time to remove the caldb files from the GammaLib distribution and to replace them by some dummy response files. Dummy response files would be sufficient for unit testing, and this would avoid that we ship CTA internal files.

I can see some advantages of including caldb files in the gammalib and ctools repos:

• No extra download needed for the user.
• Software and caldb versions are linked, because new caldb formats require new software and support for very old caldb formats (e.g. the ones we have now for CTA) will be removed in newer software versions.
• Some unit tests need caldb files.

Agree. The only problem is size. Maybe a compromise is having minimal response files in GammaLib, and a full fledged database to be downloaded.

But I think it would be better to have the caldb files separate from the software repos, for these reasons:

• It would allow us to make ctools public after the next release, every collaboration can decide when / which caldb files to release.
• HESS full caldb is > 1 GB and soon CTA caldb will get large too, so it is not possible to keep it in the code repos in the long run anyways.
• Making it separate now allows us to establish good practices for handling the software vs. caldb version issues and methods to download and store caldb files on end-user machines.
• I think dummy caldb files (either contained in the code repos or created on the user machine by a script) might not be worth the effort in all cases, it’ll be easy to get the real deal with one or two commands.

Agree. I think I should bring this up in the Data Management group, or eventually at the project office level. Would be good if we have an official blessing for this.