Graphics courtesy of J.Kelsey MIT, |
FGT. . . . . . . . . . P H Y S I C S goals, publications, presentations (PowerPoint, PDF, KeyNote, etc. presentations given by members at meetings, conferences, etc.) |
minutes, calendar |
FGT. . . . . . . . . . S I M U L A T I O N S
|
Hardware Thermo-model 16 cm FGT . . . . . . . . . . DAQ readout, DAQ, etc. FGT. . . . . . . . . . H A R D W A R E -- S L O W C O N T R O L S |
FGT. . . . . . . . . . S O F T W A R E muDst container, geant hits, DB tables
|
FGT . . . . . . . . . . C A L I B R A T I O N algo1, y2010 |
FGT . . . . . . . . . . D O C U M E N T S proposal,reviews,design notes, tables, responsibilities,etc (generally text documents related to the FGT) |
FGT . . . . . . . . . . A N A L Y S I S e/h algo Endcap, high-pT tracking |
FGT. . . . . . . . . . P H O T O - - G A L L E R Y + PR figures (useful plots, drawings, pictures, etc. in original format that people can use in presentations) |
FGT. . . . . . . . . . I N S T R U C T I O N S edit web-page, HPSS I/O |
FGT. . . . . . . . . . V A R I A |
FGT sub-system web pages use Drupal nodes: 7217, 10145-156.
HTAR : save/restore private directory (large set of small files) in HPSS
Known problems:
WARNING: htar_PreallocateSpace: HPSS OUT-OF-SPACE error preallocating
**** bytes for file=[/home/salur/myfile.tar]
This is a directory with 350G. Do I have to divide my files into smaller.
there is a 60GB max file size limit [when creating tarballs], Another
limit to be aware of, however, is an 8GB limit on member files
Mass restoring of ~100GB files from HPSS using Data Carusel
Prepare input file xxx.hpss with list of source +destination paths for all files you need, one line per file
Execute the command (at any location at rcas6nnn)
hpss_user.pl -f xxx.hpss
Wait 10-1000 minutes fro the files to show up at your destination (if all paths are correct)
Instruction for remote uploading of documents to the common FGT Drupal place to complement missing features of fgt-hn
First time setup
Uploading subsequent documents
.... new docs are uploaded to: http://drupal.star.bnl.gov/STAR/subsys/upgr/fgt/hn-upload-contributions under myName, files xxx-yyy-jpg and zzz-uuu-mmm.pdf
Report to me if there are any problems,
Jan
date | person | format | title | occasion |
---|---|---|---|---|
April 2006 | Frank | pdf ppt | Development of Tracking Detectors with Industrially Produced GEM foils | TPC workshop, Berkeley |
October 2006 | Frank | pdf ppt | Development of Tracking Detectors with Industrially Produced GEM Foils | IEEE NSS 2006, San Diego, CA, USA |
January 2007 | Bernd | FGT-Technical implementation, Cost, R&D plan, Schedule | BNL Detector Advisory Committee Meeting | |
- | - | - | - | - |
Simulation of physics background for development of e/h algo. ( Physics Background Simulation)
Selected topics:
Ongoing effort of preparing physics-background samples for developing of e/h discrimination algos for W reconstruction
With the completion of the FGT hardware review, focus must now be made on the creation and implementation of efficient analysis algorithms. To this end a framework for creating simulation files must be established. Here I document the existing framework I created this past summer for a small FGT project.
The creation of simulation files within STAR is handled in two steps.
The kumac sets all parameters of the underlying physics events, while the bfc handles the fine tuning of the reconstruction of the STAR detector.
In the following analysis the simulation was split by the underlying physics processes: those producing W bosons and those from QCD 2->2 interactions. Both are produced with the geometry UPGR13 and sqrt(s) = 500 GeV, in accordance with the FGT upgrade. Moreover, each kumac accepts a random number seed to ensure that different jobs are independent of each other. Specific details are included below,
W | Hadron | |
Geometry | UPGR13 | UPGR13 |
sqrt(s) | 500 GeV | 500 GeV |
Vertex (mean, variance) | 0 cm, 60 cm | 0 cm, 60 cm |
Subprocesses | 2, 15, 20, 23, 25, 31 | 11, 12, 13, 28, 53, 68, 96 |
CKIN3 | 10 GeV | 10 GeV |
CKIN4 | None | None |
Additional Cuts | Require electron in the endcap with pT > 15 GeV | None |
Additional Notes | W bosons made explicitly unstable | None |
Events / Job | 4000 | 2000 |
Cross Section / Job | O(103 pb) | O(103 pb) |
PYTHIA + GSTAR + BFC Running Time / Job | O(20 hours) | O(16 hours) |
PYTHIA + GSTAR Running Time / Job | O(12 hours) | O(6 hours) |
Memory Used / Job | O(1000 MB) | O(1500 MB) |
Size of Output Files / Job | O(2.5 GB) | O(2.5 GB) |
bfc.C\(1,nEvents,"trs ssd upgr13 pixFastSim Idst IAna l0 tpcI fcf Tree logger ITTF Sti StiRnd PixelIT IstIT StiPulls genvtx NoSvtIt SsdIt MakeEvent McEvent geant evoutgeantout IdTruth tags bbcSim emcY2 EEfs big -dstout fzin MiniMcMk McEvOut clearmem","fileName.fzd")
Detailed log files can be found at
/star/institutions/mit/betan/FGT/Logs/
while the existing files are at
/star/institutions/mit/betan/ROOT_Files/FGT/
Attached are the relevant scripts (the _.txt has been added to get around DRUPAL attachment restrictions), although the hardcoded paths are no longer valid. The master script is submit_simulations.csh, which submits all the others to the RCAS queue star_cas_big. In particular, W_job.csh and hadron_job.csh are each called with the command line arguments
*_job.csh <em>nEvents fileName randomNumberSeed
The *_job.csh scrips then call the starsim and bfc with the necessary arguments passed as appropriate.
Critical to the upcoming flavor physics at STAR is efficient electron identification in the endcap, particularly amongst the dominant charged hadron/meson background. The development of such discrimination algorithms, however, requires extensive simulations. To reduce the computational burden of these simulations to a practical level we must modify starsim, reconstructing only those events of interest.
In this case we require electrons and charged hadrons/mesons in the endcap, and by adding a filter to PYTHIA we can ensure that only events matching the this criteria are reconstructed. Below is a small study showing the significant reduction in computing time gained with this filtering.
The filtered simulations required a charged hadron or meson in the endcap with pT > 15 GeV before GSTAR was allowed to reconstruct the event. Candidate refers to an event meeting the above requirements in the PYTHIA record, and projected refers to an extrapolation estimate for 80 pb-1.
Hadrons/Mesons | Filtered | Filtered (Projected) | Unfiltered | Unfiltered (Projected) |
Candidates | 10 | 18,604 | 10 | 18,604 |
Reconstructed GEANT Events | 10 | 18,604 | 2863 | 5,326,325 |
Integrated Luminousity (pb-1) | 0.043 | 80 | 0.043 | 80 |
Starsim Running Time (hours) | 0.274 | 509 | 7.42 | 13,817 |
BFC Running Time (hours) | 0.845 | 1572 | 24.2 | 45,023 |
Looking at the tracks in the GEANT record we see that the filtering worked as described. Here every charged hadron/meson in every reconstructed event is shown, and in the Filtered sample we see a sharp cutoff at 15 GeV exactly as expected.
The same analysis can be done for the W boson simulations, here instead requiring an electron(positron) from a W decay in the endcap with pT > 15 GeV.
Ws | Filtered | Filtered (Projected) | Unfiltered | Unfiltered (Projected) |
Candidates | 10 | 672 | 10 | 672 |
Reconstructed GEANT Events | 10 | 10 | 357 | 24,020 |
Integrated Luminousity (pb-1) | 1.189 | 80 | 1.189 | 80 |
Starsim Running Time (hours) | 0.0361 | 2.42 | 0.822 | 55.3 |
BFC Running Time (hours) | 0.0882 | 5.93 | 2.807 | 188.8 |
Again, comparing the two files shows the desired effects
In both cases the computational demands seem impractical, but one has to remember that this extrapolation is based on the use of a single processor. Real jobs will be run in parallel, significantly reducing the projected times to more reasonable levels. Despite the reduction, however, it might still be necessary to reduce the desired integrated luminousity slightly.
Within the STAR framework, simulation files are created with the command starsim which runs both PYTHIA and GEANT. Unfortunately, this means that there is no straightforward way to filter PYTHIA events before the GEANT reconstruction and producing simulation files for rare events can be very time consuming, as most of the CPU is wasted on the GEANT reconstruction of undesired events.
The trick around this is to modify the PYTHIA libraries themselves. In particular we want to modify the PYEVNT subroutine which is run during the generation of each PYTHIA event. Begin by
The body of this new subroutine will in general go as the following
while(conditions have not been met)
Call the original PYEVNT
Call any necessary auxillery subroutines
Loop over particles
if(not desired characteristic a) continue
if(not desired characteristic b) continue
...
if(not desired characteristic i) continue
Calculate relevant kinematic variables
Check conditions
Call PYLIST
Note that to avoid too many nested if loops we abort when the first test fails.
For example, consider an analysis requiring a high energy electron in the endcap. The usual PYTHIA settings allow one to require a high energy electron, but there is no way to restrict its location in the detector. So in the above pseudocode becomes
while(no high pT electron in the endcap)
Call the original PYEVNT
Loop over particles
if(not electron) continue
Calculate pT
Calculate eta
if(pT < 15) continue
if(eta < 1) continue
if(eta > 2) continue
return
Call PYLIST
The main background to the above is charged hadrons/mesons. In order to filter these we require that the particle has a charge of +/- 1, that is has the PDG ID of a hadron or a meson, that it has not decayed in the PYTHIA record, and fulfills the kinematic requirements.
while(no high pT jet in the endcap)
Call the original PYEVNT
Loop over the jets at the end of the PYTHIA record
if(not stable) continue
if(charge not equal +/- 1) continue
if(not hadron or meson) continue
Calculate pT
Calculate eta
if(pT < 15) continue
if(eta < 1) continue
if(eta > 2) continue
return
Call PYLIST
Once pyevnt.F has been succussfully modified it must be compiled with cons, and the path to the compiled library itself must be explicitly set in the kumac. For example,
gexec $STAR_LIB/libpythia_6410.so
must be replaced by
gexec /star/u/username/path_to_directory/.slxx_gccxxxx/lib/name_of_new_pythia_library.so
Examples of modified pyevnt.F files for both the electron example and the jet example are attached, as is a kumac for use with the jet example.
.
M-C Event Samples Available
BFC w/ generic vertex finder has ~50% efficiency,
Vertex distribution: Gauss(Z=0, sigZ=60cm, Z=Y=0, sigX=sigY=0)
Type of events | total events | time per event |
---|---|---|
Pythia, minB | 400K, 100 jobs | GSTAR: 8.4 sec, BFC ??? |
Files location: 80K eve at IUCF disk: /star/institutions/iucf/kocolosk/2008-02-15-fgt-hadron-background
full sample at MIT ...
Filtering of Pythia events: seed cell =10GeV ET, pair of cells>20 GeV ET,
particle eta range [0.8,2.2], grid cell size: 0.14 in eta, 9 deg in phi
BFC w/ PPV vertex finder has ~95% efficiency, SSD, STI not used in tracking
Vertex distribution: Gauss(Z=-60, sigZ=5cm, Z,Y offset)
Pythia event generator,
" DbV20080310 trs -ssd upgr13 Idst IAna l0 tpcI fcf -ftpc Tree logger ITTF Sti StiRnd -IstIT -SvtIt -NoSvtIt SvtCL,svtDb -SsdIt MakeEvent McEvent geant evout geantout IdTruth bbcSim emcY2 EEfs bigbig -dstout fzin -MiniMcMk McEvOut clearmem -ctbMatchVtx VFPPV eemcDb beamLine"
BFC chain:Type of events | Pythia filter | total events | time per event | job name | file size, MB |
---|---|---|---|---|---|
W-events (kumac) | 1/6.5 | 1K, 1 job | GSTAR 10 sec, BFC 5.3 sec | wElec4 | fzd=149, stevent=132, geant=154, McEvent=132, muDst=14 |
1:1 , OFF | 5K, 1 job | - | wElec5 | - | |
QCD-events (kumac) pt=20-30 GeV | 1/40 | 1K, 1 job | GSTAR 11 sec, BFC 6.7 sec | qcd2 | fzd=203, StEvent=157, geant=212, McEvent=172, muDst=17 |
1:1, OFF | 5K, 1 job | - | qcd3 | - | |
QCD-events, scan pt 10...90 GeV | varies | 100 eve, 1 job | - | qcd_pt_xx_yy | files at ...balewski/2008-FGT-simu/setB-pt-scan/ |
Files location: /star/institutions/iucf/balewski/2008-FGT-simu/setB-pilot/
* setC1: /star/institutions/iucf/balewski/2008-FGT-simu/setC2-pt-0.2inv_pb
This is LT balanced for 0.2/pb, using your ppQCDprod.kumac
pt1 pt2 neve 10 ,15 ,373 15 ,20 ,1252 20 ,25 ,2516 25 ,30 ,3367 30 ,35 ,2330 35 ,40 ,1015 40 ,45 ,705 45 ,50 ,292 50 ,55 ,114 55 ,60 ,67 60 ,65 ,28 65 ,70 ,13 70 ,75 ,8 75 ,80 ,4 80 ,85 ,2 85 ,90 ,1 90 ,95 ,1
* setC4 ( filtered QCD events w/ various partonic PT )
Based on setC3 the number of events with reco EM cluster ET>20 GeV is similar for the filtered and unfiltered pythia samples after LT correction - compare yellow & green areas:
------------ From Brian -------
Hi Jan,
I processed the events in setC3 and I put the plots into the
fgt-hn-contributions drupal page. (All plots show unfiltered events on
the left and filtered events on the right).
Transverse energy spectrum for the QCD events:
http://drupal.star.bnl.gov/STAR/system/files/ETspectrumQCD.png
Number of events passing ET>20GeV and ET>20GeV + Eta < 1.7 for QCD
events: http://drupal.star.bnl.gov/STAR/system/files/OPcountsQCD.png
Transverse energy spectrum for the W events:
http://drupal.star.bnl.gov/STAR/system/files/ETspectrumW.png
Number of events passing ET>20GeV and ET>20GeV + Eta < 1.7 for W events:
http://drupal.star.bnl.gov/STAR/system/files/OPcountsW.png
Brian
Pythia Filer: cell>10 GeV ET, cluster >20 GeV ET , grid covers Endcap Pythia events
Note, 'live' spreadsheet is attached at the bottom
Examples of event filtering for some choices partonic PT ranges:
partonic PT 15-20 GeV Filter=1/760 |
|
|
partonic PT 40-45 GeV Filter=1/3.6
|
|
|
partonic PT 75-80 GeV Filter=1/4.6
|
|
|
Filtering of Pythia events preserving those which may fire HT trigger in the Endcap.
Motivation
In order to develop efficient e/h discrimination algo for reco of electrons from Ws it is necessary to generate sizable sample of QCD physics background events with 1e5 or more events triggering Endcap HT >10 GeV. The brute force approach (run PYTHIA+GSTAR+BFC long enough) is investigated by my not succeed due to low yield of events of interests.
Therefore, we are working on the in-fly Pythia events filtering. It must be more complex than accepting events with a single Pythia track above certain threshold because multiple tracks from jet (also hadrons) may deposit in a single tower cumulative energy exceeding the HT threshold even if all tracks have energy below this threshold.
The tricky part is to decide if EEMC response may be large before GSTAR does very time consuming simulation of EM & hadronic showers for the whole event.
Proposed Method (2-stage Pythia filtering)
Additional comments:
* for Barrel eta range should be [-0.2,1.2] and cell size 0.05x0.05 in eta x phi.
* the code should be written in F77.
* at any step priority should be given to processing speed vs. program size. E.g. use lookup tables when reasonable.
* provide few QA histos generated with Pythia using HBOOK + kumac to display them
Content of Pythia record
1 proton 1 2 proton 2 3 parton from proton1 4 parton from proton2 5 parton from proton 1 after intial state radiation 6 parton from proton 2 after intial state radiation 7 parton 1 after scatter 8 parton 2 after scatter 9 ... intermediate and final partons/particles ....
Evaluation of minB events ample produced by Mike at Bates in January of 2008.
Events characteristic: Pythia MinB events, sqrt(s)=500 GeV, vertex Gauss(0,60cm)
Below you see detectors acquired by e+/e- surrogate :
1st pi-,pi+ with pT>2.0 GeV and eta>0.7
FGT disks are located at Z of 70,80,...,110 cm - our best guess location.
3 events samples were chosen based on Geant vertex location of -60, 30, and 0 cm, with margin of +/-10 cm, what leads to smeared FGT disks.
Several versions of FGT disk geometries has been studied in 2007
as documented here (disk-based HTML documentation)
Propagation of the Z hit location inaccuracy on to the error of predicted Rxy location of the Endcap EM shower.
Documented evolution of implementation of FGT geometry in GSTAR, started on May, 2008
Our studies are below seen as child pages.
Here are links to other studies
Fig 1
Fig 2
Fig 3
Fig 4
Fig 5
Fig 5 Realistic geometry from Jim K. model, May 2008
UPGR15 geometry was modified to match best guess of FGT geometry as of May 2008.
The active FGT area is : Z1=70,..., Z6=120cm, DZ=10 cm, Rin=11.5cm, Rout=37.5 cm
There is 1cm of additional dead material at Rin & Rout
Fig 1. Zvertex=0 cm, green= eta [1.06,2.0]. , red=eta[2.5,4.0]
Fig 2. Zvertex=+30 cm, green= eta [1.06,2.0]. , red=eta[2.5,4.0]
Fig 3. Zvertex=-30 cm, green= eta [1.06,2.0]. , red=eta[2.5,4.0]
Fig 4. Zoom in on 1 FGT disk. Detected particle enters from the left, 'active' gas volume has depth of 3mm (between magenta ad blue lines), FGT strips collect charge on the 1st green line.
(units in cm)
Zstart = 70.0 ! starting position along Z axis
Z = { 0.0, 10.0, 20.0, 30.0, 40.0, 50.0} ! Z positions for GEM front face
FThk = { 0.05, 0.05, 0.05, 0.05 } ! foil thicknesses inside GEM
SThk = { 0.3, 0.2, 0.2, 0.2 } ! support/spacing thicknesses
SR = 1.0 ! radial size for support
USED material:
Fig 4b FGT disk front view in Geant
Fig 5. 1st FGT disk by Jim K. as of April, 2008
Fig 6. 3 FGT disks by Jim K. as of April, 2008
Fig 7 Realistic geometry from Jim K. as of May, 2008
Fig 8 Disk material budget, from Doug, as of May, 2008
Fig 9 APV location , from Doug, as of May, 2008
Green dashed lines at eta=1.0,.1.06,2.0
red lines at eta=2.5, 4.0
another 6 disks are added at the following Z:
Zstart = 62.98 ! starting position along Z axis
Z = { 5.4, 15.4, 25.4, 35.4, 45.4, 55.4, 75., 90., 105., 120., 135., 150.} ! Z positions of GEM front face
Green dashed lines at eta=1.0,.1.09,2.0
red lines at eta=2.5, 4.0
Notes,
If I want to know the total area for one FGT disk what is the proper multiplier : 4, 28, or 24*28 ?
Within the cable, multipliers for the individual "subcomponents" are in column L.
Then, there are overall 4 cables per FGT disk - the column B tells you number of cables and I-J tells you where they go.
In other words, for instance, overall total copper area in FGT-power cables is
24*(7*5.176E-3+1*3.255E-3) = 0.948 cm^2.
I know you asked to break out with one "line" per cable route - we can do this later but for now there are already a lot of lines... I'll leave them grouped as this and you should look at I-J to decide the lengths and where they are.
By the way, I imagine the "patch" between cone/FGT cables and "external" cables lying on TPC endwheel, through services gap, to crates, occurs somewhere just outside the cone, within the first foot or so.
3 versions of GEANT geometries were investigated:
Plot below is just example of material using current SSD.
Many more plots are in attached PDF, in particular figs 2a-c, 3a-c, 4a-c.
Geometry= UPGR16, 6 FGT disks , fixed barrel geometry.
Single electrons, 20 GeV ET, thrown at eta=0, 0.4, 0.8, 1.2, 1.6, 2.0
Fig 1, Z vertex=0
Fig 2, Z vertex=+30 cm
Fig 3, Z vertex=-30 cm
1, MC tracks (eta < -1.3) are thrown backwards and FGT are found fired.
Fig. 1, An events with FGT hits fired by backward tracks (UPGR16)
2, To investigate with tracks (1.3 |eta| < 3.1) from MC events of RQMD Au-Au 10 GeV
Fig. 2
There are two rows in Fig. 2. Each row has three plots, the left is track multiplicity of events, the middle pt of
tracks, and the right dE of FGT hits in KeV. The top row is plotted for backward tracks which fire FGT and for fired FGT
hits (backward hits). The first two of the bottom are for all backward tracks. The right of the bottom is a dE spectrum
of FGT hits fired by FORWARD tracks (forward hits). From Fig. 1, we see
1, A low level of backward hits (mult_0/mult_1 = 200 shown in the top left plot)
2, A relatively large energy loss of backward hits which is 2-3 time larger than that of forward hits.
This suggests backward tracks which fire FGT have very low speed and deposit more energy than forward MIPs.
Based on the above, we believe that backward hits in FGT come from multiple scattering.
Fig. 3, Split spectra of the top row of Fig. 2 for individual FGT disks: disk1 (top) disk2 (middle)
and disk3 (bottome)
Fig. 4, Split spectra of the top row of Fig. 2 for individual FGT disks: disk4 (top) disk5 (middle)
and disk6 (bottome)
date | revision | format | component |
---|---|---|---|
March 2008 ? | revXXX? | west support cylinder | |
March 2008 ? | 4.0 ? | mounting of FGT foil quadrant |
Hi all;
I've put some results from the latest electrostatic
calculations for the WSC at:
http://hepwww.physics.yale.edu/star/upgrades/WSC-D.ppt
http://hepwww.physics.yale.edu/star/upgrades/WSC-D.pdf
The first page shows the key elements of the model and
the changes from previous versions:
- All edges of the WSC are radius'ed with 2 cm
- The resistor chain is now from Jan's "good" drawing
- The resistior chain is not rotated 16 degrees from
top - this makes it easier to navigate the "region
of interest" for studying the high field region.
This page also shows the orientation of the coordinate
system.
The next six pages are pairs of field plots. Each pair
shows the magnitude of the electric field in a slice
normal to the Z (X, Y) axis. The slice is taken at
the location of the maximum field. The second of each
pair of plots is just a zoom in on the hot spot.
The last plot shows that maximum field in an X-slice
vs. X. If people have questions or suggestions, we
can discuss this in tomorrow's meeting.
Best regards,
Dick Majka
Calculations from 24-July-2008 with "corrected" resistor chain geometry.
Rusults compared using 1mm mesh and 2mm mesh
Photo documentation of Thermo-model A of FGT, 2009-08-10
Consistent with measurements posted by James on 2009-07-28.
Please note the following attachments:
Donald Koetke
donald.koetke@valpo.edu
These are the current drawings for the FGT full-size prototype frames, HV layer, and GEM foils.
Cheers,
Douglas
these Gerber files show the general routing for the top and bottom GEM foil layers plus a representative sample of the GEM foil holes showing the spacing from frame edges and segment boundaries.
see below
This set of analysis was done in preparation to PAC presentation at BNL, May 2008, ( Jan)
Definitions:
S1,S2 - "signal" yields for 2 spins states (helicity) "1", "2" , S1+S2=S
B1,B2 - "background" yields for 2 spins states "1", "2" , B1+B2=B
N1=S1+B1; N2=S2+B2; N1+N2=N=S+B - "raw" yields measured in real experiment
Assumptions:
ALraw=(N1-N2)/(N1+N2)= (S1-S2)/(S+B); V(ALraw)= 4*N1*N2/N3
I used capital & small letters to distinguish this two experiments.
Problem: find statistical error of 'signal' asymmetry:
ALsig= (S1-S2)/S
Solution:
Model predictions of A_L for W+, W- , used files:
rb800.w+pola_grsv00_2.root, rb800.w-pola_grsv00_2.root, rb800.w+unp_ct5m.root rb800.w-unp_ct5m.root
LT=800/pb,
Brown oval shows approximate coverage of IST+FGT
Red diamond shows region with max A_L and ... little yield.
From Brian, e/h algo ver 2.4, LT=800/pb.
This version uses only tower seed in bin 6-11, this is main reason efficiency is of 40%.
I'll assume in further calculation the W-reco efficiency is of 70%, flat in lepton PT>20 GeV.
Left: W-yield black=input, green - after cut 15.
Right: ratio. h->Smooth() was used for some histos.
PT=20.6 sum1= 1223 PT=25.6 sum1= 1251 sum2= 473 att=1/2.6 PT=30.6 sum1= 987 sum2= 406 att=1/2.4 PT=35.6 sum1= 771 sum2= 343 att=1/2.2 PT=40.6 sum1= 372 sum2= 166 att=1/2.2 PT=45.6 sum1= 74 sum2= 16 att=1/4.6
From Brian, e/h algo ver 2.4, LT=800/pb. h->Smooth() was used for some histos.
This version uses only tower seed in bin 6-11
Left: QCD-yield black=input, green - after cut 15.
Right: ratio= QCD attenuation, not the a;go gets ~3x 'weaker' at PT =[34-37] GeV , exactly where we need it the most
PT averaged attenuation of QCD events
PT=20.6 sum1=2122517 PT=25.6 sum1=528917 sum2=3992 att=1/133 PT=30.6 sum1=135252 sum2= 736 att=1/184 PT=35.6 sum1= 38226 sum2= 320 att=1/120 PT=40.6 sum1= 11292 sum2= 127 att=1/89 PT=45.6 sum1= 3153 sum2= 41 att=1/77
From Brian. h->Smooth() was used for some histos.
Left: final yield of QCD events (blue) and W-events (green) after e/h algo.
Right: ratio.
I'll assume w=b/s is better than the red line, a continuous ET dependence:
w(pt=20)=10
w(pt=25)=1.
w(pt=40)=0.5
PT=25.6 sum1= 3992 sum2= 473 att=1/8.4 PT=30.6 sum1= 736 sum2= 406 att=1/1.8 PT=35.6 sum1= 320 sum2= 343 att=1/0.9 PT=40.6 sum1= 127 sum2= 166 att=1/0.8 PT=45.6 sum1= 41 sum2= 16 att=1/2.5
Assumed LT=800/pb
fpol=new TFile("rb800.w+pola_grsv00_2.root"); <--GRSV-VAL (maximal W polarization)
funp=new TFile("rb800.w+unp_ct5m.root");
histo 215
Total W+ yield for lepton ET[20,45] GeV and eta [1,2] is of 7101 for unpolarized cross section and of -2556 for the helicity dependent part.
Assuming 70% beam polarization measured spin dependent asymmetry:
eps_L= P* del/sum= -0.25 +/-0.012
(assuming err(eps)=1/sqrt(sum) )
Fig 1 , W+ : top row - unpol & pol cross section GRSV-VAL (maximal W polarization),
bottom left: integrated over eta, black=unpol, red=pol
bottom right: asy=P *pol/unpol vs. lepton PT, green=fit
Total W- yield for lepton ET[20,45] GeV and eta [1,2] is of 5574 for unpolarized cross section and of +2588 for the helicity dependent part.
fpol=new TFile("rb800.w-pola_grsv00_2.root");
funp=new TFile("rb800.w-unp_ct5m.root");
histo 215
Assuming 70% beam polarization measured spin dependent asymmetry:
eps_L= P* del/sum= +0.325 +/-0.013
Fig 2. W- GRSV-VAL (maximal W polarization)
Assumptions:
lepton PT range | w=backg/signal |
20-25 GeV | 5.0 +/- 10% |
25-30 GeV | 1.0 +/- 10% |
30-35 GeV | 0.8 +/- 10% |
35-40 GeV | 0.7 +/- 10% |
40-45 GeV | 0.6 +/- 10% |
Formulas:
Left : N1(PT)=red, N2(PT) blue. Right: reconstructed signal AL
ipt=0 y-bins=[41,50] unpol=1826.5 pol=-327.3 AL=-0.125 +/- 0.0234 QA=1.8 B2S=5.0 , N1=3721 N2=3950 ALraw=-0.021 +/- 0.011, dil=6.00 ALsig=-0.125 +/- 0.069 ipt=1 y-bins=[51,60] unpol=1403.0 pol=-265.8 AL=-0.133 +/- 0.0267 QA=2.9 B2S=1.0 , N1=889 N2=1075 ALraw=-0.066 +/- 0.023, dil=2.00 ALsig=-0.133 +/- 0.046 ipt=2 y-bins=[61,70] unpol=1233.7 pol=-384.7 AL=-0.218 +/- 0.0285 QA=4.7 B2S=0.8 , N1=643 N2=912 ALraw=-0.121 +/- 0.025, dil=1.80 ALsig=-0.218 +/- 0.047 ipt=3 y-bins=[71,80] unpol=1811.9 pol=-1041.9 AL=-0.403 +/- 0.0235 QA=10.0 B2S=0.7 , N1=713 N2=1443 ALraw=-0.237 +/- 0.022, dil=1.70 ALsig=-0.403 +/- 0.040 ipt=4 y-bins=[81,90] unpol=808.8 pol=-525.2 AL=-0.455 +/- 0.0352 QA=8.1 B2S=0.6 , N1=269 N2=637 ALraw=-0.284 +/- 0.033, dil=1.60 ALsig=-0.455 +/- 0.056 sum2=7084.000000 sum3=-2544.850098 asy=-0.251
ipt=0 y-bins=[41,50] unpol=1239.1 pol=490.8 AL=0.277 +/- 0.0284 QA=3.2 B2S=5.0 , N1=2774 N2=2430 ALraw=0.046 +/- 0.014, dil=6.00 ALsig=0.277 +/- 0.086 ipt=1 y-bins=[51,60] unpol=1452.7 pol=641.2 AL=0.309 +/- 0.0262 QA=6.6 B2S=1.0 , N1=1241 N2=792 ALraw=0.154 +/- 0.022, dil=2.00 ALsig=0.309 +/- 0.047 ipt=2 y-bins=[61,70] unpol=1426.5 pol=689.9 AL=0.339 +/- 0.0265 QA=7.5 B2S=0.8 , N1=1140 N2=657 ALraw=0.188 +/- 0.024, dil=1.80 ALsig=0.339 +/- 0.045 ipt=3 y-bins=[71,80] unpol=1135.3 pol=596.1 AL=0.368 +/- 0.0297 QA=7.6 B2S=0.7 , N1=884 N2=467 ALraw=0.216 +/- 0.027, dil=1.70 ALsig=0.368 +/- 0.049 ipt=4 y-bins=[81,90] unpol=313.8 pol=166.4 AL=0.371 +/- 0.0565 QA=4.3 B2S=0.6 , N1=234 N2=117 ALraw=0.232 +/- 0.053, dil=1.60 ALsig=0.371 +/- 0.086 sum2=5567.280273 sum3=2584.398926 asy=0.325
Fig 5. W+ GRSV-VAL (maximal W polarization)
Fig 6. W- GRSV-VAL (maximal W polarization)
Input from RHICBOS , GRSV-VAL model:
if(Wsign==1) { fpol=new TFile("rb800.w+pola_grsv00_2.root"); funp=new TFile("rb800.w+unp_ct5m.root"); WPM="W+ "; } else { fpol=new TFile("rb800.w-pola_grsv00_2.root"); funp=new TFile("rb800.w-unp_ct5m.root"); WPM="W- "; }
The sign of pol cross section from RHICBOS has reversed convention, I have changed it to Medison convention.
hpol->Scale(-1.);
from my macro, compare bottom right to blue from fig 2a
from my macro, compare bottom right to blue from fig 2b
A | B | C |
---|---|---|
ET_range (EEMC 3x3_cluster) |
assumed w=backg/signal | QCD eve suppression needed for(B) |
20-25 GeV | 5.0 +/- 20% | - (for W+ or W-) |
25-30 GeV | 1.0 +/- 20% | 1/539 or 1/520 |
30-35 GeV | 0.8 +/- 20% | 1/196 or 1/169 |
35-40 GeV | 0.7 +/- 20% | 1/43 or 1/ 69 |
40-45 GeV | 0.6 +/- 20% | 1/33 or 1/86 |
45-50 GeV | 0.5 +/- 20% | 1/119 or 1/289 |
Formulas:
1 | 2 | 3 | 4 | 5 | 6 | 7 | 8 | 9 | 10 |
---|---|---|---|---|---|---|---|---|---|
reco EMC ET GeV
|
reco W+ yield helicity: S1, S2 |
reco W+ unpol yield |
QCD Pythia accepted yield |
assumed B/S |
reco signal AL+err |
reco AL/err |
AL dilution: 1+B/S |
QCD yield w/ EMC cluster |
needed QCD suppression *) |
20-25 | 242 ,236 | 479 | 2397 | 5.0 | 0.019 +/-0.160 | 0.1 | 6.00 | ||
25-30 | 192 ,176 | 368 | 368 | 1.0 | 0.062 +/-0.105 | 0.6 | 2.00 | 198343 | 1/539 |
30-35 | 190 ,133 | 323 | 259 | 0.8 | 0.249 +/-0.109 | 2.3 | 1.80 | 50719 | 1/196 |
35-40 | 333 ,141 | 475 | 332 | 0.7 | 0.576 +/-0.098 | 5.9 | 1.70 | 14334 | 1/43 |
40-45 | 151,61 | 212 | 127 | 0.6 | 0.606 +/-0.132 | 4.6 | 1.60 | 4234 | 1/33 |
45-50 | 13,6 | 19 | 9 | 0.5 | 0.457 +/-0.393 | 1.2 | 1.50 | 1182 | 1/119 |
1 | 2 | 3 | 4 | 5 | 6 | 7 | 8 | 9 | 10 |
---|---|---|---|---|---|---|---|---|---|
reco EMC ET GeV
|
reco W+ yield helicity: S1, S2 |
reco W- unpol yield |
QCD Pythia accepted yield |
assumed B/S |
reco signal AL+err |
reco AL/err |
AL dilution: 1+B/S |
QCD yield w/ EMC cluster |
needed QCD suppression *) |
20-25 | 116,208 | 325 | 1626 | 5.0 | -0.403 +/-0.205 | 2.0 | 6.00 | ||
25-30 | 133,248 | 381 | 381 | 1.0 | -0.431 +/-0.112 | 3.8 | 2.00 | 198343 | 520 |
30-35 | 126,247 | 374 | 299 | 0.8 | -0.461 +/-0.107 | 4.3 | 1.80 | 50719 | 169 |
35-40 | 97,200 | 298 | 208 | 0.7 | -0.495 +/-0.115 | 4.3 | 1.70 | 14334 | 69 |
40-45 | 26,55 | 82 | 49 | 0.6 | -0.506 +/-0.203 | 2.5 | 1.60 | 4234 | 86 |
45-50 | 2,5 | 8 | 4 | 0.5 | -0.521 +/-0.617 | 0.8 | 1.50 | 1182 | 293 |
1 | 2 | 3 | 4 | 5 | 6 | 7 | 8 | 9 | 10 |
---|---|---|---|---|---|---|---|---|---|
reco EMC ET GeV
|
reco W+ yield helicity: S1, S2 |
reco W- unpol yield |
QCD Pythia accepted yield |
assumed B/S |
reco signal AL+err |
reco AL/err |
AL dilution: 1+B/S |
QCD yield w/ EMC cluster |
needed QCD suppression *) |
20-25 | 316,168 | 484 | 2424 | 5.0 | 0.436 +/-0.175 | 2.5 | 6.00 | ||
25-30 | 235,137 | 373 | 373 | 1.0 | 0.375 +/-0.111 | 3.4 | 2.00 | 198343 | 531 |
30-35 | 189,132 | 322 | 258 | 0.8 | 0.252 +/-0.109 | 2.3 | 1.80 | 50719 | 196 |
35-40 | 255,223 | 479 | 335 | 0.7 | 0.094 +/-0.085 | 1.1 | 1.70 | 14334 | 43 |
40-45 | 109,102 | 212 | 127 | 0.6 | 0.048 +/-0.124 | 0.4 | 1.60 | 4234 | 33 |
45-50 | 10,9 | 19 | 9 | 0.5 | 0.027 +/-0.393 | 0.1 | 1.50 | 1182 | 119 |
1 | 2 | 3 | 4 | 5 | 6 | 7 | 8 | 9 | 10 |
---|---|---|---|---|---|---|---|---|---|
reco EMC ET GeV
|
reco W+ yield helicity: S1, S2 |
reco W- unpol yield |
QCD Pythia accepted yield |
assumed B/S |
reco signal AL+err |
reco AL/err |
AL dilution: 1+B/S |
QCD yield w/ EMC cluster |
needed QCD suppression *) |
20-25 | 157,151 | 308 | 1544 | 5.0 | 0.024 +/-0.199 | 0.1 | 6.00 | 795943 | 515 |
25-30 | 187,180 | 367 | 367 | 1.0 | 0.029 +/-0.105 | 0.3 | 2.00 | 198343 | 540 |
30-35 | 187,179 | 367 | 293 | 0.8 | 0.033 +/-0.100 | 0.3 | 1.80 | 50719 | 173 |
35-40 | 151,144 | 295 | 206 | 0.7 | 0.033 +/-0.108 | 0.3 | 1.70 | 14334 | 69 |
40-45 | 41,40 | 81 | 49 | 0.6 | 0.026 +/-0.200 | 0.1 | 1.60 | 4234 | 86 |
45-50 | 3,3 | 7 | 3 | 0.5 | 0.012 +/-0.624 | 0.0 | 1.50 | 1182 | 301 |
FGT 6 identical disk have active area Rin=11.5 cm, Rout=37.6 cm;
Z location: 70,80,90, 100,110,120 cm with respect to STAR ref frame.
Unpolarized yield for W+, RHICBOS
Unpolarized yield for W-, RHICBOS
Unpolarized & pol yield for W+, RHICBOS, ideal detector
Unpolarized & pol yield for W-, RHICBOS, ideal detector
Fig 1 - Ideal detector
Fig 2 - Realistic detector efficiency & hadronic background, ideal charge reco
kinematics | LT=300/pb | LT=100/pb |
---|---|---|
W+, forward | 8.6 | 5.3 |
W-, forward | 6.7 | 3.9 |
W+, backward | 5.1 | 3.0 |
W-, backward | 0.3 | 0.2 |
kinematics | LT=300/pb | LT=100/pb |
---|---|---|
W+, forward | 8.6 | 5.3 |
W-, forward | 8.2 | 4.7 |
W+, backward | 5.9 | 3.4 |
W-, backward | 3.9 | 2.3 |
Fig 3 - Realistic detector efficiency, hadronic background, and charge reco
missing
Plots show AL for W+, W- as function of ET (fig1) and eta (fig2,3)
I assumed beam pol=70%, electron/positron reco off 70%, QCD background included, no vertex cut (as for all earlier analysis).
For AL(ET) I integrated over eta [-2,-1] or [1,2] and assumed the following B/S(ET) = 5.0 for ET>20 GEV, 1.0 for ET>25, 0.9 for ET>30,....
For AL(Eta) I integrated over ET>25 GeV and assumed a constant in eta & ET B/S=0.8.
Fig 1. AL(ET). Only Endcap coverage is shown. ( EPS.zip )
Fig 2. AL(Eta) . Only Endcap coverage is shown. ( EPS.zip )
Fig 3. AL(Eta) has continuous eta-axis, binning is exactly the same as in Fig 2. It includes Endcap & Barrel coverage.
(PS.gz) generated by take2/do5.C, doAll21()
Plots show AL for W+, W- as function of ET (fig1,2) and eta (fig3)
I assumed beam pol=70%, electron/positron reco off 70%, no vertex cut (as for all earlier analysis).
NO QCD background dilution.
For AL(ET) I integrated over eta [-2,-1] , [-1,+1], or [1,2] and assumed no background
For AL(Eta) I integrated over ET>25 GeV and assumed no background
Fig 1 ( PS.zip )
Fig 2 ( PS.zip )
Accounted for 2 beams at mid rapidity.
Fig 3
Common assumptions:
This page is tricky, different assumptions/definitions are used for different eta ranges.
determine the degree to which we can measure an asymmetry different from zero.
LT=100/pb | LT=300/pb | |
W+, forward | 0.27 | 0.15 |
W-, forward | 0.30 | 0.18 |
I fit constant to the black points what is equivalent to taking the weighted average.
determine the ratio of difference of DNS-MIN and DNS-MAX to sigma(measured AL)
avr(ALMIN-ALMAX) | LT=100/pb | LT=300/pb | |
W+, mid | 0.15 | 13 | 21 |
W-, mid | 0.34 | 13 | 22 |
C) Backward rapidity: eta range [-2,-1], (shown on fig 1c+d in study 7 revised for White Paper, AL(eta), AL(ET) , (Jan))
determine the ratio of difference of DNS-MIN and DNS-MAX to sigma(measured AL)
avr(ALMIN-ALMAX) | LT=100/pb | LT=300/pb | |
W+, backward | 0.10 | 1 | 2 |
W-, backward | 0.5 | 5 | 9 |
determine the ratio of difference of DNS-MIN and DNS-MAX to sigma(measured AL)
avr(ALMIN-ALMAX) | LT=100/pb | LT=300/pb | |
W+, mid | 0.15 | 7 | 11 |
W-, mid | 0.34 | 10 | 15 |
Common assumptions:
Dashed area denotes pt-averaged statistical error of STAR measurement.
Projection of STAR sensitivity for AL for W+,W- at mid rapidity for LT=10/pb and pol=60% or 50%
Common assumptions:
beam pol | avr AL(W+)THEORY=0.35 | . | avr AL(W-)THEORY=0.15 | ||
---|---|---|---|---|---|
sig ALSTAR | STAR signifcance | sig ALSTAR | STAR signifcane | ||
50% | 0.092 | 3.8 sigma | 0.18 | 0.8 sigma | |
60% | 0.077 | 4.6 sigma | 0.15 | 1 sigma |
not developed, add your analysis as child pages to this page
For the new QCD background,
partonic pT 15 - 20 GeV : 50,000 events LT=8.0/pb
partonic pT 20 - 30 GeV : 20,000 events LT=0.3/b
partonic pT 30 - 50 GeV : 10,000 events LT=0.4/pb
partonic pT 50+ GeV : 1,000 events LT=0.8/pb
The high pT tail is still weak. I could run more high pT events (with the time frame of one more day) or double the bin widths to smooth out the tail and allow for an efficiency plot up to ~50 GeV (albeit with relatively large error bars). Let me know your choice.
The W files are mit0009 and the QCD files are mit0012.
I use r = 0.26 for the isolation cut, as per the original IUCF proposal, and use the jet finder for the away side veto.
-Mike
This is geant-track based analysis
Mike:
Bottom plots are S/B ratios.
These are extremely loose cuts and I don't think you can base the entire FGT analysis on them.
First of all, the e/p cut isn't quite right. I use the actual energy of the track whereas most hadrons would just drop MIPs into the calorimeter making the e/p cut very helpful. I did try to do this in my code but the e/p cut became TOO good and I didn't want to have to deal with trying to convince people of that.
Second of all, no neutral energy isolation cut is made to veto against neutral energy depositions.
Third of all, no shower shape (transverse and longitudinal) information is used at all.
I think it's fair to say that this is a worst case scenario analysis.
Jan:
I try to understand better this last two S/B plots.
The message from the lower figure is:
* isolation cut alone results with background by a factor 2 to 3 for W+ and factor 4 to 10 for W- with reverse PT dependence for W+ & W-
* away said jet veto helps almost nothing in e/h discrimination.
* if only isolation & away side jet cuts are applied background dominates over signal by a factor of ~300 at PT of 20 GeV and improves to a factor ~2 at PT=40 GeV.
Taken at the face value Enddcap information add discrimination power of ~1000 for PT=20 GeV changing toward factor of 6 for PT of 40 GeV/c. (Assuming we want S/B=3)
My comment:
The value of 6 is in reach but value of 1000 may be not trivial.
e/p cut - I agree with Mike,
Looks like the e/p cut applied to h- reduces it up to a factor of 2
for pT of 40 GeV.
This cut needs to be dropped for real data- we will not measure PT in
FGT with reasonable accuracy at large track PT - this reduces overall
e/h discrimination power for W- at for PT>30 GeV, so more realistic
estimate of discrimination power of this (geant based) algo for W- at
PT of 40 GeV is rather S/B=0.35 and we need additional factor of 8
from the endcap.
Comparison of BFC with and without filtering
See pdf file at bottom of page:
The left-hand plots are the unfiltered events and the right-hand plots are the filtered
Non-Filtered
Electrons:
Fig1: No eta cuts
Fig 2: Eta between -1 and 1
Fig 3: Eta between 1.2 and 2.4
Positrons:
Fig 4: No eta cuts
Fig 5: Eta between -1 and 1
Fig 6: Eta between 1.2 and 2.4
Filtered on the pythia level: 20GeV in eta [0.8,2.2]
Electrons:
Fig 7: No eta cuts
Fig 8: Eta between -1 and 1
Fig 9: Eta between 1.2 and 2.4
Positrons:
Fig 10: No eta cuts
Fig 11: Eta between -1 and 1
Fig 12: Eta between 1.2 and 2.4
This analysis was preformed on the events in setC2. See here for details. I ran 48,000 qcd background events and 16000 W events using version 1.0 of my analysis program.
Fig 2: The number of primary tracks found for each event. The W events are on the left and the qcd background events are on the right.
The first cut an event is required to pass is that the transverse energy in a 3X3 patch of towers, centered on the tower with the highest energy, must be greater than 15GeV. All subsequent cuts are made only on events which pass this trigger.
Fig 3: The transverse energy deposited in the trigger patch for each event. The W events are on the left and the qcd background events are on the right.
For this analysis, I used the cuts I developed from looking at single particle events. For the 1-D histograms the W events are in black and the qcd background events are in red. For the 2-D histograms the W events are on the left and the qcd background events are on the right.
Fig 4. These plots show how many events passed a particular cut. W events are on the left and qcd background events are on the right. For reference, a total of 5997 W events passed the trigger and 6153 qcd background events passed the trigger.
Hi everyone,
I have some results for my first iteration of isolation cut and I would
appreciate some feedback as to whether they look reasonable or not.
These plots were made after requiring that the 3x3 trigger patch ET be greater than 20GeV.
First I find the eta and phi coordinates of the highest tower in the end
cap. I then set a value for the radius. I then loop over all tracks and
towers and if their endcap crossing point lies within my radius I add
their Pt or Et to the total.
By highest tower you mean:
- reco vertex is found
- ADC is converted to ET in event reference frame (you are using event-
eta, not detector eta
- you find highest ET tower
I use energy to find the highest tower, not transverse energy. StEEmcTower highTow = mEEanalysis->hightower(0). And for any event to be processed further, it must have a reco primary vertex found.
By highest tower you mean:
I use energy to find the highest tower, not transverse energy. StEEmcTower highTow = mEEanalysis->hightower(0). And for any event to be processed further, it must have a reco primary vertex found.
- reco vertex is found
- ADC is converted to ET in event reference frame (you are using event-
eta, not detector eta
- you find highest ET tower
StEEmcTower StEEmcA2EMaker::hightower( Int_t layer = 0 )
Returns the tower with the largest ADC response
3x3 trigger patch is built around this tower by construction. I ask for the high tower, then I ask for all of its neighbors. The high tower and its neighbors (usually 8, but could be less for high towers on sector boundries) make up the trigger patch.
Yes, I use these QA conditions.I then set a value for the radius.I then loop over all tracksDo you mean primary tracks with flag()>0 and nFit/nPos>0.51 ?
These plots show the ratio of the transverse energy in the 3x3 trigger
patch to the total transverse energy in the isolation radius. I ran W
events from files setC2_Weve_N (black curve) and QCD events from files
setC2_qcd_N (red curve).
Trigger ET over Et in iso radius r=0.1:
Trigger ET over ET in iso radius r=0.26:
Trigger ET over ET in iso radius r=0.7:
Here I take a first look at how various cuts effect the trigger patch ET spectrum. For this first run, I look at 13 cuts. The first four reduce the energy range and areas of the endcap that I look in. All of these cuts are applied before any additional cuts are made. The final eleven cuts are various isolation and endcap cuts. For this analysis I used sample ppWprod from setC2 for the W sample and pt30-50 from setC4 for the QCD sampel. Details here. These figures are not scaled to 800inv_pb so all W events must be multiplied by (800/1014) and all QCD events must be multiplied by (800/12.1).
Here are the cuts:
The following plots show the effects the above cuts had on the trigger patch ET spectrum when applied in the order given.
Fig 1: This plot shows the number of events that passed a set of cuts. Bin 1 shows the raw number of events processed and each subsequent bin shows all events that passed a given cut and all cuts before it. So bin eight will show all events that passed cuts 1-7. W events are on the left and QCD events are on the right.
Fig 2: This plot shows the effects of the four phase space cuts on the trigger patch ET spectrum. Again W events are on the left and QCD events are on the right.
Fig 3: This plot shows the effects of the remaining 9 cuts on the trigger patch ET spectrum. Here the black line, instead of representing the raw spectrum, represents the ET spectrum after the four phase space cuts have been applied. Again the cuts are sequential. W events are on the left and QCD events are on the right.
Fig 4: This plot shows the effect of all thirteen cuts in an easier to see form. The black line is the raw spectrum and the red line is the spectrum after the four phase space cuts and the blue line is the spectrum after all remaining cuts. W events on the left and QCD on the right. For the W sample: In the region 20-60, the raw sample contains 4319 events, the sample after the phase space cuts contains 2400 events, and the sample after all cuts contains 1924 cuts. For the QCD sample: In the region 20-60, the raw sample contains 7022 events, the sample after the phase space cuts contains 4581 events, and the sample after all cuts contains 160 events.
Effect of Cuts on Trigger Patch ET
In this analysis I look at the effect the cuts I used in Ver 2.3, as well as two new cuts, have on the transverse energy spectrum of the 3x3 trigger patch. For this analysis I used all files in setC4 for the QCD background and I used setC2_Wprod_N for the W samples. Details here. I weighted all events to 800 inverse pb. As before the first four cuts restrict the energy range and the area of the endcap we look at and the final eleven cuts are endcap and isolation cuts. The black curves are the QCD events and the red curves are the W events. All ET and eta's are event eta.
Here are the cuts: (Note, ordering different from ver 2.3)
Fig 1: This plot show the effects of all 15 cuts. The black line is the spectrum before any cuts are applied, the red line is the spectrum after the phase space cuts (1-4) are made, and the green line is the spectrum after all 15 cuts have been applied. QCD events are on the left and W events are on the right. For the QCD sample: The raw spectrum contains 718100 events in the region 20-60, the spectrum after the phase space cuts contains 452000 events, and the spectrum after all cuts contains 5215 events. For the W sample: The raw spectrum contains 3476 events in the region 20-60, the spectrum after the phase space cuts contains 1933 events, and the spectrum after all cuts contains 1407 events.
Fig 2: This plot shows the the QCD spectrum(black) after cuts 1-15 and the W spectrum(red) after cuts 1-15 on the same figure.
Results for Each Pt Bin
The first plot shows the effects that the first four cuts (the phase space cuts) have on the trigger patch transverse energy spectrum. The black line is the raw spectrum and the subsequent lines are the cuts, detailed on the parent page.
The second plot shows the effects the remaining cuts have on the ET spectrum. The black line is the spectrum after the phase space cuts, the red line is the spectrum after the isolation cut, the green line is the spectrum after the awayside energy cut and the blue line is the spectrum after all cuts have been applied.
The QCD events are on the left and the W events are on the right. Event ET is used. This is detected ET, not thrown ET. Everything is scaled to 800 inv_pb
Pt 50-inf:
Pt 30-50:
Pt 20-30:
Pt 15-20:
Pt 10-15:
The following plots show the cuts I intend to use on my first iteration of the e/h discrimination code. These plots were generated using ppWprod from setC2 (row 11) for W events and mit0015>10 from set C4 (row 13) for QCD events. Details are here. All events in plots have reco vertex in range z=[-70,-50] and have a trigger patch ET > 20GeV. Furthermore the isolation cut plots have the added condition that the high tower does not fall in etabins 1-5 or 12. The W sample is in black and the QCD sample is in red.
Fig 1: Plot of the ratio of transverse energy in the 3x3 trigger patch to transverse energy of towers located inside a radius of 0.45. Cut: > 0.95.
Fig 2: Plot of the displacement between a track and the center of the high tower when there is only one track above 1GeV in a radius of 0.70. Cut: < 0.6.
Fig 3: Plot of the number of hit towers with energy above .8GeV that lie in the same sector as the trigger patch. Cut: < 6.
Fig 4: Plot of the number of hit strips in the U plane in the sector containing the trigger patch. Cut: < 48.
Fig 5: Plot of the energy in the post-shower layers of the 3x3 trigger patch. Cut < 0.04.
Fig 6: Plot of the ratio of energy in the post-shower layers of the 3x3 trigger patch to the total energy in the trigger patch. Cut: < 0.0005. Fig 7: Plot of the ratio of energy in the seven highest U strips under the 3x3 trigger patch to the energy in all the U strips under the trigger patch. Cut: > 0.7.
Fig 8: Plot of the ratio of the energy in the two highest towers in the 3x3 trigger patch to the energy in all towers of the trigger patch.
Comparison Between 0, 1, and 2 Step BFC Filtering
For this analysis, I used code V2.5 which is the most recent version to use reconstructed tracks and vertices. I used a scaling factor of 1.25. Event ET used.
QCD events
Fig 1: Plot showing how many times each cut is passed individually. Values should coincide after bin 2
Fig 2: Plot showing how many events pass each cut in sequence. Values should coincide after bin 2
Fig 3: Plot showing spectrum after cuts 1-4 have been applied
Fig 4: Plot showing spectrum after cuts 1-5 have been applied
Fig 5: Plot showing spectrum after cuts 1-6 have been applied
Fig 6: Plot showing spectrum after cuts 1-7 have been applied
Fig 7: Plot showing spectrum after cuts 1-8 have been applied
W events
Fig 8: Plot showing how many times each cut is passed individually. Values should coincide after bin 2
Fig 9: Plot showing how many events pass each cut in sequence. Values should coincide after bin 2
Fig 10: Plot showing spectrum after cuts 1-4 have been applied
Fig 11: Plot showing spectrum after cuts 1-5 have been applied
Fig 12: Plot showing spectrum after cuts 1-6 have been applied
Fig 13: Plot showing spectrum after cuts 1-7 have been applied
Fig 14: Plot showing spectrum after cuts 1-8 have been applied
ET scaling factor
In order to investigate the discrepensy between the thrown pt of a lepton and the ET that the endcap detects, I have run electron events with single energies through the big full chain Jan has used for all the simulations and ploted the detected ET. I ran three energies 20GeV, 30GeV, and 40GeV. I ran 5000 events at each energy and each event has only one electron going into the endcap.
Fig. 1: This plot shows the detected ET of the electrons which were thrown at 40GeV.
Fig. 2: This plot shows the detected ET of the electrons which were thrown at 30GeV.
Fig. 3: This plot shows the detected ET of the electrons which were thrown at 20GeV.
We see that multiplying the detected ET by a scale factor of 1.23 recovers the thrown Pt of the electron.
Transverse Energy correction factor of 1.23 included
Code Version 2.5
Fig 1: Isolation cut
Fig 2: Awayside isolation cut
Fig 3: Seven strip cut
Fig 4: Post patch over full patch cut
Fig 5: All cuts spectrum with linear scale for W signal
Fig 6: All cuts spectrum with log scale for W signal
Fig 7: All cuts spectrum showing only W+ linear scale
Fig 8: All cuts spectrum showing only W+ log scale
Fig 9: All cuts spectrum showing only W- linear scale
Fig 10: All cuts spectrum showing only W- log scale
Brief explanation of cuts found here.
Below are plots showing the contributions that other W decay channels will have to the spectrum. All spectrum are weighted to 800inv_pb. Details can be found in rows 14-18 of the plot detailing events in setC2 here.
Fig 11. Spectrum of W decay events.
Fig 12. Spectrum of Z production events.
Fig 13. Spectrum of W jet events.
Fig 14. Spectrum of Z jet events.
Fig 15 Spectrum of W Z events.
Fig 16: Table of integrated yields for W, Z processes scaled to 800 inv_pb after all cuts have been applied.
PT>20 | PT>25 | |
W_Prod | 1827 | 1359 |
W_Dec | 64 | 30 |
Z_Prod | 113 | 67 |
W_Jet | 212 | 144 |
Z_Jet | 18 | 8 |
WZ | 4 | 2 |
Fig 17a,b: Table of Pythia cross section and branching ratio
Fig 18: Table of integrated QCD yields for all pT bins scaled to 800 inv_pb after all cuts have been applied.
pT>20 | pT>25 | |
All pT | 16460 | 4892 |
pT50-inf | 67 | 54 |
pT30-50 | 2247 | 1430 |
pT20-30 | 9179 | 2611 |
pT15-20 | 3628 | 558 |
pT10-15 | 1032 | 86 |
pT05-10 | 308 | 154 |
Analysis Summary
Introduction
A future goal of the STAR collaboration is the measurment of flavor separated polarized anti-quark distribution functions. To make these measurments we will be looking at charged leptons - electrons and positrons - arising from the decay of W bosons created in quark anti-quark collisions. One difficulty in making this measurment is the large flux of background hadronic particles, giving a signal to background on the order of 1/1000. The following details my efforts at developing an algorithm which can reject the hadronic background while retaining the signal leptons to achieve a S/B of greater than one-to-one over a significant portion of the observed lepton transverse energy spectrum which runs from roughly 20-50GeV.
Basic Philosophy
Discrimination between leptons and hadrons is posible because of the different processes giving rise to signal and background events as well as different showering properties of leptons and hadrons in the EEMC. Hadronic events tend to be dijets, meaning these events will deposit two blobs of energy located 180 degrees away in azimuth from eachother. Leptonic events, on the other hand, arise from the decay of W bosons which produce a charged lepton and a neutrino. The neutrino is not detected so only one blob of energy is deposited in the detector. This difference allows for the application of an away-side cut which will veto events having significant energy 180 degrees away from the candidate lepton. Hadrons and leptons also behave differently inside of the EEMC with hadrons tending to produce larger and wider showers as compared to leptons due to collisions with nuclei. This difference in shower behavior means isolation cuts on the energy around a candidate lepton can be effective. Finally, the EEMC is roughly 21 electron radiation lengths deep and only one hadron radiation length deep meaning that much more hadronic energy will escape the back of the detector, allowing for cuts based on the amount of energy leaving the detector. Below are pictures from starsim showing the evolution of hadronic and leptonic showers in the EEMC:
Fig 1: Picture of a 30GeV charged pion going into the EEMC generated using starsim.
Fig 2: Picture of a 30GeV electron going into the EEMC generated using starsim.
As described above, the algorithm discriminates between leptons and hadrons in three basic ways: looking at the number of tracks and energy around candidate leptons, vetoing events with too many tracks or too much energy 180 degrees away in azimuth from the candidate lepton, and by comparing shower evolution in the EEMC. Another important aspect of the discrimination algorithm is the trigger patch. The trigger patch is always taken to consist of the tower with the highest energy - which is also taken as the position of the candidate electron - and all adjacent towers, usually yielding a 3x3 patch. This trigger patch is the area of the EEMC where shower evolution is investigated. The investigation of shower evolution is possible in the EEMC due to the five separate readout layers: the two pre-shower layers, the two shower maximum detectors (SMDs) and the post-shower layer. The pre-shower layers are located at the front of the detector where few leptons will have started to shower, the SMDs are located five out of 24 layers deep and are positioned at the depth where there is maximum shower energy deposition, and the post-shower layer is at the back of the detector where most lepton showers will have died out. By looking at the energy deposited in the separate layers, one can get an idea of the longitudinal shower development inside the EEMC. One can also see the transverse shower development by looking at the number of hit strips in the SMD layers. Many combinations of EEMC quantites were tried over the course of developing the discrimination algorithm, but the best discrimination by far was achieved by looking at the ratio of the energies in the seven highest adjacent SMD strips under the trigger patch to the energy of all SMD strips under the trigger patch. Less effective but still usefull EEMC cuts include the ratio of the energy in the two trigger patch towers with the highest energy to the energy in the full trigger patch and the ratio of the energy in the post-shower layer to the energy in the full trigger patch. The away-side and isolation cuts provide powerful discrimination as well and are largly independent of the EEMC cuts listed above.
Code Versions
The discrimination code has gone through many versions as new cuts were tested, tracking methods were improved, and other improvements were made. Below is a brief discription of each version as well as the source code for future reference.
V1.0:
Version 1.0 is the first version of the discrimination code designed to work with the Pythia simulations run at MIT. This version borrowed heavily from earlier code designed to work on single thrown lepton and hadron events. The code used to access the EEMC information was taken directly from this earlier work. In addition to the EEMC anlysis this version includes code to access tracking information from the MuDst files as well as a function to determine if a track passed close to the tower with highest energy. Also included was a primative function which looked at the awayside energy only in the endcap. This code looked at approximately eleven different cuts and displayed what the trigger patch transverse energy spectrum would look like after each one was applied as well as what the spectrum would look like when several different combinations of cuts were applied.
V1.1:
Version 1.1 follows the same basic pattern as version 1.0 detailed above. The major difference is in the trigger criteria used to determine wether an event should be analysed. In version 1.0, all events needed to have a trigger patch ET greater than 15GeV in order to be processed further. In addition to the 15GeV condition, version 1.1 requires that all events have a found vertex and that that vertex be found in within ten centimeters of z=-60. (The simulations were generated with the interaction point at -60 cm so that tracks with large etas would pass through more TPC volume). The next significant change was the inclusion of a function which calculated the transverse energy deposited in a tower taking into accout the z position of the vertex as ET value for a particle originating at z=-60 can be significantly different from the ET value gotten assuming the particle originated at z=0. Minor changes include the addition of a function which allows the setting of the energy threshold needed to consider a tower hit, a function which gives the ET weighted position of the trigger patch, and the investigation of several new cut quantities.
V2.0:
Version 2.0 differs from the 1.x versions in that it implements functions allowing isolation cuts, both same side and away side, utilizing tower energies, track momenta, and barrel information. Simulations done by Les Bland showed that these kinds of cuts had the potential to provide nearly two orders of magnitude in background reduction. These functions add up the transverse energy/momentum of all towers/tracks which fall within a user set region. For the same side isolation cut, this region is a circle with user set radius centered on the high tower. For the away side isolation cut, the region is a slice in phi with a user set width around the line which is 180 degrees away in azimuth from the high tower. In addition to the isolation cut functions, this version addopts the new cuts from version 1.1 and adds histograms exploring various radii for the isolation cuts. The code to calculate the transverse energy was also changed again, this time to set the 'center' plane of the tower to the position of the SMD plane as opposed to the actual physical center because we expect the most shower activity at the SMD depth.
V2.1:
Version 2.1 is very similar to version 2.0 and contains only minor changes. One concern with previous versions was that events occuring at high eta did not have reconstructed tracks because of poor TPC tracking in this region and thus it was hard to get a good idea of how well cuts using tracking were doing. To investigate this problem, several isolation cuts and histograms were made with the condition that the hightower not be located in etabins 1-5 - which excluded high eta events - or etabins 11&12(because of edge effects around the transition from endcap to barrel). In addition to this bin restriction investigation, new histograms were made to study the effects of moving the trigger patch ET threshold from 15 to 20GeV on the cut quantites from version 2.0. Other small changes included the addition of a crude function to determine approximately how many electrons/positrons were going into the endcap and a modification to the away side isolation function to read out the track, barrel, and endcap energies separately.
V2.2:
Version 2.2 adds two functions which provide a different way to carry out the same side isolation cuts. The first function counts the number of tracks above a certain threshold which cross the endcap within some radius of the high tower and also calculates the transverse displacement between the track and the high tower if there is one and only one track in the radius. This one and only one track scheme is flawed and is modified in later versions. The second function calculates the transverse energy deposited in the barrel and endcap towers within a certain radius. The idea behind the new isolation cuts was that QCD events should have many tracks around the high tower while W decay events should have few, maybe only one. It was also thought that events with one and only one track in the isolation radius may only be displaced some slight amount from the high tower and that this could give good lepton hadron discrimination. There are many new histograms exploring these ideas.
V2.3:
Version 2.3 makes many changes to how the cuts are organized. The trigger patch ET spectrum is shown after each individual cut as well as after each cut in succession. The cuts in this version were chosen from the cuts in the previous version which showed the best discrimination power, all other cuts were removed. In addition to re-organizing the cuts, new trigger conditions were included. Along with the trigger conditions from previous versions, events now must have a trigger patch ET greater than 20GeV, have the high tower be in etabins 6-11, and have the ET weighted trigger patch eta position be greater than 1.7 to be processed further.
V2.4:
Version 2.4 is very similar to version 2.3 in terms of cuts. Cuts on the away side energy and the displacement between tracks and the high tower have been added. This version of the code has also been cleaned up significantly, with many extraneous histograms and function calls being removed. This version also allowed for overall weighting of the event samples being processed. This allows for the scaling of all pythia samples to the same integrated luminosity. This method of weighting the samples was cumbersome because the code must be recompiled for each seperate simulation batch and if a mistake were made, the whole pythia sample would need to be rerun. In the future, this method is dropped in favor of a script which weights the batches while merging the seperate event files.
V2.5:
Version 2.5 is the last version of the code to use cuts based on reconstructed tracks from the TPC. It is also the version used to produce plots for several presentations and proposals. As such, it has many histograms which were specifically requested for those presentations, chief among them histograms showing the effects of cuts on the trigger patch ET spectra for electrons and positrons separately. In anticipation of using GEANT tracking in future versions a function was created which would count tracks going into a isolation region using the GEANT record. This function looped over all vertices within three centimeters of the primary vertex and counted all the tracks above a certain threshold which made it into the isolation region. This method often double-counts tracks and is modified in later versions. In addition to the new functions and histograms, two glitches in the code have been fixed in this version. The first is the addition of an ET scaling factor which single particle simulations had shown were needed to make the thrown electron pt and detector response agree, the value used is 1.23. The second correction fixed a problem in calculating the phi displacement between two objects in the endcap. Because the endcap coordinate system splits the detector into two halves and maps one 0 -> 180 and the other 0 -> -180, just taking the difference between phi coordinates will occasionaly lead to the wrong actual displacement. To rectify this, the difference in phi is now calculated as acos(cos(phi1 - phi2)) instead of just (phi1 - phi2). In this version the cuts remain the same as in version 2.4.
V3.0:
Version 3.0 uses GEANT for tracking and vertex finding information. Looking at the results from previous code, it was thought that tracking efficency and vertex finding were still too poor. It was decided to use GEANT tracking in anticipation of the improved tracking which would be available with the FGT upgrade. With the perfect tracking from GEANT, it was possible to explore the upper limit of how much discrimination track cuts could provide. Because of the perfect tracking, the volume of the detector looked at would not need to be restricted as much. Thus, the trigger conditions were changed from version 2.5 to eliminate the restriction that the ET weighted eta position of the trigger patch must be less than 1.7. The restriction on the etabin of the high tower was also relaxed so that it could be located in bins 2-11 (bins 1 and 12 were still excluded to reduce edge effects). The isolation cuts are now handled by four functions, two calculate the energy deposited in the calorimeters for the same side and away side cuts, and two count the number of tracks above a certain pt threshold going into the same side and away side regions. The track counting functions still have the double counting problem in this version. The last major change to this code is the way in which the cuts are organized and displayed. In this version the cuts are divided into three groups, the initial trigger cuts that all events must pass, the isolation cuts and the EEMC cuts. Each cut quantity is displayed after the trigger cuts as usual, but now each cut is displayed after the trigger cut and the isolation cuts have been applied and each cut is displayed again after all other cuts have been applied so that in the end, each cut is displayed three separate times. This was done to see which cuts where independent of each other.
V3.1:
Version 3.1 of the code solves the double counting problem that the previous track counting functions had. In this version the track counting is done recursively. The GEANT track and vertex infromation is set up as a network of connected nodes. Each node is a vertex and represents a particle decay and the lines coming out of each node represent the resultant particles of this decay. These lines will then connect to other nodes if that particle decays. The track counting function loops through all the particle lines coming from the primary vertex and asks where the next vertex connected to that line is, if there is no other vertex or the vertex is located greater than three centimeters away from the primary vertex, the particle is considered stable and is counted (if it is heading into the proper region). If the next vertex is less than three centimeters from the primary vertex however, the function is called again and loops over the tracks coming from this secondary vertex and the process is repeated until all tracks have been looped over. In this way, the code avoids counting the track of a particle which decays along with the tracks of its daughter particles. In addition to the double counting problem the values of the cuts were changed in this version. Version 3.0 threw away too many signal events so version 3.1 used the same set of cuts but just loosened the values where the cuts were made so they did not throw away as many events.
V3.2:
Version 3.2 is very similar to version 3.1, the major differences are the values used for the cuts. The quantities cut on are the same as in version 3.0 and 3.1, but now the values have been tightened slightly compared with version 3.1, so now each cut throws away around 2 or 3% of the signal. In addition to this tightening, the away side energy and track quantities were plotted against the trigger patch ET in a 2-D plot. This allowed for cuts which rejected much more background at low pt than was possible before with the same 1-D cuts.
V3.21:
Version 3.21 is almost exactly the same as version 3.2, the major difference is that this version introduces an ineffiecency into two of the track cuts. The cuts on the number of charged tracks above .5 and 5GeV going into the same side isolation circle both have large numbers of events with zero tracks in the QCD background sample and very few events with zero tracks in the signal sample. It is likely that many of these neutral tracks are Pi0's. With GEANT tracking, these Pi0's can be identified with 100% efficiency, but for real data, material in front of the detector will cause many of the Pi0's to convert giving rise to charged tracks. This conversion process will make the zero charged track cuts less efficient. To explore the effects of these conversions, a random number generator was used to pass 30% of events with zero charged tracks in both cuts. The only other change from version 3.2 was to move the 2-D histograms showing the trigger patch ET vs the cut quantites after all other cuts but themselves were applied so that they would be incremented properly.
Results
Detailed results from the latest version of the discrimination code can be found on the pages linked to in sections 3.2 and 3.21 but the major points as well as some summary plots will be shown here.
Fig 3: This plot shows the final trigger patch ET spectra after all cuts have been applied. The QCD background is in black and the W signal is in red. The plot on the left is from v3.2 and the plot on the right is from v3.21.
Fig 4: This plot shows the signal-to-background ratio for versions 3.2 and 3.21 after all cuts have been applied.
Fig 5: This table shows the effectivness of each cut for version 3.2.
Cut | QCD Events Cut | Signal Events Cut |
Iso Cut | 235 of 754: 31% | 18 of 1151: 2% |
Small Iso Track | 82 of 536: 15% | 11 of 1131: 1% |
Away ET Cut | 1300 of 1754: 74% | 9 of 1135: 1% |
Away Track Cut | 924 of 1378: 67% | 45 of 1165: 4% |
Big Iso Track | 3542 of 3997: 89% | 4 of 1124: <1% |
2 Highest Towers | 63 of 521: 12% | 21 of 1141: 2% |
7 U Strips | 527 of 1195: 44% | 31 of 1175: 3% |
7 V Strips | 579 of 1195: 48% | 33 of 1175: 3% |
Hit U Strips | 7 of 468: 1% | 10 of 1138: <1% |
Hit V Strips | 8 of 468: 2% | 10 of 1138: <1% |
PS patch/Full patch | 151 of 606: 25% | 10 of 1130: <1% |
Fig 6: This table shows the effectivness of each cut for version 3.21.
Cut | QCD Events Cut | Signal Events Cut |
Iso Cut | 739 of 2852: 26% | 17 of 1107: 2% |
Small Iso Track | 1042 of 2931: 36% | 11 of 1089: 1% |
Away ET Cut | 3983 of 5897: 68% | 15 of 1093: 1% |
Away Track Cut | 3461 of 4897: 71% | 63 fo 1121: 6% |
Big Iso Track | 3310 of 5171: 64% | 4 of 1080: <1% |
2 Highest Towers | 110 of 2024: 5% | 19 of 1097: 2% |
7 U Strips | 1194 of 3620: 33% | 30 of 1131: 3% |
7 V Strips | 1323 of 3620: 37% | 32 of 1131: 3% |
Hit U Strips | 27 of 1966: 1% | 10 of 1096: 1% |
Hit V Strips | 44 of 1966: 2% | 10 of 1096: 1% |
PS patch/Full patch | 189 of 2095: 9% | 10 of 1088: 1% |
Figures 5 and 6 show the effect of each cut after all other cuts have been applied. (The exception is for cuts on U and V plane quantites, in which case all other cuts but the similar cut on the other plane are applied). For each cut, the number of events which survived the other cuts and the number of those events which the cut removes are shown. So for example, looking at the iso cut in figure three, 754 background events survive the thirteen other cuts and the iso cut removes 235 of these surviving events. This can be taken as a way to measure how independent a cut is from all the others. The tables show that with perfect tracking, the cut on the number of charged tracks above 5GeV is by far the best cut, but with the 30% ineffieciency added in the effectiveness of this cut is reduced so that it is around parity with the away side cuts.
Conclusions
As the figures above show, the discrimination code achieves a signal-to-background ratio of greater than one-to-one over a significant portion of the lepton transverse energy range, indicating that background should not be an insurmountable barrier to preforming the W analysis at STAR. These results were obtained using GEANT and any analysis of real data will need to monitor vertex finding and tracking efficency to ensure they do not degrade the effectiveness of the cuts too much. The addition of the FGT should help with these issues and it is likely that the code will need to be optimized to take advantage of the improved tracking of the FGT. Finally, this analysis is based on a powerful discrimination code which can be refined and modified to suit future analyses.
Analysis of all setC4 events using geant tracks and vertices
In this analysis, I looked at all QCD background events from setC4 as well as W events from setC2 Wprod detailed here. I used version 3.0 of my analysis code which uses geant vertices and tracks instead of reconstructed vertices and tracks as version 2.5 did. I have also made changes to the quantities I make cuts on, see below. All transverse energy is event ET and an energy scaling factor of 1.23 is used.
Cuts:
I make 14 cuts described below. Plots of the cut spectra can be found here. Pages 1-11 show the cut spectra after 3 preliminary phase space cuts have been made (spectra of the first 3 cuts are not shown). Every event must pass the first three cuts to be considered. Pages 12-18 show cut spectra 8-14 after cuts 1-7 have been applied. Pages 19-29 show cut spectra after all cuts but its own have been applied. Pages 30-32 show a possible alternative cut.
I have also made several 2-D plots of other quantities which may provide good electron/hadron discrimination. These plots can be found here.
Spectra
The plots showing the effect of the various cuts on the trigger patch ET spectrum can be found here. Pages 1-14 show the effect that the first 3 cuts plus the individual cut has on the trigger patch ET spectrum. So, for example, page 7 shows the spectrum after cuts 1, 2, 3, and 7. Pages 15-26 shows the effects that a number of cuts applied sequenitally has on the spectrum. In all plots the black curve is the detected ET spectrum before any cuts have been made and the red curve is the ET spectrum after the cuts in question have been applied.
Fig 1: This plot shows the effects of all the cuts applied in sequence on the trigger patch ET spectrum
Fig 2: This plot shows the final trigger patch ET spectra after all cuts have been applied. The QCD background is in black and the W signal is in red.
Analysis of all setC5 events using geant tracks and vertices
In this analysis I looked at all QCD background events from setC5, which has an integrated luminosity on the order of what we expect to get in data. I also looked at W events from setC2 Wprod. The details of both event samples can be found here. This analysis was done using version 3.1 of my code which uses geant vertices and tracks, meaning we have perfect tracking for the cuts. All transverse energy is event ET and an energy scaling factor of 1.23 is used. All samples are scaled to LT=800 inverse pb.
Cuts:
I make 14 cuts which are described below. These cuts have been loosened compared to those in version 3.0, now each cut throws away no more that 1% of the signal. I have also added conditions to cuts 5 and 8 to reject events where no charged track was found. Plots of the cut spectra can be found here. Pages 1-11 show the cut spectra after the 3 preliminary phase space cuts have been made (spectra of the first 3 cuts are not shown). All events must pass the first three cuts to be analysed further. Pages 12-18 show cut spectra 8-14 after cuts 1-7 have been applied to them. Pages 19-29 show all the cut spectra after all cuts but their own have been applied.
I have also made several 2-D plots of other quantities which my provide good electron/hadron discrimination. These plots can be found here.
Spectra
The plots showing the effect of the various cuts on the trigger patch ET spectrum can be found here. Pages 1-14 show the effect that the first 3 cuts plus the individual cut has on the trigger patch ET spectrum. So, for example, page 7 shows the spectrum after cuts 1, 2, 3, and 7. Pages 15-26 show the effects that a number of cuts applied sequentially has on the spectrum. In all plots the black curve is the detected ET spectrum before any cuts have been made and the red curve is the ET spectrum after the cuts in question have been applied.
Fig 1: This plot shows the effects of all the cuts applied in sequence on the trigger patch ET spectrum. For the QCD sample: The raw spectrum contains 2.6E6 events in the region 20-70, the spectrum after the phase space cuts (1-3) contains 2.2E6 events, and the spectrum after all cuts contains 1.5E4 events. For the W sample: The raw spectrum contains 4645 events in the region 20-70, the spectrum after the phase space cuts contains 3747 events and the spectrum after all cuts contains 3378 events.
Fig 2: This plot shows the final trigger patch ET spectra after all cuts have been applied. The QCD background is in black and the W signal is in red.
Analysis of all setC5 events using Geant tracks and vertices
In this analysis I attempt to get a feeling for the effects that imperfect tracking will have on the trigger patch ET spectrum while still using geant tracking information. My main focus was on the inefficencies which will arise in trying to identify converting Pi0's, so I focused on cuts 5 and 8. Both of these cuts have large numbers of events with no charged tracks and it is likely that many of these events are Pi0's. In v3.2 of the analysis code cuts 5 and 8 both throw away events with no charged tracks, so to simulate the tracking inefficency I use a random number generator to allow 30% of events with zero charged tracks to pass each cut. The code I used for this analysis is v3.21 which uses the same cuts as v3.2 except for the code introducing the 30% inefficency. Descriptions of the cuts used as well as explanations of the plots in the pdf files can be found on the page describing v3.2 of my code found here. I have also changed the 2-D plots of the trigger patch ET Vs. the cut quantities found on pages 23-33 of the 2-D plot pdf. They now show the plots after all cuts but themselves have been applied as opposed to v3.2 where they were shown after all cuts were applied.
Fig 1: These plots show the effects of all the cuts applied in sequence on the trigger patch ET spectrum. The top plot is from v3.2 and the bottom plot is from v3.21. The number of events cut for v3.2 can be found on the main page for that analysis. The numbers for v3.21 are given here. For the QCD sample: The raw spectrum contains 9.9E5 events in the region 20-70, the spectrum after the phase space cuts (1-3) contains 8.2E5 events, and the spectrum after all cuts contains 1906 events. For the W sample: The raw spectrum contains 1671 events in the region 20-70, the spectrum after the phase space cuts contains 1347 events and the spectrum after all cuts contains 1078 events.
Fig 2: This plot shows the final trigger patch ET spectra after all cuts have been applied. The QCD background is in black and the W signal is in red. The plot on the left is from v3.2 and the plot on the right is from v3.21.
Analysis of all setC5 events using Geant tracks and vertices
In this analysis I looked at all QCD background events from setC5, which has an integrated luminosity on the order of what we expect to see in the data. I alo looked at W events from setC2 Wprod. The details of both event samples can be found here. This analysis was done using version 3.2 of my code which uses geant vertices and tracks, meaning we have perfec tracking for the cuts. All transverse energy is event ET and an energy scaling factor of 1.23 is used. All samples are scaled to LT=300 inverse pb; note that the samples in all previous versions were scaled to 800 inverse pb.
Cuts:
I make 14 cuts which are described below. These cuts have been tightened slightly compared to those in version 3.1, now each cut throws away between 2-3% of the signal, except for cuts 6 and 7. For cuts 6 and 7, I have used a 2-D plot of the patch ET Vs. the cut quantity to cut harder on the low pT background. I have also included plots of quantites which we thought had potential to be used as cuts.
Plots of the 1-D spectra can be found here. Pages 1-11 show the cut spectra after the 3 preliminary phase space cuts have been made (spectra of the first 3 cuts are not shown). All events must pass the first three cuts to be analysed further. Pages 12-18 show cut spectra 8-14 after cuts 1-7 have been applied to them. Pages 19-29 show all the cut spectra after all cuts but their own have been applied. Pages 30 and 31 contain plots showing the ratio of U(V) strips above 0.5MeV under the trigger patch to the total number of U(V) strips under the patch. Pages 32 and 33 contain plots showing the number of U(V) strips above 0.5MeV in the sector(s) containing the trigger patch. Pages 34-37 contain the last four plots with cuts 1-7 applied and pages 38-41 contain the last four plots with all cuts applied.
Plots of the 2-D spectra can be found here. Pages 1-33 show the trigger patch ET Vs. the cut quantites so we can fine tune the cuts to eliminate background in particular ET ranges. Pages 1-11 show the cut spectra after the 3 phase space cuts have been made. Pages 12-22 show the cut spectra after cuts 1-7 have been applied. Pages 23-33 show the cut spectra after all cuts have been applied. Pages 34 and 35 show the trigger patch Energy Vs. the ratio of energy in the 7 highest adjacent U(V) strips under the trigger patch to all U(V) strips under the trigger patch. Page 36 shows the trigger patch Energy Vs. the ratio of pre-shower energy in the trigger patch to all energy in the trigger patch. Pages 37-39 show the last three quantities with cuts 1-7 applied and pages 40-42 show the same quantities with all cuts applied. Pages 43 and 44 show trigger patch ET Vs. the ratio of U(V) strips above 0.5MeV under the trigger patch to the total number of U(V) strips under the patch. Pages 45 and 46 show the trigger patch ET Vs. the number of U(V) strips above 0.5MeV in the sector(s) containing the trigger patch. Pages 47-50 show the last four plots with cuts 1-7 applied and pages 51-54 show the plots with all cuts applied. Page 55 is a plot of the trigger patch energy Vs. the post shower energy. Page 56 is a plot of the energy in both the U and V strips under the trigger patch Vs. the energy in all post shower layers under the trigger patch. Page 57 is a plot of the energy in both the U and V strips under the trigger patch Vs. the energy in all 2nd pre-shower layers in the trigger patch. Page 58 is a plot of the trigger patch energy Vs. the energy in all 2nd pre-shower layer in the trigger patch. Pages 59-62 show the last four plots after cuts 1-7 have been applied and pages 63-66 show the same plots after all cuts have been applied.
Specta
The plots showing the effect of the various cuts on the trigger patch ET spectrum can be hound here. Pages 1-14 show the effect that the first 3 cuts plus the individual cut has on the trigger patch ET spectrum. So, for example, page 7 shows the spectrum after cuts 1, 2, 3, and 7. Pages 15-26 show the effects that a number of cuts applied sequentially has on the spectrum. In all plots the black curve is the detected ET spectrum before any cuts have been made and the red curve is the ET spectrum after the cuts in question have been applied.
Fig 1: This plot shows the effects of all the cuts applied in sequence on the trigger patch ET spectrum. For the QCD sample: The raw spectrum contains 9.9E5 events in the region 20-70, the spectrum after the phase space cuts (1-3) contains 8.2E5 events, and the spectrum after all cuts contains 455 events. For the W sample: The raw spectrum contains 1742 events in the region 20-70, the spectrum after the phase space cuts contains 1405 events and the spectrum after all cuts contains 1120 events.
Fig 2: This plot shows the final trigger patch ET spectra after all cuts have been applied. The QCD background is in black and the W signal is in red.
Planning the Beamtest at DESY
Important Dates:
Scheduled from May 16-30
Contacts:
general:
Anselm Vossen (avossen@indiana.edu)
DESY testbeam page:
http://adweb.desy.de/~testbeam/
People that are going
Equipment that has to be shipped
Equipment |
Qty | Size | Weight | ? | Contact Person/Institution | Shipping Details (from where to where) | When? |
Comments (e.g. shipping details safety aspects) |
|
FGT Quadrants | MIT | ||||||||
Det Fixture | MIT | ||||||||
positioning/alignment | MIT | ||||||||
gas-setup | Valpo/MIT | might be available at DESY - see below | |||||||
bottled gas (premixed?) | DESY | ||||||||
FEE board | 6 | MIT | |||||||
terminator board | MIT | ||||||||
interconnector board | MIT | ||||||||
cable and patch | MIT | ||||||||
signal cables | IU/UKY | ||||||||
power cables | IU/UKY | ||||||||
RG-59 HV cables | 3 | DESY? | |||||||
readout crate | 1 | 2.5'x 4'x 3.5x | 100 lbs | ANL | |||||
ARC | 1 | 1'x 1'x 0.3' | 4 lb | ANL | |||||
ARM | 3 | 1'x1'x0.3' | 4 lb | IU | |||||
HVPS | 1 | 1'x1'x0.3' | 8 lb | IU | |||||
computer incl. DRORC | 1 | 1'x3'x4' | 73 lb | DESY? | |||||
Nim logic | DESY | ||||||||
data fiber | 1 | IU | |||||||
hand tools and scope | DESY | ||||||||
diff probe | 1 | IU | |||||||
Sys clock source | already provided by ARC | ||||||||
Misc computer equipment (PC etc) |
Gas at Desy
The DESY gas group can supply premixed gas. We have to ask well in advance.
Flowmeters etc. should also be available. We have to bring tools
Test Beam Description
can be found here:
adweb.desy.de/home/testbeam/WWW/Description.html
Safety at DESY
Inspection List for equipment
General:
adweb.desy.de/~testbeam/documents/AllgemeineSicherheitsunterweisungD5englisch.pdf
Radiation protection
adweb.desy.de/~testbeam/documents/RadiationProtectionInstructionsTestBeam-NM-1-2006.pdf
Testbeam safety briefing:
adweb.desy.de/~testbeam/documents/SafetyBriefingTestBeam.pdf
We have to assign one person responsible for radiation safety
That person is:
Travel Infos for Hamburg/Germany
Fly into Hamburg
Today the price from JFK is ~$950 roundtrip
Within Germany, rail is good idea if you book in advance
www.bahn.de/i/view/USA/en/index.shtml
ask me if you want to look for special fares ( I saw that that site is in German)
HOUSING
DESY hostel:
guest-services.desy.de/hostel_in_hamburg/hostels_info/
I haven't been at DESY, so if somebody else has a better idea, please tell me
CHECKLIST
OPEN ISSUES
Gas
Planned Measurements
For each of these measurements we should have a plan/protocoll what we want to do (conditions, time, software...)
Normal
0
false
false
false
EN-US
X-NONE
X-NONE
/* Style Definitions */
table.MsoNormalTable
{mso-style-name:"Table Normal";
mso-tstyle-rowband-size:0;
mso-tstyle-colband-size:0;
mso-style-noshow:yes;
mso-style-priority:99;
mso-style-parent:"";
mso-padding-alt:0in 5.4pt 0in 5.4pt;
mso-para-margin:0in;
mso-para-margin-bottom:.0001pt;
mso-pagination:widow-orphan;
font-size:11.0pt;
font-family:"Calibri","sans-serif";
mso-ascii-font-family:Calibri;
mso-ascii-theme-font:minor-latin;
mso-hansi-font-family:Calibri;
mso-hansi-theme-font:minor-latin;
mso-bidi-font-family:"Times New Roman";
mso-bidi-theme-font:minor-bidi;}
Reproduction of test beam results at FNAL: drupal.star.bnl.gov/STAR/blog/surrow/2011/feb/02/fgt-testbeam-fnal-prototype-triple-gem-detectors
Normal
0
false
false
false
EN-US
X-NONE
X-NONE
/* Style Definitions */
table.MsoNormalTable
{mso-style-name:"Table Normal";
mso-tstyle-rowband-size:0;
mso-tstyle-colband-size:0;
mso-style-noshow:yes;
mso-style-priority:99;
mso-style-parent:"";
mso-padding-alt:0in 5.4pt 0in 5.4pt;
mso-para-margin:0in;
mso-para-margin-bottom:.0001pt;
mso-pagination:widow-orphan;
font-size:11.0pt;
font-family:"Calibri","sans-serif";
mso-ascii-font-family:Calibri;
mso-ascii-theme-font:minor-latin;
mso-hansi-font-family:Calibri;
mso-hansi-theme-font:minor-latin;
mso-bidi-font-family:"Times New Roman";
mso-bidi-theme-font:minor-bidi;}
on inclination angle for P/Phi reconstruction
Crosstalk
Normal
0
false
false
false
EN-US
X-NONE
X-NONE
/* Style Definitions */
table.MsoNormalTable
{mso-style-name:"Table Normal";
mso-tstyle-rowband-size:0;
mso-tstyle-colband-size:0;
mso-style-noshow:yes;
mso-style-priority:99;
mso-style-parent:"";
mso-padding-alt:0in 5.4pt 0in 5.4pt;
mso-para-margin:0in;
mso-para-margin-bottom:.0001pt;
mso-pagination:widow-orphan;
font-size:11.0pt;
font-family:"Calibri","sans-serif";
mso-ascii-font-family:Calibri;
mso-ascii-theme-font:minor-latin;
mso-hansi-font-family:Calibri;
mso-hansi-theme-font:minor-latin;
mso-bidi-font-family:"Times New Roman";
mso-bidi-theme-font:minor-bidi;}
Rate dependence (trigger rate and signal rate).
Normal
0
false
false
false
EN-US
X-NONE
X-NONE
/* Style Definitions */
table.MsoNormalTable
{mso-style-name:"Table Normal";
mso-tstyle-rowband-size:0;
mso-tstyle-colband-size:0;
mso-style-noshow:yes;
mso-style-priority:99;
mso-style-parent:"";
mso-padding-alt:0in 5.4pt 0in 5.4pt;
mso-para-margin:0in;
mso-para-margin-bottom:.0001pt;
mso-pagination:widow-orphan;
font-size:11.0pt;
font-family:"Calibri","sans-serif";
mso-ascii-font-family:Calibri;
mso-ascii-theme-font:minor-latin;
mso-hansi-font-family:Calibri;
mso-hansi-theme-font:minor-latin;
mso-bidi-font-family:"Times New Roman";
mso-bidi-theme-font:minor-bidi;}
.Radiation effects on the frontend electronics
Normal
0
false
false
false
EN-US
X-NONE
X-NONE
/* Style Definitions */
table.MsoNormalTable
{mso-style-name:"Table Normal";
mso-tstyle-rowband-size:0;
mso-tstyle-colband-size:0;
mso-style-noshow:yes;
mso-style-priority:99;
mso-style-parent:"";
mso-padding-alt:0in 5.4pt 0in 5.4pt;
mso-para-margin:0in;
mso-para-margin-bottom:.0001pt;
mso-pagination:widow-orphan;
font-size:11.0pt;
font-family:"Calibri","sans-serif";
mso-ascii-font-family:Calibri;
mso-ascii-theme-font:minor-latin;
mso-hansi-font-family:Calibri;
mso-hansi-theme-font:minor-latin;
mso-bidi-font-family:"Times New Roman";
mso-bidi-theme-font:minor-bidi;}
EMI issues. (For the most part if there are any, have to be
addressed first and independently of the rest of the testing, test
beam or otherwise.)
Normal
0
false
false
false
EN-US
X-NONE
X-NONE
/* Style Definitions */
table.MsoNormalTable
{mso-style-name:"Table Normal";
mso-tstyle-rowband-size:0;
mso-tstyle-colband-size:0;
mso-style-noshow:yes;
mso-style-priority:99;
mso-style-parent:"";
mso-padding-alt:0in 5.4pt 0in 5.4pt;
mso-para-margin:0in;
mso-para-margin-bottom:.0001pt;
mso-pagination:widow-orphan;
font-size:11.0pt;
font-family:"Calibri","sans-serif";
mso-ascii-font-family:Calibri;
mso-ascii-theme-font:minor-latin;
mso-hansi-font-family:Calibri;
mso-hansi-theme-font:minor-latin;
mso-bidi-font-family:"Times New Roman";
mso-bidi-theme-font:minor-bidi;}
Optimum gain setting for the FGT in consideration of the limited dynamic range of APV. What tail of large events can we afford to cut off and still make the position resolution? Conversely how much noise is affordable and still make the position resolution. Presumably get to a plot of resolution as a function of HV setting.
Normal
0
false
false
false
EN-US
X-NONE
X-NONE
/* Style Definitions */
table.MsoNormalTable
{mso-style-name:"Table Normal";
mso-tstyle-rowband-size:0;
mso-tstyle-colband-size:0;
mso-style-noshow:yes;
mso-style-priority:99;
mso-style-parent:"";
mso-padding-alt:0in 5.4pt 0in 5.4pt;
mso-para-margin:0in;
mso-para-margin-bottom:.0001pt;
mso-pagination:widow-orphan;
font-size:11.0pt;
font-family:"Calibri","sans-serif";
mso-ascii-font-family:Calibri;
mso-ascii-theme-font:minor-latin;
mso-hansi-font-family:Calibri;
mso-hansi-theme-font:minor-latin;
mso-bidi-font-family:"Times New Roman";
mso-bidi-theme-font:minor-bidi;}
Survival of FEE to breakdown/discharges in detector
date | place | format | occasion |
---|---|---|---|
January 2008 | MIT | STAR Forward GEM Tracker Review Committee |
OTHER DOCUMENTS
Files from the prelimnary safety review at BNL Sept 09
The APV front-end ASIC which forms the core of the Forward GEM Tracker readout system combines a sensitive preamplifier, switched-capacitor analog memory array, and low-voltage differential analog output buffer.
Operating such an ASIC directly over a long cable, with the analog output digitized at the far end of the cable, potentially presents some challenges. Of course, there are are also opportunities, to minimize the power dissipation inside the inner field cage region, minimize dead materials, and to maximize reliability by placing most of the electronics in an easily serviceable location on the STAR electronics platform.
At IUCF we are constructing a pair of test boards, one which models the APV readout module "ARM", the other which models the APV cable connector board.
Besides testing the performance of the MIT APV motherboards with a long cable interface, this set of test boards is important to:
Here are the design files:
The connector board should be compatible with a pair of FGT APV Motherboards, a total of 10 APV chips. The mock readout board provides only two channels of analog line receiver, testing two different concepts for this. One is a DC coupled line receiver using Analog Devices # AD8129, the other is a transformer-coupled line receiver using a TI # OPA684 opamp. The transformer solution should have superior noise and common-mode rejection and lower power, but it is of course not DC coupled as we would wish. It could be used if DC restoration is applied digitally in the FPGA (on the real ARM).
First results:
Here is the APV readout sequence, looking good:
The "noise" which is apparent here is merely crosstalk from the clock signal, and as such will be easily removed by the filter in front of the ADC. Neither that filter nor the cable frequency equalization filter is in place for the measurement above.
Clock frequency was 40 MHz; APV was triggered at 1 kHz from a pulse generator. No inputs connected, no shield box. Cable is Belden 1424A, 110 feet, coiled up on workbench.
Details of final prototype of FEE interface circuitry for FGT APV Readout Module "ARM". This includes the isolated remote-regulated power supplies, the isolated I2C line interface, the isolated LVDS clock & trigger line drivers, and the differential analog receiver. Cable connectors and pinouts here are proposed for final application. (In actual ARM, cables interface through a rear transition board in the crate through the 96-pin DIN connector to ARM module. This is not implemented here - cables connect directly using same connector type and pinouts on the cables.)
Here are the details:
This is a short overview of the front end and readout electronics of the FGT. The emphasis is on providing some documentation on all the components. At present most of the items exist only as prototypes, I will try to keep this page current as things get finalized.
First, the front end board, which has 5 APV chips. Two front end boards are used per FGT quadrant (24 quadrants total). One sits at each end of the quadrant. As four quadrants fit together to form an FGT disk, the pairs of front end boards from adjacent quadrants physically sit close to each other. They are serviced by a common cable, interconnect board, and terminator board (to be described shortly).
Below is a picture of the first FGT quadrant (actually just a mechanical test assembly, the pad plane is an old design and is defective). Apologies this is a shiny object photographed on a shiny table in the Bates cleanroom. What you see here is mainly the aluminized mylar gas window which is also the ground plane, sits a couple of mm above the pad plane. On each end of the quadrant is a row of five Samtec MEC6 card-edge connectors (0.635 mm contact pitch): four 140 pin connectors and one 80 pin in the center of the other four. This connects the 640 = 5 APV * (128 ch/APV) signals from the pad plane to the FEE board. The ground is carried separately (see description below). The constraints on FGT inner and outer radius do not permit assigning any of these connector contacts to grounds.
Below is a picture of a front end board installed on an FGT quadrant. This is a view from "outside" i.e. this is the side of the front end board that does not have the APV chips. Actually in this picture is a mechanical mockup board, but is mechanically identical to the final design. The white RTV which can be seen in this picture is covering the edge of this quadrant assembly.
And here is the actual front end board. In this and the picture above you can see the two ground contact points which will be fastened with screws and washers to wide contact strips extending from the ground foil. This provides the connection of APV signal ground. The ground foil is also similarly connected to the bypass capacitor feeding bias voltage to the bottom of the last GEM foil (connections not detailed here).
Note that it is the back side of this board that would be seen in the quadrant picture above. The two front end boards serviced as a pair have the APV chips mounted on the outward facing sides. Similarly the ground foil connections are made on this outward facing side. From the quadrant's perspective, the chip side of the APV board faces in toward the center of the quadrant.
The front-end board is serviced by the "interconnect board" on one end and a "terminator board" on the other. All interface lines run through from end to end so that the design is symmetrical. Half of the frontend boards have the terminator on the right in this picture, half have the interconnect board on the right. There is only a single flavor of front end board.
The schematic of the front end board is (here). It consist only of five APV chips and a minimal set of support components.
The APV chip is a 128-channel preamp / shaper / SCA / readout mux chip developed for CMS tracker silicon, and also subsequently deployed for GEM readout in COMPASS. Most of the operational details are described in the user guide and in presentations available on the CMS tracker web pages. The APV chip incorporates an analog FIR filter (what the user guide refers to as deconvolution mode) for tail cancellation / pileup reduction at the expense of higher noise. We don't intend to make use of it. It should be noted that the appropriateness of the (fixed) filter coefficients is of course dependent on the sample clock rate. Which is another reason we don't intend to use it.
The APV chip sample clock can be run at least as fast as 40 MHz (as in CMS). For RHIC, we prefer to lock to a multiple of our collision frequency so that the signals can be synchronously sampled avoiding any additional complications or errors from asynchronous sampling. We will use 4x RHIC strobe, 37.532 MHz, a reasonable match to the capability of the APV chip.
The APV chip readout clock can be the sample clock or 1/2 the sample clock rate. With 1/2 the sample clock a single-point readout requires 280/37.532 MHz = 7.46 us. This is amply fast in comparison with other STAR detectors even if multi-point readout is employed. So we will use only the 1/2 rate readout because it significantly eases the signal transport problem.
[Insert here description of the interconnect board / terminator board. (voltage reg, clk/trig receiver, temp sensors, POR circuit, terminations)]
The above comprises the front end electronics subsystem. The interfaces from the front end electronics to the readout electronics are, in total:
(more description/documentation of the readout system to come...)
These are the official drawings and documentation used for fabrication of the FGT "DAQ" hardware. We will try to maintain this page up-to-date with any revisions.
APV Readout Controller (ARC)
APV Readout Module (ARM)
ARM Back-of-Crate Board (ABC)
FGT FEE Patch Panel
Other documentation
TIME is going backwards.
2009-05-21 , RHIC user meeting @ BNL
2009-05-12 , quarterly review presentation of the FGT project
2009-03-23, RCS presentation, Bernd
2009-08-08, 3rd quarterly review at BNL,Bernd
FGT-HN Upload site (StarTube) : You do not have access to view this node , Instruction for new users uploading FGT documents
Weekly FGT phone meetings (minutes by Doug Hasell or Gerard)
2009
2008
March: 7, 14, 21, 28
April 11 : Brian e/h-algo , Dave: X/X0 in Endcap
May 2 ,
IEEE in Dresden, 2008, Frank's talk about FGT
You do not have access to view this node, September 2008 GT meeting at BNL
September 2008, Local seminar at MIT by Jan
Title: The STAR Forward GEM Tracker, Talk (PDF), abstract
2nd STAR IFC integration meeting, BNL, July 23, 2008
You do not have access to view this node
Forward Tracking Extension Meeting at MIT, June, 2008
STAR Collaboration Meeting, Davis, June, 2008
STAR IFC integration meeting, BNL, May 16, 2008
BNL PAC, May 8, 2008,
IEEE NSS 2008 in Dresden, Germany, May 2008,
RSC meeting on April 21, 2008 , all talks , DG, W, ppTrans ,
DIS2008, London April 2008, web-page, some talks: ppTrans RHIC program (PPT) Jan
FGT review at MIT, January 7-8, 2008 ( detailed agenda )
Date: Friday April 29, 2001
Time: 1:30 pm
Place: C-AD LCR
overview cosmic teststand: Anselm
FGT disks (internal HV distribution etc) : Ben/Jason
electronics/cables/etc. : Gerard
Gas system (short) : Don
In this document one can find schematic topology and architecture of 2D_GEM Sensor Board which was used for test at FANL.
In this document one can find complete schematic topology and block diagrams for 2D_GEM Readout Control Unit which was used in test run at FANL.
In this document one can find complete schematic topology and hardware architecture for APV Module which was used for test of 2D_GEM at FANL.
Document "APV Motherboard Design" for FGT April's meeting at IUCF on April 24, 2008.
APV_MODULE is PCB where on top of APV_BOARD is bond with epoxy glue SIG_BOARD
FEE Design
In this document one can find GERBER files for Charge Sharing 2D_Readout module. This module will be used for test and study charge sharing effect in GEM detectors. All other components for assembling of this charge sharing setup we will use from old GEM detectors which we used for test purposes at FANL last year.
NOTE: Files in "TSTBOARD.zip" are possible open with P-CAD2004 software tool and file "tstboard.pdf" is "pdf" accessible file where one can see architecture of mentioned unit.
This document was requested by Dave Underwood and Gerrard Visser for they purposes to compare they design with GEM/FANL prototype buildup at MIT/Bates Linear Accelerator.
In attached document is multipurpose module with which one can test all mechanical and connectivity features.
In this document one can find VHDL Programs and State Machines for 2D_GEM Control Unit which was engaged in readout process from GEM detector at FANL.
drawings showing the final dimensions of the WSC and the GEM quarter section frames,
8-19-2009, Jason Bessuille
These are the official drawings and documentation used for fabrication of the FGT Front End Electronics hardware. We will try to maintain this page up-to-date with any revisions.
To view design files, download the Altium Viewer (no cost).
FGT Readout Module (FRM)
Terminator Board
Interconnect Board
High Voltage Board
(add child pages with specific documents below)
The manufacture's calibration for these flow meters is shown here. It is nonlinear as you can see. So, going from ~40 mm to >65 mm more than doubles the flow rate: it is well over 100 cc/min.
Scale reading Flow Rate
(mm) (cc/min)
---------------------- --------------
65 104.0
60 91.5
55 79.5
50 69.0
45 59.2
40 49.5
35 41.7
30 34.2
25 27.7
20 22.0
15 17.5
10 13.4
5 10.0
Regards,
Don
Fig 1 HOW GEM foil works
Fig 2 Filed lines through GEM foil
Fig 3 triple GEM HV
Fig 4 FOM for AL vs. lepton eta & PT, RHICBOS, GSRV-STD
Fig 5,Graphics courtesy of Tai Sakuma, MIT
Fig 6,Graphics courtesy of Jim Kelsey, MIT
more plots like this is here PPT , PDF presented at BNL, May 16, 2008.
Fig 7. Assembled setup for mechanical and electrical test for Quadrant STAR/FQT/FEE
See other (large) photos below
Fig 8. Y2008, full STAR
Fig 9. UPGR16, full STAR
Fig 10. UPGR16,inner trackers , side view
Fig 10. UPGR16,inner trackers , side view
Fig 11. Full size GEM foil , December 2008
Fig 12. APV bonding, Januar 2009
Fig 13a-d. Photos of the APV-on-a-cable test setup for FGT (full size in attachments at the bottom), May 2009.
docs.google.com/spreadsheet/ccc
How to access database:
Electronic ID Formula:
if ( apv > 11 ) apv = apv - 2;
ElectId = channel + 128 * ( apv + 20 * (arm + 6 * ( rdo - 1) ) );
General Database Info (from Dmitry)
1. For real .daq files processing, timestamp is taken from event - it cannot be set by user. For example, if event timestamp is XYZ, then db maker will get db entries with time validity spanning from [XYZ - some_time_1] to [XYZ + some_time_2] where some_time1 is the beginTime of the db entry received, and some_time_2 is the beginTime of the next db entry with beginTime > XYZ.
2. DBV option (in chain) only freezes validity range, which means "do not consider calibrations uploaded later than DBVXXYYZZ". This allows to reproduce any past conditions. So, if you set DBV to today's date, you will get latest calibration dataset. If you set it to some past date (e.g. 2010-01-01) then you will get only those datasets which were uploaded before 2010-01-01. So, tables are read using both beginTime and entryTime..
See Renee's instructions how to create and upload pedestals/status attached
-----------------
I had hoped to write this tutoral once all code was in CVS and I had automated all of the loading and writing scripts. Unfortunately these conditions are only partially fullfilled at this time, so this procedure describes how to make pedestal and status files needed to load to the database:
Software for computing (making), reading (from file or DB) and plotting pedistals has been written. The DB functionality is not fully implemented as of Jan 10, 2012.
The current code for reading and writing pedistals is contained in the following files
$CVSROOT/offline/StFgtDevel/StRoot/StFgtPedMaker/StFgtPedMaker.h $CVSROOT/offline/StFgtDevel/StRoot/StFgtPedMaker/StFgtPedMaker.cxx $CVSROOT/offline/StFgtDevel/StRoot/StFgtPedMaker/StFgtPedReader.h $CVSROOT/offline/StFgtDevel/StRoot/StFgtPedMaker/StFgtPedReader.cxx
An example of using the pedistal maker is in the file
$CVSROOT/offline/StFgtDevel/StRoot/StFgtPedMaker/macro/makeCosmicPeds.C
An example of using the pedistal reader is in the file
$CVSROOT/offline/StFgtDevel/StRoot/StFgtPool/StFgtPedPlotter/macro/plotPedsFromFile.C
An auxillary class to make a nice plot of pedistals is found in the files
$CVSROOT/offline/StFgtDevel/StRoot/StFgtPool/StFgtPedPlotter/StFgtPedPlotter.h $CVSROOT/offline/StFgtDevel/StRoot/StFgtPool/StFgtPedPlotter/StFgtPedPlotter.cxx
After the software review, it is expected to move these files to StRoot instead of offline/StFgtDevel/StRoot
The StFgtPedMaker is designed to use the FGT online containers in StEvent. The pedistals are the mean ADC value over all events processed by the chain, while the "RMS" is actually the standard deviation. Running sums are computed in the StFgtPedMaker::Make function, and the final values are computed in ::Finish member function. The values can then be written to a file, which contains four columns: (1) geoId of the strip (2) timebin (3) pedistal, i.e. mean ADC (4) RMS, i.e. st. dev.
The pedistal maker has the following user functions to modify the options:
void setToSaveToFile( const Char_t* filename ); void setToSaveToDb( Bool_t doIt = 1 ); void setTimeBinMask( Short_t mask = 0xFF );
To save to file, one uses the "setToSaveToFile" function and passes the filename to which the information should be saved. The "setToSaveToDb" function is not yet implemented. It was decided not to allow this functionality in this class, but rather have a decidated macro to upload a text file generated by this class into the DB. The time bin mask is set via the "setTimeBinMask" function. All time bins which are flagged "false" in the mask will be ignored. Note: time bin 0x01 is the 0th time bin, 0x10 is the 4th time bin, etc.
The status of the strips (e.g. dead, broken, and/or hot strips) is not considered in making the pedistals. All pedistals are computed for the time bins specified in the time bin mask. As status of the strips is given by the StFgtStatusMaker/Reader, it is expected that the code querying the StFgtPedReader for a pedistal will also query the StFgtStatusReader for a status of the strip, and then choose to act accordingly. In this manner, the status does not have to be computed before computing the pedistals, but instead should be computed before using the pedistal information.
It was anticipated that all calls for pedistals, in all software, would use the StFgtPedReader. The StFgtPedReader initially either loads the pedistals from file, or from the database, and holds them in an associative array, allowing both sparse data and for fast look ups. In future versions, one could change the implimentation to a static array, if one desired faster processing but a larger memory imprint. The code has the following accessor function, to read the time bine for a given geoId and time bin:
// accessor: input is geoId and timebin, output is ped and // st. dev. (err). Returns error if pedistal not found for given geoId and timebin Int_t getPed( Int_t geoId, Int_t timebin, Float_t& ped, Float_t& err ) const;
One can also set a time bin mask via
void setTimeBinMask( Short_t mask = 0xFF );
Time bins with bits set to false will be ignored. The fewer time bins loaded, the faster the initial load and the faster the look up time for each individual geoId afterwards.
The DB interface still needs to be programmed as of Jan 10, 2012.
This produces a nice plot of the pedistals for a given quadrant (10 APVs). The procedure is straight forward. See the macro and the code for an example of how this is done. Note: the ped. plotter gives an example of how to use the ped. reader.
Usually 2,000 are used to compute pedistals. The amount of time taken by the StFgtPedReader/Maker is significantly less than the amount of time used by the RawMaker to create the FGT containers in the StEvent and read the DAQ file from disk, and therefore can be considered negligible for the present.
An example pedistal file is attached. This file is from the cosmic test stand, when quadrants 008, 018, 007 were on the top, middle, and bottom possition, respectively. Plots of typical pedistal RMS can be found on page 1 of the QA plots produced during the cosmic test stand. The base directory is http://www.star.bnl.gov/protected/spin/sgliske/fgtCosmicQA/, from which you can then select a quadrant, and then select a .pdf file. The files are named via the quandrant and the time the data was taken.
Random notes from email exchanges:
A bfc that produces muDsts from simulation files looks like this
root4star -b bfc.C'(10,"MakeEvent,ITTF,NoSsdIt,NoSvtIt,Idst,VFPPVnoCTB,logger,-EventQA,-dstout,tags,Tree,EvOut,analysis,dEdxY2,IdTruth,useInTracker,-hitfilt,tpcDB,TpcHitMover,TpxClu,McAna,fzin,y2012,tpcrs,geant,geantout,beamLine,eemcDb,McEvOut,bigbig,emcY2,EEfs,bbcSim,ctf,-CMuDST,sdt20120501.060500","pp200_QCDprodMBc.fzd")' -q > & Log1
There is an fzd file in avossen/tmp/4jason/
The code is available at
StRoot/StFgtSimulator/
and should also be available as
The bfc to run it is in StRoot/StFgtSimulator/macros/bfc.C
You can run it from the StFgtDevel dir with the following
command line:
%root4star -b
StRoot/StFgtSimulator/macros/bfc.C'(10,"MakeEvent,ITTF,NoSsdIt,NoSvtIt,Idst,VFPPVnoCTB,\
logger,-EventQA,-dstout,tags,Tree,EvOut,analysis,dEdxY2,\
IdTruth,useInTracker,-hitfilt,tpcDB,TpcHitMover,TpxClu,\
McAna,fzin,y2012,tpcrs,geant,geantout,beamLine,eemcDb,\
McEvOut,bigbig,emcY2,EEfs,bbcSim,ctf,-CMuDST","pp200_QCDprodMBc.fzd")'
Status bits are failure states, i.e. status of 0 is good, anything else is bad. Strip status bits are defined as
Note, for bit 5, all strips are set to have this bit fail if more than the threshold number of strips on this APV failed the tests corresponding to bits 1-3.
See
drupal.star.bnl.gov/STAR/event/2012/12/07/fgt-weekly-meeting-0/fgt-run13-daq-cable-mapping
Getting started with plots for the FGT
(some old documentation on how to read MuDSTs: drupal.star.bnl.gov/STAR/blog/avossen/2012/apr/26/how-read-mudsts)
Prepare your libraries
If you're brand new or starting fresh directory for FGT, you'll need to check out some files... This is a list of all the offline FGT software you're likely to need for whatever it is you're working on...
> mkdir mydir
> cd mydir
> cvs co StRoot/RTS
> cvs co StRoot/St_base
> cvs co StRoot/StEvent
> cvs co StRoot/StFgtA2CMaker
> cvs co StRoot/StFgtClusterMaker
> cvs co StRoot/StFgtDbMaker
> cvs co StRoot/StFgtPool
> cvs co StRoot/StFgtRawMaker
> cvs co offline/StFgtDevel/StRoot/StMuDSTMaker
> ln -s offline/StFgtDevel/StRoot/StFgtMuDSTMaker/ StRoot/StFgtMuDSTMaker
The last step is necessary since StFgtMuDSTMaker is not yet in devel.
Make sure you are in the proper STAR version (you want "development") and compile...
> starver dev
> cons
Pick your data
After your libraries installed correctly, pick a daq file for your FGT studies... (If you're using MuDST files this will be different..)
> ls /star/data03/daq/2012/xxx/13xxxyyy
where 13xxxyyy is the run number you want. (If the run number you want isn't there, restore the daq files yourself or ask somebody to do it.)
Before running over data, make sure to run klog to ensure you get a token to communicate with the database..
> klog
>For MuDSTFiles the corresponding #define directive in StFgtPool/StFgtClusterTools/StFgtGeneralBase.h has to be set.
Run over the data
To fill all the plots you want, you'll need to run this command (when sitting in mydir)...
> cd mydir
> root4star -b -q StRoot/StFgtPool/StFgtClusterTools/macros/agvEffs.C'("/star/data03/daq/2012/131/13173068p_rf/st_physics_13173068_raw_202001.root",10,10000,2)' > & output.txt
The above command will attempt to run over 10,000 events from the example daq file, using disc 2 as the disc that is removed for efficiency calculations. Piping the output to file is necessary in order to cut down on running time. On average, 10,000 events takes ~45 minutes as long as you use an output file.
Look at the plots
The agvEffs.C macro will output some .root files...
-clusterEff.root
-clusterPics.root contains visual "pictures" of the first 1000 clusters found in the daq file.
-pulses.root counts pulses in the electronics etc
-signalShapes.root contains a whole heck of a lot of plots... To see exactly all that is put into signalShapes.root, take a look at StFgtClusterTools/StFgtGenAVEMaker.cxx
There are some friendly macros to help you pull out the plots you want in an organized way. Run these guys to output a whole ton of .png files. A few examples are...
> root4star -b -q StRoot/StFgtPool/StFgtClusterTools/macros/saveSignalChar.C'("signalShapes.root")' //this will output histograms per quadrant
> root4star -b -q StRoot/StFgtPool/StFgtClusterTools/macros/saveSignalCharAPV.C'("signalShapes.root")' //this will output histograms per APV
> root4star -b -q StRoot/StFgtPool/StFgtClusterTools/macros/saveClusterSizes.C'("signalShapes.root")' //this will output cluster size histograms per quadrant
For now it's been most convenient to just dump the .png files into your protected directory but hopefully something a little more elegant is on its way very soon...
Streamlining the process
Right now we have a shell script that pulls daq files name from a list and then runs over them one after the other, dumping the output .root files into a directory. Look around for things like "runChain.sh" and "l13173068.list" if you want to have a go at that.
> ./runChain.sh > & output.txt
Coming soon: pre-written xml job for STAR scheduler.
Available data sets
Most recent runs are located in http://www.star.bnl.gov/protected/spin/ezarndt/fgt/
Coming soon: plots better organized into a scroll-friendly format.
The online software uses the 'JPlot' framework:
> cvs co OnlTools/Jevp
> cvs co OnlTools/PDFUtil
> cvs co StRoot/RTS
> cvs co StRoot/StDaqLib
>cvs co StRoot/StEvent
The framework currently only compiles correctly with the 'pro' library version:
> starver pro
> cons
To run do:
> OnlTools/Jevp/launch fgtBuilder -file filename -pdf outputfilename.pdf
Jevp instructions can be found in
OnlTools/Jevp/readme.txt
The fgt specific code is in OnlTools/Jevp/StJevpBuilders/fgtBuilder.{h,cxx}
At the moment FGTEventDisplay incorporates much of the code that we've been using to generate plots, and allows the viewing of individual events. It's certainly not perfect (and it will likely be replaced at some point in the near future), but since it contains this functionality, I thought I might give a brief overview of what it can currently do and how to use it.
Here's what it can do:
* Calculate and display pedestals
Currently, pedestals are calculated from the first 1000 events in a file. These pedestals are only calculated the first time a daq file is viewed using the FGTEventDisplay, when the APV range is changed, and when you force the pedestals to be recalculated. Otherwise, it saves the pedestals to a file in the FGTEventDisplay directory.
When the pedestals are displayed, they are displayed as ADC response per channel. Three graphs are shown with error bars, at 1, 2 and 3 sigmas. Many of the algorithms in the code use the three sigma cutoff when accepting an ADC response for use.
Figure 1: Example pedestal plot
* Generate Radio Hits graphs
The code can generate and save radio hits plots, similar to those that I have been posting to track down the APV mapping problem. The graphs that are generated are just raw 2-D histograms that are then saved to root files. The processing done to improve the appearance of those graphs as well as applying the device boundaries are actually done by a utility macro included with FGTEventDisplay. This macro is called Display.C and is in the same directory as FGTEventDisplay.
Note that all 7 time bins are accumulated by this code separately, and all 7 time bins are saved as separate histograms to the root file.
There are two types of radio hits graphs that are generated. The first plots only the maximum hits. The algorithm finds the maximum value for each event that is above the pedestal 3*sigma and then fills that location in the histogram/radio plot. The second algorithm finds all values that exceed 3*sigma above pedestal and then fills those locations in the histogram/radio plot. These two types of graphs are saved in separate root files.
Figure 2: Example max hits plot
Figure 3: Example all r/phi matches plot
* Generate ADC Response graphs
This code generates and saves per-phi, per-r, and per-channel ADC response plots. Once again, these are just 2-D histograms that are then saved to a root file, and processing to improve the appearance of these plots was done in Display.C. The algorithm selects all ADC responses greater than 3-sigma over pedestal for each event. The channel number in this case is the APV number (offset so that all APV ranges start at 0) times 128 plus the actual channel number. Phi and R values are determined based on the mapping that is included with the FGTEventDisplay (this is located in fgt_mapping.txt). Once again, note that all 7 time bins are accumulated by this code separately, and all 7 time bins are saved as separate histograms to the root file.
Figure 4: Example ADC response vs channel plot
Figure 5: Example ADC response vs phi plot
Figure 6: Example ADC response vs r plot
* Generate Raw ADC Response graphs
This code generates and saves per-phi, per-r, and per-channel ADC response plots, very similar to the above, but it does not apply pedestal subtraction or thresholds. The channel number is still the APV number (offset so that all APV ranges start at 0) times 128 plus the actual channel number. Phi and R values are determined based on the mapping that is included with the FGTEventDisplay (this is located in fgt_mapping.txt). Once again, note that all 7 time bins are accumulated by this code separately, and all 7 time bins are saved as separate histograms to the root file.
Figure 7: Example raw ADC response vs channel plot
Figure 8: Example raw ADC response vs phi plot
Figure 9: Example raw ADC response vs r plot
* Display individual events
FGTEventDisplay allows you to iterate both forward and (slowly) backwards through individual events in a daq file, as well as jump (slowly) to individual events. For each event, at least three graphs are shown, possibly four. The three that are always shown are ADC response versus R, ADC response versus Phi, and ADC response versus channel (using the same channel calculation method and mapping as described earlier).
The fourth graph will only display if the values for the current event are found that exceed 3*sigma over pedestal. It shows all possible hit locations in R and Phi for these values. Currently this is not a radio plot, but this may change in the future for clarity.
The time bin selected for display here is always the fourth time bin.
Figure 10: Example default event display plot
Anselm's clustering code is currently in a developmental version of FGTEventDisplay. We are working on incorporating a correction for common mode noise, relative R/Phi gains, and gain matching into this clustering code.
Here are instructions for downloading, compiling, and using FGTEventDisplay:
To download:
FGTEventDisplay is currently stored in a googlecode SVN repository. In order to use this repository, you have to set up your svn proxy properly so that you can contact the googlecode.com (this has already been done on fgt-ops). Probably the easiest way to do this is to attempt to download the code first by issuing the command:
svn co https://fgt-daq-reader.googlecode.com/svn/trunk/FGTEventDisplay FGTEventDisplay
This will almost certainly fail, but it should create the file ~/.subversion/servers. You will need to edit that file and by adding the following two lines to the end of the file:
http-proxy-host=proxy.sec.bnl.local
http-proxy-port=3128
Once that is done, try issuing the command again. This time it should work (let me know if it doesn't), and it should create a directory FGTEventDisplay containing all the program files. From then on you can just update that working copy to get updates by issuing the command
svn update
in the FGTEventDisplay directory. This should automatically merge changes into your files, without clobbering your own changes, although if there are conflicts you may have trouble.
If you want or need access to this repository, please send e-mail to Dr. Fatemi and let her know. At that point she'll probably ask me to add you, and I'll try and remember how to do that.
To compile:
Go into your FGTEventDisplay directory and issue the command:
make
Compilation stuff should happen, and you should be left with an FGTEventDisplay executable.
Please note that you should NOT use Rts_Example.sh to compile. I can't guarantee that it will work, and it is included in the repository only for historical reasons (because, historically, we've been too lazy to remove it).
To run:
Go into your FGTEventDisplay directory (this is IMPORTANT. . . the code will not run from another directory) and issue the command:
./FGTEventDisplay <location of DAQ file>
Replacing <location of DAQ file> with the actual path to a DAQ file.
This will start the program. The code will either automatically generate or load pedestals, depending on whether or not they have already been calculated by some previous run.
Then the program will show the main text menu. The menu lists most of your options, and most of them should be pretty straight forward.
However, there are a few things that should be mentioned. First, by default, the code will assume that you are using the APV range 17 through 21. If you are using a different range, you need to set that difference in the program options, and currently the software only supports ranges 17 through 21 and 12 through 16. To get to options, just type "o" at the main menu. Once there, type "a" to change the APV range. then press "q" to return to the main menu. Doing this will now AUTOMATICALLY force pedestal recalculation, so at this point you should be able to use the code normally.
Also, in options you can tell the program to display bar graphs when displaying events (instead of scatter plots), and change the marker style in the scatter plots. These ONLY effect the event display.
Figure 11: Example default event display with bars
The event display plots do not currently allow any user interaction. This is unfortunate, and I'm planning on fixing it in the future, but right now nearly all x-windows events are ignored by that window, so resizing and clicking and even moving it off screen (for some window managers) will not work as expected.
The daq reader does not have a mechanism for iterating backwards, or a mechanism for jumping to an arbitrary event. As such, iterating backwards (using "h" or "k") may be very, very slow, as the program has to iterate forwards from the beginning of the daq file to the previous event. Similarly, though I have tried to make it as efficient as possible, jumping to an event may be very slow (although, jumping to an event *forward* of your current position in the file will start from your current position, so it should be more efficient).
When jumping to an event directly, you should use the event number that is displayed by the program in the main menu as you are iterating through the daq file. That event number should appear right above the command prompt.
Finally, many of the plots above are colorful and contoured. These are not the raw images that the FGTEventDisplay will produce. With the exception of the individual event display and the pedestal display, FGTEventDisplay will produce root files containing histograms. Generating the plot for these histograms must be done separately. A macro, Display.C, is included with FGTEventDisplay that can be used to generate these nice, colorful plots, however it currently requires modification to function with every possible root file and contained histogram.
Dave's Web page Argonne
Here is what we know about TPC resistor chain in IFC positioned at 106 deg in phi.
As seen from the East toward West:
BAD drawing:
Good drawing:
As seen from the West toward East:
Any child pages belonging here is a trash.
Note only the owner can recycle them by attaching to a new mother-page and changing the title,URL, and content.
Jan
this is my link to my previous blog
this age can be used for some testes
Bhla Bhla
Deleted documents.