sPHENIX MAPS tracker discussion

[Hugo Pereira Da Costa <hugo.pereira-da-costa AT cea.fr>]

Also, another question: where do you think would be the best place to add the additional y-offset, discussed yesterday, needed to "fix" the residuals in z and phi ?

I could consider two places:

1. inside CylinderGeom_Mvtx directly, in get_local_coords_from_pixel. This would ensure that the offset is applied consistently everywhere, but on the other hand is somewhat misleading, since this correction is not really geometry related, but rather to the digitization process

2. inside the clusterizer when building clusters from hits, and applied to the clusters only, not the hits. This would make sure that it is properly used for the rest of the tracking, which deals with clusters only, but introduces some small inconsistency between hit position and cluster position.

Personally, I think 2. is better, provided it is properly documented/commented in the code. But other's oppinion is welcome. Is there another place where it could be added ?

Best,

Hugo

On 5/28/20 9:55 AM, Hugo Pereira Da Costa wrote:

Hi Yasser, others

Following up on yesterday's discussions, attach is a patch that printouts the local coordinates I mentioned yesterday, inside the PHG4MvtxHitReco module.

(for completeness, you can apply it via: patch -p1 < diff.patch in your coresoftware source checkout)

What is printed is:

- the local_in PHG4Hit coordinates (all located at y = +15 um)

- the local_out PHG4Hit coordinates (all located at y = -15 um)

- the mid point, located at y = 0;

- the local position of the corresponding "pixel", obtained via CylinderGeom_Mvtx::get_local_coords_from_pixel() which is located at y = +5um. (example output at the end of this email)

This same method is then used late on, in MvtxClusterizer, to calculate the "local" cluster positions, then converted into world coordinate. (see MvtxClusterizer.cc, line 330 or so).

My understanding is that this difference, between y = 0 for the mid-point, and y = +5um for the pixel local_coord (and then the cluster), which is propagated to world coordinate by converting all the above with the same method, namely CylinderGeom_Mvtx::get_world_from_local_coords, is why I still get a non zero offset in phi residuals even if I use identical diffusion radii R_min and R_max.

Comments welcome: is it a misunderstanding on my side ? A bug in the code ? Something expected ?

Best,

Hugo

--------------------------

/phenix/u/hpereira/sphenix/src/coresoftware/simulation/g4simulation/g4mvtx/PHG4MvtxHitReco.cc:308:  local_in:     (-0.463923,0.0015,-0.462255)
/phenix/u/hpereira/sphenix/src/coresoftware/simulation/g4simulation/g4mvtx/PHG4MvtxHitReco.cc:309:  local_out:    (-0.465142,-0.0015,-0.458722)
/phenix/u/hpereira/sphenix/src/coresoftware/simulation/g4simulation/g4mvtx/PHG4MvtxHitReco.cc:310:  midpoint:     (-0.464532,0,-0.460488)
/phenix/u/hpereira/sphenix/src/coresoftware/simulation/g4simulation/g4mvtx/PHG4MvtxHitReco.cc:313:  local pixel:  (-0.46368,0.0005,-0.46053)

On 5/26/20 11:00 AM, Ming Liu wrote:

Dear all,

A remind of MVTX Test Beam analysis and MC tuning bi-weekly meeting this Wed 5/27 evening, 8:30PM/BNL (6:30PM/LANL, 5:30PM/LBNL; 8:30AM/China)

 

Draft agenda page with BlueJeans, https://indico.bnl.gov/event/8612/

 

Cheers,

Ming

 

-- 

Ming Xiong Liu

P-25, MS H846                     TEL: 505-667-7125 

Physics Division                            631-344-7821(BNL)

LANL                                               630-840-5708(FNAL)

Los Alamos, NM 87545      FAX:  505-665-7020

 

_______________________________________________
sPHENIX-MAPS-l mailing list
sPHENIX-MAPS-l AT lists.bnl.gov
https://lists.bnl.gov/mailman/listinfo/sphenix-maps-l