improve TOF infos in TPCtimeseries

[noferini]

This is to port additional TOF(FT0 event time) infos in TPC timeseries

@miranov25 @ercolessi

• applying FT0-AC to TOF times
• quality mask for TOF
  • single/multiple hits in tof clusters
  • single/multiple strips matched
  • chi2 matching

[github-actions]

REQUEST FOR PRODUCTION RELEASES:
To request your PR to be included in production software, please add the corresponding labels called "async-" to your PR. Add the labels directly (if you have the permissions) or add a comment of the form (note that labels are separated by a ",")

+async-label <label1>, <label2>, !<label3> ...

This will add <label1> and <label2> and removes <label3>.

The following labels are available
async-2023-pbpb-apass4
async-2023-pp-apass4
async-2024-pp-apass1
async-2022-pp-apass7
async-2024-pp-cpass0
async-2024-PbPb-apass1
async-2024-ppRef-apass1

[miranov25]

Hello @noferini,

Thank you for your modification. I need to test the new time series before proceeding with the merge.
Could you let me know which tests you performed earlier?

Marian

[miranov25]

This relates to the JIRA O2-4592 (https://its.cern.ch/jira/browse/O2-4592) and pull request:
#13809

[miranov25]

Code to test the time series - Example running of the time series and skimmed data

Hello @noferini
I am not sure if you know how to run the code. Below you can find the test code, which should work and produce time series:

      ARGS_ALL="--shm-segment-size 30000000000"
      o2-global-track-cluster-reader --disable-mc --cluster-types "TOF,TPC" --track-types "ITS,TPC,ITS-TPC,ITS-TPC-TOF,ITS-TPC-TRD-TOF" --primary-vertices --hbfutils-config o2_tfidinfo.root ${ARGS_ALL} \
      | o2-tpc-time-series-workflow  --enable-unbinned-root-output --sample-unbinned-tsallis --sampling-factor 0.05 ${ARGS_ALL} -b

hadd -k time_series_tracks.root time_series_tracks_*.root

[noferini]

Hi @miranov25,
I run a MC test to check that everything is set properly and it works fine. In particular TOF-FT0 alignement is validated.
In my MC tests I included also a fix for FT0 which is needed only in MC digitization but not yet merged (FT0 people is finalizing it).
There is, at least, one thing I would like to discuss with you.
In principle we can write a tof time already with respect to the collision BC (moving it from double to float) but I don't know if you need the TOF time inside the TF.

[miranov25]

Hello @noferini,

I see that you’ve already removed FT0/A+C for the TOF information (mTOFSignal). If I understand your modification correctly, the line:
<< "mTOFSignal=" << std::get<4>(idxTPCTrackToTOFCluster[iTrk])
is now corrected for the event time.

It would indeed be useful to verify whether vertexTime is consistent with the TOF time. I’m not sure if we can access this information at the moment, but it would be helpful to apply a time-match cut later.

Separately, we’ve been discussing within the AO2D framework the TOF momentum and effective TOF momentum. For example, if I wanted to create a time series for the pT correction, this variable would be very valuable to include. Can you include also that in your pull request?

Regarding the bitmask, you constructed it manually in the code. Is its definition consistent with the AO2D definition, or is it currently not included in AO2D at all?

As for the time-dependent pT correction, my plan is roughly as follows:

• The pT bias is dependent on φ and η due to ITS misalignment and TPC miscalibration.
• We will determine the semi-static part (caused by misalignment) as a fill average.
• The dynamic part will be obtained by fitting DCA and TPC-ITS track matching across the time series.

Best regards,
Marian

[noferini]

Hello @noferini,

I see that you’ve already removed FT0/A+C for the TOF information (mTOFSignal). If I understand your modification correctly, the line: << "mTOFSignal=" << std::get<4>(idxTPCTrackToTOFCluster[iTrk]) is now corrected for the event time.

Yes, for the moment only the fine part. As I mentioned, the BC is not yet subtracted.

It would indeed be useful to verify whether vertexTime is consistent with the TOF time. I’m not sure if we can access this information at the moment, but it would be helpful to apply a time-match cut later.

In principle with FT0-AC we have also an independent measurement of Z-vertex. This information is already available and we can use it. For vertex-time I can have a look to what is available in the task (vertex-time is in any case less precise that Z-vertex I guess)

Separately, we’ve been discussing within the AO2D framework the TOF momentum and effective TOF momentum. For example, if I wanted to create a time series for the pT correction, this variable would be very valuable to include. Can you include also that in your pull request?

Here, I don't know how TOF momentum and effective TOF momentum are defined. Can you add more details?

Regarding the bitmask, you constructed it manually in the code. Is its definition consistent with the AO2D definition, or is it currently not included in AO2D at all?

In AO2D only chi2 is propagated, the information related to chi2 can be easily recover in AO2D analysis. The information related to TOF cluster topology (single/multiple hits) are not yet ported. In principle these infos are needed only for TOF performance studies and it is enough for us to have them in time-series.

As for the time-dependent pT correction, my plan is roughly as follows:

* The `pT` bias is dependent on `φ` and `η` due to ITS misalignment and TPC miscalibration.

* We will determine the **semi-static part** (caused by misalignment) as a fill average.

* The **dynamic part** will be obtained by fitting DCA and TPC-ITS track matching across the time series.

Best regards, Marian

One more info we can consider to propagate is the time-dependent TOF acceptance. This requires a bit of work (especially for MC). If it is useful for you I can have a look (but it will require more time so it is probably worth not to include it in the first iteration)

[miranov25]

I am focused on using the TOF as an additional tool for distortion monitoring and eventual correction.

At low β, the time bias is strongly influenced by the p_T bias (the importance of other effects should also be quantified).
The effect can be characterized by the linear formula dt/dp_rel.

We can extract a correction by fitting the time bias as a function of the local p_T bias (for low β particles such as protons, kaons, and deuterons). While it is unclear if other effects are contributing, we can assume that the relative change of the time bias over time or space is independent of the material budget.

In the K⁰, Λ, and D⁰ analyses, we observed that the Run 1 and Run 2 resolutions are significantly better than in Run 3, even at relatively low momenta. This fact cannot be explained by a constant q/p_T shift. However, what we observe is that the q/p_T bias is indeed dependent on the rate, position, and q/p_T.

As a demonstration example, we can use the DCA as a function of q/p_T and rate, the EMCAL E/p measurement, and the easily accessible TOF delta time measurement.

In the figure below, you can find the delta time profile for kaons and pions as a function of φ, which resembles the previously observed E/p measurement and electron/positron behavior in the EMCAL.

At the moment, we do not yet have enough statistics to extract reliable dt/dp_rel fits. However, we plan to extract them for some example fills with significant rate variations.

It would be preferable to enable the necessary TOF information in production as soon as possible. For that we will need delta Time

These fits will be validated by applying the corrections to V⁰ and D⁰ analyses.

Example query in the AO2D analysis:

tree->Draw("fTOFNSigmaPr:fPhi","TOFOK&&isTOFProton3&&fSigned1Pt>0","prof");
tree->Draw("fTOFNSigmaKa:fPhi","TOFOK&&isTOFKaon3&&fSigned1Pt>0","prof");

[noferini]

Hi @miranov25 ,
in principle in the current version of time-series all expected times are stored.
The quality of the information we are storing for TOF in time-series is already much higher than what we have in AO2D.
From expected times (mT[]) we can extract such biases and then we don't need other information.

In general I don't like to use Nsigma, I think that for our purpose it is better to use (t - texp) and get the shift in ps.
The sigma-dependence on phi/eta/p is defined empirically and it can add noise to your analyses.
Do you agree?

[miranov25]

Hello @noferini and @ALL,

From what I understand, I believe we can retrieve the required information. In the example above, I used NSigma as it was readily available in the AO2D.
To calculate the pt correction and time correction, the input delta time would be more appropriate. However, I did not use it initially because it was unclear how to access it in the AO2D. I have since contacted Nicolo for clarification on how to retrieve the time information.

The advantage of the time series approach is that the analysis is much more efficient, as the time series size is approximately $10^3$ times smaller.

For the next iteration (after this pull request), I propose creating a TOF delta time series to further accelerate the analysis.
I can implement the time-biased part similarly to how it was done for the TPC+ITS afterward.

@wiechula, @shahor02, could you please review and approve @noferini's pull request?

Best regards,
Marian

[noferini]

Hi @miranov25 , all,
in the meanwhile I moved the PR from WIP to ready for review.

[shahor02]

@noferini see one suggestion below. Note that the FT0 data are loaded conditionally (if useft0 is true) but is used unconditionally in the run. It will not crash, simply

AliceO2/Detectors/TPC/workflow/src/TPCTimeSeriesSpec.cxx

Line 220 in d9e0fdc

const auto& ft0rec = recoData.getFT0RecPoints();

will return an empty span, so that the t0array will never be filled.

[noferini]

@noferini see one suggestion below. Note that the FT0 data are loaded conditionally (if useft0 is true) but is used unconditionally in the run. It will not crash, simply

AliceO2/Detectors/TPC/workflow/src/TPCTimeSeriesSpec.cxx

Line 220 in d9e0fdc

const auto& ft0rec = recoData.getFT0RecPoints();

will return an empty span, so that the t0array will never be filled.

@shahor02
I agree, but I think I still need it in line 1826

if (useft0) {
dataRequest->requestFT0RecPoints(false);
}

Am I wrong?

[shahor02]

@noferini if you want it conditionally, yes, I was just stating that it useft0==false, it will look like no matches to FT0.

[noferini]

@noferini see one suggestion below. Note that the FT0 data are loaded conditionally (if useft0 is true) but is used unconditionally in the run. It will not crash, simply

AliceO2/Detectors/TPC/workflow/src/TPCTimeSeriesSpec.cxx

Line 220 in d9e0fdc

const auto& ft0rec = recoData.getFT0RecPoints();

will return an empty span, so that the t0array will never be filled.

@shahor02
I agree, but I think I still need it in line 1826

if (useft0) {
dataRequest->requestFT0RecPoints(false);
}

Am I wrong?

@noferini if you want it conditionally, yes, I was just stating that it useft0==false, it will look like no matches to FT0.

Hi @shahor02 , I checked again the code. What you said it is true, I added the option in order not to break simulation (O2DPG). in principle I can make FT0 mandatory but I have to wait that also O2DPG PR is merged. As soon as O2DPG PR is merged I can remove the condition.
Se also
AliceO2Group/O2DPG#1873

[alibuild]

Error while checking build/O2/fullCI for f80f564 at 2025-01-17 18:53:

## sw/BUILD/O2-latest/log
c++: error: unrecognized command-line option '--rtlib=compiler-rt'
c++: error: unrecognized command-line option '--rtlib=compiler-rt'


## sw/BUILD/O2Physics-latest/log
Error in cling::AutoLoadingVisitor::InsertIntoAutoLoadingState:
Error in cling::AutoLoadingVisitor::InsertIntoAutoLoadingState:
Error in cling::AutoLoadingVisitor::InsertIntoAutoLoadingState:
Error in cling::AutoLoadingVisitor::InsertIntoAutoLoadingState:
Error in cling::AutoLoadingVisitor::InsertIntoAutoLoadingState:
Error in cling::AutoLoadingVisitor::InsertIntoAutoLoadingState:
Error in cling::AutoLoadingVisitor::InsertIntoAutoLoadingState:
Error in cling::AutoLoadingVisitor::InsertIntoAutoLoadingState:
Error in cling::AutoLoadingVisitor::InsertIntoAutoLoadingState:
Error in cling::AutoLoadingVisitor::InsertIntoAutoLoadingState:
Error in cling::AutoLoadingVisitor::InsertIntoAutoLoadingState:
Error in cling::AutoLoadingVisitor::InsertIntoAutoLoadingState:


## sw/BUILD/O2-full-system-test-latest/log
Detected critical problem in logfile reco_NOGPU.log
reco_NOGPU.log:[29047:internal-dpl-ccdb-backend]: [17:53:25][ERROR] Exception while running: Fatal error. Rethrowing.
[29047:internal-dpl-ccdb-backend]: [17:53:24][ERROR] CCDBDownloader CURL transfer error - Timeout was reached
[29047:internal-dpl-ccdb-backend]: [17:53:24][ERROR] CcdbDownloader finished transfer http://alice-ccdb.cern.ch/CTP/Calib/OrbitReset for 1550600800000 (agent_id: alimetal09.cern.ch-1737136403-HdpNFd) with http code: 0
[29047:internal-dpl-ccdb-backend]: [17:53:24][ERROR] File CTP/Calib/OrbitReset could not be retrieved. No more hosts to try.
[29047:internal-dpl-ccdb-backend]: [17:53:24][FATAL] Unable to find object CTP/Calib/OrbitReset/1550600800000
[29047:internal-dpl-ccdb-backend]: [17:53:25][ERROR] Exception while running: Fatal error. Rethrowing.
[29047:internal-dpl-ccdb-backend]: [17:53:25][FATAL] Unhandled o2::framework::runtime_error reached the top of main of o2-itsmft-stf-decoder-workflow, device shutting down. Reason: Fatal error
[ERROR] Workflow crashed - PID 29047 (internal-dpl-ccdb-backend) did not exit correctly however it's not clear why. Exit code forced to 128.


## sw/BUILD/o2checkcode-latest/log
--
========== List of errors found ==========
++ GRERR=0
++ grep -v clang-diagnostic-error error-log.txt
++ grep ' error:'
++ GRERR=1
++ [[ 1 == 0 ]]
++ mkdir -p /sw/INSTALLROOT/eb722f627c7d914fd6d3853ebc40c9b4ab767649/slc8_x86-64/o2checkcode/1.0-local16/etc/modulefiles
++ cat
--

Full log here.