2008 PPV evaluation plan

Run #9069005 will be used

http://online.star.bnl.gov/RunLog/Summary.php?run=9069005
 

 daq files are located at

/star/data03/daq/2008/069/

9069005f 9069005t  9069005z  9069005p
 

bfc.C will be run in stardev with options:

root4star -b -q  bfc.C'(1,1e6,"DbV20080820 pp2008 ITTF OSpaceZ2 OGridLeak3D beamLine VFPPVnoCTB debug logger","/star/data03/daq/2008/069/*")'

The verision of PPV includes the August 2008 change that Post Crossing Tracks are dropped which was enacted in response to the change of the TPC cluster finder

MuDst files will be placed at:

/star/data05/scratch/rjreed/PPV2008Eval/*

Observables to Monitor:

# primary vertices

Z location primary vertices

delta Z between primary vertex z position and bbc or vpd z position

# tracks associated with each primary vertex

Cuts to Monitor:

mMinTrkPt (Currently 0.20)

mMinFitPfrack (Currently at 0.70)

Include all EEMC rings

mMaxZradius

Weights for TPC, EEMC, BEMC

Detailed event comparison PPV & VPD vertex, (Rosi)

 BFC

Detailed event count

1271 Events ,
256 Events with no PPV vertex,
271 Events with vpd vertex,
144 with at least one PPV vertex matching the vpd,
136 events with the 0 ranked vertex matching the vpd,
10 Events with the 1 ranked vertex matching the vpd ,
49 Events with no PPV vertex  and a vpd Vertex,
5 Events with multiple vertices matching the vpd ,
1 Event with 2 ranked Vertex matching the vpd (multiple match),
1 Event with 3 ranked vertex matching  the vpd (multiple match)
44 Events out of 222 with both PPV and vpd vertex have all vertices
outside of 50 cm of vpd. 11 of these have more than 1 PPV vertex

 Conclusion: out of 271 events with VPD vertex:

• 49 (18%) has no PPV vertex
• 151 (56%) has one of PPV vertex closer than 8 cm from VPD vertex
• 71 (26%)  none of PPV vertices is closer than 8 cm to VPD vertex

VertexAnalysis8cm.txt file lists (for the events with a vpd vertex) the event #, # of vertices, rank of each vertex that matches vpd.

Details of Events with mismatched PPV VPD vertices with vertex location forced

I've run through 5 events where the vpd and the PPV vertices don't match.   daq file location is:

star/data05/scratch/balewski/2008-daq/st_fmsslow_9060086_raw_1090001.daq

Here are the PPV Vz values prior to "forcing" the values.  For the histograms, the solid red lines indicate the location of the vpd vertex and the circles indicate the location(s) of the PPV vertices.

EventID = 749 vpdVz = 98.2939 PPV vertices at Vz = -48.75 140.85

EventID = 2115 vpdVz = -34.348 PPV vertices at Vz = -106.55

EventID = 3346 vpdVz = -33.7838 PPV vertices at Vz = 129.35

EventID = 3952 vpdVz = 0.664319 PPV vertices at Vz =

EventID = 4447 vpdVz = 25.5813 PPV vertices at Vz = -99.95

For comparison, here is an event where the VPD vertex and PPV vertex were within 8 cm of each other:

All the important files (including the likelihood histograms and track multiplicities) can be found at:

/star/u/rjreed/Vertex3/Eventdaq*

Here are the results:

daq #7 EventID = 749 vpdVz = 98.2939 # PPV vertices = 10 at Vz = 90 92 94 96 98 100 102 104 106 108

Primaries that passed the cut (flag>0,  pt>0.2GeV, nFitP/nPoss>0.51):

id = 277 flag = 801 Nhits = 7 Npos = 11 pt = 0.370926 frac = 0.636364

id = 278 flag = 801 Nhits = 6 Npos = 11 pt = 0.250512 frac = 0.545455

id = 279 flag = 801 Nhits = 6 Npos = 11 pt = 0.271426 frac = 0.545455

id = 281 flag = 801 Nhits = 8 Npos = 11 pt = 1.57357 frac = 0.727273

id = 283 flag = 801 Nhits = 6 Npos = 11 pt = 0.638242 frac = 0.545455

id = 292 flag = 801 Nhits = 5 Npos = 9 pt = 0.292521 frac = 0.555556

id = 295 flag = 801 Nhits = 7 Npos = 11 pt = 0.213841 frac = 0.636364

daq #22  EventID = 2115 vpdVz = -34.348 N PPV vertices = 10 at Vz = -42 -40 -38 -36 -34 -32 -30 -28 -26 -24

Primaries that passed the cut:

id = 48 flag = 301 Nhits = 40 Npos = 45 pt = 0.362589 frac = 0.888889

id = 63 flag = 301 Nhits = 26 Npos = 34 pt = 0.602728 frac = 0.764706

id = 64 flag = 301 Nhits = 35 Npos = 45 pt = 0.392374 frac = 0.777778

id = 66 flag = 301 Nhits = 32 Npos = 45 pt = 0.772336 frac = 0.711111

id = 288 flag = 801 Nhits = 6 Npos = 11 pt = 2.56192 frac = 0.545455

id = 290 flag = 801 Nhits = 9 Npos = 11 pt = 0.206602 frac = 0.818182

id = 291 flag = 801 Nhits = 10 Npos = 11 pt = 0.556056 frac = 0.909091

id = 292 flag = 801 Nhits = 8 Npos = 11 pt = 0.722384 frac = 0.727273

id = 296 flag = 801 Nhits = 6 Npos = 11 pt = 0.236179 frac = 0.545455

id = 297 flag = 801 Nhits = 6 Npos = 11 pt = 0.267664 frac = 0.545455

id = 298 flag = 801 Nhits = 6 Npos = 11 pt = 0.9994 frac = 0.545455

id = 299 flag = 801 Nhits = 5 Npos = 8 pt = 0.332944 frac = 0.625

id = 300 flag = 801 Nhits = 9 Npos = 11 pt = 0.389091 frac = 0.818182

id = 310 flag = 801 Nhits = 5 Npos = 9 pt = 0.236941 frac = 0.555556

daq #44 EventID = 3346 vpdVz = -33.7838 N PPV vertices = 10 at Vz = -42 -40 -38 -36 -34 -32 -30 -28 -26 -24

Primaries that passed the cut:

id = 129 flag = 301 Nhits = 38 Npos = 42 pt = 0.352418 frac = 0.904762

id = 433 flag = 801 Nhits = 6 Npos = 9 pt = 0.73871 frac = 0.666667

id = 436 flag = 801 Nhits = 6 Npos = 11 pt = 4.33162 frac = 0.545455

id = 441 flag = 801 Nhits = 7 Npos = 11 pt = 1.19905 frac = 0.636364

id = 446 flag = 801 Nhits = 6 Npos = 11 pt = 2.52832 frac = 0.545455

daq #63 EventID = 3952 vpdVz = 0.664319 N PPV vertices = 10 at Vz = -8 -6 -4 -2 0 2 4 6 8 10

Primaries that passed the cut:

id = 177 flag = 301 Nhits = 35 Npos = 40 pt = 0.751434 frac = 0.875

id = 433 flag = 801 Nhits = 7 Npos = 11 pt = 1.16509 frac = 0.636364

id = 437 flag = 801 Nhits = 6 Npos = 10 pt = 0.277501 frac = 0.6

id = 440 flag = 801 Nhits = 6 Npos = 11 pt = 6.03469 frac = 0.545455

daq #70 EventID = 4447 vpdVz = 25.5813 N PPV vertices = 10 at Vz = 18 20 22 24 26 28 30 32 34 36

Primaries that passed the cut:

id = 324 flag = 311 Nhits = 9 Npos = 10 pt = 0.50257 frac = 0.9

id = 391 flag = 801 Nhits = 6 Npos = 11 pt = 0.332764 frac = 0.545455

Jan's notes

 -------- Loose notes, needs cleanup, Jan

Lidia's most recent test prodcution of 3 runs (89 files) also had
CTB matching off

 Low Lumi (run9060086), Mid Lumi (run9069059), High Lumi (run 9068124)
 /star/data10/reco/ppProduction2008/ReversedFullField/P08ic_test/2008/*/*
 log files on /star/rcf/prodlog/P08ic_test/log/daq

--------------

Akio's event classification  txt file from 3 files (with differnt luminosity) at the bottom of

http://www.star.bnl.gov/protected/spin/akio/200806/index_5th.html

from Lidia's test production. I checked that I get identical results
with Jan's production and Lidia's for the low lumi run.

-------------

Just remind you that there is "accidental match" between VPD and
TPC vertex up to ~25% (@ high lumi) under the peak.

--------------

* could you show Rosi how to print VPD & BBC vertex position in BFC?

Once Mudst is created, you can get VPD vertex (from TOF electronics) by
   StMuEvent->vpdVz()

For BBC I have not yet implemented the calibrated vertex. Once done,
one should be able to get it from
   StEvent->triggerDetectorCollection()->bbc()->zVertex()

--------- Rosi ---------

While I was doing this, I spun a macro over the MuDst in the folder
above and duplicated some of Akio's results, just to make sure I
understand.

So here are the z positions of the ranks 1 and 2 vertices and the vpd:

Fig 1.

Locations of Akio's pages in protected/spin

August 13, 3 runs produced with PPV w/o using CTB

• Start page
• track/vertex distribution
• pi0 inv mass from FMS

----- 

PPV vs. VPD , by Xin

Fig 1. VPD-Minuit, d-Au 2008 events, minB events: ZDC East+VPD

Fig 2. VPD-PPV, p-p 2008 events, st_physics , no trig selection, mostly E & BEMC triggers

Hi Jan, Akio,

Xiaoping helped me to check the test 2008 pp production data Jan suggested. Please take a look at the attached plot. Basically what is plotted here is vz difference between vpd vertex and tpc vertex for different vpd hit configuration, similar to that in Akio's web page, but using the TOF electronics for vpd hit configuration selection.

So firstly we didn't see the ~30cm width gaussian component. The two narrow gaussian components are attributed to the VPD resolution. In the VPD timing resolution, we see a double gaussian structure, and with about a factor of 2-3 difference in widths. This is consistent with what we see here.  The largest ~50-60 cm gaussian component should be due to the fail of TPC VF and it is related to the beam vz distribution.

And secondly, the resolution in the (E,W)>(1,1) configuration is expected better than the configuration of (E,W)=(1,1). The "dilution" in vpd resolution with more hits seems not true to us.

Generally, we don't see an obvious issue on the VPD side. I am not sure if how the result will change when you use the DSM for selection. Or maybe your statistics is not good enough? Or the data are from some bad TOF runs?

Thanks and Best Regards

/xin

Jan Balewski wrote:
Hi Xin,
Those 2 analysis do not need to be contradicting.
There is much less pileup in dAu than in pp. There may be beam background in pp.

Can you investigate this effect in 2008 pp data from production requested by Matt  ~2 weeks ago, it is done, files are on data09,10.
http://www.star.bnl.gov/HyperNews-star/get/starprod/249/4/1/1/1/1/2.html
It is 3K daq files, 1M events w/ TPC , 1/4 of events have VPD vertex, ~90 % have TPC vertex produced by  fixed PPV.

Thanks
Jan



On Oct 1, 2008, at 11:40 PM, Xin Dong wrote:

Hi Akio,

Thanks for this message. Actually we always see the resolution will be improved if we require more VPD hits. I don't quite understand the ~25cm gaussian distribution at this step. Xiaoping helped me check the dAu data (we don't have TPC vertex in pptoftpx triggered data), you can find the distribution from the attached plot. It shows that with more VPD hit requirement, the vertex resolution is better. No 25cm-width gaussian contribution appears.

So  let me answer your questions directly, see them inline.
Akio Ogawa wrote:
Hello

I posted this yesterday to vertex mailing list. I'd like to make
sure you know this since you may be more intersted than us.

In zVPD-zTPC distribution at pp, we see 3 structures. See Fig 2 (2 gaussian fit) and Fig6 (3 gaussian fit) of
http://drupal.star.bnl.gov/STAR/blog-entry/rjreed/2008/sep/11/ppv-revision-1-29-high-luminosity-fmsslow-trigger-evaluation 

First is sigma ~3cm peak where TPC and VPD vertex matches. Quite
reasonable with resolutions of those two vertex finding.

2nd is sigma ~80cm, which is understandable if TPC and VPD picked
up 2 different vertex. Vertex distribution is ~gaussian with sigma
~60cm. If we pick 2 randomly and take difference, then sigma should be sqrt(2)*60cm ~ 85cm.

3rd one is the mistery. Sigma is around 25-30cm. So its much
narrower than random. Its hard for TPC to "miss" vertex by
10-20cm, since all track's DCA_z is <3cm.

Rosi changed selection of TPC vertex (more matched tracks) to
make TPC vertex better, she saw no difference in the structure.

Now if look at the plot at bottom of http://www.star.bnl.gov/protected/spin/akio/200806/index_8th.html

which is essentially same plot but divided by # of VPD hits.
This 3rd structure with sigma~25cm is most evident when both VPD-E
and VPD-W has 2 or more hits.

This suggests (at least to me) that when you have more than one hit
in VPD and taking time average, sometimes you are diluting VPD vertex resolution. This can be "real" (another collisions in the same crossing
or some beam halo hitting VPD) or detector effects (hot pmt, too
loose timing cut, etc).

Have you seen this?
==>Xin
No.
Is there way to get some more info from mudst?
==>Xin
The number of hits and Tdiff information should be available from MuDst. Tdiff cut may help some in resolution, but shouldn't create a 20cm gaussian peak.
(For example distance or rms of hits included in average?)
==>Xin
I don't quite understand, distance or rms of hits to what?
Is there some cut you tuned when you accepting hit to form average?
==> Xin
Yes. We have already removed the hits with non-physical timing information (out of trigger timing window, but for sure with 25ns resolution). And we always take the earliest hit.
(for exapmple maximum time difference?)
Is average weighted by ToT?
==> Xin
No. Supposedly the ToT dependence is calibrated. We just do simple average.
Have you tried taking earliest hit only?
==> Xin
Yes.

We will trying to see what the pp data look like. Thanks

/xin

Plots Jan

 plots

01 transverse vertex , pp 500 data & Pythia (Rosi, Jan)

 Study of vertex reconstruction in transverse X-Y plane, pp 500 data from 2009, high PT events from W-stream

Large variance in the initial determination of beam line constrain for pp 500 data has been observed. The concern was that reconstruction accuracy for high PT TPC electron tracks from W decay may be not sufficient.

At first simpleminded  idea of increasing minimal PT of used tracks and imposing high track multiplicity did not improve accuracy of vertex determination in the transverse plane.

Next we look at individual events passing the following selection criteria, passing through most likely primary tracks candidates from the pool of global tracks:

• use only global tracks matched to BTOW,ETOW, or central membrane
• require nFit/nPoss>51%, and Rxy @ DCA to X=Y=0 below 3 cm
• require PPV finds valid vertex along Z direction, require delZ <3cm
• require global pT in range [0.8, 8.0] GeV/c
• require Sti extrapolation error in transverse plane is below 3 mm
• require at least 5 tracks passed criteria listed above

  
Fig 1. Typical spectra for some of the cut parameters for W-stream pp 500 events

Tracks passing selection are approximated by straight lines in the vicinity of DCA to X=Y=0 and shown in Fig 2. Z-axis range  is always 6 cm, centered at the max likelihood of PPV.
The following encoding was added to plots:
*head of arrows indicates direction of the momentum vector 
*size of the arrow is proportional to track PT, max PT for given set of tracks (event) is in the title of the left histograms
* thickens of the line is proportional to the weight of  track in vertex (or beam line) determination, I used formula:
       width= 3.* (0.15*0.15)/sig/sig; , where sig=sigYlocal from Sti .
(The last 2 conditions sometimes interfere, since the thicker line increases also the arrow size, but still plots should help us to gain intuition).

Fig 2, Projections of global tracks at most likely vertex location. One event per row, two projections: Y vs. X and Y vs. Z.
Stray tracks are most likely form pileup or from decays matched to fired EMC towers.
The width of arrows is proportional to likelihood the vertex is below it (~1/track error^2)

Attachments A,B show more real data events.

Attachments C,D show M-C Pythia QCD events with partonic pT>10 & 20 GeV, respectively. C has fixed vertex offset, D has varied vertex offset.

Conclusion:

*Very often one sees 2 jets what impedes determination of transverse vertex position on event by event basis, in particular if vertex finder is not returning non-diagonal covariance matrix element covXY (see last event in fig 2.)

* we will pursue alternative method of beam line determination by fitting its equation directly to preselected tracks from multiple events. We try to skip event by event vertex determination.

02 3D beam line fit to tracks, no tilt

Stand alone 3D beam line fitter developed by Jan & Rosi in June 2009

Fig 2. Example of X0,Y0 fit for pp 500 data F10415, more in att. A)

Attachment A): slides vetting 3D beam-line  fitting algo

Attachment B): document describing math used to compute 3D likelihood

Attachment C: Source code for fitting contains:

03 2009 PPV upgrade #1

 PPV vertex finder code have been upgraded and default changed as follows.

(July 9, 2009)

1) the threshold for pT of  single-matched-track vertices was lowered from 15 GeV/c to 10 GeV/c.
The purpose if this change is to not loose W-events for the case when TPC calibration is approximate and error of reco PT of TPC track is sizable for tracks with true PT of 20 GeV/c.
Those vertices will be now more likely pileup contaminated, since there is a fair chance for a random matching of a global track to a fired BTWO tower. Users should use vertices with at least 2 matched tracks which will have rank>1e6.

2) Additional expert-only functionality was added to PPV , encapsulated in the new class Vertex3D.

If BFC is run in normal way, e.g. in production no new action is taken.

However if BFC option "VtxSeedCalG" is added for every event high quality most likely primary tracks candidates from the pool of global tracks:

• use only global tracks matched to BTOW,ETOW, or central membrane
• require nFit/nPoss>51%, and Rxy @ DCA to X=Y=0 below 3 cm
• require PPV finds valid vertex along Z direction, require delZ <3cm
• require global pT in range [0.8, 8.0] GeV/c

and printed in to the logfile in the format:

      printf("track4beamLine %f %f %f   %f %f %f   %f %f %f   %d %f  %.1f %d \n",x,y,z,px,py,pz,er->_cYY,er->_cZY,er->_cZZ , tr.nFitPoint,tr.gChi2,z0,eveID);

Fig. 1. prim tracks candidates in the vicinity of beam line

Fig. 2. QA plots for prim track selection