SB's SVT analysis log
June 2003
Ghost taxonomy.
Running svtsim_diag with hand hacked svtsim_diagmodule.cc to
dump ascii ntuple. Then grep them from log and read into
paw ntuple with paw kumac.
On unixts. belforte/svt/491/...
look at the two runs with 4/4, 4/5 taken few days ago.
See
SVT e-log .
The runs are
164303 (4/4) and
164304 (4/5).
Data are in pclx06:/localdisk/belforte/svt/data/run164303/ and ...4
Number of XFT tracks per road. From this I decide that for the time
being is OK to limit to roads with only one XFT track, so that
there is no ambiguity in associating roads to tracks.
Now look at ghosts per tracks, i.e. in the end we will make one
only SVT track from each XFT track, let's see how many intermediate
roads/combination we have to deal with in the TF/GhostBuster.
I thought it may be interesting to look at the numner of
road/combination for each XFT track. Since in the end we
want to make just one SVT track for each input track, this
is a good measure of the "number of ghosts".
Attached is from 1K events in runs 164303/4 (4/4 and 4/5).
Top is 4/5, bottom is 4/4
Left is number of roads per XFT track, right is number
of combination to fit.
For the time being I only looked at roads with only one
XFT track, i.e. only 1 hit in layer 5 (80% of the total) to
avoid ambiguity in associating roads to tracks.
Now I have to figure out some way to classify the ghosts
by cathegories to make sense of them. I will start by
counting 5/5 and 4/5, look how many of the 4/5 are
contained in some 5/5, then... we'll see.
Input on this is always welcome.
Before you ask, I have no clue at what is the peak at ~10
roads on left-top plot.
More in detail, count for each track how many roads have
1 combination to fit, 2 combinations, etc.
It turns out for 4/4 there is no road with 5 or more, while
for 4/5 is is much more corwded, also because roads are wider.
Sometime will try to use Alberto's 128K pattern file with
narrower roads to see if the problem is the road width more
then the 4/5.
Here are the plots of nroad, ncomb and nroad with 1-2-3-4
combinations, for the two runs:
If I only look at tracks that make no roads with 5 hits,
so that the "usual proposal for ghostbusting before tf"
can notbe applied, they are 30% of the event and
the overall road/combination multiplicity
there is a factor 2 less then the total 4/5 multiplicity,
or 5x the 4/4.
This is a likley irreducible load for the TF,
that is about a factor 1.5 on the 4/4 timing.
Just for 4/5 run (164304 first 1K events). Top: number or roads and
number of combinatio per XFT track, all of them. Bottom: only the cases in which there is no road with 5 hits for this track.
June 19
First try at a real ghostbusting before TF.
Implement as a hack in svtsim_diagmodule the "perfect" ghostbusting
and look at distributions. Assume that the following will be possible:
- roads will be classified according to what superstrips
in the pattern are hit (no need to record hits, just superstrips)
- all 5-hit roads will be passed on to the TF
- all roads that have only 4 hit-superstrips will be suppressed
if the same 4 superstrips are present in a 5-hit road
- in case more then one 4-hit roads share the same 4 hit-superstrips,
only one will be passed, the others will be called ghosts and
suppressed
- the TF result for 4-hit roads will only depend on the 4 hit-superstrips
(and the wedge number) and not on the road number. I.e. the constants
will have to be those for the z barrel of the first hit-superstrip, not
those for the z barrel of SVX layer 0 in that road. This is not the
case now.
This is the first non-clearly-wrong distribution from
about 30K events from run 164304. There is one entry for each
wedge with at least one road, so the plots represent average
over non-empty wedges. Top-bottom, left-rights
the 8 histograms are:
- Number of roads (ave=21)
- Number of 5-hit road (ave=4)
Note that in 30% of the cases there is no 5-hit road.
- Number of 4-hit roads (ave=17)
- Number of 4-hit roads whose 4 superstrips with hits are a
subset of the the 5 superstrips of a 5-hit road (ave=10)
- Same distribution as before, removing the bin at 0
- Number of 4-hit roads whose 4 superstrips with hits are
an exact match the the 4 superstrips with hits of another
4-hit road. (ave=3)
Note that if there are 10 roads with the same 4
superstrip with hits, there is an entry at 9, this plot
(like the previous 2) is the number of "busted" roads, one
of the 4-hit roads has to survive to be fitted.
- total number of ghostbusted roads (ave=13)
- number of surviving roads to be fitted by TF (ave=8)
bottom line: the ideal ghostbuster reduces in average the
TF input from 21 to 8 roads.
I now have to make sure this is correct, i.e. run the surviving
roads through TF and final GB and verify that we get same track list
as before.
June 23
Run same code on Alberto's favorite run run152133
(run 152133.
using his mapset/patterns
mapset fnal:/cdf/ome/annovi/SVT/svtsim_new/svtsim/svtdata/offline_100030_20030613-my32k-1288812.mapset
also saved in trieste:/home/belforte/svt/491/svtsim/svtdata
after having
modified from a hack into svtsim_diagmodule.cc to the separate
simulation of a new board (rgb) inserted on HB output.
I obtain
Same plots, removing limit at 63 roads (Alberto has 126 in his mapset)
zooming in, still with road limit at 126
to be compard with Alberto's result:
so we have the same input (top plot=AMS output), but slightly different
results after ghostbusting. Since results are very similar, we decide
to leave the chase for the small bug to when it will matter.
and these are Alberto's plot with full range
July 9
Feasibility study for removing road duplicates before TF (road
busting).
- Overview and strategies on what to do in hardware. As
a sketchy note
- Study of what we can gain with a RB after the HitBuffer.
There is probably still a small bug that Alberto discovered
in my ascii ntuple making, where I do not count multiple XFT
tracks in the same SS, so number of combinations is slightly
underestimated. Should not affect results.
I ran svtsim_diag modifying svtsim_diagmodule.cc to get my
"ascii ntuple" and adding the RB simulation as/when needed (see
point 3. below). I ran on run
164304, i.e. our first run with 4/5 but using
the AMS ucode version 3.0 in svtsim, so to remove XFT tracks
below 2 GeV as we do now in real life. In practice I used
the mapset
4outof5_20030614141858
I made 4 plots:
- Fit load
in most crowded wedge "before the cure".
From top left to bottom right:
- Number of Roads in the wedge with the most roads.
- Number of combinations to fit in the wedge with the
most combinations to fit.
- Number of XFT tracks in the wedge with the most combinations to fit.
- Number of tracks in output from TF in the wedge with the largest TF output.
- Total number of tracks in output from all TF's (i.e. final GB input).
- Number of tracks in output from final
GB (i.e. in input to Level2).
- Fit load "after the cure". I.e.
after inserting the RB between HB and TF. The comparison (looking just
at histogram averages) suggest the folling gain:
- From 30 to 12 roads
- From 63 to 29 combinations to fit
- From 23 to 7 tracks to final GB input
- Modest loss of efficiency (3.5 -> 3.3 tracks final)
- Details of road busting. From
top left to bottom right: this time each plot is simply the combination
of entries from all wedges with non-zero roads, i.e. not the most
crowded one. In the end the information is the same.
- Number of roads in input.
- Number of roads with 5 hits.
- Number of roads with 4/5 hits.
- Number of roads with 4/5 hits that share the 4 hits with a 5-hit roads and can therefore be "busted"
- Number of roads with 4/5 hits that have the same 4 hits of another 4-hit road and can therefore be "busted"
- Number of busted roads (should be equal to sum of previous 2)
- Number of passed (OK) roads to Track Fitter
- Number of words read from HitBuffer (multiply by 40nsec to know
much it takes to receive all the data from the HB)
These plots more or less confirm previous conclusions: From 21 to 8 roads
(30% reduction).
Note that for this run with 4/5 patterns the average HB output load is
74 words = 3 microsec.
- Details of road busting as before,
but only look at wedges that have NO ROAD WITH 5-HITS. I.e. these are the
wedges that would not be helped at all by a RB placed before the HitBuffer.
These are about 25% of all wedges.
- Simulation. I have modified svtsim to include an rgb
board between HB and TF. All the files are in my local test
release on pclx06.ts.infn.it. As of July 9 I tarred everything
and copied it to FNAL in /cdf/spool/belforte/SVT/491/...
I did all in 4.9.1 release.
- Implementation. I described in Verilog the core functions of
a RB placed after the HitBuffer, and fitted it using Quartus on the
GB Apex. It looks great (47% usage, 68MHz clock). See
details.
Stefano Belforte
Last modified: Wed Jul 9 15:34:35 CEST 2003