Following up on previous work (here and here), this is to implement codes that provide a T0 which represents the time of a collision with respect to the trigger, given that the trigger is issued with respect to the RHIC clock. This T0 is retrievable from the timing data of trigger detectors already available in StEvent. This T0 has previously been ignored until BES-II, where it was first noticed in TPC tracking for the long bunches in FXT data. Given that there are also long bunches in the collision data, additional functionality is needed. And given that this T0 may be of interest to more subsystems than just the TPC, it is prudent not to place this work under the TPC subsystem.

Needed components:

1. A class that can be used to determine the T0 correction, and be used in calibrating parameters of the correction
2. A database table with dataset-specific parameters for the parameters of the T0 correction
3. Modification of any subsystem codes that would use this T0 (for now, this is just the StTpcHitMoverMaker)
4. BFC chain options to turn the correction on/off at the command line
5. A calibration macro

Below are specifics on each of these.

---

1. StEventUtilities/StEbyET0.h,cxx

Given that the correction is determined by using information only from StEvent plus the database, the StEventUtilities directory seems a reasonable home for this code. The only concern with putting it there is increasing the dependence of the StEventUtilities library on database codes. There was already one instance of database calls in the directory, but in code that wasn't typically run. However, I checked all nightly test jobs, and it appears that the necessary other database libraries are indeed loaded in all of these jobs. So it should not impact production jobs to add the dependence explicitly in StBFChain.h.

This does not need to be a "maker" (inherit from StMaker and run in the chain). It simply needs to make the appropriate determination the first time its getT0() function is called for any event. Making it a singleton accessed by an instance() function serves the purpose of making it accessible to any other code, whether part of the maker scheme or not.

This class will also have a calibration mode, which, on the first call for an event, fills an ntuple of quantities that will be useful in calibrating the T0 arithmetic that will be used for reconstruction.

---

2. Calibrations/trg/EbyET0

Because this calibration is related to the trigger time, it makes sense to have the table live under Calibrations/trg in the offline database, agnostic to any other particular subsystem.

The calibration may need to be done a few times per Run year, for different collision systems, and perhaps even more than once for a collision system if a trigger detector changes mid-Run for some reason. So only a few entries will be needed in this table per year. I (Gene Van Buren: genevb) plan to manage the content of this table.

The table needs to have multiple rows to allow the use of multiple trigger detectors because not all trigger detectors are available in every event (or they may have unusable time values). The scheme of allowing a secondary, tertiary, etc. choice for trigger detectors is easily satisfied by stepping through rows in the table until either one one that works for the event is available, or the options are exhausted and no correction can be applied (a detector whose value is negative can also stop the stepping process). I propose a maximum of 32 rows (elementIDs), though in most cases only a few of these will be used.

Here is the proposed table structure StDb/idl/EbyET0.idl:

struct EbyET0 {
  long   detector; // row index
  double min;   // correction range
  double max;   // 
  long  func;   // function
  double par[4];  // parameters
};

This struct has a size of 56 bytes. And in more detail:

• detector: which trigger detector this particular row will be good for (a list of the corresponding detectors is available in the StEventUtilities/StEbyET0 class)
• min,max: range of the detector's time coordinate that are considered usable for a correction
• func: flexibility for how the parameters are used in a functional form to determine the T0 (a list of the corresponding functions is available in the StEventUtilities/StEbyET0 class)
• par: parameters of the function, e.g. a 3rd order polynomial

One possible way to imagine leveraging the flexibility built into these is to divide a particular trigger detector's time spectrum into multiple ranges via the min,max parameters. The different ranges would be in different rows of the table, allowing different functions and/or parameters to be used in different parts of the time spectrum. This is another reason why having up to 32 rows in the table is potentially helpful.

The struct can have an interface under StDetectorDbMaker/St_EbyET0C.h as well.

---

3. Subsystem codes

For the TPC group, StTpcHitMaker.cxx needs modified to call the getT0() function of the StEventUtilities/StEbyET0 class, but only when the attribute "EbyET0" is set for this maker. This only needs to be called once for the event, and then the returned T0 can be used for any/all hits' times.

---

4. BFC options

The "EbyET0" chain option will set attributes for all subsystems wishing to optionally use this T0. A subsystem may chose not to make this an option, but the TPC group wanted it to be chain-controllable for themselves.

---

5. calibEbyET0.C

Calibration macros...in progress.

---

-Gene