search

JeffersonLab / hps-java

HPS reconstruction and analysis framework in Java
2 stars 10 forks source link

Fix track state at ECal #266

Closed normangraf closed 6 years ago

normangraf commented 6 years ago

Plotting the track state at the ECal face shows a microstructure (especially in y) which seems to indicate that the propagation is starting from the hit strip and not the fitted track position at the last sensor.

TrackState trackAtEcal = TrackStateUtils.getTrackStateAtECal(t);

Also, the track position at this state, viz.

double[] tposAtEcal = trackAtEcal.getReferencePoint();

appears to be in the lcsim coordinate system.

2016_fee_toptrackyatecal

Note that the large-scale structure in this particular plot arises from the requirement that the FEE ECal cluster seed energy be greater than half the beam energy and is unrelated to this issue.

normangraf commented 6 years ago

It appears that the track state at the Ecal may have been propagated from the IP. In this case, tracks which have 1-strip hits in axial layers 1 and 2 would always have a fixed theta-y (which would be an analytic function of the strip numbers in those layers). These discrete values for theta-y would then show up as discrete values of y. There also seems to be an alternating pattern of high/low peaks in the fine structure, especially at values of x between 25 and 35

mdiamon commented 6 years ago

Currently, it extrapolates to the z position given by ecalPosition = detector.getConstants().get("ecal_dface").getValue(); which is apparently the position of the "scoring plane". Do we want to set this to a different value (e.g. crystal face)?

normangraf commented 6 years ago

Let's fix the problem first, then we can discuss whether we wish to extrapolate to this plane, the crystal face, or to the z of shower max.

normangraf commented 6 years ago

I was mistaken when viewing the Wired event display. The value of "ecal_dface" is 1393mm, which is pretty much right up against the face of the Ecal crystals.

normangraf commented 6 years ago

trackatecalz_ecalclusterzoverlay Here's a plot of the z position for the TrackAtEcal state and also for the calorimeter clusters. I think we're fine.

mdiamon commented 6 years ago

Sorry, I thought it was resolved, but not yet. It's changing the # of reconstructed particles more often than I'm comfortable with. I think it's because of effects on track-cluster matching. Needs more study.

mdiamon commented 6 years ago

Resolved by PR #287