Add residuals for external detectors #14592
Conversation
|
REQUEST FOR PRODUCTION RELEASES: This will add The following labels are available |
|
@miranov25 this is still incomplete PR to add extra residuals (at the moment for extrapolated ITS tracks only).
|
|
Hello @shahor02, For points 1 and 2: clear to me — this looks fine and should remain backward-compatible (though having a getter here would also be useful). For point 3, it’s still not fully clear how this is implemented. In the code diff I couldn’t find it — are these two separate vectors for X and alpha? My assumption was that we could reuse row and sector to encode the ITS layer and chip ID, and then provide simple getters for X and the rotation alpha. What would you prefer here? Perhaps you had a reason to store X and alpha explicitly instead of relying on static getters from the ITS geometry? |
|
@miranov25 I haven't yet added then x, alpha. |
|
Hello @shahor02, For the Alpha and X getters, I suggest using an interface that will also allow their usage in
Would it make sense to add a general |
|
@miranov25 it is not over yet. |
shahor02
force-pushed
the
pr_tpcExtRes
branch
2 times, most recently
from
478affe to
aef833b
Compare
|
@miranov25 I've tested code, seems to be fine, you can find a small tree extracted from the MC: The for the interface see the commir description, example is: 
|
|
Hello @shahor02, Sorry for the late reply. The residuals in your figure look qualitatively as I expected. Regarding the test with the data: unfortunately I am not able to access the file — I get a permission denied both via CERNBox and via The file definitely exists on EOS (I can list it from lxplus): But when I try to copy it to GSI, I get: Not sure what the issue is — maybe the file permissions on EOS? |
|
Hello @shahor02, If the format is backward compatible, could we switch to the new unbinned residuals? I am asking in the context of the ongoing MC closure test production. I will be on holiday starting tomorrow (for one week), but I would like to get access to the data when I return. Once the permissions are fixed, I will check the unbinned residuals. Marian |
|
@miranov25 For me both ways of fetching from the cernbox work. I've copied the file to The format is backward compatible. Will merge this PR once you check the residuals. |
|
Hello @shahor02, From AliEn I can access the data now, and I am checking them. Here are my first observations (I can not use getters for a moment, this I can not comment): Looking at the TOF residuals, I suggest adding TOF Δt and TOF nsigma to the
If I understand correctly, the data you provided are from the MC closure test. As I mentioned earlier, I was surprised to see the TOF shifted by ~1.2 cm. Is there really no residual misalignment in the MC data? At the beginnig I suspected energy loss correction, but this is not consitent with TRD Interestingly, the TRD shows a bias in the opposite direction. Clearly, such long tails will affect the quality of the calibration using the TRD, so we should address this by providing extra information in the
It would be better to add these before running the next test, and I assume this should be relatively straightforward to implement. I don’t think this is the only issue in the TRD, but certainly one of the important ones. Later I will check it in the production, hopefully using the trackData criteria I described above. TRD residulas -tail 2 cm
TOF residuals - bias 1.2 cm
|
|
@miranov25 indeed, conditioning interactive drawing by the trackInfo will not work w/o flattening. I don't know how to put in these trees TOF measured - expected or nsigma, this requires determination of Time0, i.e. matching to FT0 etc. I don't want to do such analysis in the residuals extraction. A crude cut on the time-of-flight (as a difference between the track time and TOF signal time) is already applied at the matching stage. Concerning the TOF rphi bias: I assume this is an artefact of evaluating residual at TOF while for the same data the residuals extracted from the |
|
Hi @shahor02 ,
Assuming In TOF matching propagation is done to miinimize DeltaY (-> 0) As I mentioned Y in my local coordinate space and X in (your) sector coordinate space are the same only for eta=0 since TOF strips in general are tilted. This means that you are not really extrapolating to the TOF pad center (or at least this is my guess). If you think I didn't interpret correctly the problem let me know. Cheers, |
|
Hi @noferini AliceO2/Detectors/TPC/calibration/SpacePoints/src/TrackInterpolation.cxx Lines 930 to 943 in 5282568 The same is used to constrain the tracks by TOF in the interpolated residuals AliceO2/Detectors/TPC/calibration/SpacePoints/src/TrackInterpolation.cxx Lines 509 to 523 in 5282568 So, the clusters are basically useless for track extrapolation, except providing the principal pad ID? Thas said, I don't see better residuals also at |
|
Hi @shahor02 , |
|
Hello @noferini, Could you also help @shahor02 with the TOF time determination? I remember you had implemented something similar before in the time series. Please see Ruben’s comment here for context: We don’t need perfect time resolution for this purpose — just enough for fake tagging. A resolution of order 100–200 ps would be sufficient. Regards |
Sorry @noferini , I don't understand: why should I rotate the cluster if it is already in the sector frame (and it is indeed according to this code AliceO2/Detectors/TOF/reconstruction/src/Clusterer.cxx Lines 272 to 277 in 7fccf1d Note that for the constraint with TOF when fitting track inwards to extract the interpolated TPC residuals, the TOF is the 1st detector updating the track, so strictly speaking, the track position at this stage is not known, hence the minimization of deltaY makes no sense (though in reality we are using tpcOut propagation to TOF). |
|
Hi @shahor02 , you are right I misunderstood one comment. Indeed there is nothing suspicius in the code. Do you have the same also for @miranov25 : for time resolution I have to check how I implemented it in the timeseries (I don't remember if I did it in the matching part and then attached the info to the cluster or if I did it directly in the timeseries workflow). A question: what do you mean with tagging? Do you need a rough selection on pions (subtracting the closest BC could be enough) or you really need to subtract FT0-AC (< 100 ps resolution + collision association)? |
|
Hello @noferini We would like to reject the fake association. For that we do not need a perfectly calibrated T0, but something O(100 ps) will be sufficient. Regards |
|
Hi @noferini , Yes, the track is at the cluster X, with the patch I get: |
|
Hi @shahor02 , To run a check on my side can you provide me the file with the cluster and the geometry file you are using so that I can inspect what is wrong in the cluster position? Cheers, |
|
Hi @miranov25 ,, Note that in tpc timeries I didn't subtract bclong since I want to keep the full time information inside the tf. Cheers, |
|
Hi @noferini , indeed, selecting 1-pad clusters does not change anything. For the data file, I've replied to the private email. |
|
Hello Ruben and Francesco, For the TPC unbinned residuals, we stored them with respect to the ideal position (simple rotation by the rotation angle).
This clarification is important for track refits in the iterative TPC calibration, as well as for ITS/TRD/TOF alignment monitoring. Regards |
|
@noferini following your comment I've added to tof::Geo a method to translate "aligned sector" cluster coordinates to the nominal sector frame. Also, I've added to tof::Cluster a flag (uses base cluster bit field) telling in which frame it is. I've updated the @miranov25 , we store TPC residuals in the ideal frame simply because the TPC has no alignment. |
|
I agree, let's proceed with merging this PR. We'll address the timing implementation in a follow-up PR.
These were the key motivations for ensuring a decent time resolution with the TOF. |
…is passed The unbinned residuals got channel data member which holds ITS chipID, TRD chamber ID or TOF pad within the sector resp. The convention for non-TPC rows: 160-165: TRD layers 170: TOF 180-186: ITS layers The getters isTPC(), isTRD(), isTOF() and isITS() can be used to query the residual type and getDetID() will return 0,1,2 and 3 for ITS, TPC, TRD and TOF points resp. Also, getX() and getAlpha() will provide the tracking frame X and alpha of the residual. These getters, when acting on the non-TPC residuals require initialized geometry helpers. The initialization can be done manually via static method o2::tpc::UnbinnedResid::init(long timeStamp = -1) which will load from the CCDB the geometry corresponding to the requested timestamp (-1 : now). If the initialization was not done in advance then it will be done internally at the 1st query of getX() or getAlpha(), with the timestamp = -1.
|
Merging after squashing some commits, the tests were passed. |
3 participants
No description provided.