Sphenix-calibration-l mailing list

[Anthony Frawley <afrawley AT fsu.edu>]

Hi Hugo,

Good question. Thinking more about it:

There is a particular drift velocity implicit in the conversion of time to z position in the electron drift code - the magic drift velocity.

So, if we use a drift velocity in the electron drift code that is different from that one, we will compress or expand the z scale relative to the z position truth.

But the effect of using something other than the magic drift velocity depends on how far the electron drifts, which depends on the start time.

Because the g4hit knows the start time, and the TPC does not, I think we have to do this in the electron drift code.

All of this makes me wonder if we should not make the hits use TPC readout time instead of z. Comments?

Cheers

Tony

---

From: Hugo Pereira Da Costa <hugo.pereira-da-costa AT cea.fr>
Sent: Wednesday, October 27, 2021 3:52 PM
To: Anthony Frawley <afrawley AT fsu.edu>; sphenix-calibration-l AT lists.bnl.gov <sphenix-calibration-l AT lists.bnl.gov>
Subject: Re: [Sphenix-calibration-l] Drift velocity in TPC code

 

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