search

ipta / pulsar-clock-corrections

Distribution point and tools for observatory clock corrections for pulsar timing.
BSD 3-Clause "New" or "Revised" License
6 stars 5 forks source link

Latest `time_gbt.dat` differs from tempo version #16

Closed dlakaplan closed 8 months ago

dlakaplan commented 10 months ago

Part of #15 : time_gbt.dat on the repo (and at https://github.com/nanograv/tempo/tree/master/clock) differs from the latest version https://www.gb.nrao.edu/~fghigo/timer/time_gbt.dat in the first ~14 records. In the recent one those values are 0, but in the one on the tempo repo those are -3 ns. Was there some revision back?

dlakaplan commented 10 months ago

I've asked Ryan Lynch

dlakaplan commented 10 months ago

Ryan says:

Thanks for bringing this to my attention. I'm not sure why those first 14 entries differ. It was not intentional. We did have to make some modifications to the scripts that generate that file but it should not have impacted the early entries (and I checked that the new entries were correct). I'll have to look into this and get back to you.

aarchiba commented 8 months ago

It seems the problem remains, and the discrepancy is stopping this site from updating. Unfortunately the easy fix, just accepting the version from the observatory, discards those first 11 values and replaces them with zeros. I'm inclined to say the harm of doing this is less than the harm of letting the GBT timing info go out of date. The old values will persist in version control.

aarchiba commented 8 months ago

Made the change, with explanatory comment and pointer to where to find old values.

dlakaplan commented 8 months ago

Ryan said:

A while back you noted that the time_gbt.dat file at GBO had some conflicting entries in the first few lines compared to the NANOGrav records. Sorry it took a while but we went back to the archived clock corrections from way back then and they agree with the NANOGrav records (not surprisingly). The software that updates time_gbt.dat seemed to run into some sort of weird error due to an array variable exceeding a certain size and we think this caused some of the bogus entries. That has now been fixed and the time_gbt.dat file should have the correct historical entries going forward.