Sphenix-calibration-l mailing list

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

Hi Tony,

Thanks for the feeback !

Some comments below

On 10/27/2021 1:38 PM, Anthony Frawley wrote:

        Hello Hugo,
      
        
      
      
        Thanks for looking into this. Yes, we should discuss this next
        week.
      
        
      
      
        My immediate attempt at this (i.e. not a lot of thought yet) is:
      
        
      
      
        For in-time events (where we know the time zero):
      
      
        
      
      
        What we will see in DATA is a set of hits tagged with a time bin
        by the TPC readout.
      
        We will convert this to z position assuming a drift velocity.
      
        If that drift velocity is incorrect, it will appear as a
        linearly z-dependent error in the position.
      
        The only way we can measure that error is through matching to
        the silicon (right?).
    
    yes, and to TPOT in limited acceptance (which is ok since one
    expects the drift velocity to be the same in the full acceptance ?)
    
      
        --- Essentially, make the drift velocity correction a fit
        parameter, and fit many tracks.
    
    yes. In fact, something very similar to what we do for the track
    based distortions, with less parameters. This is what I said I could
    look into yesterday. 
    
      
        
      
      
        In SIMULATION, we want to introduce a linearly z-dependent error
        in the position.
    
    
    
      
        We can do this by adding a delta to the electron drift velocity
        when we calculate arrival time at the readout plane. 
        
      
    
    
    
      
      
      
        That will make all the TPC z values wrong, in the correct
        linearly z-dependent way.
    
    
    
      
        That would mimic what happens in real data when we assume the
        wrong drift velocity to convert time to z.

Naively I was thinking to add the delta at the clustering stage, corresponding to improperly assigning a given z_bin (or time bin in real data) to its corresponding z in the TPC.

In the end it would be equivalent to what you propose I think. No ?

        Then we estimate the error in drift velocity in the way we would
        with real data.
      
        The truth value of that error is the offset we used in the
        electron drift code.
      
        
      
      
        For out-of-time events:
      
        
      
      
        We need to know the bunch crossing in this case, when
        reconstructing both real and simulated data.
      
      
        --- If we don't know the start time, we cannot propagate the
        drift velocity error properly.
      
      
        I think we have to add determination of the bunch crossing to
        our workflow anyway.
      
      
        
      
      
        Is that right?
      
        
      
      
        Tony

---

From: sPHENIX-calibration-l <sphenix-calibration-l-bounces AT lists.bnl.gov> on behalf of Hugo Pereira Da Costa via sPHENIX-calibration-l <sphenix-calibration-l AT lists.bnl.gov>
Sent: Wednesday, October 27, 2021 2:47 PM
To: sphenix-calibration-l AT lists.bnl.gov <sphenix-calibration-l AT lists.bnl.gov>
Subject: [Sphenix-calibration-l] Drift velocity in TPC code

 

Hello Ross, Tony, Christof, others

Following up on discussions we had yesterday I looked a bit into how the electron drift velocity is handled in the TPC code.

It turns out that

1/ Tony was right, there is no drift velocity used anywhere outside of PHG4ElectronDrift

2/ in PHG4ElectronDrift the only place were it is used, once you have properly compacted the multiply and divided by velocity, to convert G4Hit time into a position offset in the TPC (due to out-of-time pileup collisions and propagation time along the particle path). Everywhere else, we effectively use z, which we convert into a z_bin in the TPC length, via LayerGeom->get_zbin(z) and at clustering back to z via: z = z_bin x (tpc_length/2) / n_zbins.  (or rather, LayerGeom->get_zcenter(zbin))

So it is unclear to me

- how one can include a discrepancy of drift time between generation and reconstruction, to mimic an incorrect velocity ? Adding some discrepancy between LayerGeom->get_zbin(z) and LayerGeom->get_zcenter(zbin)) ? adding some correction factor after LayerGeom->get_zcenter(zbin) ?

- how we will handle that when processing real data

Maybe we can have a discussion dedicated to this next week ? (either Monday at the tracking meeting, or Tuesday during the TPC calibration ?

Hugo

On 10/25/21 20:41, Ross Corliss via sPHENIX-calibration-l wrote:

Dear Distortions Folks,

A reminder that the distortion meeting will take place tomorrow at the usual coordinates and time, 11AM EDT.  If you let me know in advance, I will add a slot to the agenda for you, but impromptu updates are also welcome.

https://stonybrook.zoom.us/j/94081538941?pwd=Y256N3ptUC9zV2M4cjNtUGgyWnJYdz09
https://indico.bnl.gov/event/12844/
-Ross

==========
Dr. Ross Corliss
Research Assistant Professor
Center for Frontiers in Nuclear Science
Stony Brook University
ross.corliss AT stonybrook.edu

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