Skip to Content.
Sympa Menu

sphenix-maps-l - Re: [Sphenix-maps-l] Local coordinates

sphenix-maps-l AT lists.bnl.gov

Subject: sPHENIX MAPS tracker discussion

List archive

Chronological Thread  
  • From: Yasser Corrales Morales <ycmorales AT rcf.rhic.bnl.gov>
  • To: sphenix-maps-l AT lists.bnl.gov
  • Subject: Re: [Sphenix-maps-l] Local coordinates
  • Date: Thu, 28 May 2020 14:28:22 -0600

Hi Hugo,

you  are right, the position of the reconstructed hit from the fired pixels is located at center of the chip (code from ALICE) while the generated hit is estimated from the center of the sensors in Y coordinates. That's why the pixel position is at +5 um in local (sensor coordinates).

We can fixed it by applying a shift using an effective length as it's done in ALICE. In this way we adjust the length according the ALPIDE response in the MC simulation.

Thank you,

Y.

On 5/28/20 09:55, 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

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

Postdoctoral Research Associate
PO Box 1663
MS H846
LANL
Los Alamos, NM 87544



Archive powered by MHonArc 2.6.24.

Top of Page