Here’s a followup that could agree with Tim’s hypothesis, but also possibly various other magnetic field effects, where the dx issues (probably) have the appropriate symmetries with q/Py/Bz.

-Nathan

> On Feb 25, 2019, at 14:19, 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
>>>
>