1 / 32

Pooling & Cutting Comments-I

Pooling & Cutting Comments-I. TK Hemmick. Issue Pool Segmentation Requirements:. Particles from different centralities don’t “deserve” to be mixed with one another. The consequence of having too few pools are: Shape trouble since momentum spectrum is sensitive to centrality.

taini
Télécharger la présentation

Pooling & Cutting Comments-I

An Image/Link below is provided (as is) to download presentation Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author. Content is provided to you AS IS for your information and personal use only. Download presentation by click this link. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server. During download, if you can't get a presentation, the file might be deleted by the publisher.

E N D

Presentation Transcript


  1. Pooling & Cutting Comments-I TK Hemmick

  2. Issue Pool Segmentation Requirements: • Particles from different centralities don’t “deserve” to be mixed with one another. • The consequence of having too few pools are: • Shape trouble since momentum spectrum is sensitive to centrality. • Normalization trouble (Large x…only affects Akiba/Zajc). • Simple check is to try a large variety of pool segmentationsand then compare the resulting background asestimated for Min Bias:

  3. Surprise (to me) in Pool Segmentation. • Reaction Plane Pooling Unnecessary? • CabanaBoy allows Centrality, Z-vertex, & Reaction Plane pooling. • If we pool in reaction plane, we find: • The background shapes of different pools are QUITE different: • They have distinctly different shapes. • They have the same normalization (same evt count in every one). • When you sum across them…you get the same result as though you did not bother to pool. • I expected that reaction plane pooling would be necessary, but I was wrong (good news) and I don’t know why (worse news). • Pooling technology makes only small error: • “Akiba Pools” = Rolling buffer • Positrons from one event…electrons from another. • Is having two positrons from the SAME event OK? • “Matathias Pools” = Regenerating Pool. • Retains “requested statistics” (e.g. 2 e+ & 1 e-, regen until cuts are passed…) • No two particles are ever from the same pool. • Requested stats are “after cuts” requirements…no losses. • These pools make different normalization (must be corrected). • They don’t seem to alter the shape…again, I was surprised.

  4. Differences AkibavsMatathias (original) • Keeps event-track lists. • Two Mixing Steps: • + from “n” MIXED- from “n-1””n-d” • + from “n” MIXED+ from “n-1””n-d” • GOOD: • Real stats in like-sign. • Automatic kappa(?) • BAD: • Residual correlations? • x correction needed. +’s -’s -’s +’s -’s +’s -’s +’s -’s +’s • Keeps Large Pools • One Mixing Step: • +/- from counters w/ REGEN. • GOOD: • Bad stats (use counters!!!) • No residual correlation. • BAD: • Must avoid over-sampling. • k correction needed. • ONLY EVT CUT ALLOWED???

  5. Lunch Plans • I need to look over the current code (changed from years ago) to investigate: • How/when different cutters are applied. • Possible changes in philosophy as these were developed. • I will do this over lunch time and report in the afternoon.

  6. Our biggest enemy: PAIR CUTS! • Since ee are generated (almost) entirely in pairs…the “pre-detector” relationship BG = 2*SQRT() is rigorous. • Uncorrelated single-particle losses result in the BG=2*SQRT() normalization still being correct even when the numbers are the measured counts instead of the primordial ones (FANTASTIC!). • Correlated losses (purposeful or intrinsic) have the possibility of affecting the normalization and the shape of the background estimate. • Fundamental Question: How to apply these cuts? • Remove the pair of particles…retain the rest. • Remove one particle (RICH ring sharing) retain the other. • Remove the event. • Limit who can pair with who... (don’t pair w/ someone else’ partner)

  7. RICH Ring Sharing • A spherical mirror reflects all parallel rays to focus on a single point: • In our RICH, tracks that exit the field movingparallel would place their rings at the samelocation. • Result: in high multiplicity,some pions will accidentallyalign with an electron ring. • What do you do when an event contains such an ambiguity?

  8. Sharing (RICH, EMC, DC, …) • All finite detector segmentation effects result in some form of pair trouble. • In a calorimeter clusters will merge. • In the RICH parallel tracks share rings. • In a tracker close tracks generate ghosts or losses. • Some are APPLIED cuts and some are intrinsic. • All must be studies for bias.

  9. An Old Toy Desires New Users • YA wrote toy.cc as a standalone toy code to apply various cut techniques in the face of a STRONG NBD input distribution (k=10…WOW). • Caveats “Not exactly the same as CabanaBoy. • TKH wrote ULToysReco that places tracks made by the toy.cc routines (cut&pasted) into UltraLightTracks and feeds them to CabanaBoy. • ULToysCutter and ULToysHistos written to allow cut style changed at macro level. Code in repository All params available in macro

  10. No Cuts • Um…yeah. No Cuts = disaster • (we already knew that) Ring Sharing Peak Normalization Terrible

  11. Cut One Track • The SHAPE is bad! • The reason: • Electrons from Dalitz soft. Electrons from RING ghost stiff. • Keeping 50-50 shot keeps wrong momentum disturbs shape. Ring Sharing Peak Gone Shape is BAD!!

  12. Remove Both Tracks • Shape repaired. • Normalization “close” but not quite. No RICH Peak Good Shape (ratio flat) Normalization Low Of course…small k

  13. Remove Sharing Event • Good normalization. • Good Shape. • What Alberica has always did. No RICH peak Good Shape Good Normalization

  14. class MyCutter : public leptoCutter MyCutter Object VARIABLES float, shorts, cuts, whatever… METHODS isEventOK? isParticle1OK? isParticle2OK? isPairOK? So… we can feed the MyCutter events, particles or pairs and it simply returns bools. T. Hemmick, S. Campbell, J. Kamin, B. Huang

  15. Cutter is Properlygeneric • Look at the signature of the methods. • They want PHParticles!! Nice. • But how do I cut on CentralTrack stuff? • dynamic_cast<PHCentralTrack>(part); T. Hemmick, S. Campbell, J. Kamin, B. Huang

  16. Why are containers cool? Put old container onto buffer – 1 line Akiba Shuffle T. Hemmick, S. Campbell, J. Kamin, B. Huang

  17. Kappa • Throwing the event away was best for the RICH ring sharing trouble, but this is NOT always the best approach. • Despite the optimistic conclusion of the “Toys” slide, further studies indicate a pair bias.

  18. Results for Kappa • Cuts only result in losses of pairs. • The like-sign losses are NOT equal to the unlike sign. • Kappa fixes this trouble… • I HATE KAPPA! Let’s avoid it (when possible).

  19. Fv cuts (maximally kappa…unless…) • The opening angle plane can be used to identify pairs that are likely coming from a conversion. • These are PHYSICAL pairs that are undesirable (since they are device-dependent). • They gain an apparent mass due to the false vertex. • The opening angle is “signed” in that one knows which side the + and – go to. • fV is undefined for like-sign. • Maximally disturbing to normalization!!!

  20. Solution for fV • Any pair that “fails” the fV cut is simply identified as an uninteresting BUT physical source. • If you keep the particles failing fVthen you will get the normalization right but have an undesirable source in your measurement. • If you reject particles failing fVyou will likely introduce a kappa term and need to correct for a large cuts bias. • Solution: • Keep the particles for normalization. • Reject them after correct backgroundsubtraction! • Fill foreground and backgroundalong the pass/fail axis. • Normalize to integral of pass/fail axis • Cut the data AFTER a correct normalization is applied! pt mass Pass/fail

  21. With and Without conversion cut • This image compares the integral along the pass/fail axis to the very same axis cut on pass. • You can even make the cut into a continuous parameter to analytically increase the cuts after normalization:

  22. Correlations in like-sign • Nature’s production of like-sign pairs is NOT free of singal • “Cross pairs” = Double Dalitz…Dalitz + conversion… • Kinematical correlations from Jets?

  23. Pythia-inspired Jet contribution • Pythia can be studies to make both foreground and background pairs (mixed events) • The results (including effect of PHENIX aperture are shown below with “ZYAM” normalization. • We can project the difference into ptvs mass

  24. How can you know if you’re done? • ANSWER: Increase the background and see whether the result after subtraction is insensitive to this effect. • In PHENIX (for the single electron studies) we add a photon convertor wrapped around the beampipe to measure photonics. • This gives us a second “high background” sample.

  25. The factor “f” • We add an arbitrary normalization change onto the data as DATA = (1+f)*DATA. • We plot the subtracted results in the high background region for both the convertor and regular analysis. • These cross at f=0 verifying the subtraction. • Loosen the DCA cut to get a continuously variable bkg?

  26. Summary • Pair cuts are real trouble as these introduce a kappa factor. • Troubles with pair cuts can be circumvented WHEN THE PAIRS ARE BOTH ELECTRONS (i.e. phi-v). • When one of the pair might be a hadron, it is best to throw out the event, but you must calculate the kappa that results from this procedure.

More Related