add best knowldge of collision time in tof matching info

[noferini]

Dear @shahor02 , @miranov25 ,
I am preparing a PR to attach the best FT0 info already in the TOF matching info since the info is available in the final stage of TOF matching (it is needed for TOF calibInfo).
I added one double (collision time) and one float (T0 res.) in the TOF matching info (whose output is in any case not persistent)
Once ready it should be easy for you to use it.

[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
async-2024-PbPb-apass2
async-2023-PbPb-apass5

[miranov25]

Hello @noferini

Thank you.
It will be nice to have it by default in the Unbinned residuals (latest update in #14592)
I did not understand your previous comments regarding usage in the time series - can we use it already there?

Regards
Marian

[noferini]

I tested this PR in MC (--use-fit option should be added since it is not the default)

Results look fine

[noferini]

@miranov25 ,
in tpc timeseries FT0 info is loaded from FT0 rec point and it is then subtracted to TOF. You don't need there this PR since we have already implemented it (but if you want you can replace old implementation and use this).

This PR provide FT0 info already coupled to TOF matching info so that you can use it without any dependence on FT0 recPoints (which means it is easier to be used in other task without any extra requirement).

[noferini]

All checks were passed.
If there are no objections I would merge it.

[miranov25]

Hello Francesco.

Before mering, I have 2 question:

• Why in your plot the delta Time in ideal MC is not centered but shifted by 24 ps? Is it normal?
• Will we profit from new interface in the Time series - so we can replace the code there?

[shahor02]

Hi @noferini

Thanks, this would be very useful! But I think for PbPb one should 1st apply FT0 clean up, to get rid of the QED triggers.

You can see the spectrum or FT0A,C amplitudes and number of triggers passing your selection for the sample were only 138661 primary vertices were found:

You can use the same selection I apply in the ITS/TPC matching to contain the TPC tracks time:

AliceO2/Detectors/GlobalTracking/src/MatchTPCITS.cxx

Line 228 in de1d18e

mFT0Params = &o2::ft0::InteractionTag::Instance();

AliceO2/Detectors/GlobalTracking/src/MatchTPCITS.cxx

Line 1929 in de1d18e

if (!mFT0Params->isSelected(ft)) {

Note that the o2::ft0::InteractionTag is a configurable param, in the PbPb we init it with thresholds:

ft0tag.minAmplitudeA=5;ft0tag.minAmplitudeC=5;ft0tag.minAmplitudeAC=20;

[noferini]

Hi @shahor02 ,
do we really need to filter it (for calibration info I don't)?

Are you suggestion this for a computational time or to reduce contamination.

For contamination issue: I would like to stress that FT0 is used here only if

• it is in the same BC as the TOF hit (coincidence of FT0-TOF)
• the TOF hit is matched to a track

Under these conditions I would not expect issue.

[shahor02]

@noferini my concern is the contamination by QED triggers. If you want, we can merge it as is, the check on the real data updated TOFInfo from your code with the one hacked by the selection above.

[noferini]

Hi @shahor02 ,
I added the filtering in findFITIndex method.
It is now applied when using FT0 as a reference fir calib info.
I checked with MC that everything works fine.
Let's wait for the check.

[shahor02]

@noferini looks fine to me, shall I merge it?

[noferini]

Hi @shahor02 , yes we can merge. Thanks

@miranov25 : concerning the small shift it should be investigated. Only recently we managed to fix an issue with FT0 in MC to have the collision time in the right BC but I have the feeling that there are second order effects which has to be tuned (I will check on our side after the Pb-Pb run but I suspect it can be on FT0 side)

[noferini]

@miranov25

in any case, trivial checks on MC show that TOF digitization chain doesn't introduce any shift

[miranov25]

Thank you.
This delta can be used as either an absolute or relative measurement for beta (pt) bias. What is its behavior in real data for high-$p_T$ tracks?
If I understand what you wrote, the problem is with the T0 simulation, not in real data.
There, I remembered the centered values that I had seen in my winter tests.

[noferini]

Hi,
FT0 is well center.
The issue here is in the expected times.

In few cases it is overestimated by ~ 80 ps. I cannot say more with the current stat

[noferini]

For your info.
Both in TOFCluster and in o2match_tof_* infos I stored, since a long time (I did forget), MC truth information for quick checks

mTgeant -> geant time (real travel time) in ns
mT0true -> collision time (within the TF) in ps