Use solar_system_ephemeris for barycentric corrections and coordinate transforms? #4942

Activity

1. mhvk

   added

   time

   coordinates

   on May 18, 2016
2. StuartLittlefair commented on Aug 25, 2016

   

   StuartLittlefair

   on Aug 25, 2016

   Last edited by StuartLittlefair

   Contributor

   More actions

   Following the work done by @mhvk in #5231, this wouldn't actually be too much of a challenge. Most of the transformation code base between co-ordinate systems can remain in place, but we would replace the calls to erfa.apcs13 and erfa.apci13 with calls to erfa.apcs and erfa.apci. The former use erfa.epv00 to calculate the heliocentric and barycentric position and velocity; the latter ask the user to supply their own.

   I'm thinking we should allow the transform_to method to accept an ephemeris argument which defaults to None, in which case the solar_system_ephemeris is used.

   😄React with 😄1Reacted by Marten van Kerkwijk
3. StuartLittlefair commented on Aug 27, 2016

   

   StuartLittlefair

   on Aug 27, 2016

   Contributor

   More actions

   OK I could do with some guidance on this from wiser heads; @eteq, @mhvk.

   We can do as I describe above but at the moment all the co-ordinate transforms have a hard-wired signature of (fromcoord, toframe). So there are two options:

   1. Change the signature of all transforms to (fromcoord, toframe, **kwargs). This allows us to add an ephemeris argument to transform_to which would work exactly as we have in get_body.
   2. Have the coordinate transforms "silently" respect the ephemeris context manager, e.g

   In [1]: ippeg = coord.SkyCoord.from_name('IP Peg')
   
   In [2]: ippeg.transform_to(coord.GCRS(obstime="J2000")) # use the builtin ephemeris by default
   Out[2]: 
   <SkyCoord (GCRS: obstime=J2000.000, obsgeoloc=[ 0.  0.  0.] m, obsgeovel=[ 0.  0.  0.] m / s): (ra, dec) in deg
       (350.78366528, 18.4178038)>
   
   In [3]: with coord.solar_system_ephemeris.set('jpl'):
      ...:     gcrs = ippeg.transform_to(coord.GCRS(obstime="J2000"))
      ...:     
   
   In [4]: gcrs
   Out[4]: 
   <SkyCoord (GCRS: obstime=J2000.000, obsgeoloc=[ 0.  0.  0.] m, obsgeovel=[ 0.  0.  0.] m / s): (ra, dec) in deg
       (350.78366528, 18.4178038)>
   

   Those two results are different by the way, at the 0.2 microarcecond level!

   Despite the former being more explicit, I am leaning towards the latter since, for many transforms, the "ephemeris" argument makes no sense, and so it seems odd to add it to transform_to.
4. StuartLittlefair commented on Aug 27, 2016

   

   StuartLittlefair

   on Aug 27, 2016

   Contributor

   More actions

   To help discussion, I have a branch which fully implements option 2 here
5. mhvk commented on Aug 27, 2016

   

   mhvk

   on Aug 27, 2016

   ContributorAuthor

   More actions

   @StuartLittlefair - I haven't looked at your branch yet, but like the idea of using the science state (although for items like light_travel_time, where one might not immediately think of coordinate transforms, I think an ephemeris element is still appropriate).
6. mhvk

   closed this as completedin #5273on Oct 20, 2016