The STAR experiment

Recently, we have made changes to the StJetMaker and StSpinPool Directories, which will allow the user to determine the underlying event using two different methods.

 

 

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.