There is another issue here, which is what I was referring to in the EC meeting.
I know we discussed this before, but it has been a while:
A fundamental issue in the way the corrections were done is that they assume that an energy maps uniquely to an x-position on the ECal face: that the variation in x_Ecal is entirely due to energy. (analysis assumes energy varies but phi_0 = 0)
https://confluence.slac.stanford.edu/download/attachments/174396677/Report_ECal_simulations.pdf
Our data is totally different, especially for FEE, which is what you are looking at here. In this case, the energy is the same for all particles and what is responsible for all of the variation in x_Ecal is phi_0, the horizontal angle at the origin of the track. (energy is constant but phi_0 varies)
The significance of this is that the angle that the track makes with the ECal face is completely different as a function of x_ECal for these two cases. The corrections to cluster position were derived assuming the former, but the data you have with FEEs needs a different correction because the entry angle into the ecal is different as a function of x_ECal.
Tim
> On Feb 25, 2019, at 12:26 PM, Nelson, Timothy Knight <[log in to unmask]> wrote:
>
> Right, but the field map changed, no?
>
> Tim
>
>> On Feb 25, 2019, at 11:19 AM, Nathan Baltzell <[log in to unmask]> wrote:
>>
>> Tim pointed out the bottom right, py vs dx, “funny business” could be from the current cluster corrections. But from what I understand, and Holly reminded me, those corrections were calculated from full 3-D field in SLIC and truth position at ECAL, so independent of changes to the extrapolator in reconstruction. Did we not really have full 3-D field in SLIC/GEANT?
>>
>> -Nathan
>>
>>> On Feb 25, 2019, at 13:02, Graf, Norman A. <[log in to unmask]> wrote:
>>>
>>> Hello Nathan,
>>>
>>> Thanks for this update. I'll have to spend some time digesting the information.
>>>
>>> I posted the original plots on the 2pt3gev channel in slack.
>>>
>>> Norman
>>>
>>>
>>> From: Nathan Baltzell <[log in to unmask]>
>>> Sent: Monday, February 25, 2019 9:26 AM
>>> To: Graf, Norman A.
>>> Cc: [log in to unmask]; hps-software
>>> Subject: Re: ECal-SVT relative alignment
>>>
>>> Hi Norman And All,
>>>
>>> I started to look into this. I think Norman is right that there’s an issue with the old method, *especially* if a correction is already applied in the nsigma. Meanwhile, I do remember its original incarnation gave different results than the software geometry at the time (asymmetric top/bottom, per survey), and was reasonably consistent with an independent method.
>>>
>>> Anyway, I went back to just cluster/track positions (using the pass4 2016 ntuples), and I don’t yet find any evidence that we need to move the calorimeter in Y. Various plots attached, we can discuss in a meeting or on slack; I’ll put together a proper presentation if people want. There does appear to be some funny business maybe related to magnetic field or non-calorimeter alignment.
>>>
>>> -Nathan
>>>
>>> P.S. I heard there was a Slack channel on this, but couldn’t find it.
>>>
>>>
>>>
>>>
>>>> On Feb 14, 2019, at 19:43, Graf, Norman A. <[log in to unmask]> wrote:
>>>>
>>>> Dear Colleagues,
>>>>
>>>> One of the few outstanding issues holding up the generation of a high-statistics MC sample to accompany the 2016 data analysis is the determination of the ECal position relative to the SVT. I have repeated the analysis pioneered by Nathan to plot the track-cluster match nSigma vs y for the 2016 data. Specifically, I used the FEE runs 7479 and 7483. I get essentially the same values (~42.5) as were found for the 2015 data. I have posted plots and some description to the slack 2pt3gev channel. I would appreciate it if someone were to review the methodology to ensure that this technique is valid, i.e. that there are no hidden corrections in the calculation of nSigma which would skew the measurement.
>>>>
>>>> Sincerely,
>>>> Norman
>>>>
>>>> If anyone wants to replicate this, I used the org.hps.analysis.alignment.SvtCalorimeterAlignmentDriver class with the following modification to pick up the new FEE collection,
>>>>
>>>> protected void process(EventHeader event) {
>>>> List<ReconstructedParticle> rpList = event.get(ReconstructedParticle.class, "FinalStateParticles");
>>>> if (event.hasCollection(ReconstructedParticle.class, "OtherElectrons")) {
>>>> rpList.addAll(event.get(ReconstructedParticle.class, "OtherElectrons"));
>>>> }
>>>> for (ReconstructedParticle rp : rpList) {
>>>>
>>>> if (!TrackType.isGBL(rp.getType())) {
>>>> continue;
>>>> }
>>>>
>>>> // require both track and cluster
>>>> if (rp.getClusters().size() != 1) {
>>>> continue;
>>>> }
>>>>
>>>> if (rp.getTracks().size() != 1) {
>>>> continue;
>>>> }
>>>>
>>>> double nSigma = rp.getGoodnessOfPID();
>>>> Track t = rp.getTracks().get(0);
>>>> TrackState trackAtEcal = TrackStateUtils.getTrackStateAtECal(t);
>>>> double[] tposAtEcal = trackAtEcal.getReferencePoint();
>>>>
>>>> // look for calorimeter edge wrt SVT
>>>> if (tposAtEcal[2] > 0) {
>>>> trkAtEcalXvsNSigmaTop.fill(nSigma, tposAtEcal[2]);
>>>> } else {
>>>> trkAtEcalXvsNSigmaBottom.fill(nSigma, -tposAtEcal[2]);
>>>> }
>>>> }
>>>> }
>>>>
>>>>
>>>> Use REPLY-ALL to reply to list
>>>>
>>>> To unsubscribe from the HPS-SOFTWARE list, click the following link:
>>>> https://listserv.slac.stanford.edu/cgi-bin/wa?SUBED1=HPS-SOFTWARE&A=1
>>>>
>>
>>
>> ########################################################################
>> Use REPLY-ALL to reply to list
>>
>> To unsubscribe from the HPS-SOFTWARE list, click the following link:
>> https://listserv.slac.stanford.edu/cgi-bin/wa?SUBED1=HPS-SOFTWARE&A=1
>
>
> ########################################################################
> Use REPLY-ALL to reply to list
>
> To unsubscribe from the HPS-SOFTWARE list, click the following link:
> https://listserv.slac.stanford.edu/cgi-bin/wa?SUBED1=HPS-SOFTWARE&A=1
########################################################################
Use REPLY-ALL to reply to list
To unsubscribe from the HPS-SOFTWARE list, click the following link:
https://listserv.slac.stanford.edu/cgi-bin/wa?SUBED1=HPS-SOFTWARE&A=1
