Bug #3199
Fix ambiguity in position angle
Status: | Closed | Start date: | 04/03/2020 | |
---|---|---|---|---|
Priority: | Urgent | Due date: | ||
Assigned To: | Knödlseder Jürgen | % Done: | 100% | |
Category: | - | |||
Target version: | 1.7.0 | |||
Duration: |
Description
The GSkyDir::posang()
returns different position angles depending on whether coordinates are present in the celestial or the galactic frame. If galactic coordinates are present the position angle is with respect to Galactic North, if celestial coordinates are present the position angle is with respect to celestial North.
Recurrence
No recurrence.
History
#1 Updated by Knödlseder Jürgen over 4 years ago
It’s probably best to introduce a GSkyVector
class that associates a sky position to a direction on the sky. This class can then handle the transformation from the celestial to the Galactic coordinates, and there would be no ambiguity anymore. The posang()
methods should then be removed from GSkyDir
.
Note that adding a length attribute to that class could then be used to deal also with polarisations.
#2 Updated by Knödlseder Jürgen over 4 years ago
- Status changed from New to In Progress
Here a list of GammaLib classes where posang()
is currently used:
include/GSkyDir.hpp src/model/GModelSpatialElliptical.cpp => impacts computation in eval() method src/sky/GSkyDir.cpp inst/cta/src/GCTAOnOffObservation.cpp => no impact since not used inst/cta/src/GCTAPointing.cpp => impacts detx/y computation in instdir() method inst/cta/src/GCTAResponseCube.cpp => impacts position angle in irf_elliptical() method inst/cta/src/GCTAResponseIrf.cpp => impacts nroi_radial(), nroi_elliptical() and irf_elliptical() methods inst/spi/include/GSPIResponse.hpp => impacts azimuth() method inst/spi/src/GSPIResponse.cpp => impacts set_cache() method inst/cta/test/dev/test_irf_elliptical.py inst/cta/test/dev/test_irf_radial.py inst/cta/test/dev/test_npred_elliptical.py inst/cta/test/dev/test_psf_radial.py
And here where
posang_deg()
is used:include/GSkyDir.hpp inst/com/include/GCOMOad.hpp => impacts phi() method cscripts/csphagen.py
#3 Updated by Knödlseder Jürgen over 4 years ago
- % Done changed from 0 to 50
I added a coordsys
argument to the posang()
and posang_deg()
methods that either can take the value "CEL"
or "GAL"
, returning the position angle either with respect to celestial North or to Galactic North. In all cases the position angle is counted counter clockwise.
I added some unit tests to the test_GSky.cpp
file to test the computations.
make check
does not reveal any problem.
#4 Updated by Knödlseder Jürgen over 4 years ago
- Status changed from In Progress to Pull request
- % Done changed from 50 to 100
I check all uses of posang()
and posang_deg()
and in general no impact is expected. Importantly, the orientation of the ellipse in GModelSpatialElliptical::eval()
depends on the definition of the position angle, hence we have to see whether the orientation of the ellipse in fit is changed.
#5 Updated by Knödlseder Jürgen over 4 years ago
- Status changed from Pull request to Closed
Merged into devel
.