[Difx-users] J2000 to date conversions {External}

[Phillips, Chris (S&A, Marsfield)]

The “celestial sphere” rotates wrt the earth. So any observations need to be appropriate rotated to a specific epoch (usually J2000). I want to be able to calculate the rotation terms myself for some tests.

I’m possibly using the wrong terminology, but B1950, J2000 and “date” are commonly used. I’m guessing date <==> J2022 currently.

Cheers
Chris

> On 12 Jan 2022, at 12:50, Leonid Petrov <Leonid.Petrov at lpetrov.net> wrote:
> 
> Chris,
> 
>  Why do you need it? Words like "equinox of date" are related to
> efforts to simplify computations in the pre-computer epochs.
> What do you want to achieve at the end?
> 
> Leonid
> 
>> On 2022-01-11 20:42, Phillips, Chris (S&A, Marsfield) via Difx-users wrote:
>> Hi al
>> Apologies for using the DIFX mailing list for a decidedly non-DIFX
>> question. I’m guessing there is a number of people on this list who
>> can help me with this query.
>> I am trying to convert some J2000 coordinates to “date
>> coordinates” (ie precess to a specific date).
>> The initial idea was to use python astropy (rather than perl/slalib)
>> to get with the times. However I am getting inconsistent results, and
>> cannot find any documentation on how to do this in astropy.
>> As an example I am trying to convert 1934-638 from J2000 to epoch
>> 2020-1-1. Various different approaches are here:
>> 1934-638 19h39m25.026s -63d42m45.63s J2000
>> astropy 19h41m15.463s  -63d39m55.69s
>> perl 19h41m13.563s -63d39m56.94s
>> SLA 19h41m10.545s -63d40m02.77s
>> Perl SLA 19h41m10.559s -63d40m02.76s
>> Online 19h41m15.5s     -63d39m56s
>> http://www.robertmartinayers.org/tools/coordinates.html
>> “Perl” is code I wrote years ago for Astro:Coord (on CPAN) based
>> on Fortran code at Hobart observatory
>> SLA is a hacked version from Caltech VLBI package “PRECESS” which
>> uses SLALIB
>> PerlSLA is a perl version which makes the same calls (mostly for
>> coding consistency check)
>> Online is a random webpage found via google.
>> Clearly astropy and the online version use the same algorithm (or
>> online is using astropy under the hood).
>> My perl version is similar to astropy, but slalib is different by a
>> lot. I remember years ago looking into this sort of stuff
>> (maybe B1950-J2000 rather than epoch precession) and SLALIB used a
>> very different implementation to astronomical
>> Almanac, following a paper which basically said the almanac
>> implementation was wrong.
>> FYI, the relevant code is:
>> Astropy:
>> from astropy.coordinates import SkyCoord, FK5
>> from astropy.time import Time
>> c = SkyCoord('19h39m25.026s', '-63d42m45.63s', frame='icrs')
>> t = Time('2020-01-01 00:00:00', scale='utc')
>> my_date = FK5(equinox=Time(t))
>> c_date = c.transform_to(my_date)
>> I’m a little dubious this is correct, given the use of
>> “Equinox”, while I really want to change Epoch.
>> The SLALIB implementation is:
>>      CALL SLA_MAPPA(2000D0, DATE, AMPRMS)
>>      CALL SLA_MAPQKZ(R2000, D2000, AMPRMS, RA, DA)
>> Where DATE is the MJD (checked to be consistent).
>> Does anyone have code which they trust to test these conversions (or
>> comments)?
>> Thanks
>> Chris
>> _______________________________________________
>> Difx-users mailing list
>> Difx-users at listmgr.nrao.edu
>> https://listmgr.nrao.edu/mailman/listinfo/difx-users