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