Updated point-like IRFs specifications

[TarekHC]

• Now allowing a keyword within point-like IRF HDUs and an additional HDU with the description.
• Still to do:
• proper links to the different headers
• add an example script
• ?

[cdeil]

@TarekHC - Thanks!

• Yes, having one example file in the right format is very important. Please add a Python script and FITS file and link to it, like we do in other places.

• I see you're defining formats for 2D and 3D arrrays, like we have for background. I would suggest to just define the 2D format for now, and remove the 3D format. That would be equivalent to what we have for AEFF. Having RAD_MAX cuts really only makes sense when you have AEFF. So if that particular 3D format is needed in the future (I doubt it's a good set of axes and will be used), it could be added later, in a PR adding it for AEFF and RAD_MAX, and maybe EDISP as well.

• If you can put a rendered HTML version up on the web somewhere, it helps with review and to get good feedback on the new version.

[TarekHC]

Yes, having one example file in the right format is very important. Please add a Python script and FITS file and link to it, like we do in other places.

Ok, I'll do it by today probably.

I see you're defining formats for 2D and 3D arrrays, like we have for background. I would suggest to just define the 2D format for now, and remove the 3D format. That would be equivalent to what we have for AEFF. Having RAD_MAX cuts really only makes sense when you have AEFF. So if that particular 3D format is needed in the future (I doubt it's a good set of axes and will be used), it could be added later, in a PR adding it for AEFF and RAD_MAX, and maybe EDISP as well.

You are absolutely right. We should separate those pull requests. Although I do not agree with the fact that it will not be used... With CTA FoV size, radial symmetry will very likely not be good enough to reach the systematic uncertainty required. If I have time, I might do the pull request after we merge this one.

If you can put a rendered HTML version up on the web somewhere, it helps with review and to get good feedback on the new version.

Yes, I think I can also do that.

[cdeil]

With CTA FoV size, radial symmetry will very likely not be good enough to reach the systematic uncertainty required.

Agreed. But we don't have MC simulation with sufficient statistics to map out the field of view now for any existing IACT or CTA, and when someone starts doing it, I think it's likely that they will do it brute force and just for a grid of DETX, DETY. It's very inefficent to produce or also to store it that way.

So I would really suggest we wait to see what people do, and then only define formats that are motivated by a use case of at least one person producing such data and having a little bit of experience with it and to show that it's really useful. Trying to first write the spec without prototyping isn't a good idea in general, and we already saw this here with the point-like format, which we added to the spec first, but not in a good way, because we didn't have the experience from writing and reading such files.

[TarekHC]

Hi again,

You may find the rendered version of the specs here: http://www.gae.ucm.es/~thassan/gamma/irfs/point_like/index.html

I removed the rad_max_3d format and added an example fits file + script to generate it. Please review or merge if you agree with everything.

[TarekHC]

@cdeil I think it makes more sense to merge now. The point-like part was not usable as it was, so better to make it usable asap, even if it is not used yet. @jjlk will see if this is good enough or it needs to be improved.

[cdeil]

I see, the incorrect statement on THETA binning was copy & paste from http://gamma-astro-data-formats.readthedocs.io/en/latest/irfs/full_enclosure/bkg/index.html

@TarekHC - OK to remove it from there also? If yes, can you do it or should I?

[TarekHC]

Sure, no problem.