Repository navigation
Behaviour of apply_space_motion without distance without a distance #10092
Description
Description
I'm confused about the behaviour of apply_space_motion when the SkyCoord to which it applies hasn't defined a distance. Just following the example from the documentation, if you remove the distance kwarg you get
>>> c = SkyCoord(l=10*u.degree, b=45*u.degree, distance=100*u.pc,
pm_l_cosb=34*u.mas/u.yr, pm_b=-117*u.mas/u.yr,
frame='galactic',
obstime=Time('1988-12-18 05:11:23.5'))
>>> c.apply_space_motion(dt=10. * u.year)
WARNING: ErfaWarning: ERFA function "starpm" yielded 1 of "binary logical OR of the above warnings" [astropy._erfa.core]
Out[77]:
<SkyCoord (Galactic): (l, b, distance) in (deg, deg, pc)
(10., 45., 10000000.)
(pm_l_cosb, pm_b, radial_velocity) in (mas / yr, mas / yr, km / s)
(0., 0., 0.)>which produces a very confusing result in which the resulting coordinates are located at a distance of 10000000 pc and the proper motions are zero, but the original coordinates have not changed.
I would expect that if the parallax is zero, only the proper motion would be applies (i.e., the equivalent of assuming the object is at an infinite distance). Am I missing something?
Activity
StuartLittlefair commentedon Apr 1, 2020
Damn! This looks like a problem in
erfa, which is intended to duplicate the functionality of the IAU SOFA library with a more permissive licence. Specifically the issue lies in the routineserfa.starpmanderfa.starpv.The problem is that when you drop the distance from the
SkyCoord,erfatries to treat the object as if it were at "infinite distance". In practice this means setting the parallax to 1e-7 arcseconds (10 Mpc).In an intermediate step, the
erfaroutine calculates the cartesian position and velocity vectors of your star, but at this large distance the space velocity is >1/2 the speed of light, whicherfa.starpvdoesn't like. As a result it sets the velocity vector to 0. This is why you see no change in the coordinates.I think three things need to happen here:
SkyCoord.apply_space_motionwe should catch the cases whereerfasets the distance to 10 Mpc and not set the distance in the resulting SkyCoord.erfabecause as it standserfa.starpmis not suitable for objects with moderate proper motion but no distance.erfatracks SOFA, and the people behind SOFA are generally conservative about changes to the code. I can imagine the reply to a request being that this is an artificial problem, as the majority of high proper motion sources have a known distance...erfaand our wrapper of that library is not producing very useful Python warnings in that case. Normally a warning more along the lines ofor
is raised, which is more useful (even if it does involve digging into the erfa source code for an explanation).
pllim commentedon Apr 1, 2020
Thanks for investigating, @StuartLittlefair ! If this issue has been reported to ERFA, please cross-link here.
albireox commentedon Apr 2, 2020
Thanks for the detailed explanation. Is there a workaround for this in the meantime? Something like artificially setting the distance to a large value so that is still treated, in practice, as being at an infinite distance?
StuartLittlefair commentedon Apr 2, 2020
@albireox - yes that would work. For the object above you could set the distance to 200 kpc or so and the routine will work; you have to ignore the returned distance on the object. I'm about to raise an issue on the ERFA repository. Do you have a real-world example where this is needed; i.e an object with proper motion of > 20mas/yr but no known distance?
albireox commentedon Apr 2, 2020
No, not really. I was researching
apply_space_motionto convert the epoch of the coordinates in several large catalogues, some of which have proper motions but no parallaxes, but I don't have a specific case in mind. In fact I want to change all the coordinates to Gaia J2015.5 but keep them BCRS so I don't want to apply the parallax correction.Ultimately that's a very trivial algebraic problem and maybe I don't need astropy to deal with it, but it simplifies things because I can have astropy calculate the delta epochs.
StuartLittlefair commentedon Apr 2, 2020
Ah. Well you don’t need to remove the distance then.
apply_space_motionis not applying a parallax correction: coordinates that are barycentric like ICRS remain barycentric.The parallax is used in two ways: the first is so the distance can be updated to allow for motion along the line of sight. The second is to handle light travel time and retardation effects.
mhvk commentedon Apr 3, 2020
It would seem to me the warning should actually lead to a failure rather than not applying anything. Perhaps we could introduce an additional argument to
apply_space_motionthat allows one to pass in an assumed parallax (thus overriding the default 0.1 mas)? Alternatively, we could simply bypassstarpmfor the case of no parallax, and use the representation machinery directly.StuartLittlefair commentedon May 4, 2020
Looks like it might be a simple fix in the end; just switch to
erfa.pmsafeand make sure we set the distance correctly on new SkyCoord.