desisurvey.utils.equ2gal_J2000 doesn't agree with NED about desisurvey

[weaverba137]

That function is using a custom rotation. Has anyone tried this using astropy.coordinates?

[weaverba137]

PS, aren't rotations implemented by symmetric matrices? Because the rotation matrix in that function is not symmetric.

[sbailey]

astropy.coordinates seems fast enough in this case:

def radec2lb(ra,dec):
    from astropy.coordinates import SkyCoord
    from astropy import units
    c = SkyCoord(ra*units.deg, dec*units.deg)
    return (c.galactic.l.value, c.galactic.b.value)

n = int(1e6)
ra = np.random.uniform(0,360, size=n)
dec = np.random.uniform(-90,90, size=n)  #- ok not uniform in cos(dec)

%time l,b = radec2lb(ra, dec)
CPU times: user 966 ms, sys: 216 ms, total: 1.18 s
Wall time: 1.19 s

We've had trouble with astropy.coordinates for alt,az calculations for survey planning because it wants to get things accurate to sub-arcsecond precision and it doesn't know about the earths wobble terms into the future. But for equatorial to galactic conversions this seems fine. Any objections?

[mlandriau]

Ben, Rotations are represented by orthogonal matrices, not symmetric ones. You can verify that the matrix in the routine is indeed orthogonal, i.e. RR^T = I. For a rotation about one of the coordinate axes, the matrix will be anti-symmetric, but for a rotation about an arbitrary axis, like in this case, the matrix doesn't show any obvious symmetries. Martin

…

On Thu, Mar 30, 2017 at 10:45 AM, sbailey ***@***.***> wrote: astropy.coordinates seems fast enough in this case: def radec2lb(ra,dec): from astropy.coordinates import SkyCoord from astropy import units c = SkyCoord(ra*units.deg, dec*units.deg) return (c.galactic.l.value, c.galactic.b.value) n = int(1e6) ra = np.random.uniform(0,360, size=n) dec = np.random.uniform(-90,90, size=n) #- ok not uniform in cos(dec) %time l,b = radec2lb(ra, dec)CPU times: user 966 ms, sys: 216 ms, total: 1.18 s Wall time: 1.19 s We've had trouble with astropy.coordinates for alt,az calculations for survey planning because it wants to get things accurate to sub-arcsecond precision and it doesn't know about the earths wobble terms into the future. But for equatorial to galactic conversions this seems fine. Any objections? — You are receiving this because you are subscribed to this thread. Reply to this email directly, view it on GitHub <#25 (comment)>, or mute the thread <https://github.com/notifications/unsubscribe-auth/ASznwoOH1wGfONCCUtmZu0DxaClwNcVfks5rq-pLgaJpZM4Mt5ya> .

-- Martin Landriau Lawrence Berkeley National Laboratory 1 Cyclotron Road Mailstop 50R5008 Berkeley, CA 94720 USA -- Tel: [phone] Fax: [phone]

[weaverba137]

OK, fair enough, I was just tying to figure out why the function was so completely wrong. Seems like astropy.coordinates is the way to go here.

[mlandriau]

The bug was in the spherical-to-cartesian transform before the rotation was applied (the angles were mixed up). Now gives the same answer as astropy to better than 10^-5 degrees.

P.S. Ben: part of my previous comment wrong. When referring to rotation matrices about a coordinate axis, I should have said that they be decomposed into the sum of a diagonal matrix and an anti-symmetric matrix.

[sbailey]

It's reassuring to know the source of the discrepancy, but let's switch to the astropy.coordinates version anyway since that already supports scalar, list, and numpy array inputs. This implementation only supports scalar inputs and thus will be very slow for N>>1 targets.

Please also re-enable the unit test on this to check those cases.

[weaverba137]

Note that #29 did not actually implement @sbailey's request to use astropy.coordinates.

[dkirkby]

The only call to equ2gal_J2000() is now in afternoonplan where it is commented out. All new desisurvey code is using astropy.coordinates via helper functions in desisurvey.utils. Closing.