Skip to content

Conversation

@njacazio
Copy link
Collaborator

@njacazio njacazio commented Dec 1, 2021

@noferini please have a look

@njacazio njacazio requested a review from a team as a code owner December 1, 2021 14:03
@njacazio njacazio force-pushed the nj-t0tof branch 2 times, most recently from 705ebe2 to 7f6dc91 Compare December 1, 2021 14:17
noferini
noferini previously approved these changes Dec 1, 2021
Copy link
Collaborator

@noferini noferini left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Ok, from my side.
@chiarazampolli: we couldn't test with aod-producer (we don't know how to do)

Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Why has the unit changed by 3 orders of magnitude and the comment stays the same: \mus ?

Copy link
Collaborator Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

This is a fix, the time was stored in ns before and the comment was inconsistent. Now we store both trackTime and trackTimeRes with the same units

Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

in the comment you still have mus. Could you write "ns"? I guess this was the comment of @jgrosseo

Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Sorry, you move to mus everything (I was mislead by the part commented)

noferini
noferini previously approved these changes Dec 3, 2021
Copy link
Collaborator

@noferini noferini left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I re-generated new AO2D with the last fixes and now everything looks fine.

Let remember to fix in O2Physics this

--- a/Common/Core/PID/PIDTOF.h
+++ b/Common/Core/PID/PIDTOF.h
@@ -227,7 +227,7 @@ class TOFSignal
/// Computes the expected time of a track, given its TOF expected time
/// \param trackTime trackTime in ns
/// \param response response to use to compute the expected time for the propagation from the vertex to TOF
// - static float ComputeTOFSignal(const float& trackTime, const float& expTime) { return trackTime * 1e+3 + expTime; }
// + static float ComputeTOFSignal(const float& trackTime, const float& expTime) { return trackTime * 1e+6 + expTime; }

Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Sorry, you move to mus everything (I was mislead by the part commented)

- Use TOF Utils to subtract bunch crossing time

- Add PID in tracking into track flags

- Clean TOF signal from output object
@njacazio
Copy link
Collaborator Author

njacazio commented Dec 3, 2021

Thanks @noferini I forgot this, I fixed the comments and am ready to merge!

extraInfoHolder.trackTime = static_cast<float>((tofMatch.getSignal() - exp) * 1e-3 - interactionTime); // tof time in \mus, FIXME: account for time of flight to R TOF
extraInfoHolder.trackTimeRes = 200e-3; // FIXME: calculate actual resolution (if possible?)
extraInfoHolder.trackTime = static_cast<float>((tofSignal - exp) * 1e-3); // tof time in ns, taken from the definition of Ruben scaled by 1000 to convert from mus to ns to match the collisionTime
extraInfoHolder.trackTimeRes = 200e-3; // FIXME: calculate actual resolution (if possible?)
Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

@shahor02 I am in favour of merging this. Unrelated: Don't we have an estimate of the track type already somewhere?

Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

@jgrosseo sorry, just saw the question. If you are asking whether we do reco-time PID: no, for that the TPC would need to provide a dedx -> PID algorithm.

Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

@shahor02 I wrote track type but mean track time resolution (sorry for this; and that's why I made the comment here).
So do you already have a track time resolution (even course based on the type of track)?

Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Not for ITS-TPC-TOF tracks: they are somewhat special since their time is given by the TOF signal stored in the match info (while the kinematic comes from ITS-TPC). In the

const float timeErr = 0.010f; // assume 10 ns error FIXME
if (creator(tracksTPCTRD[gidx.getIndex()], {i, GTrackID::TPCTRDTOF}, timeTOFMUS, timeErr)) {
a 10 ns error is assigned (which is surely an overkill but is much more precise that the ITS-TPC time errors), but AOD producer does not use this method, since it relias on the vertex->tracks attachments tables.

Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I think we should propagate these values into the AOD (even if you mark them as "overkill" for now). All this info should be available in the AOD converter, so it just requires adjusting the code, right?

Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

TrackTime contains here the track time estimate based on TOF (absolute wrt BC). We do not talk about the estimated time with a momentum and particle hypothesis. Do we talk about the same thing?

Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

@jgrosseo for tracks with TRD the error corresponds to the nominal triggered BC duration (i.e. a few 100 ps), for ITS-TPC tracks: uncertainty in matching point Z / vdrift.

Can we add this to the AOD producer already?

Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I see. A deltat (t_tof - t_track) is avaliable with the matching info.
For the resolution we depend on the track time precision which is available with the track.
Is this what you need?

Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

@jgrosseo

We do not talk about the estimated time with a momentum and particle hypothesis. Do we talk about the same thing?

Does this matter if we speak about the uncertainty?

Can we add this to the AOD producer already?

Do you mean to fill extraInfoHolder.trackTime and extraInfoHolder.trackTimeRes for all tracks types?

Copy link
Collaborator

@jgrosseo jgrosseo Dec 7, 2021

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Do you mean to fill extraInfoHolder.trackTime and extraInfoHolder.trackTimeRes for all tracks types?

Yes!

@njacazio
Copy link
Collaborator Author

njacazio commented Dec 6, 2021

@shahor02 if you have no objections I would merge this

@shahor02 shahor02 merged commit ff03ce9 into AliceO2Group:dev Dec 6, 2021
@njacazio njacazio deleted the nj-t0tof branch December 6, 2021 12:34
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Development

Successfully merging this pull request may close these issues.

4 participants