Need one volunteer per week of spin running

see 2009: http://www.star.bnl.gov/protected/spin/sowinski/runQC_2009/

Please send me a mail if you are willing to take a shift.

 

Begin spin running:

Beginning Feb - Mid April

Feb 1-8:  Hal Spinka

Feb. 8 - 15: Brian Page

Feb 15- 22: Rob Fersch

Feb 22 - March 1: Grant Webb

March 1 - March 8: Justin Stevens

March 8 - March 15: Pibero Djawotho

March 15 - March 22: Hal Spinka/Liaoyuan Huo

March 22 - March 29: Qinghua Xu

March 29 ---- end of spin run: Stephen Trentalange

 

 

I also edited the Q&A scripts to add new triggers and some requests from Jan:

One example is here:

www.star.bnl.gov/protected/spin/vossen/testSummaryJan25.csv

if you have any special requests, please tell me

 

In the directory:

www.star.bnl.gov/protected/spin/vossen/

you'll also find csv files in which the status codes have to be entered

In order to faciliate the procedure, I ask you to fill in your status codes for the week at the end of the run, when I produce the lists for the runs

that have to be sorted in primary and secondary priority lists. During datataking you can keep the notes in your own format.

I will give you a csv for your period and ask you to replace the ?? field and add comments in the end. One way to do this, is to import it into excel.

 

Status Codes: 

These are the ones used in 2009. Will add new ones as needed:

 

Use as many as needed separated by one space, NO COMMAs. They are all 2 characters. The first is upper case and represents a system, the 2nd is lower case and a status. Don't change case!

?? - no one checked this run in eLog/ShiftLog/P-plot. I start with this in my file. For some few runs you may not be able to get any information on it from usual sources. Then leave this as the key.
Ok - all seems to be reasonable for this run
Xx - never use this run for any analysis. If runs are marked "junk","bad" or questionable by shiftleader, use your judgement as to whether these are analyzable at least for some detector and you wish to over rule them. If in doubt go with the advice of the shift leader and operator.

Cm - minor TPC problems
Cx - TPC not useable but run ok for calo only analyses

Ec - endcap tower crate(s) was(were) bad but most were working
Er - endcap data corruption few-few 100 events
Ex - Endcap towers unusable, e.g. all corrupted or off
Eh - anything wrong with EEMC high tower trigger
Ej - anything wrong with EEMC jet patch trigger

Mb - EEMC MAPMT box was bad e.g. more than 30% corruption or off
Mx - EEMC MAPMTs not usuble this run
Ms - EEMC MAPMTs had signals below ped - typical corruption early in run 9

Bc - any Barrel tower crate was bad or off but most working
Bx - Barrel towers unusable, e.g. all corrupted or off
Bh - anything wrong with BEMC high tower trigger
Bj - anything wrong with BEMC jet patch trigger

Gc - any FMS tower crate was bad or off but most working
Gx - FMS towers unusable, e.g. all corrupted or off
Gh - anything wrong with FMS high tower trigger
Gj - anything wrong with FMS jet patch trigger

Sc - Barrel SMD crate bad or off
Sx - Barrel SMD system unusable

Pc - Barrel preshower crate bad or off
Px - Barrel preshower system unusable

Fc - ToF problems for subset of detectors
Fx - ToF detector unusable

Db - Run stopped due to BEMC troubles
De - Run stopped due to EEMC troubles

Df - run stopped due to FMS troubles
Dg - anything wrong with other STAR triggers
Dt - Run stopped due to TPC problems

Dm - Run stopped due to Magnet problems
Do - Run stopped due to other detectors with problems e.g. ToF, SSD
Dq - run died due to daq crash

Qc - data taken during polarization measurement
Qb - excessive beam background reported in shift logs. Note quantitative measures like min/max in endcap jet patches and BBC bgs are best collected via scripts.
Qx - bunch crossing or spin pattern problems

Tr - trigger rate anamolies for small part of run as seen in the rate plots in the RunLog. For example the rate goes to 0 during run or the rate goes high (polarimeter target in?).

Other advice:
1) Don't use a problem code for a detector if it is out of the run but there is no indication it has a problem. The data base will be searched and the list of detectors in a run added to the spread sheet by a script. If it is out and known bad, from shift log comment etc., then try to include the appropriate error code.
2) Not all information will be available for each run. Feel free to interpolate as needed. For example you may have Panitkin plots for a run then a few without and then the plots again. If the same thing is wrong in both sets of plots and there is nothing in shift logs or logbooks to indicate differently you probably want to conclude the problem persisted through the runs w/o Panitkin plots. Again it is a judgement call. Would you want to analyze those runs for that detector or are you convinced you would be wasting your time.
3) Please use the comment field to explain interpolations, assumptions, reasons for markings etc.
4) If no other code is needed use the Ok code! This will indicate that someone really looked at it and gave their stamp of approval.