Getting Started

The files which are used for this are from L2 and they're stored on the online "starp" network.  You will need to request an account on those machines.  Following the instructions here, you should request an account on the "onlldap.starp.bnl.gov" host with the "onlmon" username (you should also request an account with your username if you can).  After your request is approved you can log in with the commands shown here:

It is also necessary to set up the proper directory structure and files. 

Now you should go through l2status.py and indexWrite.py and change each instance of the year and species/energy to the current ones.  Also there are some lines in l2status.py which refer to runnumbers, these should be changed as well.  I also like to start fresh with the QA every year, and comment out the lines which hard-code bad channels.  The variable "minimumMedianCounts" should be changed to a value appropriate for the species/energy that is being run. 

Generating Status/Pedestal Tables with L2

In each run, as part of the L2 algorithm, a 2D histogram is filled with (channel# + 160*crate#) vs. (ADC-l2ped+20).  This histogram is named "h22" and is contained within the root files located here: /ldaphome/onlmon/L2algo2013/l2ped/output/   The python macro named "l2status.py" takes this histogram as an input, and generates individual 1D histograms of the ADC spectra for every tower.  These histograms are analyzed to determine the tower status, the ADC value of the pedestal peak, and the sigma of the pedestal peak.  See below for the status code definitions and examples. 

To execute the code do:

You can monitor the progress of the script by looking at l2status.log (for example, by opening another terminal and doing 'tail l2status.log -n50' periodically).  As the script progresses you will see the summary pdf files posted to the webpage http://online.star.bnl.gov/emcStatus/pp500/ (for the relevant species/energy), the status and pedestal tables will be written as text files into db/bemc and db/eemc, the actual root histograms will be written into the histoFiles directory, and the results will be written into the database file l2status2013.sqlite3. The statuses and pedestals should be generated once for every good fill.

In a perfect world you would run over the code over the entire dataset once and you would have the status tables which are then uploaded to the STAR database.  However, its usually not that simple.  There are often problems with a handful of channels that aren't caught by the status checking code, or some that are flagged as bad, but shouldn't be.  My suggestion would be to run the code over all the files first and then then we can use the information in the pdfs and in l2status2013.sqlite3 to isolate problem channels. Some of the parameters in the code you may need to tweak to improve the status tables, and some channels you may have to hard code as a bad status for a period of time.

If you want to clear everything and start fresh, you can do this: clean out the folders db/bemc/ and db/eemc/, remove the log file, remove runList.list, and do 'cp empty.sqlite3 l2status2013.sqlite3'

So as a first step, let l2status.py run for a while (it will take time, I often run it in screen so that I don't have to keep a terminal open).  You should kill it manually (ctrl+c) when it reaches the end of the runs that you want to look at.  When you start it running again it should just pick up (approximately) where it left off. 

The code only computes status/pedestal tables if there are enough hits to get good-quality calibrations.  The median number of hits above the pedestal must surpass some threshold (minimumMedianHits) in a given fill; this parameter should be set to an appropriate value in l2status.py (not too high that we miss a lot of fills, and not too low that we don't get good calibrations -- there are some examples for appropriate values given in the code).  When the threshold is reached you will see some messages in the log file like

To evaluate the status of each BEMC tower, its ADC spectrum is tested for various features.  If a test fails, then a bit (or multiple bits) is flipped to indicate the nature of the problem with the tower.  It is possible for a tower to fail multiple tests and therefore have a status code which indicates multiple problems.  I show examples of towers which fail each of the basic tests and are therefore assigned specific status codes.  

Status Code Definitions

000 == channel does not exist or is masked in L2ped
001 == channel is good
002 == channel is either hot or cold (see bit 16)
004 == channel has a weird pedestal (see bit 32)
008 == channel has a stuck bit (see bits 64 and 128)
016 == if off, hot (10x as many hits); if on, cold tower (10x fewer hits)
032 == if off, pedestal mean is out of bounds; if on, pedestal width is too large/small
064 == bit stuck on
128 == bit stuck off
254 == identical channel

These codes can be seen by going to the EMC Status webpage and clicking on any of the Details pages. 

I show examples from a heavy ion (U+U) run where the numbers of counts in the histograms are higher than in p+p, for clarity.  All these plots come from the pdf here. 

status = 1 (normal ADC spectrum)

status = 0  (channel is masked out)
Note: MOST of the channels marked with a zero status are (or were) hot channels that were caught and masked out. 

status = 2 (hot channel)
Hot channels look like the above plot, and most of them are caught in realtime and masked out, and thus assigned a status of zero.  It is unusual to actually catch a really hot channel after the fact. 

status = 18 = 2+16 (cold channel)

status = 4 or 36 (bad pedestal)
This status catches a range of problems, from weird-looking spectra (like shown here), to wide pedestals, etc.

status = 72 = 8+64 (stuck bit - on)

status = 136 = 8+128 (stuck bit - off)

status = 254 (identical channels)