<!-- Title: 11:31:30  Mon Nov  1 2004 -->
<!-- Crewchief: Bruce Knuteson -->
<!-- Op1: &nbsp; -->
<!-- Op2: &nbsp; -->
<!-- Op3: &nbsp; -->
<!-- Op4: &nbsp; -->
<!-- Op5: &nbsp; -->
<!-- Op6: &nbsp; -->
<!-- Notes: -->
Vista@CDF: a global look at CDF high-pT data


<!-- Date: Mon Nov 1 12:24:55 2004 -->
"People" should also include Markus Klute, Khaldoun Makhoul, Georgios Choudalakis, Ray Culbertson, Steve Levy.  This elog is set up for the convenience of the Vista@CDF project, for posting plots, referencing useful observations, and above all pointing out discrepancies. 
  
<!-- Author: Knuteson -->


<!-- Date: Wed Nov 3 13:50:46 2004 -->
<pre>Email test.</pre>
<!-- Author: Knuteson -->


<!-- Date: Thu Nov 4 08:46:27 2004 -->
<table><tr><td><a href=/elog/notebooks/Vista/Thu_Nov__4_2004_084604.ps align=top><img src=/cgi/elog/det-system-elog.pl?nb=Vista&action=view&page=-2  align='top'></a></td><td>Problem with muon pt</td></tr></table>
<!-- Author: Knuteson -->
<!-- Comment: Thu Nov  4 08;53;43 comment by...Knuteson -->
The problem we are seeing with muon pt appears I think to be due to cosmic rays, rather than incorrectly measuring the curvature of the muon track.  (Steve will hopefully check this for sure using electron tracks.)  I base this statement on the nicely reconstructed Z mass seen in this comparison (where we have remove dimuon events with deltaphi(mu1,mu2)>3.1 radians, eliminating cosmic rays from this sample).

If cosmic rays are indeed the problem, we will want to implement the latest and greatest from CosmicMods.

Click on the picture in this log entry to view it.

The W- > mu nu cross section folk must have gotten around this problem somehow.  (How?)



<!-- Date: Thu Nov 4 14:26:28 2004 -->
The electron and photons samples we have been using in our comparisons only include run numbers up to 175000, while the muon sample contains run numbers beyond 175000.  This has caused some of the normalization problems seen in our comparison.  Until we rerun over data up to mid-2004, I will restrict our analysis to runs up to 175000.  This corresponds to 178.5 pb^-1.  
<!-- Author: Knuteson -->


<!-- Date: Thu Nov 4 16:48:12 2004 -->
Vista@CDF v02.8 is now located <a href="http://mit1.fnal.gov/~knuteson/Quaero/quaero_development/doc/devel/cdf/Vista/madevent/v02.8/">here</a>.<p> 
Changes:<br> 
  <dd>reverted from likelihoods to CDF standard object ID cuts 
  <dd>reverted from kT jets to cone jets 
  <dd>now using a set of run numbers consistent among electrons, muons, and photons 
  <dd>p(j->mu) zeroed (set to 1e-08) 
  <dd>problem in handling background Monte Carlo zvtx position fixed (in ReconstructEvent_stn.cc) 
  <dd>p(j->e) increased to accomodate 1e1j final states 
 <br>  
<!-- Author: Knuteson -->


<!-- Date: Fri Nov 5 09:30:16 2004 -->
I have modified my GraphicalOutputSimple class to show the (dominant four) processes contributing to the background estimate.  The link in the above entry has been replaced with the improved comparison.
<!-- Author: Knuteson -->


<!-- Date: Sat Nov 6 20:02:44 2004 -->
<pre>The peak of the data in mass(e+,e-) in the final state 1e+1e- is lower than in Monte Carlo; I have reduced plug electron energies in the Monte Carlo by 4% as a fudge to compensate.  (Presumably there is an "official" way to handle this?) 
 
There are more 1e1ph events in data than expected from background; I have set p(e-&gt;"ph")=0.01. 
 
I discovered what I believe is an error in my setting of nupmax as input to mlm.f from generateAllMadEventProcesses.cpp -- I was setting nupmax e.g. to 3 for e+e-jjj (for the 3 jets), when it looks like it should be set to 5 (for the 5 particles, counting the electrons).  I am rerunning the SM event generation now on the rtc and uchicago clusters.</pre>
<!-- Author: Knuteson -->


<!-- Date: Sun Nov 14 09:57:22 2004 -->
In going from Vista@CDF v03.1 to v03.1.1, I updated the JetUser jet corrections library.  I re-ran the Standard Model prediction using these new jet corrections, but did not run the data through the same.  I believe this is the cause of the much larger discrepancies I see in v03.1.1 than were seen in v03.1.  I am rerunning the data through the new jet corrections now.
<!-- Author: Knuteson -->


<!-- Date: Sun Nov 14 15:05:23 2004 -->
<pre>Vista@CDF v03.1.2 contains the new jet corrections, but still looks horrible.  I reduced p(j-&gt;"e") from 2.9e-05 to 1.4e-05 for v03.1.3, and now see agreement that is close to what we had in v03.1.  This comparison is with electrons and muons only; my jobs converting cph10da Stntuples to text files with the new jet corrections is still running.   
The next step is to again include Mrenna's W-&gt;e+ve and W-&gt;mu+vm samples, and see where we are.  This will become v03.1.4.</pre>
<!-- Author: Knuteson -->


<!-- Date: Sun Nov 14 16:06:32 2004 -->
<pre>v03.1.4 contains W-&gt;e+ve and W-&gt;mu+vm from Mrenna's MadEvent samples, and represents an improvement. 
For v03.1.5, I am reducing p(j-&gt;"tau") from 0.01 to 0.005 in the central region.  I am also performing a simple e+ -&gt; e- and mu+ -&gt; mu- switch to create W-&gt;e-ve- and W-&gt;mu-vm- Mrenna samples corresponding to the positively charged leptons in the files I actually have.  This is running now.</pre>
<!-- Author: Knuteson -->


<!-- Date: Sun Nov 14 17:25:14 2004 -->
<pre>v03.1.5 looks as expected. 
For v03.1.6, I am changing midId.dat:"j -&gt; j  1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 0 0 0 0" to midId.dat:"j -&gt; j  1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1" in an attempt to solve the problem I see with 1e1j:j_eta.  I have changed Refine.cc to remove objects with |eta|&gt;2.5 to help address the same problem.  I have also changed p(mu-&gt;"mu") from 0.93 to 0.95 to be consistent with Victoria Martin's talk at a recent joint physics meeting and obtain better agreement in this comparison.   
 
</pre>
<!-- Author: Knuteson -->


<!-- Date: Sun Nov 14 20:10:06 2004 -->
v03.1.6 looks as expected.  For v03.1.7, I am including photon data from cph10da; my run over the Stntuples to make text files finished while I was at the gym this evening.  I have modified checkDistributions.cc to take an option to only generate plots in final states with an expected background greater than 100 events; this in the interest of speed.
<!-- Author: Knuteson -->


<!-- Date: Sun Nov 14 21:51:28 2004 -->
<pre>v03.1.7 shows normalization disagreement in Nj1ph.  Changed the kfactor mad_0l1ph1j0b from 1.05 to 1.33.  Set all kfactors mad_2l0phNjNb to 1.25.  Multiplied offline luminosity of 285.6 pb^-1 by 1.019 from the Physics Coordinator's web page (so lumi is now 290.03 pb^-1).  Running v03.1.8 now with these changes.</pre>
<!-- Author: Knuteson -->


<!-- Date: Mon Nov 15 08:53:55 2004 -->
v03.1.8 looks as expected.  For v03.1.9, I am changing p(e->"j") from 0 to 0.05 in the plug region, for consistency with <a href="http://fcdfwww.fnal.gov/internal/WebTalks/Archive/0402/040220_joint_physics/05_040220_joint_physics___other_1_0_jp_2004_feb_20.pdf">Cigdem's talk</a> and to help explain the Z peak I see in 1e1j:mass(e,j).  Running this now.  
<!-- Author: Knuteson -->


<!-- Date: Mon Nov 15 10:01:55 2004 -->
Little difference is observed between v03.1.8 and v03.1.9.  I am now changing p(b->"e") from 0 to 0.001 to see what effect this has on the 1e1j final states.  This will become v03.2.  
<!-- Author: Knuteson -->
<!-- Comment: Mon Nov 15 10;48;58 comment by...Knuteson -->
I have also added stripFakes "b" to mad processes not containing a b in Vista/files/carlo/mc/madevent/cdfSim/prepareSm.tcsh, to eliminate CdfSim misreconstructing a j as a b, and then having misReconstruct re-misReconstruct the object as an electron using p(b->"e").


<!-- Date: Mon Nov 15 14:56:15 2004 -->
<pre>For v03.2.01, I am replacing my stn_mad_e+e-(nj) samples with Mrenna's matched stn_mad_e+e-(nj) samples. 
For v03.2.02, I am removing plug b-jets in Refine.cc.  Also changing p(j-&gt;"b") from 0.001 to 0.01, based on Figure 1(b) of CDF-7326.  Also changing p(e-&gt;"tau") from 0 to 0.01 to help disagreement in 1e-1tau+.  I have queries in to Mrenna regarding the normalization of his Z-&gt;ee sample and my matched MadEvent aj and ajj samples.  Running the new comparison now -- this will become v03.2.03. 
 
</pre>
<!-- Author: Knuteson -->
<!-- Comment: Mon Nov 15 16;12;40 comment by...Knuteson -->
I meant of course "this will become v03.2.02".


<!-- Date: Mon Nov 15 16:16:40 2004 -->
I asked Chris Hays the difference difference in the muon pT distributions between pg. 16 of <a href="http://fcdfwww.fnal.gov/internal/WebTalks/Archive/0410/041026_wz/02_W_1_mytalk.ps">Victoria's talk</a> and pg. 2 of his recent <a href="http://www-cdf.fnal.gov/internal/WebTalks/Archive/0411/041111_cdf/04_041111_cdf_W_massgroup_1_wmassstatus_111104.pdf">CDF Weekly meeting talk </a>.  The COT t0 was apparently treated incorrectly in the 5.3.3 simulation.  Ray is now rerunning the W and Z to muon Mrenna matched samples with a piece of the 5.3.4 tcl that does this properly. 
  
<!-- Author: Knuteson -->


<!-- Date: Mon Nov 15 16:21:37 2004 -->
I have changed p(b->"e") from 0.001 to 1e-4 to resolve a discrepancy in the final state 1b1e.  This change will go into v03.2.03.
<!-- Author: Knuteson -->


<!-- Date: Tue Nov 16 11:54:05 2004 -->
<pre>Ray has re-run the simulation with a new tcl file that we hope will resolve the muon pT problem we see.  The new files include Mrenna's W-&gt;mu nu +jets samples and Mrenna's Z-&gt;mu mu +jets samples (the latter is known to be screwed up -- Mrenna is working to fix this).  I am rerunning the comparison with these new files -- this new comparison will be v03.2.04.</pre>
<!-- Author: Knuteson -->


<!-- Date: Thu Nov 18 16:46:43 2004 -->
There does indeed appear to be something wrong with Mrenna's Z->ee+jets samples in addition to his Z->mumu+jets samples, according to Steve, who is investigating this.  My current version of mlm.f does not work for aj and ajj final states, according to Mrenna -- the mlm.f code needs to be fixed to accommodate this.  This (presumably) explains the discrepancy I currently see in the final states 1ph1j and 1ph2j.  I am now generating my own V+jets samples on the Rice Terascale Cluster, targeted to finish in roughly 24 hours.
<!-- Author: Knuteson -->


<!-- Date: Sun Nov 21 15:59:47 2004 -->
<pre>An event display look at the events in the final states 2e+ and 2e- indicate that these events are "clearly" conversions, as one of the electrons has a nearby oppositely-signed track in each case.  I am imposing an e+ &lt;--&gt; e- mix-up rate p(e+- -&gt; "e-+") in order to model this in Vista.</pre>
<!-- Author: Knuteson -->


<!-- Date: Wed Dec 1 19:28:58 2004 -->
Vista@CDF comparison v4.0.00 has just been completed.  This version implements a better understanding of Mrenna's matching prescription (and the use of nupmax in mlm.f in particular).  I see lots of discrepancies; currently working to understand these.
<!-- Author: Knuteson -->


<!-- Date: Wed Dec 1 19:30:20 2004 -->
Vista@CDF v04.0.01 implements improved fudge factors and a first shot at including events that pass a "trigger" of containing one jet with pT > 125 GeV.
<!-- Author: Knuteson -->


<!-- Date: Wed Dec 1 22:03:38 2004 -->
Vista@CDF v04.0.03 implements some fudge factor changes.  The next step is to use constructMisidentificationMatrix to systematically determine fudge factors.
<!-- Author: Knuteson -->


<!-- Date: Thu Dec 2 10:45:48 2004 -->
I am reverting to a comparison with 35pb^-1 of data in order to have a consistent run set of electrons, muons, photons, and jets.  I am rerunning ReconstructEvent_stn.cc over gjt40d_533nt to be able to use the full 285pb^-1; a substantial fraction of my gjt40d_533nt jobs must have failed previously.  Now gearing up constructMisidentificationMatrix to determine fudge factors.
<!-- Author: Knuteson -->


<!-- Date: Thu Dec 2 20:18:42 2004 -->
Tonight I am rerunning over bewk0d and bewk2d.  I am now using ZVertexBlock and ordering vertices according to sumPt, rather than using VertexBlock and ordering according to the number of tracks; I will then require that all events have a found vertex with fabs(z)<60cm.  I am now also identifying CMX muons.  No other changes to object id at this time.
<!-- Author: Knuteson -->


<!-- Date: Fri Feb 4 11:39:59 2005 -->
<pre>Back in action after finishing this consuming Special Relativity course. I believe the poor agreement in jet final states may be due to my not generating jets at low enough pt.  I was making a pt cut on generator-level jets at 125 GeV for a Vista trigger cut of 150 GeV, which is silly.  I am now reducing the generator-level jet cut to 100 GeV, and rerunning the mad_jj sample (with nupmax=2).</pre>
<!-- Author: Knuteson -->


<!-- Date: Sat Feb 5 10:34:20 2005 -->
I have raised the sumPt threshold on final states with only jets to 500 GeV, in order to get above the generator level cut of 125 GeV on the leading jet mentioned in the previous log entry.  I am also tweaking lumi and misId fudge factors.
<!-- Author: Knuteson -->


<!-- Date: Sat Feb 5 11:41:08 2005 -->
<table><tr><td><a href=/elog/notebooks/Vista/Sat_Feb__5_2005_114050.ps align=top><img src=/cgi/elog/det-system-elog.pl?nb=Vista&action=view&page=-4  align='top'></a></td><td>1e+2j1pmiss discrepancy 
</td></tr></table>
<!-- Author: Knuteson -->
<!-- Comment: Wed Feb  9 16;31;27 comment by...Markus -->
<pre>the hypothesis so far is that the excess is 1e2j1pmiss and 1e3j1pmiss is due to Zj(j) events where one jet is close to the electron and causes a id inefficiency for the electron. The event is reconstructed with only one electron, but one additional jet. The missing Et could have been generate by the jet energy corrections.

A deltaR cut between a lepton and a jet was removed in the madevent event generation to verify the assumption. </pre>


<!-- Date: Sun Oct 30 09:19:47 2005 -->
Due to a CVS update mistake, the cph10da data in the current comparison does not have Ray's photon energy corrections applied.  I am re-running over the cph10da sample now.  This is intended to address 2ph:mass(ph1,ph2).<p> 
My hypothesis about 1e+1tau+:mass(e+,tau+) is that the Stntuple used for the mrenna_e+e- Monte Carlo is dev_242_11rlc, rather than dev_243.  I am currently running over tewk1e, a dev_243 Z->ee Monte Carlo sample from the electroweak group, to test this hypothesis.  Also, this sample has been generated with Pythia Tune AW, which will allow us to check 1e+1e-:uncl_pt at the same time.<p> 
  
<!-- Author: Knuteson -->


<!-- Date: Sun Oct 30 09:29:43 2005 -->
The current 1e+1j1pmiss discrepancy likely comes from including both j and jf objects when calculating the kT balance in sumOverProcesses.cc.  This has been fixed, and will be included in the next comparison.<p> 
Today's comments refer to the <a href="http://mit.fnal.gov/~knuteson/Quaero/quaero_development/doc/devel/cdf/Vista/2005_10_30_00:20:22/shape.txt">2005_10_30_00:20:22 comparison</a>.
<!-- Author: Knuteson -->


<!-- Date: Sun Oct 30 11:55:48 2005 -->
The Sleuth 2ph1pmiss:sumPt discrepancy appears related to the 2ph:mass(ph1,ph2) discrepancy, which should be helped by re-running over cph10da.
<!-- Author: knuteson -->


<!-- Date: Sun Oct 30 13:27:10 2005 -->
I ran over tewk1e (a Z->ee electroweak group monte carlo dev_243 Stntuple sample) to see if using a newer Stntuple resolves the tau discrepancies we are seeing.  The discrepancy is not resolved, but the nature of the problem was brought to light.  See the tau+_detEta distribution on page 4 of <a href="http://mit.fnal.gov/~knuteson/Quaero/quaero_development/doc/devel/cdf/Vista/2005_10_30_00:20:22/plots_1e+1pmiss1tau+.ps">plots_1e+1pmiss1tau+.ps</a>.  The simulation systematically misreconstructs an electron as a tau too often in the region |detEta|<0.1.<p> 
For now I am adding a hack to Refine.cc that turns all taus with |detEta|<0.1 into jets. 
 
<!-- Author: knuteson -->


<!-- Date: Sat Nov 5 20:25:24 2005 -->
We are now able to get 1e+1e-:uncl_pt,clusteredObjectsRecoil_pt,pmiss_pt roughly right in the current comparison at http://mit.fnal.gov/~knuteson/Quaero/quaero_development/doc/devel/cdf/Vista/2005_11_05_18:48:29/, page 65 of the plots.ps.gz file.  I have committed the modification in sumOverProcesses.cc to CVS. 
 
 
  
<!-- Author: knuteson -->


<!-- Date: Wed Nov 23 15:27:39 2005 -->
<table><tr><td><a href=/cgi/elog/det-system-elog.pl?nb=Vista&action=view&page=-5&button=yes target='xxx' onclick='jswindow()'; align=top><img src=/cgi/elog/det-system-elog.pl?nb=Vista&action=view&page=-5  width='300' align='top'></a></td><td>After some investigation we think it would be right to hard-code the following effect: The probability that a jet fakes a photon is higher in detEta>1.1 by about a factor of 3, as compared to the same probability in the central region.  
In the following image you see the detEta(black) and the eta(red) distributions of photons coming from jets faking photons, coming from the pythia_jj_040 sample.</td></tr></table>
<!-- Author: Georgios Choudalakis -->


<!-- Date: Tue Nov 29 09:02:34 2005 -->
<table><tr><td><a href=/elog/notebooks/Vista/Tue_Nov_29_2005_090229.ps align=top><img src=/cgi/elog/det-system-elog.pl?nb=Vista&action=view&page=-11  align='top'></a></td><td>Generated Sum Pt spectrum of pythia photon+jet events before and after the fix.</td></tr></table>
<!-- Author: knuteson -->


<!-- Date: Tue Nov 29 09:03:47 2005 -->
<table><tr><td><a href=/elog/notebooks/Vista/Tue_Nov_29_2005_090344.ps align=top><img src=/cgi/elog/det-system-elog.pl?nb=Vista&action=view&page=-13  align='top'></a></td><td>The above entry shows the plot only after the fix.  Here is the plot before the fix.</td></tr></table>
<!-- Author: knuteson -->


<!-- Date: Fri Dec 16 19:23:05 2005 -->
<center><a href='/elog/notebooks/Vista/Fri_Dec_16_2005_192220.ps'><img src='/cgi/elog/det-system-elog.pl?nb=Vista&action=view&page=-23' ></a><a href='/elog/notebooks/Vista/Fri_Dec_16_2005_192211.ps'><img src='/cgi/elog/det-system-elog.pl?nb=Vista&action=view&page=-21' ></a></center>
<!-- Author: Georgios Choudalakis -->
<!-- Comment: Fri Dec 16 19;24;15 comment by...Georgios Choudalakis -->
<pre>The second ps file shows the 1e+1pmiss final state data, compared to the wewkee sample assigned a cross section of 4nb (which obviously is too big). 
The first ps file is the same final state with the mrenna_e+ve and mrenna_e-ve- samples. We should have not used 4nb but something like 3.6nb, and then then mrenna and wewkee would agree. The shapes are very close, and that is our conclusion. We did all that in order to confirm that the mrenna samples agree in shape with the samples of the EWK group.</pre>


<!-- Date: Sat Jan 7 15:45:40 2006 -->
<pre>In this afternoon's comparison the following changes are made: 
 
  * We use sewkad (a gen6 sample) rather than wewkee (a gen5 sample) for the W-&gt;enu background.  This is because our reconstruction algorithm was unable to find any plug (phoenix) electron tracks in the wewkee sample.  PrepareSm.tcsh has been updated accordingly. 
  * p(j-&gt;e)_plug, p(e-&gt;e)_plug, and p(e-&gt;trigger)_plug are now much more tightly constrained, and their values have been updated. 
  * KFactor.cc has been updated to use sewkad for the W+0j and W+1j final states. 
  * There have been percent-level changes to some of the "big" fudge factors, like luminosity and the jj k-factor, to accommodate the (significant) additional data. 
 
There are the following known discrepancies from the fudge factor fit: 
 
e 10 j j j          +5.4            data = 11337    bkg = 8675  
e 10 j j j j        +7.9            data = 1870     bkg = 1060  
e 10 j j ph 10      +8              data = 210      bkg = 77  
e 10 j ph 10        +15.3           data = 1123     bkg = 555  
 
This comparison (starting now, should be done sometime this evening) is being run to get plots that will hopefully point out the reason for these discrepancies. 
 
The addition of this plug electron trigger is probably one of the last major additions to our offline trigger.  Additional anticipated additions (photon+muon, dilepton, photon+b-jet) are expected to be minor perturbations. 
</pre>
<!-- Author: knuteson -->


<!-- Date: Sat Jan 7 21:03:40 2006 -->
<table><tr><td><a href=/cgi/elog/det-system-elog.pl?nb=Vista&action=view&page=-24&button=yes target='xxx' onclick='jswindow()'; align=top><img src=/cgi/elog/det-system-elog.pl?nb=Vista&action=view&page=-24  width='300' align='top'></a></td><td>I believe I understand what is causing this: we have applied Khaldoun's intrinsic kT smearing to the sewkae sample, but we shouldn't have.  I have given sewkae exemption from the kT smearing section of sumOverProcesses.cc.</td></tr></table>
<!-- Author: Knuteson -->


<!-- Date: Sat Jan 7 21:07:45 2006 -->
<table><tr><td><a href=/cgi/elog/det-system-elog.pl?nb=Vista&action=view&page=-25&button=yes target='xxx' onclick='jswindow()'; align=top><img src=/cgi/elog/det-system-elog.pl?nb=Vista&action=view&page=-26  width='300' align='top'></a></td><td>Including the plot correctly this time.</td></tr></table>
<!-- Author: Knuteson -->


<!-- Date: Thu Jan 12 21:18:13 2006 -->
<pre>The 2e+1j discrepancy is due to a single electromagnetic cluster of energy in the plug being reconstructed as an electron and also as a photon, with different positions.  These object pairs have deltaR(e,ph)&lt;~1.5 and have energies |e_e-ph_e| &lt;~ 2 GeV.  I have changed Refine.cc to remove events with such object pairs. 
</pre>
<!-- Author: Knuteson -->


<!-- Date: Fri Jan 13 12:12:56 2006 -->
<pre>In the Sleuth plots of the current comparison, there is an excess in the final state 1e+1pmiss (which contains both electrons and muons).  Below is the list of events with sumPt &gt; 377 GeV.  You will notice that these events all contain muons, and nearly all from before the October 2004 shutdown.  I note we have not re-run over dataset sewkbd since November 13, which is well before we imposed our additional COT chi^2 cut.  I am re-running over sewkbd now. 
 
b0pcmit35&gt; more data_1mu+1pmiss_377+.txt 
data  178513.85019  1  ppbar  1960  0  20.26  mu+ 222.073 -0.959 129.78  uncl 0 4.548 0 -35.82   ;  
data  182874.3208111  1  ppbar  1960  0  -15.28  mu+ 202.956 0.896 43.4  uncl 0 10.899 0 -161.86   ;  
data  153372.431624  1  ppbar  1960  0  5.97  mu+ 188.12 0.738 -19.32  uncl 0 6.494 0 109.63   ;  
data  178120.646152  1  ppbar  1960  0  -4.18  mu+ 233.128 -0.687 60.24  uncl 0 17.885 0 -96.9   ;  
data  185848.2789725  1  ppbar  1960  0  -44.58  j 2.784 17.396 -0.004 2.51  mu+ 266.79 -0.676 167.47  uncl 0 9.79 0 -170.07   ;  
data  186084.1896585  1  ppbar  1960  0  -22.63  mu+ 206.676 -0.804 46.21  uncl 0 8.159 0 171.91   ;  
data  183617.10110197  1  ppbar  1960  0  6.7  mu+ 218.659 -0.817 20.47  uncl 0 2.782 0 -166.56   ;  
data  162664.2504135  1  ppbar  1960  0  -17.78  j 1.791 17.025 -0.683 -118.5  mu+ 182.39 0.754 74.82  uncl 0 11.399 0 41.17   ;  
data  161324.1066286  1  ppbar  1960  0  -20.3  j 2.025 15.225 -0.25 -177.68  j 4.013 18.353 -0.127 147.06  mu+ 219.683 0.839 -25.65  uncl 0 13.03 0 1.56   ;  
data  160175.2522013  1  ppbar  1960  0  44.78  mu+ 321.957 0.155 -81.3  uncl 0 14.101 0 94.98   ;  
data  193051.3955822  1  ppbar  1960  0  2.1  mu+ 258.815 0.951 37.45  uncl 0 5.782 0 -138.24   ;  
data  177938.1039787  1  ppbar  1960  0  -24.75  mu+ 287.513 -0.767 166.4  uncl 0 5.79 0 25.78   ;  
data  178758.320368  1  ppbar  1960  0  39.46  mu+ 202.495 -0.895 -22  uncl 0 1.246 0 -12.99   ;  
data  178738.4190468  1  ppbar  1960  0  20.87  mu+ 310.458 -0.887 57.07  uncl 0 14.102 0 -106.51   ;  
data  177315.1510482  1  ppbar  1960  0  -29.24  mu+ 219.866 0.859 -43.14  uncl 0 14.447 0 158.36   ;  
data  177416.1469342  1  ppbar  1960  0  37.38  j 4.144 17.806 1.31 -172.05  mu+ 260.766 -0.897 -10.17  uncl 0 4.245 0 54.59   ;  
data  185517.4900351  1  ppbar  1960  0  18.17  mu+ 247.027 -0.911 171.5  uncl 0 7.555 0 39.45   ;  
data  185248.11160840  1  ppbar  1960  0  49.94  mu+ 239.452 -0.764 110.97  uncl 0 7.056 0 -82.03   ;  
data  185848.4449866  1  ppbar  1960  0  -7.66  mu+ 192.19 -0.786 -173.97  uncl 0 10.476 0 13.85   ;  
data  165121.1196147  1  ppbar  1960  0  -1.15  mu+ 267.438 -0.876 -146.5  uncl 0 7.45 0 -125.32   ;  
data  183696.544003  1  ppbar  1960  0  -9.65  mu+ 283.629 -0.81 179.06  uncl 0 3.746 0 2.61   ;  
data  156117.396315  1  ppbar  1960  0  -11.07  mu+ 260.433 0.247 150.97  uncl 0 2.635 0 13.63   ;  
data  184445.267946  1  ppbar  1960  0  -0.44  j 6.384 19.828 1.961 -68.36  mu+ 279.845 0.328 100.3  uncl 0 7.421 0 123.36   ;  
data  178255.268211  1  ppbar  1960  0  -28.28  mu+ 222.263 0.988 107.7  uncl 0 8.625 0 -151.44   ;  
data  183209.4591709  1  ppbar  1960  0  -4.01  j 4.85 19.465 -0.573 31.92  mu+ 226.635 0.271 -141.66  uncl 0 1.275 0 89.46   ;  
data  192348.251795  1  ppbar  1960  0  -1.64  j 3.566 17.42 -0.715 -103.08  mu+ 201.296 -0.441 87.12  uncl 0 10.771 0 90.99   ;  
data  156116.1154538  1  ppbar  1960  0  -25.15  mu+ 173.77 -0.303 162.22  uncl 0 15.551 0 -170.76   ;  
data  195805.11314333  1  ppbar  1960  0  -17.9  j 4.233 19.247 0.177 -87.1  mu+ 209.648 0.09 84.2  uncl 0 6.46 0 -129.47   ;  
</pre>
<!-- Author: Knuteson -->