Page History

Jump to updates of 30 June 200620 Nov 2007

Wiki Markup
LAT Photons (FT1, LS-002) \[formerly Event Summary Data\]

...

These issues are resolved. See STGEN-30.

\[Jim pointed out that

...

20 November 2007

The current version of the FT1 template is here. Since the last update 13 months ago we have gained more experience with the kinds of analyses we be making with the FT1 files and the L1 pipeline has reached an advanced stage of development. Some aspects of the FT1 files need to be updated as a result.

23. GPS_OUT

(Digel) In the current iteration of the definition, we had assumed that whether or not the absolute times are based on the 1 pulse per second signal being synched with the spacecraft's GPS clock could be indicated with one flag in the header of the file. Anders points out that we really should be carrying this as a column in the FT1 files because the answer can be different for different events. GPS_OUT as a header keyword could be interpreted to indicate whether any event in the FT1 file had a time based on the internal oscillator, but that in itself would not be particularly informative.

For reasons that I don't quite grasp right now, correcting event times after GPS lock has been re-established for oscillator drift during periods when lock was lost is not really practical. Also, except in extreme circumstances (e.g., the fastest ms pulsar considered over a very long time range) the potential drifts are probably negligible. So the GPS_OUT flag being set for a given event would be just a warning to be careful.

Anders also suggests that we consider including the number of seconds since GPS lock was lost as a way of allowing users to estimate the relative qualities of the time accuracy. These times could range up to thousands of seconds in the worst case

I propose that we make GPS_OUT be a column as a 2-byte integer; 0 means that the event time was assigned while the GPS system was in lock. Values >=1 indicate the number of seconds since lock was lost. If the time since loss of lock is <1 s, it gets rounded to 0.

24. Replacing RECON_VERSION and CALIB_VERSION

(Digel) These columns are 2-byte and 3x 2-byte quantities that were intended to represent the version of Gleam and the versions of the ACD, CAL, and TKR calibrations (however exactly they are defined) that were used in the processing.

I propose to replace these with a single 2-byte integer PIPELINE_VERSION that is indexed to the configuration of the L1 pipeline (versions of Gleam and other software and versions of the calibrations) that were active at the time that a given event was run through the pipeline. When the L1 pipeline is under configuration control, these versions will be carefully tracked.

Anders: "We don't really have such a uber-version number yet. But we do need one."

With reprocessing, we'll want a way to tell whether a given event or file of events are in their most current processing versions. We could maintain a table or graph of most current PIPELINE_VERSION vs. event time.

25. Revisiting CONVERSION_TYPE and EVENT_CLASS

(Digel) These are 2-byte integer columns that define whether an event converted in the front or back section of the tracker and what event class the event satisfies.

As we currently manage the response functions, front and back are de facto different event classes. The EVENT_CLASS column is intended to make other distinctions, such as classes A and B for DC2. Right now for Pass5 we have still another column (CTBCLASSLEVEL) that is used to specify the event classes - so EVENT_CLASS is not actually being used.

What should do here depends in part on whether we rearrange the Pass 5 IRFs so that each event can be a member of one and only one event class; currently that is not the case.

In the future we can look forward to having still different sets of response functions - obviously - that will correspond to different versions of reconstruction and classification. In principle we could keep incrementing EVENT_CLASS (if we had a table someplace that mapped the response functions and processing versions into EVENT_CLASS values). Or we could have some kind of string column related to the name of the IRF that the event qualifies for. Or we could not try to protect people from themselves and let EVENT_CLASS have different meanings for different sets of response functions (possibly including a header keyword to name the response function family that applies to the file).

I don't have a recommendation about which option would work best.