Hi all,<div><br></div><div> So I went and took another look at the energy dependence of the preshower location, because at the time I had a lot of back and forth between Transversity BB lib and our d2n lib. I replayed 100,000 events for a negative 1-pass H2 and 3He run for the original preshower location currently in our db this has the detector at </div>
<div><br></div><div> x=0.0, y=0.0 and z=0.77m (in detector coords) </div><div><br></div><div>and again for the transversity preshower location, this was at</div><div><br></div><div> x= -0.015m, y=0.0 z=0.97m (detector coords)</div>
<div><br></div><div>Here I only show the results for the 1-pass 3He run, because the 1-pass H2 showed the same behavior. There are 2 versions of each plot ones with d2_xxxxx.png are with the current d2n preshower location and the ones labeled trans_xxxxxx.png are with the transversity location. The d2/trans_ps.png shows the preshower energy, this is identical between the 2 different preshower locations. The next thing that I checked is the preshower cluster positions, d2/trans_clusloc.png these also seem to be consistent. Finally I also checked the difference between the preshower cluster X,Y and the reconstructed track onto the preshower, using a projected track distance of 0.77m for d2_ps_trkdiff.png and 0.97m for trans_ps_trkdiff.png. This plot shows a large resolution difference.</div>
<div><br></div><div>When I did go through the THaBBTotalShower class in our current db, there was some reference to tracking in the Coarse() and Fine() functions. It seems like there was cluster matching, but was commented out, this can be seen in the CoarseProcess(). I am not too sure what the FineProcess() is doing however. The relevant code is as follows:</div>
<div><br></div><div>THaBBTotalShower::CoarseProcess(TClonesArray& tracks )<div>{</div><div> // Reconstruct Clusters in shower and preshower detectors.</div><div> // Then compute total shower energy and cluster ID.</div>
<div> //</div><div> // Valid fIDs:</div><div> // 1 Matching clusters found.</div><div> // 0 Clusters found, but separated too far</div><div> // -1 No cluster found in either shower or preshower or both</div>
<div> //</div><div><br></div><div> if( !IsOK() )</div><div> return -1;</div><div><br></div><div> fPreShower->CoarseProcess(tracks );</div><div> fShower->CoarseProcess( tracks );</div><div><br></div>
<div> fNclust = 0;</div><div><br></div><div> // if( ( fShower->GetNclust()+fPreShower->GetNclust() )> kMaxNClust ) cerr << "Error: Too many clusters ( " << fShower->GetNclust() << " shower and " << fPreShower->GetNclust() << " preshower ). We are restricted to " << kMaxNClust << endl;</div>
</div><div><div> for (int sh=0;sh<fShower->GetNclust();sh++) {</div><div> Bool_t keep = false;</div><div> Int_t ps = 0;</div><div> while ((ps < fPreShower->GetNclust()) && (fNclust < kMaxNClust)) {</div>
<div> double dx = fShower->GetClust(sh)->GetX()-fPreShower->GetClust(ps)->GetX();</div><div> double dy =</div><div> fShower->GetClust(sh)->GetY()-fPreShower->GetClust(ps)->GetY(); if (TMath::Abs(dx)<fMaxDx && TMath::Abs(dy)<fMaxDy && (fNclust < kMa</div>
<div>xNClust)) {</div><div> keep = true;</div><div> fE[fNclust] = fShower->GetClust(sh)->GetE() + fShower->GetClust(</div><div>ps)->GetE();</div><div> fX[fNclust] = fShower->GetClust(sh)->GetX();</div>
<div> fY[fNclust] = fShower->GetClust(sh)->GetY();</div><div> fID[fNclust] = 1;</div><div> fNclust++; }</div><div> ps++;</div><div> }</div></div>
<div><div> for (int ps=0;ps<fPreShower->GetNclust();ps++) {</div><div> Bool_t keep = false; Int_t sh = 0;</div><div> while (!keep && sh < fShower->GetNclust()) {</div><div> double dx =</div>
<div> fShower->GetClust(sh)->GetX()-fPreShower->GetClust(ps)->GetX();</div><div> double dy =</div><div> fShower->GetClust(sh)->GetY()-fPreShower->GetClust(ps)->GetY();</div>
<div> if (TMath::Abs(dx)<fMaxDx && TMath::Abs(dy)<fMaxDy)</div><div> keep = true;</div><div> sh++;</div><div> }</div><div> // This throws away if they cluster positions are not within some range.</div>
<div> Let's not do that for now</div><div> //if (!keep)</div><div> // fPreShower->RemoveCluster(ps--);</div><div> }</div><div><br></div><div><br></div><div> return 0;</div><div>}//_____________________________________________________________________________</div>
<div>Int_t THaBBTotalShower::FineProcess( TClonesArray& tracks )</div><div>{</div><div> // Fine processing.</div><div> // Call fPreShower->FineProcess() and fShower->FineProcess() in turn.</div><div> // Return return value of fShower->FineProcess().</div>
<div><br></div><div> if( !IsOK() )</div><div> return -1;</div><div><br></div><div> fPreShower->FineProcess( tracks );</div><div> return fShower->FineProcess( tracks );</div><div>}</div></div><div><br>
</div><div><br></div><div>-Matt </div><div><br></div><div><div class="gmail_quote">On Thu, Oct 14, 2010 at 6:15 PM, Brad Sawatzky <<a href="mailto:brads@jlab.org">brads@jlab.org</a>> wrote:<br>
<blockquote class="gmail_quote">Sorry I had to vanish today. (I'm really looking forward to next monthwhen things should calm down some...)<br>
<br>
Anyway, I found a note from our meeting on 01 July 2010 where we saw<br>
that a change in the preshower location in the DB had a big effect on<br>
the shower vs. preshower histogram. This was later traced to the the<br>
(old) shower class using the projected track information as a factor in<br>
its cluster identification. (I think Diana recalled this episode just<br>
before I had to go.)<br>
<br>
Bottom line is that even in the old Shower code, the "total deposited<br>
energy" information reported by the Shower code can be influenced by the<br>
reconstructed track -- something that needs to be kept in mind. That<br>
couples the shower energies to the behavior of the tracking code in a<br>
non-trivial way.<br>
<br>
-- Brad<br>
<br>
--<br>
<font color="#888888">Brad Sawatzky, PhD <<a href="mailto:brads@jlab.org">brads@jlab.org</a>> -<>- Jefferson Lab / Hall C / C111<br>
Ph: 757-269-5947 -<>- Fax: 757-269-5235 -<>- Pager: <a href="mailto:brads-page@jlab.org">brads-page@jlab.org</a><br>
The most exciting phrase to hear in science, the one that heralds new<br>
discoveries, is not "Eureka!" but "That's funny..." -- Isaac Asimov<br>
_______________________________________________<br>
d2n-analysis-talk mailing list<br>
<a href="mailto:d2n-analysis-talk@jlab.org">d2n-analysis-talk@jlab.org</a><br>
<a href="https://mailman.jlab.org/mailman/listinfo/d2n-analysis-talk">https://mailman.jlab.org/mailman/listinfo/d2n-analysis-talk</a><br>
</font></blockquote></div><br><br clear="all"><br>-- <br>Matthew Posik<br>Email: <a href="mailto:posik@temple.edu">posik@temple.edu</a><br>Temple University Physics Dept.<br>Office: BA-319<br>Office #: 215-204-1331 <br>
WebSites:<br>Temple:<br><a href="http://quarks.temple.edu/">http://quarks.temple.edu/</a><br>d2n:<br><a href="http://hallaweb.jlab.org/experiment/E06-014/">http://hallaweb.jlab.org/experiment/E06-014/</a><br><br>
</div>