The STAR experiment

 

 

 

NLO calculations for di-jet asymmetries using latest pol

Trigger-bias-discussion-during-the-STAR-colloboration-meeting-January-2016

Slides I presented during the discusion: 

Slides
Slides2

E /p distribution plots for mometum slices:

BHT1->didFire()==>tower
BHT3->didFire()     ===>  2x2cluster ,  tower
BHT3->didFire() && ! trackAboveTH(3) ===>   tower
BHT3->didFire() && ! trackAboveTH(3) && !(BHT1->didFire() && trackAboveTH(1))  ===>  tower

---

Electron-Analysis-Cuts

• Vertex Rank > 1e6
• |vertex-Z| < 30 cm
• Track momentum > 1.5 GeV/c 
• towerStatus = 1
• mipStatus = 1
• Track nHits > 25
• Track must enter and exit the same tower
• (ADC-ped) > 2.5 ped RMS
• 3.5e-6 < dE/dX < 5e-6
•  nSigmaPion > 3 
• -1 < nSigmaPion < 2

Comments from the discussion :

Up on the discussion, (Renee, scoutt, Jeff) everyone claim that the shape of the tower enrgy distribution for BHT3 trigger is not understananble.  The bump around ~5 GeV is not acceptable for BHT3 triggerd events. So Jeff suggested to obtain the same distribution with out any track cuts:

---

****************************************************************************************************************************************************************
Jeff's response on slides2 : 

The conclusion that you make about BHT1 events are unintentionally mixed in with BHT3 does not seem possible to me.   BHT3 was unprescaled.  Therefore, any event that has a high tower > BHT3 is by definition a BHT3 event, and can not be "incorrectly added to the sample".   There are two possible effects that could lead to a true problem:

    1.  If you find BHT3 events that DO NOT have a tower > BHT3
    2.  If you have doubly counted events.

Point #1 has never been shown but would be easy to check.   Point #2 could happen due to straight out bugs in the analysis code.   It could also happen if you are including multiple data streams in your analysis but this is well known not to be allowed...

Beyond this, I have serious issues with many of the plots.   For example, on page 4 the plots are labeled, "Energy distribution for a track matched to a tower above BHT3".   By definition, the smallest energy in that distribution has to be BHT3.   But there is actually a broad peak kicking in at BHT1.  Either I am missing something very basic, or else there is something horribly and obviously wrong with the plot.  The energy matching used in the cut of events is different from the energy calculation in the plot.   If towers that have an energy > BHT3 show up on these plots having energy ~BTH1 on this plot, then I suspect the thing is happening on the other plots as well.

I don't know what to do about the calibration problems you are having, but if the question you are trying to address is whether or not the BHT1 is corrupting the BHT3 sample the simple thing to plot is the bare HT spectrum for these two triggers.  No tracks, no cuts, nothing.   The distributions for the two triggers should look nearly the same with the peaks at different energies.    If you see a sharp peak at BHT1 distribution superimposed on the BHT3 spectrum them there is an obvious problem!

---

Scott's response on slides2 : 
for each event, check if it satisfied the BHT3->didFire condition.  If so, loop through all the barrel towers; whenever you find one with an energy above some threshold (maybe 0.5 GeV), increment the histogram in that energy bin.  No tests or loops based on tracks, no requirement of tracks matching to towers (or not), and you can even give up the vertex cuts.  This should yield a very smooth, min-bias-like spectrum, until you get close to the BHT3 threshold, where there should be a notable enhancement in the yield.

---

Based on suggestions, I read MuDsts again to get Tower_ADC values and Tower_pedestal valuse for each triggeroptions at the event elevel. No tracks , vertex info .

BHT3->
if(BHT3->didFire()){
for(Int_t i=0< i<4800;++i)
Tower_energy=[ mEvent->Tower_ADC(i)- mEvent->Tower_Ped(i)] * Tower_MIPgain(i)
h->Fill (Tower_energy)}},  distribution

 

lead copper rules and proper measuring of water samples -inspired by flint and the guidelines from bnl on how to handle water when staying in the efficiencies/apartments.

 

 

Time	Talk	Presenter
12:00	Run14 st_physics data reproduction request and VF parameter test ( 00:20 ) 0 files	Guannan/Mustafa/Xin
12:20	Run14 vertex resolution ( 00:20 ) 1 file	Bingchu Huang

Time	Talk	Presenter
12:00	Data vs. Simulation - DCA studies (slide 14 - 23) ( 00:20 ) 1 file	Michael L.
12:20	Vertex Resolution data-MC comparison ( 00:20 ) 1 file	Bingchu Huang

Time	Talk	Presenter
11:00	quick/preliminary look FastOffline run16 ( 00:20 ) 1 file	Jonathan
11:00	PXL fast simulation ( 00:20 ) 1 file	Kunsu OH
11:20	HFT Matching Simu vs. Data ( 00:20 ) 1 file	Michael Lomnitz

Time	Talk	Presenter
11:00	HFT_MatchingRatio_FastofflineQA ( 00:20 ) 1 file	Zaochen Ye

Time	Talk	Presenter
12:00	HFT Ratio Data vs Simu ( 00:20 ) 1 file	Michael
12:20	QA For firmware check production ( 00:20 ) 0 files
12:40	HFT_MatchingRatio_update ( 00:20 ) 1 file
13:00	gamma tomography with HFT ( 00:20 ) 2 files	Kunsu OH

Time	Talk	Presenter
11:00	SSD hit resolution [final] ( 00:20 ) 1 file	jonathan
11:20	PxlRawHitMaker Bug/Fix and Impact on Run14 Data ( 00:20 ) 1 file

Time	Talk	Presenter
11:00	Run15 tracking update ( 00:20 ) 1 file	Hao
11:20	SSD Run16 performance summary ( 00:20 ) 1 file	Long/Jim
11:40	Run16 HLT Trigger for MB events ( 00:10 ) 0 files	Xin Dong
11:50	SSD items ( 00:20 ) 1 file	jonathan
12:10	p+p VF study ( 00:20 ) 2 files	Liang He

Time	Talk	Presenter
11:00	HFT Tracking issue in Run15 pp ( 00:20 ) 0 files	Zaochen
11:20	SST hit errors update ( 00:20 ) 1 file	Jonathan