Exception raised when converting from LSRK to other frames

Astropy
1

I am trying to convert velocity from LSRK to ICRS (or any other frame), following the example in https://docs.astropy.org/en/stable/coordinates/velocities.html#. However, an exception is raised in SkyCoord.transform_to(). I would appreciate some help in understanding where I’m going wrong.

Astropy version: ‘5.2.2’

Minimum failing example:

from astropy.coordinates import SkyCoord, LSRK, ICRS
import astropy.units as u
mysource = SkyCoord(‘04h21m59.43s +19d32m06.4’, frame=LSRK, radial_velocity=25* u.km / u.s)
mysource.transform_to(ICRS())

The exception is:
TypeError: Position information stored on coordinate frame is insufficient to do a full-space position transformation (representation class: {data.class})

Full traceback:

TypeError Traceback (most recent call last)
Cell In[1], line 4
2 import astropy.units as u
3 mysource = SkyCoord(‘04h21m59.43s +19d32m06.4’, frame=LSRK, radial_velocity=25* u.km / u.s)
----> 4 mysource.transform_to(ICRS())

File ~/Anaconda3-2023.03/lib/python3.10/site-packages/astropy/coordinates/sky_coordinate.py:702, in SkyCoord.transform_to(self, frame, merge_attributes)
698 generic_frame = GenericFrame(frame_kwargs)
700 # Do the transformation, returning a coordinate frame of the desired
701 # final type (not generic).
→ 702 new_coord = trans(self.frame, generic_frame)
704 # Finally make the new SkyCoord object from the new_coord and
705 # remaining frame_kwargs that are not frame_attributes in new_coord.
706 for attr in set(new_coord.frame_attributes) & set(frame_kwargs.keys()):

File ~/Anaconda3-2023.03/lib/python3.10/site-packages/astropy/coordinates/transformations.py:1579, in CompositeTransform.call(self, fromcoord, toframe)
1576 frattrs[inter_frame_attr_nm] = attr
1578 curr_toframe = t.tosys(**frattrs)
→ 1579 curr_coord = t(curr_coord, curr_toframe)
1581 # this is safe even in the case where self.transforms is empty, because
1582 # coordinate objects are immutable, so copying is not needed
1583 return curr_coord

File ~/Anaconda3-2023.03/lib/python3.10/site-packages/astropy/coordinates/transformations.py:1341, in BaseAffineTransform.call(self, fromcoord, toframe)
1339 def call(self, fromcoord, toframe):
1340 params = self._affine_params(fromcoord, toframe)
→ 1341 newrep = self._apply_transform(fromcoord, *params)
1342 return toframe.realize_frame(newrep)

File ~/Anaconda3-2023.03/lib/python3.10/site-packages/astropy/coordinates/transformations.py:1194, in BaseAffineTransform._apply_transform(self, fromcoord, matrix, offset)
1191 # Some initial checking to short-circuit doing any re-representation if
1192 # we’re going to fail anyways:
1193 if isinstance(data, UnitSphericalRepresentation) and offset is not None:
→ 1194 raise TypeError(
1195 “Position information stored on coordinate frame "
1196 “is insufficient to do a full-space position "
1197 “transformation (representation class: {data.class})”
1198 )
1200 elif (
1201 has_velocity
1202 and (unit_vel_diff or rad_vel_diff)
(…)
1206 # Coordinate has a velocity, but it is not a full-space velocity
1207 # that we need to do a velocity offset
1208 raise TypeError(
1209 “Velocity information stored on coordinate frame is insufficient to do”
1210 " a full-space velocity transformation (differential class:”
1211 f” {data.differentials[‘s’].class})"
1212 )

TypeError: Position information stored on coordinate frame is insufficient to do a full-space position transformation (representation class: {data.class})

2

There are two issues here, and the first is arguably a bug that can be fixed.

The first issue is that you are specifying a 2D coordinate, with unspecified distance from the origin. Astropy raises the error you see when the transformation of a 2D coordinate includes a shift in origin, since handling such a shift is undefined. The transformation from LSRK to ICRS doesn’t actually include a shift in origin, but it does include a velocity shift, and the bug in Astropy is that the presence of the velocity shift is enough to trigger the above error, because the code doesn’t looking deep to check if the origin shift is actually nonzero. I encourage you to report this bug on Astropy’s GitHub, and it should be straightforward to fix.

In the meantime, you can easily work around this bug by specifying a distance, any distance, when instantiating your SkyCoord, e.g.:

mysource = SkyCoord('04h21m59.43s +19d32m06.4', distance=1*u.kpc,
                    frame=LSRK, radial_velocity=25* u.km / u.s)

After you address the first issue, the second issue is that you are specifying only a radial velocity, with unspecified proper motion. Astropy cannot apply the velocity shift between LSRK and ICRS without knowing what the proper-motion values are. If you intend them to be zero, you still need to specify them explicitly, e.g.:

mysource = SkyCoord('04h21m59.43s +19d32m06.4', distance=1*u.kpc,
                    frame=LSRK, radial_velocity=25* u.km / u.s,
                    pm_ra_cosdec=0*u.mas/u.yr, pm_dec=0*u.mas/u.yr)

Hope that helps!

3

Thank you for this explanation and workaround! I had tried distance=astropy.coordinates.spectral_coordinate.DEFAULT_DISTANCE and proper motions = None, but hadn’t tried proper motions = 0. I will submit an issue on github.

4

This behavior has been reported already in Issue #12731.(The problem with the use of finite differences in Astropy transforms. · Issue #12731 · astropy/astropy · GitHub).
I also subsequently ran into the problem described in the issue with superluminal radial velocities when transforming to GCRS.