Response to JIRA GRINF-38
https://jira.slac.stanford.edu/browse/GRINF-38 (by Denis D, Lucas G, David S)
The fundamental issue is: providing information on the quality of the event-by-event absolute time stamps to the users of the FT1, FT2, and/or Merit files, primarily for pulsar phase analyses.
The definition of "adequate quality" depends on the analysis in progress. Loose timing precision is perfectly acceptable for a slow pulsar with low photon statistics (the bins of the phase histogram will be wide).
Furthermore, absolute time drift is not a simple function of time since GPS lock-loss. Eric Siskind provided a way to estimate the typical drift. Actual drift could be a bit better or a bit worse.
We therefore believe that to handle data samples with GPS-lock loss users should simply be warned about lock loss, and methods to evaluate the timing quality should be recommended by the Pulsar group. Suggestions below.
In light of this, it seems less important that a cumulated time-since-lock-loss variable be included in the end-user data files, especially if it is technically challenging to implement.
EXECUTIVE SUMMARY:
1) Having 'sourceGPS()' in the FT1 and Merit is essential (see https://jira.slac.stanford.edu/browse/GRINF-44) ;
2) gtpphase and/or gtbary should emit warnings, such as "events without GPS lock in this data sample", possibly listing fraction of events, duration, start and stop time, etc. A separate warning could be issued if the data set or data run had no GPS lock at the first event.
3) Users may elect to remove some time intervals from the analysis. gtselect and gtexpcube already handle selection on time intervals.
4) If the cumulated time since GPS lock was lost can be included in FT1 and/or Merit and/or FT2 and/or the metadata information then that is good and useful but not essential.
SUGGESTIONS TO EVALUATE TIMING QUALITY
1) The user can calculate elapsed time since GPS lock-loss within their own data sample, and use E. Siskinds' typical or maximum drift rates to estimate the deviation from true absolute time. [anders] How can the user do this if they only have individual, non-successive events from multiple runs and the only information per event is 'sourceGps()? (See Dave S reply #1 towards bottom of page.)
2) "Vela pulsar peak position versus elapsed time", as in Marianne's IRF monitoring tasks , will, in many cases, provide a limit on the deviation from true absolute time.
[]https://confluence.slac.stanford.edu/display/DC2/2008/03/05/Absolute+timing+using+the+Vela+pulsar
COMMENTS ON THE JIRA COMMENTS
A) The choice of the technical discussions mentioned by Anders & Jim are beyond us. Andrea Tramacere's slides for the FT2 review (link here) suggest that he knows quite well how to accumulate information across run and file boundaries [anders] No. FT2 is made on a per run basis. . So... if the digi L1Proc can generate a cumulated value to be stored with the metadata, then great! do it! And if a cumulated quantity can be stored in the FT2 (and the user then imposes some condition for it to then affect the GTI !?!?) then also good. [anders] We'll try 
B) Nota bene that Masa & James were thinking in December and January about how to add "ephemerides quality" messages to gtephem (link to his note, here). Perhaps if we start
adding "quality control quantities" to the files, we should do it consistently across ephemerides to timestamp space. In that case, space craft position precision might be thought about at the same time (although we expect it to always be right). See HERE for the "Five Easy Pieces of Good Phase Calculations".
C) Siskind reminds us in his comment that there is a 1 or 2 second lag in reporting GPS lock loss, and as much as a 20 second latency before reporting that GPS lock has returned. For most analyses, this is unnoticeable (see "slow, faint pulsars", above). For precision studies (high statistics on a millisecond pulsar?) the analyst will need to demonstrate adequate timing quality. (EJS: Actually, I remind you that even after the spacecraft reports that it has regained GPS lock, it may be up to 20 seconds until this is truly the case as far as the LAT is concerned. There is NO indication given when the PPS signal furnished to the LAT is locked to the PPS signal from the GPS receiver - only when the GPS receiver is locked to the GPS satellites.)
Dave S reply #1 It's post-processing by the User!
Say you have a few months of data in some few degree ROI near the galactic plane. 3 degree radius is 9*pi ~ 30 sq. degrees.
Is the all sky raw gamma rate about 20 Hz? So 10 Hz after "transient" or "source" cuts? Dominated by the Milky Way diffuse? The whole sky is 40 k square degrees. Milky Way maybe 5k square degrees?
So a W.A.G. for the gamma rate in the ROI is 10Hz*30/5k = 0.06 Hz, that is, 3 or 4 photons per minute. For the larger ROI's needed for gtlike, the rate is higher.
So now the analyst checks the time sequence of events without GPS lock in his data sample. He finds sequences of a few events here and there, and either says "times are probably fine for my slow, faint pulsar, I'll keep all the data" or he says "I'm a paranoid perfectionist working on a high precision analysis, I'll throw them away" and either way it doesn't amount to much. [anders] I suppose I'm paranoid here, but if we have been out of lock for some time and the photons you see are on the tail of that then the only thing you can say is that we have only been out of lock for N minutes (which would be the last time we pointed in that direction, assuming the photons from the previous pass were locked). If that is good enough (and I should be able to answer my own question with all the information available, but I'm lazy) then there is no problem. Of course, having the accumulated out-of-lock time makes all this much simpler (with the only exception being if we start a run with no lock). (See Dave S reply#2, below.)
-OR- the analyst find a sequence of hundreds of photons without GPS time lock, and he starts to calculate maximum drift. Or he checks the Vela peak position using Marianne's IRFmon tools. Or he just throws them away.
Anything wrong with my reasoning? David.
Dave S reply #2 Good point Anders -- I hadn't thought about the >1/2 orbit that the ROI is out of sight. Well then... if you don't have the accumulated out-of-lock time, then either you toss the few events that don't have GPS lock when the ROI first returned to view (presuming that it was a short outage and that the GPS comes back soon) ; or you do the Vela-check that the times are okay.
Of course, this is getting more complicated, because Joe User didn't think that he needed to keep track of where he was in the orbit when he was validating his times. So now the time sequence I mentioned about has to be plotted versus theta (photon angle from the LAT z-axis) or something like that.
I've always said that we'd like to have the accumulated time. You & yours have said a different times that it's do-able, or too much of a pain. So I think I've always said that if we can have it, great, and if we can't, then Joe User will have to figure something else out.
I (or rather, we the Pulsar group) was asked to formulate a clear request to the ST keepers, so that Davi d Band could then refuse or implement. So... I'm not quite sure how to proceed.