Repository navigation
GPS-UTC corrections for astropy.time? #2134
Description
Hi All (esp @mhvk and @taldcroft),
So with all of the current time functionality, astropy seems "correct" with the pulsar timing "standard" TEMPO2 to about the 10-20 ns level.
The next most important correction, which could easily get us to the couple ns level would be the addition of the (known) GPS (which, effectively, all of our observatory measurements are based on) to true UTC corrections which are sent out by the BIPM in Circular T. http://www.bipm.org/jsp/en/TimeFtp.jsp?TypePub=publication
Given the (really cool!) infrastructure that is already in astropy to download and incorporate new data (like for IERS), adding this capability to correct given times to "true" UTC seems like it would be fairly straight-forward. It seems like applying the correction to a "scale='utc'" time should be optional, though, possibly via a keyword when you make a Time instance.
Opinions? Thanks,
Scott
Activity
mhvk commentedon Feb 26, 2014
@taldcroft - given the above, it seems we may need a
scale=gpsafter all... (#1879). Not completely sure whether in the network, it should connect to UTC or TAI. On the one hand, TAI-GPS is also explicitly included in the bulletins too and it would make interpolating less problematic around leap seconds. On the other, I think GPS times used in observatories are usually given as "UTC(GPS)" (@scottransom?)From a quick look, the files the differences are disseminated in [1] will need some work to allow them to be read in to a table (IERS is much more civilized...). @scottransom - do you know of better summaries?
Also, I do wonder whether indeed there should be a "precise" and a "rough" option. Not entirely simple...
[1] e.g., ftp://ftp2.bipm.org/pub/tai/scale/UTCGPSGLO/utcgpsglo12.ar
taldcroft commentedon Feb 26, 2014
@scottransom - this sounds good. @mhvk understands the issues a bit better (from practical experience), but maybe you could help us by proposing an outline of the specific transformations to apply, how best to get the data (including which files need to be parsed and which data values are relevant), and a candidate API that would work for you. We can iterate from there.
One thing I noticed from the [1] link @mhvk provided is that if you list that directory there doesn't seem to be any 2013 data (ftp://ftp2.bipm.org/pub/tai/scale/UTCGPSGLO/). So there is some mix of archive and "bulletin" style data?
demorest commentedon Feb 26, 2014
@mhvk - to answer your question, in typical pulsar timing usage we do not use true "GPS time" which (I think) has something like an 18 or 19 sec offset from TAI. Our "GPS" timescale stays on the same integer second as UTC but otherwise tracks GPS time. tempo2 does call this "UTC(GPS)" but I don't know how standard that notation is outside of pulsar-land.
scottransom commentedon Feb 26, 2014
@taldcroft - yes, there are a mix of archive and bulletin data. Seems like it would be able to package up the archive stuff fairly easily and then just focus on the bulletins. The UTC-GPS offsets from 1993-2003 are in ftp://ftp2.bipm.org/pub/tai/scale/UTCGPS/ and the later ones are in ftp://ftp2.bipm.org/pub/tai/scale/UTCGPSGLO as you already showed.
mhvk commentedon Jan 13, 2015
I cleared the milestone on this as it won't be possible to get this in for 1.0. It would seem very nice to have, and once we have the automatic downloading of IERS A in place (#3275), this would be a logical sequel. Now the only thing is to find time to implement it...
taldcroft commentedon Nov 2, 2015
Summary:
aarchiba commentedon Jun 8, 2022
I chased down how to do this for pulsar clock corrections. It's a bit messy but doable (and of course I'm happy to work the code into Astropy if that would be helpful). There is a complexity that there are two kinds of "GPS time": the GPS Combined Clock, and time inferred from this using the transmitted almanac predictions of how to correct this to UTC. The corrections from these two timescales to UTC are different. The latter seems like a more likely choice for GPS time standard devices, but alas the BIPM only publishes the relevant correction back to 2011.
Corrections obtained from the BIPM data: https://nanograv.github.io/pulsar-clock-corrections/T2runtime/clock/gps2utc.clk.html
Code to do it: https://github.com/nanograv/pulsar-clock-corrections/blob/main/import_bipm.py
mhvk commentedon Jun 8, 2022
@aarchiba - it would be wonderful to have this in astropy! For implementation, I guess it would need a new time scale, that is connected with an already existing one (see https://docs.astropy.org/en/latest/time/index.html#time-scale) with some new
delta_gps_???(???=tai??) attribute that by default gets automatically set using the BIPM tables (with possibly an option to choose C0 or C0'?).One tricky bit is the name, since we already have
format='gps', which is what is returned when one doest.gps. Possibly the scale should be 'utc_gps'? One can also argue, as in #1879, that the format is unlikely to be used much, so that perhaps one can change (after all, one can still get the value witht.to_value('gps'). On the other hand, perhaps it is not as important to havet.gpsreturn a GPS-scale time, since mostly the transformation will be in the other direction (and we could have a newto_scale('gps')method?).Anyway, this probably best is done in stages - first get a the retrieval routines in, plus a function/method to calculate the offset (likely just as a
Quantity), which could be added to a given time object, and then a second one to add the actual time scale, etc. The former is perhaps most logical inutils.iersor a newutils.bipmor so.aarchiba commentedon Jun 8, 2022
I think it would be good to better understand the C0/C0' issue before making a time scale (two time scales?). Specifically, if someone has "GPS time", which are they more likely to have? How can they find out?
The retrieval routines are standalone apart from
astropy.utils.data.download_file, so they should drop in quite nicely. I'm planning to do something with the TT to TAI tables too (I'm trying to autogenerate all the timing-related files TEMPO2 uses). I expect Astropy has appropriate plumbing for applying the clock corrections, so if we can get the various data loaded we should probably have a discussion about how to map all this to Astropy time scales.scottransom commentedon Jun 8, 2022
Love that webpage in your clock-correction repo, @aarchiba! Re the C0/C0' issue, is there a plot that shows the difference between the two? I would guess that they are really small. Or is there maybe a DC-offset as well as tiny wiggle?
mhvk commentedon Jun 8, 2022
@aarchiba - makes sense to first get the retrieval routines working. If we have a
delta_gps_taiattribute, then perhaps we can use that to separate the types of GPS timescale.Just to be sure I understand at least conceptually: one could have a GPS clock that just takes the time from the satellites literally, or one could have one that already pre-corrects the times using some predicted offsets, which may need some further correction. Is that right? And is
C0the offset between "truth" and what GPS satellites emit, andC0'the difference with predictive models?aarchiba commentedon Jun 9, 2022
That is my understanding, yes. The predictive models are transmitted as part of the "almanac" message.
aarchiba commentedon Jun 9, 2022
The GPS Common Clock is steered to match UTC (as kept by the USNO), and the predictive coefficients just capture the expected deviations in the steering (presumably the steering has continuity constraints?). The difference seems to be short-term only, and of order a few ns, while the individual corrections are of order 10 ns and contain trends.
(By the way, autogenerated pages showing selected comparisons are on the wishlist for the clock correction repository.)
mhvk commentedon Jun 9, 2022
I guess for the machinery we can follow a bit what we do for IERS - have some kind of "Auto" correction that perhaps picks C0 and C0' as you do for nanograv, but allow the user to set the table used. For most use cases, the rms of 1 ns even if you pick the wrong C0 or C0' would seem "good enough"!
aarchiba commentedon Jun 9, 2022
Particularly as the published values are integer nanoseconds we can't hope for a lot better.
aarchiba commentedon Jun 13, 2022
Just for fun here's the TT to TAI BIPM corrections (which include a forecast, drawn as a line) from successive BIPM bulletins.
aarchiba commentedon Jul 11, 2022
I think the two things that could go in are
Code to do both is (moved to) here: https://github.com/ipta/pulsar-clock-corrections/blob/main/bipm.py
A first step would be to just plonk the two bits of code (with the PINT stuff removed) into Astropy somewhere, so people could manually apply the corrections.
A second step would be to simply make TT(BIPMyyyy) a permissible timescale for Astropy. (What about TDB(BIPMyyyy)?) That gives a well-defined way for users to specify that they want this correction applied, and which one.
A third step would have to be to figure out how users should specify that their data is referenced to an uncorrected estimate of UTC (timescale UTC(GPS) maybe? UTC(GPS-uncorr) or some more elaborate monstrosity?) and then apply one or other version of the GPS corrections upon conversion.
If these two arise as new timescales users can request conversion to, there shouldn't be compatibility headaches (should there?). If one were comfortable with a profusion of timescales one might consider allowing UTC(GBT), which would involve the Green Bank Telescope observatory clock corrections - not as a scale provided by Astropy but as one users (or PINT) could define and then have clean, coherent access to clock correction machinery that kept careful track of what scale everything was in.