TPC Digits/Clusters t/z shift beyond max possible

[shahor02]

@wiechula I've processed 1 pbpb event in "triggered mode", below is the plot of dz and t for the clusters reported by the reco to be on the wrong side (..Removing cluster 14 time: 485.531, abs. z: -0.534119)
There is a long tail after the "naive" last possible bin 484.5 = 250./0.516.

BTW, I see that the SAMPA response distributes the signal of this naive time within the next
8 time bins:

      const float ADCsignal = sampaProcessing.getADCvalue(static_cast<float>(nElectronsGEM));
      for (float i = 0; i < nShapedPoints; ++i) {
        const float time = absoluteTime + i * eleParam.getZBinWidth();
       ...
       mDigitContainer->addDigit( ... sampaProcessing.getTimeBinFromTime(time), globalPad,signalArray[i]);          

with most of signal going to 1nd and 2d extra bins:

root [52] sampaProcessing.getShapedSignal(20, tm0, signalArray);
root [53] signalArray
(std::vector<float> &) { 0.00000f, 15.8681f, 6.60470f, 0.324541f, 0.00819697f, 0.000148887f, 2.21938e-06f, 2.89932e-08f }

Effectively, this shifts the digits by > 1 timebin. But the reconstruction currently calculates the Z simply as a t*vdrift, w/o accounting for the delay from the sampa, hence all the clusters are shifted by >2cm.
@davidrohr , in the triggered mode this causes a loss of full drift clusters (even w/o the extra tail in timebins seen on the plot) and also makes the matching of A/C side track segments impossible. Should not the TPCCATracking use TPCFastTransofrm, which allows for the time offset subtraction in t->z conversion?

[davidrohr]

@shahor02 : It should. The conversion was written before TPCFastTransform was available.
I'll write to Sergey, if he is ready to create a simple default fast transform map for O2, which just takes into acount the shifts and drift speed.

[sgorbuno]

@shahor02
Hi Ruben, I made O2 initializer for the TPCFastTransform, but i can't find the value for T0 offset.
Where can I find it?

[shahor02]

@sgorbuno : right now not sure how to extract it w/o doing a special MC and extracting the difference between the MC and reconstructed track Z-intercept with beam-line in triggered mode. Unfortunately, I am not able to reconstruct even 1 PbPb event due to the memory problems (@matthiasrichter any news on this? PC with 32GB dies on the 1st event).

@a-mathis : I am wondering if it is a correct thing to introduce a hard cut-off on the max time-bin in the triggered mode? The mTmaxTriggered you use accounts only for the assumed ZBinWidth (i.e. VDrift), which in reality is known only after the calibration and in any case does not account for the Sampa response. Don't we simply lose the clusters with full drift ?

[davidrohr]

@shahor02 @a-mathis : In Run 2 we have a hard cut of at 1024, right? I think a hard cut at some average drift speed + 15% margin might work?

[shahor02]

@davidrohr: In the triggered mode this kind of cut will be there by construction at the readout level (as max numbers of timebins read). What's point of introducing another level of hard cut? We should have the VDrift calibrated before CTF storage so we can apply more precise cut before writing the data (and via VDrift feedback mechanism, before the reco of the following TFs). In any case, the triggered more makes sense only at low rates, we will not gain much from cutting extra bins neither in disk space nor in CPU.

@sgorbuno : here is the default sampa response vs timebin.

Don't know if the shape is realistic, but currently the hit time is incremented by ~1.6 time bins (your mT0), could be bit less for the clusters after application of the threshold, but to extract precise number one should fix the reco flow.

[wiechula]

Hi,

On 05.11.18 23:47, Ruben Shahoyan wrote: @davidrohr <https://github.com/davidrohr>: In the triggered mode this kind of cut will be there by construction at the readout level (as max numbers of timebins read). What's point of introducing another level of hard cut? We should have the VDrift calibrated before CTF storage so we can apply more precise cut before writing the data (and via VDrift feedback mechanism, before the reco of the following TFs). In any case, the triggered more makes sense only at low rates, we will not gain much from cutting extra bins neither in disk space nor in CPU.

I think in the triggered mode the correct thing would be to specify a maximum number of time bins, irrespective of the VDrift, as David said. I guess this will be what triggered readout will do. I think the problem we have is coupled with the fact how we sample the hits, which also uses VDrift ... We'll need to look into this. Andi and I will meet with Sandro as soon as possible to discuss this.

@sgorbuno <https://github.com/sgorbuno> : here is the default sampa response vs timebin. samparesp <https://user-images.githubusercontent.com/7382029/48031370-42432800-e154-11e8-97a7-3c3ea1654f7f.gif> Don't know if the shape is realistic, but currently the hit time is incremented by ~1.6 time bins (your mT0), could be bit less for the clusters after application of the threshold, but to extract precise number one should fix the reco flow.

The reason for the 1.6 time bins shift is in the sampa response itself, coupled with the relative trigger offset compare the the sampling time. The response of the sampa starts at 0 and has a peaking time of 160ns (0.8 time bins). Since we sample always at the lower edge of the time bin, the first time bin ADC value will always be 0. Andi will put this in a presentation and attach it to the discussion. In aliroot, the electronics response is defined with the maximum being at 0. In principle we can also do this in O2, but this will not be what we will have in real data. Cheers, Jens

…

— You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub <#1417 (comment)>, or mute the thread <https://github.com/notifications/unsubscribe-auth/AKri1vHGA8PLKhKadL82iRCnK7hh5BMWks5usMASgaJpZM4XesjN>.

[a-mathis]

Dear all,

Concerning the triggered readout: The idea of the hard cutoff after exactly one full drift time was to eliminate the tails you observed above. I agree, that we should minimise the dependencies on vDrift, so I'll be happy to discuss better options. Following David, I'd suggest to have a cutoff at 550 time bins. However, this again would introduce the above mentioned tails to the cluster distribution.

As already mentioned by Jens, this also concerns how we feed the hits into the digitiser. In particular, this is where the steps in the digit distribution observed in #1419 come from. We will meet asap with Sandro to fix this.

Concerning the implementation of the SAMPA: The idea was to identical behaviour as the real electronics. Therefore, the maximum of the response is shifted w.r.t. the pulse injection by the peaking time (160 ns). This time can of course increase when the pulse is misaligned with the sampling. Please see the attached slides for a more descriptive example using real test data (note that here the input comes from a pre-series SAMPA. The plan was to fine-tune the electronics response once we have the final data available, therefore the description is not yet perfect).

slides

Thanks for your input & best,
Andi

[shahor02]

@jens, @a-mathis : concerning the cutoff: I agree that we should implement in the simulation what will be in reality, i.e. fixed amount of the readout timebins, 550 should be ok.
But, as far as I understand, when we simulate the ideal TPC (default vdrit, no distortions), the only overflow beyond the TB=485 may come either from the diffusion (5sigma ~ 3 TB) and Sampa response (at most 8TB), i.e. there should be no digits with TB>496. Instead we have a tail reaching the TB 512. Do we know where it comes from, before deciding on how to cut it away?

For the delay from the Sampa response, I would simply absorb it into the vdrift calibration T0 parameter.

Cheers,
Ruben

[wiechula]

Hi Ruben,

On 06.11.18 14:25, Ruben Shahoyan wrote: For the delay from the Sampa response, I would simply absorb it into the vdrift calibration T0 parameter.

yes, this is what will be also done in real data, right? Cheers, Jens

[shahor02]

yes, this is what will be also done in real data, right?
@wiechula : yes, assuming that this shift may depend on time (as the words of @a-mathis about the misalignment suggest).

[a-mathis]

@shahor02 While the bulk of the hits has a time stamp smaller than a micro second, the digits with larger time bins stem from hits which have a time stamp of several microseconds. The largest I saw was ~12 us.

I would then in my next PR change the maximum time bin in the triggered mode to 550, or should I provide a quick fix?

[shahor02]

@a-mathis : thanks! Indeed, checking the hits I see some slow particles, this should indeed create the tail.
For the 485->550 change of the cutoff, it is not so urgent, but if you are not planning other PRs in the next few days, it is better to do this now. Currently the good clusters with full drift may be affected.

[matthiasrichter]

The hard cutoff for triggered mode as discussed above has been merged in #1467