-
Notifications
You must be signed in to change notification settings - Fork 488
Use TOF Utils to subtract BC time to tofSignal #7782
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Conversation
705ebe2 to
7f6dc91
Compare
noferini
left a comment
There was a problem hiding this 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)
17a2d21 to
b490e3c
Compare
There was a problem hiding this comment.
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 ?
There was a problem hiding this comment.
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
There was a problem hiding this comment.
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
There was a problem hiding this comment.
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)
There was a problem hiding this 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; }
There was a problem hiding this comment.
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
|
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?) |
There was a problem hiding this comment.
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?
There was a problem hiding this comment.
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.
There was a problem hiding this comment.
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)?
There was a problem hiding this comment.
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
Lines 169 to 170 in ce3e745
| const float timeErr = 0.010f; // assume 10 ns error FIXME | |
| if (creator(tracksTPCTRD[gidx.getIndex()], {i, GTrackID::TPCTRDTOF}, timeTOFMUS, timeErr)) { |
There was a problem hiding this comment.
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?
There was a problem hiding this comment.
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?
There was a problem hiding this comment.
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?
There was a problem hiding this comment.
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?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
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?
There was a problem hiding this comment.
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!
|
@shahor02 if you have no objections I would merge this |
@noferini please have a look