radially asymmetric IRFs

[mizorafa]

The current (v1.1) gammapy IRF classes provide functions only for radially symmetric IRFs (in the energy-offset axes) except for Background3D. However, asymmetric response evaluation will be more important and necessary for the analysis of data from large-zenith-angle and/or stereoscopic observations, thus requesting something like EffectiveAreaTable3D, EnergyDispersion3D, PSF4D in addition to EffectiveAreaTable2D, EnergyDispersion2D, PSF3D. Accordingly, gammapy.makers.utils needs to be updated, I guess.

[AtreyeeS]

Thanks @mizorafa ! Support for asymmetric IRFs is planned, but this needs a defined format for such IRFs first. A corresponding issue is open in the GADF for long open-gamma-ray-astro/gamma-astro-data-formats#73
A format is being prepared for the CTA by @maxnoe , once it is finalised, this can be implemented

[maxnoe]

A format is being prepared for the CTA by @maxnoe , once it is finalised, this can be implemented

It's a bit more complicated than that... I will try to summarize a bit.
The CTAO DL3 data model, in principle allows specifying non-radially symmetric IRFs, but a concrete format isn't specified in that document.
It's also not clear when these radially asymmetric IRFs will be needed on the CTAO Software release roadmaps (DPPS / SUSS). The existing experiments came pretty far with the current parametrizations. So I fear this will not have a very high priority in the next one or two years for CTAO, of course CTAC and ASWG is a different story, but we also had issues motivating more people to work on IRF related studies compared to e.g. ML reconstruction or higher-level science analysis.

The strongest case for the non-symmetric IRFs are high-zenith observations and divergent pointing, so I expect some work on IRFs by the groups pushing for these kinds of observations in the context of ASWG / CTAC or the existing experiments.

I also strongly disagree on the part of "once it is finalized, it can be implemented"
We can't just define a format and then, after a format has been specified, implementation in Gammapy comes next.

This has to go hand-in-hand. There are multiple different ways of lifting the restriction of the radial symmetry assumption and one has to implement the computation of the IRFs (e.g. in pyirf or the magic DL3 converter or the HESS software or ...) and implement the application in Gammapy in parallel to make studies and comparisons to find out what works best. This can and I think needs to be done before we finalize a proposal for a new standardized data format.

So thus far, there were so many inter-connected tasks that no-one seems to have even tried...

It would be really great if there was some kind of tutorial what would be needed to implement a new IRF component parametrization in Gammapy.
This doesn't mean it has to be part of a release / be merged into main for the study to be made, but I think just waiting for an official proposal from CTAO will not be on the timescale that MAGIC and LST need to analyze the existing data and also the other way around: CTAO doesn't have the real observed data to meaningfully test the new implementations.

So long story short: this is a long-standing issue. The corresponding discussion in GADF is over 7 years old, without resolution: open-gamma-ray-astro/gamma-astro-data-formats#73

I am happy to give support for the computation of the IRFs side. Somebody else, from the Gammapy team, should be able to advise what is needed on the Gammapy side.
On the example datasets we can use to test this, we can certainly use prod5b CTA simulations at 60 degrees zenith or the recent divergent pointing simulation set, which is currently being analysed by @Iburelli.

This is also not a task for just one person I think, and I heard from multiple places that it gets more urgent for specific analyses in LST, MAGIC and I guess also HESS.

I have a new master student in Dortmund who will look into part of this on CTA simulated data and we can start looking into more complex parametrizations of effective area.

EffectiveAreaTable3D, EnergyDispersion3D, PSF4D

A side comment: please, please don't just call then D. Be more concrete, as we could have different parametrizations with the same number of dimensions. E.g. a cartesian-like system as in the current BackgroundModel3D vs a polar-like system are both 3D, but one is (fov_lon, fov_lat, energy) while the other would be (fov_theta, fov_phi, energy).

Also, the PSF is more complex, since it is not only asymmetric in the field of view but also relative to the true source position. We recently had a bachelor thesis looking into this, and the low-energy PSF is much better described by superposition of three 2d assymetric gaussian than by either the PSF table or the existing 3-gauss formula.
And then these parameters could be stored in a 2d FOV grid.

In all these cases, the sample size of our current simulations get very limiting pretty fast.

[registerrier]

Thanks for bringing this up. I think there is a discussion #4725 started by @maxnoe to which we have not been very responsive so far. I think we could probably continue the discussion there. Or point to this one there.

I also strongly disagree on the part of "once it is finalized, it can be implemented" We can't just define a format and then, after a format has been specified, implementation in Gammapy comes next.

I tend to agree here. It is very difficult to define a priori a format without any experience on the object. Most of our formats for DL4 and DL5 products are ad-hoc formats. And they will need adaptation to make them perennial.

It would be really great if there was some kind of tutorial what would be needed to implement a new IRF component parametrization in Gammapy. This doesn't mean it has to be part of a release / be merged into main for the study to be made, but I think just waiting for an official proposal from CTAO will not be on the timescale that MAGIC and LST need to analyze the existing data and also the other way around: CTAO doesn't have the real observed data to meaningfully test the new implementations.

I agree here as well.
Creating a new IRF has become quite easy since 0.20. But this feature is indeed barely documented.
Of course, this is without any support for IO and that's why as @AtreyeeS wrote, we cannot really provide a proper public implementation of more complex IRFs in gammapy for now.
But, indeed, we should expose how to create a new IRF somewhere. There are even use cases beyond asymmetric IRFs.

There are no specific API tutorial on gammapy.irf . We could add one. Recipes could be an option (but they are still broken).

I am happy to give support for the computation of the IRFs side. Somebody else, from the Gammapy team, should be able to advise what is needed on the Gammapy side. On the example datasets we can use to test this, we can certainly use prod5b CTA simulations at 60 degrees zenith or the recent divergent pointing simulation set, which is currently being analysed by @Iburelli.

On the gammapy side, I think we need to adapt various elements:

• document user defined IRF addition
• adapt Makers to be agnostic to (offset, phi) or (fov_lon, fov_lat) IRF representations (or adapt IRF base
  class)
• build reduced IRF classes for e.g. anisotropic PSF maps. There is already draft work for this, see Implement PSFKernelMap #3689 that @LauraOlivera has started.