baltzell
commented
1 year ago Regarding the Faraday cup DSC2 scaler's clock (see issue JeffersonLab/coatjava#27) ... It was indeed 1 MHz during the first clas12 run period, but was fixed and set to an appropriate 100 kHz afterwards, but it also regressed in a later run period if I remember correctly. So, the issue there is that it can't be used uniformly for all data sets just by putting the clock frequency in CCDB (which the software is already ready for), without fixing the rollover.
There is a branch iss967-rollover that does fix the rollover, but that implementation requires reading each, entire run in one shot, which is feasible with train outputs but maybe/probably unfeasible with full DSTs (mainly requires logistics and disk footprint before writing to tape).
One could also think to extract the rollovers (a map of run/event number to number of rollovers during the run), which would need to be done during post-processing or a new upstream job before CLARA where we have access to tag-1 events, and store them (e.g., in CCDB) to apply a fix during reconstruction or post-processing. One technical issue there is that you can't fix file N+1 until all previous N files have been mapped for rollovers.
Or, we could get more clever and efficient and use another timestamp in the data (unix or TI) to calculate when the rollovers must happen and correct for them that way, but I haven't thought about that much. This would also still necessarily include getting the run start time from RCDB.
I think one thing we should do regardless is sample a few files spread across each of the different run periods and measure the clock. The ones with an appropriate clock frequency, which I think/hope should be most of them, can just use the clock, with no rollover issue, and forget about the hack of unix event time minus RCDB start time as a proxy for the scaler clock.
raffaelladevita
The conversion of the FCup integrating scaler counts to charge requires the integration time to correct for the FCup offset. The best measurement of the integration time should come from the clock scaler. However, since the frequency is set to 1 MHz, this scaler readout can roll over during a run and is not usable.
As a backup solution, the integration time is currently estimated from the current event Unix time and the run start time in RCDB. Since the latter is a local time, the result depends on the local time of the machine the code runs on.