Use sky_to_fov() also for RADEC FoVAlignment in make_map_background_irf

[SimoneMender]

Suggestion to fix issue #3510

[bkhelifi]

Hello @SimoneMender ,
Thank you for this PR. @maxnoe, is the SkyOffsetFrame(origin=pointing_icrs) compatible with the CTAO official frame in which the IRF can be defined? The link with pyrirf is obvious here and a coordination is needed.

[maxnoe]

Unfortunayley, there are no official CTAO celestial coordinate definitions yet

[maxnoe]

Unfortunayley, there are no official CTAO celestial coordinate definitions yet

[bkhelifi]

It was my fear... And do you think that, at least temporary in Gammapy&pyirf, this definition from astropy could be used? At least for testing purposes....

[SimoneMender]

From my point of view, the issue is that according to the GADF definition (https://gamma-astro-data-formats.readthedocs.io/en/latest/general/coordinates.html#coords-fov), "FOV LON should increase with decreasing OTHER LON". As this is the coordinate system in which a background model has to be stored, it is mandatory to switch the sign of longitude angle when creating a background map. This is exactly covered by the sky_to_fov() function.

[maxnoe]

I think that CTA(O) definitions are not relevant here.

As of now, Gammapy only supports GADF as input format. So what applies are the definitions of the field of view coordinate system of GADF.

And GADF defines the FOV longitude to have the opposite sign to the system ot is aligned with, for both alignments (ALTAZ / RADEC).

We should probably implement this using astropy coordinate frames like GADFFoVAltAz and GADFFoVICRS.

[SimoneMender]

Isn't the parameter sky_coord already following the definition of the right coordinate system (in the case of RADEC FoVAlignment), as it is created from the reference geometry geom, which is a ~gammapy.maps.WcsGeom object?

gammapy/gammapy/makers/utils.py

Line 191 in 0a9323a

sky_coord = map_coord.skycoord

[registerrier]

Thanks @SimoneMender .
As far as I know, sky_to_fov does the same thing as what was done here (except for the sign of fov_lon). But it does not check the input systems of the coordinates.

The issue lies probably in the sky_to_fov implementation, taking ra and dec instead of a full SkyCoord.

[registerrier]

Currently, it is not guaranteed that pointing_icrs is actually a SkyCoord in RADEC system if the input is not a FixedPointingInfo. This must be fixed before calling the ra and dec attributes.

[registerrier]

Also is it guaranteed that sky_coord is in RADEC system?

[bkhelifi]

@SimoneMender can you update your code from the main, such that the CI tests can pass successfully?