Sphenix-calibration-l mailing list

[Anthony Frawley <afrawley AT fsu.edu>]

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?).

--- Essentially, make the drift velocity correction a fit parameter, and fit many tracks.

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.

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