Detector Sub-systems

Welcome to the STAR sub-system page. The menu displays all major sub-systems in the STAR setup.

Those pages are used for keeping documentation and information about the subsystems as well as some operational procedures, drawing, pictures and for detector sub-systems calibration procedures and result of studies as well.

Also consult the STAR internal reviews for more information.



The STAR Barrel Electromagnetic Calorimeter

BEMC Detector Operator Manual

Authored by O. Tsai, 04/13/2006 (updated 02/02/2011)

You will be operating three detectors:

BTOW Barrel Electromagnetic Calorimeter
BSMD Barrel Shower Maximum Detector 
BPSD Barrel Preshower Detector

All three detectors are delicate instruments and require careful and precise operation.

It is critical to consult and follow the “STAR DETECTOR STATES FOR RUN 11
and “Detector Readiness Checklist”  for instructions.

Rule 1: If you have a concern of what you are going to do with any of these detectors please don’t hesitate to ask people around you in the control room or call experts to get help or explanations.

This manual will tell you:

  1. how to turn On/Off  low and high voltages for  all three detectors.
  2. how to prepare BTOW for “Physics”.
  3. how to recover from a PMT HV Trip.
  4. how to deal with common problems.

First, familiarize yourself with the environment of the control room. This is a picture of the four terminal windows which you will be using to operate the BEMC systems.  For run 11, Terminal 4 is not in use.  Terminal 0 (not shown) is on the left side of terminal 1/


(clicking on a link will take you directly to that section in the manual)

0 - (on

BEMC Main Control Window

1 - (on
BEMC PMT Low Voltage Power Supply Slow Control

2 - (on
BTOW HV Control

3 - (on
BSMD HV Control

0 - (on
BPSD HV Control
To login on any of these computers use the emc account with password (check the control room copy of the manual).

Terminal 0    “BEMC Main Control Window

Usually this terminal is logged on to
The list of tasks which you will be doing from this terminal is:

  1. Prepare BEMC detectors for Physics.
  2. Turning On/Off low voltages on FEEs.
  3. Turning On/Off BEMC crates.
  4. Resetting Radstone Boards (HDLC).
  5. Explain to experts during phone calls what you see on some of the terminals.

The screenshot above shows how the display on usually looks during the run. There are five windows open all the time. They are:

  1. “Barrel EMC Status”  - green.
  2. “BEMC MAIN CONTROL” – gray.
  3. “BARREL EMC CANBUS” – blue.
  4. Terminal on  (referred to as the ‘sc5 window’)
  5. Terminal from telnet scserv 9039 (referred to as ‘HDLC window’)

Prepare BEMC detectors for PHYSICS.

In normal operation this is a one click operation.

Click “Prepare for PHYSICS” button and in about 10 minutes “Barrel EMC Status” window will turn green and tell you that you are ready to run.  This window may look a little bit different from year to year depending trigger requirements for BTOW. 

However if this window turns red, then you will be requested to follow the suggested procedures which will popup on this window: simply click on these procedures to perform them. 

During “prepare for physics” you can monitor the messages on the sc5 window. This will tell you what the program is actually doing. For example, when you click  “Prepare for Physics” you will start a multi-step process which includes:

  1. Turning OFF FEEs on all SMD/PSD crates
  2. Programming TDC (Tower Data Collector, Crate 80)
  3. Reprogramming FPGAs on all BTOW crates
  4. Configuring all BTOW crates
  5. Configuring all SMD/PSD FEEs
  6. Loading pedestals on all BTOW crates
  7. Loading LUTs on all BTOW crates  (only for pp running)
  8. Checking BTOW crate configuration
  9. Checking SMD/PSD configuration
  10. Checking that pedestals were loaded correctly (optional)
  11. Checking that LUTs were loaded correctly (only for pp running)

Usually, you will not be asked to use any other buttons shown on this window. 


You can initiate all steps outlined above manually from the BEMC MAIN CONTROL window shown below, and do much more with the BEMC system. However, during normal operation you will not be asked to do that, except in cases when an expert on the phone might ask you to open some additional window from this panel and read back some parameters to diagnose a problem. 

You might be asked to:

  1. Turn OFF or ON  SMD/PSD FEE
  2. Open SMD/PSD panel and read voltages and currents on different SMD/PSD FEEs
  3. Open East or West panels to read voltages on some BTOW crates. (Click on Voltages)

 That will help experts to diagnose problems you are calling about.


From this window you can turn Off and On BEMC crates, read parameters of VME crates. This screenshot shows you this window during normal operation with all BEMC crates being ON.

  1. Crate 80 TDC  (Tower Data Collector and “Radstone boards”)
  2. Thirty crates for BTOW
  3. Eight crates for BSMD 
  4. Four crates for BPSD

The BTOW crates are powered in groups of three or four from a single power supply (PS) units.  The fragment below explains what you see.

Tower crates 0x10, 0x11, 0x12, 0x13 are all powered from a single power supply: PS 16.
Thus, by clicking the On and Off buttons you will be switching On/Off all four crates and the communication with PMT boxes which are associated with them. (see details  in Tower HV Control GUI description).

Sc5 and HDLC windows.

Two other terminal windows on “Terminal 0” are the so-called sc5, and HDLC windows.
These need to be open at all times. To open the sc3 terminal you will need to login as sysuser on  with password (check the control room copy of the manual).

From this sc5 terminal you run two programs. The first program is emc.tcl. If you need for some reason to restart “BEMC MAIN CONTROL” or “Barrel EMC Status” GUI you need to start emc.tcl: the alias for this is emc.  To kill this program use alias kill_emc.

To open “Barrel EMC Canbus” GUI use alias emc_canbus_noscale.
If you need to reboot canbus then:

  1. open sc5 window
  2. telnet scserv 9040
  3. press “Ctrl” and “x” keys
  4. wait while canbus reboots (~5 minutes or so)
  5. press “Ctrl” and “]” keys
  6. quit telnet session
  7. close sc5 window

To open an HDLC window, first you need to open an sc3 window and then telnet scserv 9039.
To close telnet session you need to press “Ctrl” and “]”, and then quit from telnet.
You may be asked by experts on the phone to reset the radstone boards. This is why you need this window open. There are two radstone boards and to reset them type:
radstoneReset 0 and radstoneReset 1


Terminal 1. “BEMC PMT Low Voltage Power Supply Slow Control

There is a change in operation procedures for Run7 for PMT HV Low Voltage power supplies.
There are two low voltage power supply PL512 units which powers PMT bases.
PL512 with IP address powers West side and PL512 with IP address powers East side of the detector. A single power supply feeds thirty PMT boxes.  The GUI for both PL512 should be open all time on one of the workspace on Terminal1.  A screenshot below shows GUI at normal conditions. Both PL512 should be ON all the time, except the case when power cycling of the PMT bases is required.
There are two buttons to turn power On and Off, as usual, wait 30 sec. after turning power supply Off before you will turn it On again. To start GUI use aliases bemc_west and bemc_east on

Terminal 2.       “BTOW HV Control

This is typical screen shot of the BTOW HV GUI during “Physics” running.

What is shown on this screen?

The top portion of the screen shows the status of the sixty BTOW PMT boxes.  In this color scheme green means OK, yellow means bad, gray means masked out. 

Buttons marked “PS1 ON” etc. allows to ramp slowly HV on the groups of the boxes. (PS1 ON will bring only boxes 32-39)
Buttons “EAST ON” and “WEST ON” allows to ramp up slowly entire east or west sides.

The fragment below explains what the numbers on this screen means.

Each green dot represent a single PMT box.  Label 0x10 tells you that signals from PMTs in boxes 1 and 2 feed to BTOW crate 0x10, boxes 3 and 4 feed crate 0x11 etc. You will need to know this correspondence to quickly recover from HV trips.


Turning ON HV on BTOW from scratch.
    1. BEMC PMT LV East and West should be ON.
    2. should be running.
    3. Made a slow ramp on the West Side by pressing button “WEST ON”
    4. Made a slow ramp on the East Side by pressing button “EAST ON”
Both steps 3 and 4 takes time, there is no audio or visual alarm to tell operators that HV was ramped – operators should observed progress in the window in the “Main Control” subpanel (see below).

Subpanel “Main Control

The HV on PMTs is usually ON during the Run.  The two buttons on top are for turning the HV On and OFF on all PMT boxes. The most frequently used button on this subpanel is “Re-Apply HV all PMT Boxes” which is usually used to recover after HV trip. Sometimes you will need to “Re-Apply HV current PMT box” if the system does not set the HV on all boxes cleanly.
The scale 0-60 shows you a progress report. The small icons below this scale tells you what PMT box and PMT were addressed or readout. 

Once you recover from a HV trip please pay attention to the small boxes labeled “Box”, “PMT”, and the speed at which the program reads the voltages on the PMTs.  This will tell you which box has “Timeout” problems and which power supply will need to be power cycled.

Subpanel “PMTs In a Selected Box”

This subpanel shows you the status of the PMTs in a given PMT box.

If you want to manually bring a single PMT box to the operational state by clicking on “Re-Apply HV current PMT box” on the Main Control subpanel you will need to specify which Box To Display on the panel first.

Subpanel “Alarm Control”

On the Alarm Control sub-panel the SOUND should be always ON, except for the case when you are recovering from a HV trip and wish to mute this annoying sound.

Shift personnel are asked to report HV trips in the shift log (type of trip, e.g. single box#, with or without timeout, massive trip, etc…)

Please don’t forget to switch this button back to the ON position after recovering from a trip.

The Main Alarm LED will switch color from green to red in case of an alarm.

HV trip with Timeout problem.

Typical situation – you hear a sound alarm indicating a HV trip. The auto-recovery program did not bring all PMT boxes to the operational state, e.g. some boxes will be shown in yellow.  First thing to check for the presence of a “Timeout” problem.

Look at the right upper corner of the GUI. If the field below “Timeouts” is blank then try to recover by re-applying  HV to all PMT boxes if the number of bad boxes more then two. If only one or two boxes is yellow then you can try to re-apply HV to the current PMT box.

If only one or two PMT bases timed out and HV tripped try to recover using above procedure. It is possible that one or two PMT bases will timed without causing trips of HV, then just continue running and made a note in the shift log about timed out PMT bases, experts will take care of this problem during the day.

But it is also a chance that a single timed out PMT base will trip lots of other PMT. In this case this bad PMT should be masked out. The procedure to do this is simple and can be found at the end of this manual. However, this is an expert operation and should only be performed after consulting with a BEMC expert.

However, if the field below “Timeouts” is filled with numbers (these are PMTs addresses) then you have a Timeout problem.  The procedure to recover is below:

  1. notify shift leader about this problem and tell him that it will take at least 20 min. to bring back BEMC for Physics running.
  2. Second, try to identify which PMT box has timeouts (usually it will be first box in yellow counting from 1 to 60). If you are not sure which box has the timeout problem then read all pmt boxes by clicking on corresponding button at the “Main Control” subpanel, and observe which box creates the problem. The box with timeout problem will be responding VERY slowly and will be clearly seen on the “Main Control” subpanel. At the same time, PMTs addresses will be appear in “Timeouts” white space to the right of the green control panel. 
  3. As soon as you find the box with the timeout problem, click “Cancel” on the “Main Control” subpanel and then click “OFF” – you will need to turn HV OFF on all PMTs.
  4. Wait till HV is shut OFF (all PMT Boxes).
  5. From Terminal 1, power cycle correspondent PL512 (Off, wait 30 sec., On).
  6. Now turn ON HV on PMT boxes from the “Main Control” subpanel. It will take about 2 to 3 minutes first to send desired voltages to all PMTs and then read them back – if the HV is set correctly.

It is possible that during step (6) one of the BEMC PMT LV on the East or West side will trip. In this case cancel ramp (press “Cancel” button on the “Main Control” subpanel).  Power cycle tripped BEMC PMT LV.  Proceed with the slow ramp.

However, if during step (6) you still get a “Timeout” problem then you will need to:

  1. Call experts

-------------------- Changes for Run10 operation procedures ----------------------------
To reduce the number of HV trips and associated efficiency losses during data taking we changed functionality of the PMT HV program. Namely, the HV read back time interval was changed from 15 minutes to 9999 hours, because it was found that most of the HV trips were self induced during HV read back. As a result efficiency of data taking was improved for the price of “conscious operation”. You can‟t relay anymore on absence of the HV Trip alarm as an indicator that HV on all PMTs is at nominal values. Instead shift crew should monitor associated online plots during data taking to be sure that HV was not tripped. In particular, for Run 10, shift crew should watch two plots “ADC Eta Vs Phi” and “Tower ADC” under the “BEMC Shift” tab. Example of missed HV trip on one of the PMT box during recent data taking is shown below.

The white gap in the upper left corner shows absence of hits in BTOW due to HV trip in one of the BTOW PMT Box. It is easy to find out which box tripped by looking at second plot.

The gap with missing hits on the second subpanel for crate 0x15 will tell you that one of the PMT box 11 or 12 was tripped (correspondence between BTOW crates ID and PMT boxes is shown in the BTOW HV GUI see the picture at the beginning of this section).
What to do if shift crew will notify you of HV trip?
The fastest way to recover is to identify what box tripped and then try to recover only this PMT box. In some case it will be impossible to do this, because you will be needed to powercycle LV power supply for PMT HV system (timeout problems).
This is typical scenario:
    1. Identify which PMT box(es) potentially tripped. (In the example above one PMT box 11 or 12 lost HV) to do that:
    1.1 From the BTOW HV GUI form subpanel “PMTs In a Selected Box” select needed box in the “Box To Display” window.
    1.2 From the BTOW HV GUI form subpanel “Main Control” press “Read HV current PMT Box”. (In the example above, detector operator         found that Box 11 was OK after reading HV, but Box 12 had timeout problems).
    1.3 Depending what will be result of (1.2) you may need to simply Re-Apply HV to current PMT box (no timeouts during step (1.2), or             you will need to resolve timeout problem.
There are additional duties for detector operators when STAR is not taking data for long period of time for any reasons. We need to keep HV On on all PMTs at all time. This will assure stable gains on PMTs. If for some reasons PMTs will be Off for long time (few hours) then it will be difficult to assure that the PMTs gain will not drift once we turn HV On again. Typical situation is APEX days, when STAR is not taking data for 12 hours or so. To check that HV is on shift will be asked to take a short run 1k events using “bemcHTtest” configuration. TRG+DAQ+BTOW only. Once the data will be taken use a link from the run log browser to “LO Trigger”. Check page 6.

All trigger patches should have some hits. In case of the HV trips you will see blank spots. 


Procedure to mask out single timeout PMT base.
Information you will need:
    1. In which PMT box timeout PMT base is located
    2. PMT (CW Base) to masked out.
In the timeout window the displayed number is CW Base ID this number need to be translated to PMT (CW Base).

From this sub panel you can find out which PMT in the affected PMT box need to be masked out. Scroll thru the
PMT (CW Base) top right small window and read out at the same time CW Base ID in the second from the bottom left window. (As shown, PMT (CW Base) 80 correspond to CW Base ID 1428).


Now, click “Configuration (expert only)” button on the Main Control panel.
 Another panel will open.
  From this panel click “CW Bases Configuration” button on the right bottom.
 Another panel will open.
  On this panel specify PMT BOX Number and then click on desired CW Base to be masked out. The color of the dot will change from           bright green to pale green. Then click OK button.
Panel will close after that.
  Click OK button on panel, this panle will close after that.

To check that you masked out right CW Base, Re-Apply HV to current PMT box. Once HV will be re-applied you will see masked CW base will be in the gray color as shown in the picture above (Bases 50, 59, 65 were masked out in the PMT box 4).


Terminal 3.       “BSMD HV Control

Your login name is emc, your password is __________________________

This screenshot shows how the window on the terminal3 will look when the HV is Off on the BSMD modules. There should be two open windows. One is a LabView GUI and another is a telnet session  SY1527 (CAEN HV Main Frame).

In normal operation it is a one click procedure to turn the HV On or OFF on the BSMD.

There is complete description of the BSMD HV program in a separate folder in this document.

Although, operation is very simple, attention should be made for audio alarms.
Do not mute the ALARM. Shift personnel are asked to report all BSMD trips in the shift log.


Terminal 0.       “BPSD HV Control

The BPSD (Barrel PreShower Detector) HV supplies are two Lecroy 1440 HV systems located on the second floor platform, racks 2C5.  Each 1440 is commanded by a 1445A controller which communicates via the telnet server on the second floor of the platform (SCSERV []).  The left supply uses port 9041 and the right supply uses port 9043.

The HV for BPRS should be On at all times.

From Run 10 for BPRS control we will be using new GUI. They will be open on one of the desktop on Terminal 0 ( Usually detector operators no need to take any actions regarding BPRS HV unless specifically requested by experts. The screen shots of of the new GUIs shown below.

To start the GUI use type bemc_lecroy and bemc_lecroy2.


A Green LED indicators tells you that HV is On and at desired level.
You can open subpanel for any slot to read actual values of HV. The screen shot is shown below.

Please Ignore empty current charts – it is normal.

Sometime, BEMC PSD GUI can turn white, due to intermittent problems with LeCroy crate controller. Simply make a log in the shift log and continue normal operation. It is likely HV is still On and at desired level. Experts not need to be called right away in this case.


Easy Troubles:

BEMC Main Control seems to be frozen, e.g. program doesn’t respond to operators requests.

Probable reason: RadStone cards in a “funny state” and needs to be reset

From Terminal 1 try to:

  1. kill_emc
  2. soft reboot first “Ctrl” + “x” from HDLC terminal window.
  3. start emc and see if problem solved

If the problem is still there then:

  1. kill_emc
  2. Power Cycle Crate 80
  3. start emc and see if problem solved

If problem is still there call experts

PL512 Information (Run 11 configuration)

There are two PL512 power supplies which provides power to the BEMC PMT boxes.  Both are located in the rack 2C2,  second floor.
The top unit (IP address serves West side of the detector.  The bottom unit (IP address serves East side of the detector.  The connection scheme is shown below

PMT Boxes
                      West Side                                East Side

1-8  9-16  17-22  23-30          32-39  40-47  48-53 54-31 
U 0,4,8 1,5,9  3,7,11  2,6,10    0,4,8  1,5,9  3,7,11  2,6,10 
U 0,1,2,3 +5 V              
U 4,5,6,7 -5 V              
U 8,9,10,11 +12 V               

Note ,  BEMC PMT Low Voltage Power Supply Slow Control channels enumerated from 1 to 12 in the Labview GUI.

Slow control for PL512 runs on EMC02,  login as emc, alias PMT_LV.
You will need to specify IP address.
Configuration (Experts Only)  password is ____________.
Log files will be created each time you will start PMT_LV in the directory
for example
/home/emc/logs/0703121259.txt  (March 12, 2007, 12:59)

To restart PL512 epics applications.
Login to bemc/star_daq_sc
Look at procIDs
->screen –list
->screen –r xxxx.Bemc-west(east) xxxx is procID
->bemclvps2 > (ctrl A) to detach
                        exit to kill
->BEMC-West or East to restart

Experts control for PL512
If you need to adjust LV on PL512 you can do this using expert_bemc_west or (east).
These GUI has experts panel. Adjusting LV setting DO NOT try to slide the bars.
Instead click on it then on popup window you can simply type desired value.
Make sure you will close expert GUI and return to normal operational GUI once
you will finish adjustments.

A copy of this manual as a PDF document is available for download below.

Expert Contacts

Steve Trentalange (on site all run) e-mail:
Phone: x1038 (BNL) or (323) 610-4724 (cell)

Oleg Tsai (on site all run) e-mail:
Phone: x1038 (BNL)

SMD High Voltage Operation

Version 1.10 -- 04/25/06, O.D.Tsai


The SMD detectors are a set of 120 proportional wire chambers located inside the EMC modules (one per module). The operating gas is Ar/CO2(90/10). The nominal operating voltage is +1430 V. As for any other gaseous detector, manipulation with high voltage should be performed with great care.

A detailed description of the system is given in the Appendix.

SMD HV must be turned OFF before magnet ramp !
Standard Operation includes three steps.

Turn HV ON
Log Defective Modules

To turn SMD HV ON the procedure is:
  1. On HOOSIER.STARP.BNL.GOV computer double click on the SMDHV icon on the Windows desktop.  The 'SMD HIGH VOLTAGE CONTROL' window will open.
  2. On the SMD HIGH VOLTAGE CONTROL window click 'POWER' button.
    1. 'POWER' button will turn RED
    2. In no later than 90 + 150 + 300 sec in window 'Current Mode' you will see the message - "Physics Mode"
    3. All modules with high voltage on them will be shown in GREEN, LIGHT BROWN or YELLOW.

To turn HV OFF on SMD the procedure is:
  1. Click on the green 'POWER' button.  Result:
    1. 'POWER' button will turn from green to BROWN
    2. after a 30 sec. or so small window will pop-up telling you that voltages an all channels reached zero.
  2. Click 'OK' on that small window to stop the program.

To Log Defective Modules

  1. Scroll down the window -- you will see three tables
  2. Log contents of the left table called 'Defect Module List' if any modules are presented here.
  3. Log contents of the right table called 'Modules tripped during Standby' (for example Run XXX  #8 - 3 trips, Run XXX  #54 - 1 trip)
  4. Close the 'SMD HIGH VOLTAGE CONTROL' window.
Detailed description of the SMD HV Program and associated hardware settings can be found in Appendix.

Indicators to watch:

1.  Interlock went RED

In case STAR global interlock went ON
  1. Interlock led will turn in RED
  2. the SMD HV program will turn OFF HV on all SMD channels and program will halt.
  3. Operator should close SMD HV Voltage control window.
Once STAR global interlock will be cleared follow usual procedure to power up SMD.

 2. Server Timeout went RED or SMD HV Control program is frozen.

This is an unusual situation and SMD Expert Contacts should be alerted.  The lost communication to SY1527 should not lead to immediate damages to the SMD chambers.

In case communication to the SY1527 is lost for some reason the 'SERVER TIMEOUT' led will turn RED.  In case SMD HV Control program is frozen the 'Current Time' will not be updated.

Procedure to resolve problem is:
  1. Open terminal window on EMC01.STARP.BNL.GOV (monitor is on top of SMD HV Control PC)
  2. ping -- observe that packets transmitted and received.
    1. If there are no communication with SY1527 (packets lost) -- Call one of the Expert Contacts!
  3. If communication is OK, then stop ping and type telnet 1527  -- You should see 'login window for CAEN SY1527 system'
  4. Press any key
  5. Login as 'admin' with password 'admin' -- you will see Main Menu window for SY1527
  6. From 'Main' chose 'Channels' by pressing 'Enter' -- you will see Channels menu window
  7. Verify HV is presented on channels (VMon)

Usually second terminal window is open on HOOSIER.STARP.BNL.GOV to monitor SY1527 HV power supply. If this window is not open use “putty” and open SY1527 session.

Now you can operate HV using this window, but if there is no emergency to turn HV OFF you should first try to restart SMD HV Control program.  

Basic operations from that window are:
Turn HV ON             

  1. press Tab key
  2. scroll to 'Groups' menu
  3. press 'Enter' to chose "Group Mode" --you will see highlighted column
  4. scroll to "Pw"
  5. press space bar -- you will see "Pw" will switched from On to Off and VMon will start to decrease.
Turn HV ON
  1. press Tab key
  2. select 'Group' mode
  3. scroll to IOSet
  4. type 5.0  (Current limit 5uA)
  5. scroll to Trip
  6. type 0.5 sec
  7. Verify that V0Set is 1430 V
  8. Scroll to Pw
  9. press Space bar -- you will see Pw will switch from OFF to ON and Status goes to Up.  VMon will start to increase.
Once HV will reach to nominal it is very important to switch I0Set to 1.6 uA and Trip to 0.1s on all channels.  Some channels might trip after I0Set and Trip were changed, that is 'normal'. For those channels I0Set and Trip should be set to 5 uA and 0.5s. To do that:
  1. Press Tab key
  2. reselect 'Group' mode
  3. Change I0Set and Trip for tripped channels
  4. Power them up - scroll to Pw, and press Space bar.
Usually it is safe to keep channels in 'Group' mode to be able to switch them OFF fast in case of emergency.


Before you start:
"Be afraid, even paranoid, and that gives you a chance to catch bad effects in the early stages when they still do not matter" 
--J. Va'vra (Wire Aging Conference)

Detailed information regarding SY1527 mainframe and A1733 HV distribution boards can be found at CAEN web page.

The SMD HV is supplied by the CAEN SY1527 HV system.  The mainframe is located in rack 2C5 (Second Floor, Third Row, near the center).  The HV cables run from modules to the SMD crates (15 cables per each crate).  At each crate HV cables re-grounded on patch panels assuring same ground for HV and signals to be read. From SMD crates, the HV lines then run to the SY1527 system. There are 10 HV cards, 12 HV channels each (model A1733) inside the mainframe to supply high voltages to the SMD chambers.  The parameters of the high voltage system controlled via Ethernet.  The GUI based on LabView and CAEN OPC server.

Hardware settings are:

 HV Hardware limit set to +1500 V on each of A1733 cards.
 HV Software limit (SVMax) set to +1450 V for each channel.
 Communications settings for SY1527 are:
Net Mask
User name Admin
Password Admin
Position of switches and status of LEDs on the front panel of SY1527
(from top to bottom, HV is Off)
Chk Pass                     On
Toggle Switch 'Loc enable'   On
Ch Status     'NIM'          On
Interlock     'Open'
Master                       On
+48 V                        On
+5  V                        On
+12 V                        On
-12 V                        On
Main                         On

Each A1733 card should have 50 Ohm Lemo 00 terminator to enable HV.

Description of SMD High Voltage Control program.

All SMD HV software is installed on EMCSC.STARP.BNL.GOV in folder C:/SY1527

The SMD HV Control provides one button operation of the HV system for the SMD. There are three main functions Power On, Physics Mode, Power Off. There are two configuration files Conf.txt and Conf2.txt which defines ramp up speed and trip settings for different mode of operation.

The nominal settings for Power On are (C:/SY1527/Conf.txt):

V0          1430 V
I0Set       5 uA
Trip        0.5 s
Ramp Down   50 V/sec
Ramp Up     20 V/sec

All channels are allowed to be ramp up in three consecutive attempts. If the first attempt (90 sec) for given channel lead to trip then ramp up speed will be set to 10 V/sec and second attempt (150 sec) will be performed. If second attempt will lead to trip then ramp up speed will be set to 7 V/sec and third attempt (300 sec) will be made. If all three attempt led to trip the program disconnect that particular channel from HV (corresponding led on main panel will turn in RED).

In no later then 90 + 150 + 300 seconds program will change parameters of I0Set and Trip form 5 uA and 0.5 sec to 1.6 uA and 0.1 sec and will switch to the Physics Mode.

The nominal settings for Physics Mode are (C:/SY1527/Conf2.txt)
V0          1430 V
I0Set       1.6 uA
Trip        0.1 s
Ramp Down   50 V/sec
Ramp Up     20 V/sec

Channels allowed to trip no more then 6 times during the Physics Mode. If channel will trip then I0Set and Trip for that particular channel will be set to 5 uA and 0.5 sec and program will try to bring that channel up. On front panel Alarm Status will turn in RED, corresponded message will pop up in 'Current Mode' window, and corresponded to that channel LED will turn in YELLOW or RED.  Once voltage reach 90% of nominal all indicators will turn to normal status.  Usually it takes about 15 seconds to bring channel back to normal.  At the bottom of the screen the right table with modules that tripped during the Physics Mode will be updated.  If some channel will trip more than 6 times that channel will be HV disabled by the program and corresponded led will turn RED.  The left table on the bottom of the screen will be updated.  Such cases should be treated by experts only later on.

All SMD channels during the Physics Mode is under the monitoring.  Each 3 seconds or so, the values of Voltage, Current and time are logged in files XX_YY_ZZ_P.txt in C:/SY1527/Log, where XX - current month, YY - current day, ZZ - current year, and P is V for Voltages and I for Currents. The current time saved in seconds.  The macro C:/SY1527/smdhv.C plots bad channels history and fills histograms for all other channels.
Turn Off is trivial and no need explanations.

The meaning of the LED on main panel are:
Green – channel is at nominal HV, current < 1 uA
Brown – channel is at nominal HV, 1 uA < current < 5 uA
Yellow – the HV is < 50% of nominal
Red    - channel was disconnected due trips during ramp up or physics modes.
Black  - channel disabled by user (Conf.txt, Conf2.txt)

It is important to monitor channels with high current (“Brown”), as well as channels that shows high number of trips during the operation.  Note: some channels (54 for example) probably has a leakage on external HV distribution board and believed to be OK in terms of discharges on anode wires as was verified during summer shutdown. The other might develop sparking during the run or might have intermittent problems (#8 for example). If problems with sparking will be detected at early stages then those channels might be cured by experts during the run, without of loss of entire chamber as it was happened during the first two years of operation.  

The C:/SY1527/ allows to monitor single channel. You may overwrite nominal parameters of HV for any channel using that program (it is not desired to do that). This program can run in parallel with the Main SMD HV Control program.  The operation is trivial, specify 'Channel to monitor' and click on 'Update Channel'. If you wish to overwrite some parameters (see above) then fill properly VOSet etc. icons and click on Update Write.

Important! Known bug.
Before you start you better to fill all parameters, if you do not do that and stop the program later on the parameters will be overwritten with whatever it was in those windows, i.e. if V0Set was 0 then you will power Off the channel.  

 In some cases it is easy to monitor channels by looking at front panel of the SY1527 mainframe. The image of this panel can be
 obtained by opening telnet session (telnet 1527) on EMC01.STARP.BNL.GOV.

 All three programs can run in parallel.

 -----Experts to be called day or night no matter what---

 1. The operation crew lost communication with SY1527
 2. Any accidental cases (large number (>5) of SMD channels
    suddenly disconnected from HV during the run)

For experts only!

What to do with bad modules?

1.    If anode wire were found broken then disable channel by changing 1430 to 0 in both configuration files. That should help to avoid confusions of detector operators.

2.    If anode wires are OK, and module trips frequently during first half an hour after power Up then it is advised to set HV on that particular channel to lower value (-100V, -200V from nominal etc…) and observe the behavior of the chamber ( In some cases after a few hours module can be bring back to normal operation.

3.    If step 2 did not help, then wait till scheduled access and try to cure chamber by applying reverse polarity HV. Important, you can do that using good HV power supply (fast trip protection, with current limit 5uA), or by using something like ‘Bertran’ with external microammeter and balance resistor of no less then 10 MOhm, only! In any case you need to observe the current while gradually increase HV. In no case ‘Bertarn’ like power supply might be left unattended during the cure procedure. It is not advised to apply more then -1000 V. In some cases curing procedure might be fast (one hour or so). In others it might take much longer (24 hours and more) to bring module back to operation. In any case I would request to talk with me.

4.    The SMDHV is also installed on EMCSC.STARP.BNL.GOV and can be run from there, although that will for sure affect BTOW HV, be advised.

  Version 1.00 was written 11/12/03
  Version 1.10 corrected   04/25/06

A copy of this manual as a Word document is available for download below.


Here you'll find links to calibration studies for the BEMC:


procedure used to set the HV online
MIP study to check HV values -- note: offline calibrations available at Run 6 BTOW Calibration

final offline

final offline

offline slope calibration


Dmitry & Julia - SMD correlation with BTOW for 200 GeV AuAu


Rory - CuCu PSD calibration studies

Jaro - first look at PSD MIP calibration for AuAu data


This task has been picked up by Rory Clarke from TAMU. His page is here:

Run 8 BPRS Calibration

Parent for Run 8 BPRS Calibration done mostly by Jan

01 DB peds R9069005, 9067013

 Pedestal residua for 434 zero-bias events from run 9069005.

The same pedestal for all caps was used - as implemented in the offline DB.


Fig 1.

Fig 2.  Run 9067013, excluded caps >120.  All 4800 tiles, pedestal residua from 100 st_zeroBias events. Y-axis [-50,+150].

Fig 3.  Run 9067013, excluded caps >120. Pedestal corrected spectra for all 4800 tiles, 10K  st_physics events. Y-axis [-50,+150].

Dead MAPMT results with 4 patches 4 towers wide.

Fig 4.

Run 9067013, excluded caps >120. 

Zoom-in Pedestal corrected spectra, one ped per channel.

Top 10K st_physics events (barrel often triggered)

Bottom pedestal residua 100 st_zeroBias events

Fig 5.

Run 9067013, input =100 events, accept if capID=124 , raw spectra.

There are 4 BPRS  crates, so 1200 channels/crate.  In terms of softIds it's

PSD1W:  1-300 + 1501-2400
PSD19W: 301-1500
PSD1E:  2401-2900 + 4101-4800
PSD20E: 2901-4100

Why only 2 channels fired in crate PSD20E ?

02 pedestal(capID)

 Run 9067013, 30K st_physics events, spectra accumulated separately for every cap.

Top plot pedestal (channel), bottom plot integral of pedestal peak to total spectrum.


Fig 1. CAP=122

Fig 2. CAP=123

Fig 3. CAP=124

Fig 4. CAP=125

Fig 5. CAP=126

Fig 6. CAP=127

Fig 7. Raw spectra for capID=125. Left: typical good pedestal, middle: very wide pedestal, right: stuck lower bit.

For run 9067013 I found: 7 tiles with ADC=0, ~47 tiles with wide ped, ~80 tiles with stuck lower bit.

Total ~130 bad BPRS tiles based on pedestal shape, TABLE w/ bad BPRS tiles

Fig 8. QA of pedestals, R9067013, capID=125. Below is 5 plots A,...,F all have BPRS soft ID on the X-axis.

A: raw spectra (scatter plot) +  pedestal from the fit as black cross (with error).

B: my status table based on pedestal spectrum. 0=good, non-zero =sth bad.

C: chi2/DOF from fitting pedestal, values above 10. were flagged as bad

D: sigma of pedestal fit, values aove 2.7 were flagged as bad

E: integral of the found pedestal peak to the total # of entries. On average there was ~230 entries per channel.

Fig 9. BPRS pedestals for 'normal' caps=113,114,115 shown with different colors

Fig 10. BPRS pedestals for caps=100..127 and all softID , white means bad spectrum, typical stats of ~200 events per softID per cap

Fig 11. BPRS:" # of bad caps , only capID=100...127 were examined.

Fig 12. BPRS:" sig(ped)

Fig 13. BPRS:" examples of ped distribution for selected channels. Assuming for sing;e capID sig(ped)=1.5, the degradation of pedestal resolution if capID is not accounted for would be: sqrt(1.5^2 +0.5^2)=1.6 - perhaps it is not worth the effort on average. There still can be outliers.


03 tagging desynchronized capID

BPRS Polygraph detecting corrupted capIDs.

Goal: tag events with desynchronized CAP id, find correct cap ID


  1. build ped(capID, softID)
  2. pick one BPRS crate (19W)
  3. compute chi2/dof for  series capID+/-2
  4. pick 'best'  capID with smallest chi2/dof
  5. use pedestals for best capID for this crate for this event
  6. if best capID differs from nominal capID call this event 'desynchronized & fixed'

Input: 23K st_physics events from run 9067013.

For technical reason limited range of nominal capID=[122,126] was used, what reduces data sample to 4% ( 5/128=0.04).


Fig 1. ADC-ped(capID,softID) vs. softID for crate 1 (i.e. PSD19W) as is'. No capID corruption detection


Fig 2. ADC-ped(capID,softID) with capID detection & correction enabled. The same events.


Note, all bands are gone - the capID fix works.

Right: ADC-ped spectra: Black: 594 uncorrupted  events, red: 30 corrupted & fixed events.


The integral for ADC[10,70] are 2914 and 141 for good and fixed events, respectively.

141/2914=0.048;  30/594=0.051 - close enough to call it the same (within stats).





Fig 3. Auxiliary plots. 


TOP left: chi/dof for all events. About 1100 channels is used out of 1200 in served by crate 1. Rejected are bad & outliers.

TOP right: change of chi2/dof for events with corrupted & fixed capID. 

BOTTOM: frequency of capID for good & fixed events, respectively.




  • BPRS-Polygraph algo efficiently identifies and corrects BPRS for corrupted capID, could be adopted to used offline .
  • there is no evidence ADC integration widow changes for BPRS data with corrupted capID.   



Table 1.

shows capIDs for the 4 BPRS crates for subsequent events. Looks like for the same event cap IDs are strongly correlated, but different.
Conclusion: if we discard say capID=125, we will make hole of 1/4 of barrel , different in every event. This holds for BPRS & BSMD.

capID= 83:89:87:90: eve=134 
capID= 1:4:11:3: eve=135 
capID= 74:74:81:72: eve=136 
capID= 108:110:116:110: eve=137 
capID= 68:72:73:75: eve=138 
capID= 58:55:65:64: eve=139 
capID= 104:110:106:101: eve=140 
capID= 9:6:8:15: eve=141 
capID= 43:37:47:46: eve=142 
capID= 120:126:118:122: eve=143 
capID= 34:41:41:40: eve=144 
capID= 3:0:126:2: eve=145 
capID= 28:33:28:30: eve=146 
capID= 72:64:70:62: eve=147 
capID= 2:6:7:5: eve=148 
capID= 22:32:33:24: eve=149 
capID= 8:4:5:124: eve=150 
capID= 23:17:17:19: eve=151 
capID= 62:57:63:61: eve=152 
capID= 54:53:45:47: eve=153 
capID= 68:75:70:67: eve=154 
capID= 73:79:73:72: eve=155 
capID= 104:98:103:103: eve=156 
capID= 12:5:13:10: eve=157 
capID= 5:10:10:2: eve=158 
capID= 32:33:27:22: eve=159 
capID= 96:102:106:97: eve=160 
capID= 79:77:72:77: eve=161 


04 BPRS sees beam background?

The pair of plots below demonstrates BPRS pedestal residua are very clean once peds for 128 caps are used and this 5% capID corruption is detected and fixed event by event.

 INPUT: run 9067013, st_phys events, stale BPRS data removed, all 38K events .

Fig 0. capID correction was enabled for the bottom plot. Soft ID is on the X-axis; rawAdc-ped(softID, capID) on the Y-axis.


Now you can believe me the BPRS pedestals are reasonable for this run. Look at the width of pedestal vs. softID, shown in Fig 1 below.

There are 2 regions with wider peds, marked by magenta(?) and red circle.

The individual spectra look fine (fig 2b, 2bb).

But the correlation of pedestal width with softID (fig 1a,1b) and phi-location of respective modules (fig 3a, 3b) suggest it could be due to the beam background at

~7 o'clock on the West and at 6-9 o'clock on the East.




05 ---- peds(softID,capID) & status table, ver=2.2, R9067013

INPUT: st_hysics events from run=9067013

Fig 1. Top: pedestal(softID & capID), middle: sigma of pedestal, bottom: status table, Y-axis counts how many capID had bad spectra.

Based on pedestal spectra there are 134 bad BPRS tiles


Fig 2. Distribution of pedestals for 4 selected softIDs, one per crate.


Fig 3. Zoom-in of ped(soft,cap) spectrum to see there is more pairs of 2 capID which have high/low pedestal vs. average, similar to the known pair (124/125).
Looks like such piar like to repeat every 21 capIDs - is there a deeper meaning it?
(I mean will the World end in 21*pi days?)

Fig 4. Example of MIP spectra (bottom). MIP peak is very close to pedestal, there are worse cases than the one below.

06 MIP algo ver 1.1

 TPC based MIP algo was devised to calibrate BPRS tiles.

Details of the algo are in 1st PDF,

example of MIP spectra for 40 tails with ID [1461,1540] are in subsequent 5 PDF files, sorted by MAPMT


Fig 1 shows collapsed ADC-ped response for all 4800 BPRS tiles. The average MIP response is only 10 ADC counts above ped wich has sigma of 1.5 ADC. The average BPRS gain is very is very low.

07 BPRS peds vs. time

Fig 1. Change of BPRS pedestal over ... within the same fill, see softID~1000

Pedestal residua (Y-axis) vs. softID (X-axis), same reference pedestals used from day 67 (so some peds are wrong for both runs)  were used both plots.

Only fmsslow events, no further filtering, capID corruption fixed in fly.

Top run 9066001, start 0:11 am, fill 9989

Bottom run 9066012, start 2:02 am, fill 9989



Fig 2. Run list. system config was changed between those 2 runs marked in blue.

Fig 3. zoom in of run 9066001

Fig 4. another example of BPRS ped jump between runs: 9068022 & 9068032, both in the same fill.

08 BPRS ped calculation using average

Comparison of accuracy of pedestal calculation using Gauss fit & plain average of all data.

The plain average method is our current scheme for ZS for BPRS & BSMD for 2009 data taking.

Fig 2. TOP: RMS of the plain average, using 13K of fmsslow-triggered events which are reasonable surrogate of minBias data for BPRS.
Middle: sigma of pedestal fit using Gauss shape
Bottom: ratio of pedestals from this 2 method. The typical pedestal value is of 170 ADC. I could not make root to display the difference, sorry.

09 BPRS swaps, IGNORING Rory's finding from 2007, take 1

This page is kept only for the record- information here is obsolete.

This analysis does not accounts for BPRS swaps discovered by Rory's in 2007, default a2e maker did not worked properly 

  • INPUT: ~4 days of fmsslow-triggered events, days 65-69
    • private  BPRS peds(cap,softID) for every run,
    • private status table, the same , based on one run from day 67
    • event-by-event capID corruption detection and correction
    • use vertex with min{|Z|}, ignore ranking to compensate for PPV problem
    • select prim tracks with pr>0.4 GeV, dEdX in [1.5,3.7] keV, |eta|<1.2
    • require track enters tower 1cm from the edge and exists tower at any distance to the edge
    • tower ADC is NOT used (yet)
  • 2 histograms of rawADC-ped were accumulated: for all events (top plot) and for BPRS tiles pointed by TPC track (middle plot w/ my mapping   & lower plot with default mapping)

There are large section of 'miples' BPRS tiles if default mapping is used: 3x80 tiles + 2x40 tiles=320 tiles, plus there is a lot of small mapping problems. Plots below are divided according to 4 BPRS crates - I assumed the bulk of mapping problems should be contained within single crate. 


Fig 1, crate=0, Middle plot is after swap - was cured for soft id [1861-1900]

   if(softID>=1861 && softID<=1880) softID+=20;
    else if(softID>=1881 && softID<=1900) softID-=20;



Fig2, crate=1, Middle plot is after swap - was cured for soft id [661-740]

  if(softID>=661 && softID<=700) softID+=40;
    else if(softID>=701 && softID<=740) softID-=40;

Fig3, crate=2, Middle plot is after swap - was cured for soft id [4181-4220].

But swap in [2821-2900] is not that trivial - suggestions are welcome?

 if(softID>=4181 && softID<=4220) softID+=40;
    else if(softID>=4221 && softID<=4260) softID-=40;


Fig4, crate=3, swap in [3781-3800] is not that trivial - suggestions are welcome?



10 -------- BPRS swaps take2, _AFTER_ applying Rory's swaps

 2nd Correction of BPRS mapping (after Rory's corrections are applied).

  • INPUT: ~7 days of fmsslow-triggered events, days 64-70, 120 runs
    • private  BPRS peds(cap,softID) for every run,
    • private status table, excluded only 7 strips with ADC=0
    • event-by-event capID corruption detection and correction
    • use vertex with min{|Z|}, ignore PPV ranking, to compensate for PPV problem
    • BPRS swaps detected by Rory in 2007 data have been applied 
    • select prim tracks with pr>0.4 GeV, dEdX in [1.5,3.7] keV, |eta|<1.2, zVertex <50 cm
    • require track enters tower 1cm from the edge and exist the same tower at any distance to the edge (0 cm)
    • tower ADC is NOT used (yet)
  • 3 2D histograms of were accumulated:
    •  rawADC-ped (softID)  for all events
    •  the same but only  for BPRS tiles pointed by QAed MIP TPC track 
    •  frequency of correlation BPRS tiles with MIP-like ADC=[7,30] with towers pointed by TPC MIP track


Based on correlation plot (shown as attachment 6) I found ~230 miss-mapped BPRS tiles (after Rory's correction were applied).

Once additional swaps were added ( listed in table 1, and in more logical for in attachment 3) the correlation plot is almost diagonal, shown in attachment 1.

Few examples of discovered swaps are in fig1. The most important are 2 series of 80 strips, each shifted by 1 software ID.

Fig 2 shows MIP signal shows up after shit by 1 softID is implemented. 

The ADC spectra for all 4800 strips are shown in attachment 2. Attachment 5 & 6  list basic QA of 4800 BRS tiles for 2 cases: only Rory's swaps and Rory+Jan swaps.


Fig 1. Examples of swaps, dotted line marks the diagonal. Vertical axis shows towers pointed by TPC MIP track. X-axis shows BPRS soft ID if given ADC was in the range [7,30] - the expected MIP response. Every BPRS tile was examined for every track, multiple times per event if more than 1 MIP track was found. 

Left: 4 sets of 4 strips needs to be rotated.                                              Right: shift by 1 of 80 strips overlaps with rotation of 6 strips.


Fig 2. Example of recovered 80 tiles for softID~2850-2900. Fix: softID was shifted by 1.

Fig 3. Summary of proposed here corrections to existing BPRS mapping

Table 1. List of all BPRS swaps , ver 1.0,  found after Rory's corrections were applied, based on 2008 pp data from days 64-70.

The same list in human readable from is here

Identified BPRS 233 swaps. Convention: old_softID --> new_softID 
389 --> 412 , 390 --> 411 , 391 --> 410 , 392 --> 409 , 409 --> 392 ,
 410 --> 391 , 411 --> 390 , 412 --> 389 , 681 --> 682 , 682 --> 681 ,
 685 --> 686 , 686 --> 685 ,1074 -->1094 ,1094 -->1074 ,1200 -->1240 ,
1220 -->1200 ,1240 -->1260 ,1260 -->1220 ,1301 -->1321 ,1303 -->1323 ,
1313 -->1333 ,1321 -->1301 ,1323 -->1303 ,1333 -->1313 ,1878 -->1879 ,
1879 -->1878 ,1898 -->1899 ,1899 -->1898 ,2199 -->2200 ,2200 -->2199 ,
2308 -->2326 ,2326 -->2308 ,2639 -->2640 ,2640 -->2639 ,2773 -->2793 ,
2793 -->2773 ,2821 -->2900 ,2822 -->2821 ,2823 -->2822 ,2824 -->2823 ,
2825 -->2824 ,2826 -->2825 ,2827 -->2826 ,2828 -->2827 ,2829 -->2828 ,
2830 -->2829 ,2831 -->2830 ,2832 -->2831 ,2833 -->2832 ,2834 -->2833 ,
2835 -->2834 ,2836 -->2835 ,2837 -->2836 ,2838 -->2837 ,2839 -->2838 ,
2840 -->2839 ,2841 -->2840 ,2842 -->2841 ,2843 -->2842 ,2844 -->2843 ,
2845 -->2844 ,2846 -->2845 ,2847 -->2846 ,2848 -->2847 ,2849 -->2848 ,
2850 -->2849 ,2851 -->2850 ,2852 -->2851 ,2853 -->2852 ,2854 -->2853 ,
2855 -->2854 ,2856 -->2855 ,2857 -->2856 ,2858 -->2857 ,2859 -->2858 ,
2860 -->2859 ,2861 -->2860 ,2862 -->2861 ,2863 -->2862 ,2864 -->2863 ,
2865 -->2864 ,2866 -->2865 ,2867 -->2866 ,2868 -->2867 ,2869 -->2868 ,
2870 -->2869 ,2871 -->2870 ,2872 -->2871 ,2873 -->2872 ,2874 -->2873 ,
2875 -->2874 ,2876 -->2875 ,2877 -->2876 ,2878 -->2877 ,2879 -->2878 ,
2880 -->2879 ,2881 -->2880 ,2882 -->2881 ,2883 -->2882 ,2884 -->2883 ,
2885 -->2884 ,2886 -->2885 ,2887 -->2886 ,2888 -->2887 ,2889 -->2888 ,
2890 -->2889 ,2891 -->2890 ,2892 -->2891 ,2893 -->2892 ,2894 -->2893 ,
2895 -->2894 ,2896 -->2895 ,2897 -->2896 ,2898 -->2897 ,2899 -->2898 ,
2900 -->2899 ,3121 -->3141 ,3141 -->3121 ,3309 -->3310 ,3310 -->3309 ,
3717 -->3777 ,3718 -->3778 ,3719 -->3779 ,3720 -->3780 ,3737 -->3757 ,
3738 -->3758 ,3739 -->3759 ,3740 -->3760 ,3757 -->3717 ,3758 -->3718 ,
3759 -->3719 ,3760 -->3720 ,3777 -->3737 ,3778 -->3738 ,3779 -->3739 ,
3780 -->3740 ,3781 -->3861 ,3782 -->3781 ,3783 -->3782 ,3784 -->3783 ,
3785 -->3784 ,3786 -->3785 ,3787 -->3786 ,3788 -->3787 ,3789 -->3788 ,
3790 -->3789 ,3791 -->3790 ,3792 -->3791 ,3793 -->3792 ,3794 -->3793 ,
3795 -->3794 ,3796 -->3835 ,3797 -->3836 ,3798 -->3797 ,3799 -->3798 ,
3800 -->3799 ,3801 -->3840 ,3802 -->3801 ,3803 -->3802 ,3804 -->3803 ,
3805 -->3804 ,3806 -->3805 ,3807 -->3806 ,3808 -->3807 ,3809 -->3808 ,
3810 -->3809 ,3811 -->3810 ,3812 -->3811 ,3813 -->3812 ,3814 -->3813 ,
3815 -->3814 ,3816 -->3855 ,3817 -->3856 ,3818 -->3817 ,3819 -->3818 ,
3820 -->3819 ,3821 -->3860 ,3822 -->3821 ,3823 -->3822 ,3824 -->3823 ,
3825 -->3824 ,3826 -->3825 ,3827 -->3826 ,3828 -->3827 ,3829 -->3828 ,
3830 -->3829 ,3831 -->3830 ,3832 -->3831 ,3833 -->3832 ,3834 -->3833 ,
3835 -->3834 ,3836 -->3795 ,3837 -->3796 ,3838 -->3837 ,3839 -->3838 ,
3840 -->3839 ,3841 -->3800 ,3842 -->3841 ,3843 -->3842 ,3844 -->3843 ,
3845 -->3844 ,3846 -->3845 ,3847 -->3846 ,3848 -->3847 ,3849 -->3848 ,
3850 -->3849 ,3851 -->3850 ,3852 -->3851 ,3853 -->3852 ,3854 -->3853 ,
3855 -->3854 ,3856 -->3815 ,3857 -->3816 ,3858 -->3857 ,3859 -->3858 ,
3860 -->3859 ,3861 -->3820 ,4015 -->4055 ,4016 -->4056 ,4017 -->4057 ,
4018 -->4058 ,4055 -->4015 ,4056 -->4016 ,4057 -->4017 ,4058 -->4018 ,
4545 -->4565 ,4546 -->4566 ,4549 -->4569 ,4550 -->4570 ,4565 -->4545 ,
4566 -->4546 ,4569 -->4549 ,4570 -->4550 ,

  For the reference:

 Below I listed BPRS tiles which look suspicious. However it is not a detailed study, there is more problems in the histos I have accumulated.
BPRS status tables need more work, in particular channels with close to 100% cross talk can't be found using single spectra, because they will fine (just belong to another channel)  


Identified BPRS hardware problems:

Tiles w/ ADC=0 for all events:

* 3301-4, 3322-4 - all belong to PMB44-pmt1, dead Fee in 2007
   belonging to the same pmt:
     3321 has pedestal only
     3305-8 and 33205-8  have nice MIP peaks, work well

* 2821, 3781 , both at the end of 80-chanel shift in mapping
     neighbours of 2821: 2822,... have nice MIP 
     similar for neighbours of 3781

* 4525, 4526 FOUND! should be readout from cr=2 position 487 & 507, respectively 
I suspect all those case we are reading wrong 'positon' from the DAQ file

Pair of consecutive tiles with close 100% cross talk, see Fig 4.
35+6, 555+6, 655+6, 759+60, 1131+2, 1375+6, 1557+8,
2063+4, 2163+4, 2749+50, 3657+8,   
3739 & 3740 copy value of 3738 - similar case but with 3 channels.

Hot pixels, fire at random
1514, 1533, 1557,
block: 3621-32, 3635,3641-52 have broken fee, possible mapping problem 
block: 3941-3976 have broken fee

Almost copy-cat total 21 strips in sections of 12+8+1
3021..32, 3041..48, 3052
All have very bread pedestal. 3052 may show MIP peak if its gain is low.


Fig 4. Example of pairs of correlated channels.

11 BPRS absolute gains from MIP, ver1.0 ( example of towers)

 BPRS absolute gains from MIP, ver 1.0 

  • INPUT: ~9 days of fmsslow-triggered events, days 62-70, 200 runs, 6M events
    • private  BPRS peds(cap,softID) for every run,
    • private status table, excluded only 7 strips with ADC=0
    • event-by-event capID corruption detection and correction
    • use vertex with min{|Z|}, ignore PPV ranking, to compensate for PPV problem
    • BPRS swaps detected by Rory in 2007 data have been applied 
    • BTOW swaps detected & applied
    • select prim tracks with pr>0.4 GeV, dEdX in [1.5,3.3] keV, |eta|<1.3, zVertex <50 cm
    • require track enters & exits a tower 1cm from the edge
  • triple MIP coincidence, requires the following (restrictive) cuts:
    •  to see BPRS  MIP ADC :  TPC MIP track and in the same BTOW tower  ADC in [10,25] 
    •  to see BTOW MIP ADC :  TPC MIP track and in the same BPRS tile  ADC in [7,30] 


Fig 1 Typical MIP signal seen by BPRS(left) & BTOW (right) for soft ID=??, BPM16.2.x  (see attachment 1 for more)

Magenta line is at MIP MPV-1*sigma -> 15% false positives


Fig 2 Typical MIP signal seen by BPRS, pmt=BPM16.2

Average gain of this PMT is on the top left plot, MIP is seen in ADC=4.9, sig=2.6

Fig 3 Most desired MIP signal (ADC=16) seen by BPRS(left) & BTOW (right) for soft ID=1388, BPM12.1.8

Magenta line is at MIP MPV-1*sigma -> 15% false positives,  (see attachment 2 for more)


Fig 4 Reasonable BPRS, pmt=BPM11.3, pixel to pixel gain variations is small


Fig 5 High MIP signal (ADC=28) seen by BPRS(left) & BTOW (right) , BPM11.5.14

Magenta line is at MIP MPV-1*sigma -> 15% false positives,  (see attachment 3 for more)


Fig 6 High gain BPRS, pmt=BPM11.5


12 MIP gains ver1.0 (all tiles, also BTOW)

 This is still work in progress, same algo as on previous post.

Now I run on  12M events (was 6 M) and do rudimentary QA on MIP spectra, which results with ~10% channel loss (the bottom figure). However, the average MIP response per tile is close to the final value.

Conclusion: only green & light yellow tiles have reasonable MIP response of ~15 ADC. For blue we need to rise HV, for red we can lower it (to reduce after pulsing). White area are masked/dead pixels.

Fig 1: BPRS MIP gains= gauss fit to MIP peak.

A) gains vs. eta & phi to see BPM pattern. B) gains with errors vs. softID, C) sigma MIP shape, D) tiles killed in QA 


Fig 2: BTOW MIP gains= gauss fit to MIP peak. Content of this plot may change in next iteration.

A) gains vs. eta & phi. "ideal" MIP is at ADC=18, all towers. Yellow& red have significantly to high HV, light blue & blue have too low HV.

B) gains with errors vs. softID, C) sigma MIP shape, D) towers killed in QA 


13 MIP algo, ver=1.1 (example of towers)

This is an illustration of improvement of MIP finding efficiency if ADC gates are set on BPRS & BTOW at the places matched to actual gains instead of  fixed 'ideal' location.

Fig 1 is from previous iteration (item 11) with fixed location  MIP gates. Note low MIP yield in BPRS (red histo) due to mismatched BTOW ADC gate (blue bar below green histo).


Fig 2 New iteration with adjusted MIP gates. (marked by blue dashed lines).

MIP ADC gate is defined (based on iteration 1) by mean value of the gauss fit +/- 1 sigma of the gauss width, but not lower than ADC=3.5 and not higher than 2* mean ADC

Note similar MIP yield in BPRS  & BTOW. Also new MIP peak position from Gauss fit did not changed, meaning algo is robust. The 'ideal' MIP ADC range for BTOW is marked by magenta bar (bottom right) - is visibly too low.


Attached PDF shows similar plots for 16 towers. Have a look at page 7 & 14

14 ---- MIP gains ver=1.6 , 90% of 4800 tiles ----

 BPRS absolute gains using TPC MIPs & BTOW MIP cut, ver 1.6 , 2008 pp data

  • INPUT:  fmsslow-triggered events, days 43-70, 525 runs, 16M events (see attachment 1)
    • BTOW peds & ped-status  from offline DB
  • DATA CORRECTIONS (not avaliable using official STAR software)
    • discard stale events
    • private  BPRS peds(cap,softID) for every run,
    • private status table
    • event-by-event capID corruption detection and correction
    • use vertex with min{|Z|}, ignore PPV ranking, to compensate for PPV problem
    • BPRS swaps detected by Rory in 2007 data have been applied 
    • additional ~240 BPRS swaps detected & applied
    • BTOW ~50 swaps detected & applied
    • BTOW MIP position determine independently (offline DB gains not used)
    • select prim tracks with pr>0.35 GeV, dEdX in [1.5,3.3] keV, |eta|<1.3, zVertex <60 cm, last point on track Rxy>180cm
    • require track enters & exits a tower 1cm from the edge, except for etaBin=20 - only 0.5cm is required (did not helped)
  • triple MIP coincidence, requires the following (restrictive) cuts:
    •  to see BPRS  MIP ADC :  TPC MIP track and in the same BTOW tower  ADC in  MIP peak +/- 1 sigma , but above 5 ADC 
    •  to see BTOW MIP ADC :  TPC MIP track and in the same BPRS tile   ADC in  MIP peak +/- 1 sigma , but above 3.5 ADC


Fig 1.   Example of typical BPRS & BTOW MIP peak determine in this analysis. 

MIP ADC gate (blue vertical lines) is defined (based on iteration 1.0) by the mean value of the gauss fit +/- 1 sigma of the gauss width, but not lower than ADC=3.5 (BPRS) or 5 (BTOW) and not higher than 2* mean ADC.

 FYI, the  nominal MIP ADC range for BTOW (ADC=4096 @ ET=60 GeV/c) is marked by magenta bar (bottom right).

  • Attachment 6 contains 4800 plots  of BPRS & BTOW like this one below ( large 53MB !!)
  • Numerical values of MIP peak position,width, yield  for all 4800 BPRS tiles are in attachment 4.


Fig 2.  ADC of MIP peak for 4800 BPRS tiles.

Top plot: mean, X-axis follows eta bin , first West then East. Y-axis follows  |eta| bin, 20 is at physical eta=+/- 1.0.Large white areas are due to bad BPRS MAPMT (4x4 or 2x8 channels), single white rectangles are due to bad BPRS tile or bad BTOW tower.

Middle plot: mean +/- error of mean, X-axis =soft ID. One would wish mean MIP value is above 15 ADC to place MIP cut comfortable above the pedestal (sig=1.5-1.8 ADC counts).

Bottom plot: width of MIP distribution. Shows the width of MIP shape is comparable to the mean and we want to put MIP cut well below the mean to not loose half of discrimination power.

Note, the large # 452 of not calibrated BPRS tiles does not mean that many are broken. There are 14 known bad PMTs and e 'halves' , total=15*16=240 (see attachment 2). There rest are due broken towers (required by MIP coincidence) and isolated broken fibers, FEE channels.

Fig 3. Example of PMT with fully working 16 channels.
Top left plot shows average MIP ADC from 16 pixels. Top middle: correlation between MIP peak ADC and raw slope - can be used for relative gain change in 2009. Top right shows BTOW average MIP response.
Middle: MIP spectra for 16 pixels.
Bottom: raw spectra fro the same 16 pixels.

300 plots like this  is in attachment 3.


Fig 4.  Top plot: average over 16 pixels MIP ADC  for 286 BPRS pmts.  X axis = PMB# [1-30] + pmt #[1-5]/10. Error bars represent RMS of distribution (not error of the mean).

Middle plot : ID of 14 not calibrated PMTs. For detailed location of broken PMTs see attachment 2,  the red computer-generated ovals on the top of 2007 Will's scribbles mark broken PMTs (blue ovals are repaired PMTs) found in this 2008 analysis.

Bottom plot shows # of pixels in given PMT  with reasonable MIP signal (used in the top figure).

  • Numerical values of MIP peak per PMT are in attachment 5.




Fig 5.  ADC of MIP peak for 4800 BTOW tower. Top lot: mean, middle plot: mean +/- error of mean, bottom plot: width of MIP 

  •  Numerical values of MIP peak position,width, yield  for all 4800  BTOW towers are in attachment 4.

Note, probably 1/2 of not calibrated BTOW towers are broken, the other half is due to bad BPRS tiles, required to work by this particular algo.

Koniec !!!


15 Broken BPRS channels ver=1.6, based on data from March of 2008

 The following BPRS pmts/tiles have been found broken or partially not functioning, based on reco MIP response from pp 2008 data.


 Based on PMT-sorted spectra available HERE  (300 pages , 3.6MB)


Table 1. Simply dead PMT's. Raw spectra contain 16 nice pedestals, no energy above, see Fig 2.

PMB,pmt, PDF page # , 16 mapped softIDs
2,3     8, 2185 2186 2187 2188 2205 2206 2207 2208 2225 2226 2227 2228 2245 2246 2247 2248 
2,4,    9, 2189 2190 2191 2192 2209 2210 2211 2212 2229 2230 2231 2232 2249 2250 2251 2252 
4,5,   20, 2033 2034 2035 2036 2053 2054 2055 2056 2073 2074 2075 2076 2093 2094 2095 2096 
5,1,   21, 1957 1958 1959 1960 1977 1978 1979 1980 1997 1998 1999 2000 2017 2018 2019 2020 
12,2,  57, 1421 1422 1423 1424 1425 1426 1427 1428 1441 1442 1443 1444 1445 1446 1447 1448 
14,1,  66, 1221 1222 1223 1224 1225 1226 1227 1228 1241 1242 1243 1244 1245 1246 1247 1248 
24,4, 119, 433 434 435 436 453 454 455 456 473 474 475 476 493 494 495 496 
25,4, 124, 353 354 355 356 373 374 375 376 393 394 395 396 413 414 415 416 
26,4, 129, 269 270 271 272 289 290 291 292 309 310 311 312 329 330 331 332 
32,3, 158, 2409 2410 2411 2412 4749 4750 4751 4752 4769 4770 4771 4772 4789 4790 4791 4792 
44,5, 220, 3317 3318 3319 3320 3337 3338 3339 3340 3357 3358 3359 3360 3377 3378 3379 3380 
39,2, 192, 2905 2906 2907 2908 2925 2926 2927 2928 2945 2946 2947 2948 2965 2966 2967 2968    


Table 2.  FEE is broken (or 8-connector has a black tape), disabling 1/2 of PMT, see Fig 3.

PMB,pmt,  nUsedPix,  avrMIP (adc), rmsMIP (adc),PDF page # , all mapped softIDs
7,1,   7,   19.14, 4.36,  31, 1797 1798 1799 1800 1817 1818 1819 1820 1837 1838 1839 1840 1857 1858 1859 1860   
40,1,  8,    5.16, 0.53, 196, 2981 2982 2983 2984 3001 3002 3003 3004 3021 3022 3023 3024 3041 3042 3043 3044  
40,2,  6,    5.44, 0.80, 197, 2985 2986 2987 2988 3005 3006 3007 3008 3025 3026 3027 3028 3045 3046 3047 3048  
40,3, 12,    8.50, 1.05, 198, 2989 2990 2991 2992 3009 3010 3011 3012 3029 3030 3031 3032 3049 3050 3051 3052    
44,1, 10,   13.72, 8.24, 216, 3301 3302 3303 3304 3305 3306 3307 3308 3321 3322 3323 3324 3325 3326 3327 3328  
45,2,  8,    5.04, 1.55, 222, 3421 3422 3423 3424 3425 3426 3427 3428 3441 3442 3443 3444 3445 3446 3447 3448   
51,5,  7,   11.37, 2.15, 255, 3877 3878 3879 3880 3897 3898 3899 3900 3917 3918 3919 3920 3937 3938 3939 3940  
52,5,  8,   15.84, 4.80, 260, 3957 3958 3959 3960 3977 3978 3979 3980 3997 3998 3999 4000 4017 4018 4019 4020  
60,1,  8,   15.12, 3.41, 296, 4581 4582 4583 4584 4601 4602 4603 4604 4621 4622 4623 4624 4641 4642 4643 4644


Table 3. Very low yield of MIPs (1/5 of typical), may de due to badly sitting optical connector, see Fig 4

PMB,pmt, QAflag, nUsedPix,  avrMIP (adc), rmsMIP (adc),PDF page # , all mapped softIDs
10,5,  14,     0,  0.00, 0.00,  50, 1553 1554 1555 1556 1573 1574 1575 1576 1593 1594 1595 1596 1613 1614 1615 1616    
31,5,  14,     0,  0.00, 0.00, 155, 4677 4678 4679 4680 4697 4698 4699 4700 4717 4718 4719 4720 4737 4738 4739 4740  
37,2,   0,    10, 12.90, 7.41, 182, 2745 2746 2747 2748 2765 2766 2767 2768 2785 2786 2787 2788 2805 2806 2807 2808    
49,1,   0,    16,  9.36, 3.55, 241, 3701 3702 3703 3704 3705 3706 3707 3708 3721 3722 3723 3724 3725 3726 3727 3728   


Table 4. Stuck LSB in FEE, we can live with this. (do NOT mask those tiles)

PMB,pmt, QAflag, nUsedPix,  avrMIP (adc), rmsMIP (adc),PDF page # , all mapped softIDs
51,1,0, 15,   8.37, 1.30, 251, 3861 3862 3863 3864 3881 3882 3883 3884 3901 3902 3903 3904 3921 3922 3923 3924  
51,2,0, 16,   8.66, 1.06, 252, 3865 3866 3867 3868 3885 3886 3887 3888 3905 3906 3907 3908 3925 3926 3927 3928  
51,3,0, 16,  11.08, 1.28, 253, 3869 3870 3871 3872 3889 3890 3891 3892 3909 3910 3911 3912 3929 3930 3931 3932  
51,4,0, 16,  17.16, 2.70, 254, 3873 3874 3875 3876 3893 3894 3895 3896 3913 3914 3915 3916 3933 3934 3935 3936   

Table 5. Other problems:

PMB,pmt, QAflag, nUsedPix,  avrMIP (adc), rmsMIP (adc),PDF page # , all mapped softIDs
31,2,0, 16,  12.32, 3.73, 152,4665 4666 4667 4668 4685 4686 4687 4688 4705 4706 4707 4708 4725 4726 4727 4728   


Fig 1. Example of fully functioning PMT (BPM=4, pmt=5). 16 softID are listed at the bottom o fthe X-axis.
Top plot: ADC spectra after MIP condition is imposed based on TPC track & BTOW response.
Bottom plot: raw ADC spectra for the same channels.


Fig 2. Example of dead PMT with functioning FEE.  

Fig 3. Example of half-dead PMT, comes in pack, most likely broken FEE.  

Fig 4. Example of weak raw ADC, perhaps optical connector got loose.  

Fig 5. Example of stuck LSB, We can live with this, but gain hardware must be ~10% higher (ADC--> 18)  

16 correlation of MIP ADC vs. raw slopes

 Scott asked for crate based comparison of MIP peak position vs. raw slopes .

I selected 100 consecutive BPRS tiles, in 2 groups, from each of the 4 crates. The crate with systematic lower gain is the 4th (PSD-20E). 

The same spectra from pp 2008 fmsslow events are used as for all items in the Drupal page.


Fig 1. BPRS carte=PSD-1W


Fig 2. BPRS carte=PSD-19W


Fig 3. BPRS carte=PSD-1E


Fig 4. BPRS carte=PSD-20E This one has lower MIP peak


Run 9 BPRS Calibration

Parent for Run 9 BPRS Calibration

01 BPRS live channels on day 82, pp 500 data

Status of BPRS live channels on March 23, 2009, pp 500 data.

Input: 32K events accepted by L2W algo, from 31 runs taken on day 81 & 82.

Top fig shows high energy region for 4800 BPRS tiles

Middle fig shows pedestal region, note we have ZS & ped subtracted data in daq - plots is consistent. White area are not functioning tiles.

Bottom fig: projection of all tiles. Bad channels included. Peak at ADC~190 is from corrupted channels softID~3720. Peak at the end comes most likely form saturation of BPRS if large energy is deposited. It is OK - BPRS main use is as a MIP counter.

Attached PDF contains more detailed spectra so one can see every tile.




Collected here is information about BSMD Calibrations.

There are 36,000 BSMD channels, divided into 18,000 strips in eta and 18,000 strips in phi. They are located 5.6 radiation lengths deep in the Barrel Electromagnetic Calorimeter (BEMC).

1) DATA: 2008 BSMD Calibration

Information about the 2008 BSMD Calibration effort will be posted below as sub-pages.

Fig 1. BSMD-E 2D mapping of soft ID. (plot for reverse mapping is attached)

01) raw spectra


  1. verify pedestals loaded to DB are reasonable for 2008 pp data
  2. estimate stats needed to find slopes of individual strips for minB events


  1. look at pedestal residua for individual strips, exclude caps 1 & 2, use only status==1
  2. fit gauss & compare with histo mean
  3. find integrals of individual strips, sum  over 20 ADC channels starting from ped+5*sig 

To obtain muDst w/o zero suppression I run privately the following production chain:

chain="DbV20080703 B2008a ITTF IAna ppOpt VFPPV l3onl emcDY2 fpd ftpc trgd ZDCvtx NosvtIT NossdIT analysis Corr4 OSpaceZ2 OGridLeak3D beamLine BEmcDebug"

Fig 1

Examples of single strip pedestal residua, based on ~80K minB events from days 47-65, 30 runs. (1223 is # of bins, ignore it).

Left is typical good spectrum, see Fig2.3. Middle is also reasonable, but peds is 8 channels wide vs. typical 4 channels.

The strip shown on the right plot is probably broken. 

Fig 2

Detailed view on first 500 strips. X=stripID for all plots.

  1. Y=mean of the gauss fit to pedestal residuum, in ADC channels, error=sigma of the gauss.
  2. Y=integral of over 20 ADC channels starting from ped+5*sig. 
  3. Raw spectra, Y=ADC-ped, exclude caps 1 & 2, use only status==1


Fig 3

Broader view of ... problems in BSMD-E plane. Note, status flag was taken in to account.

Top plot is sum of 30 runs from days 47-65, 80K events. Bottom plot is just 1 run, 3K events. You can't distinguish individual channels, but scatter plot works like a sum of channels, so it is clear the slopes are there, we need just more data.



  1. DB peds for BSMDE look good on average.
  2. with 1M eve we will start to see  gains for individual strip relativewith ~20% error. Production will finish tomorrow.
  3. there are portions of SMDE masked out (empty area in fig 3.2, id=1000) - do why know what broke? Will it be fixed in 2009 run
  4. there are portions of SMDE not masked but dead (solid line in fig 3.2, id=1400) - worth to go after those
  5. there are portions of SMDE not masked with unstable (or wrong) pedestal, (fig 3.1 id=15000)
  6. for most channels there is one or more caps with different ped not accounted for in DB ( thin line below pedestal in fig 2.3)
  7. One gets a taste of gain variation from fig 2.2
  8. Question: what width of pedestal is tolerable. Fig 2.1 shows width as error bars. Should I kill channel ID=152?


02) relative BSMD-E gains from 1M dAu events

 Glimpse of relative calibration of BSMDE from 2008 d+Au data


Input: 1M dAu minb events from runs: 8335112+8336019

Method : fit slopes to individual strips, as discussed 01) raw spectra


Fig 1

Examples of raw pedestal corrected spectra for first 9 strips, 1M dAu events

Fig 2

Detailed view on first 500 strips. X=stripID for all plots.

  1. Y=mean of the gauss fit to pedestal residuum, in ADC channels, error=sigma of the gauss.
  2. Y=integral of over 20 ADC channels starting from ped+5*sig. Raw spectra,
  3. Y=gain defined as "-slope" from the exponential fit over ADC range  20-40  channels, errors from expo fit. Blue line is constant fit to gains.

Fig 3

BSMDE strips cover the whole barrel and eta-phi representation is better suited to present 18K strips in one plot.

  1. Mapping of BSMDE-softID (Z-axis) in to eta-phi space. Eta bin 0 is eta=-1.0, eta bin 299 is eta=+1.0. Phi bin 0 starts at 12:30 and advances as phi angle. 
  2. gains for majority of 18K BSMDE strips. White means no data or discarded by rudimentary QA of peds, yields or slope.

Fig 4

For reference spectra from 1M pp events from ~12 EmcCheck runs from days 47-51. It proves I did it and it was naive on my side to expect 1M pp events is enough.

Fig 5

More pp events spectra - lot of problems with DB content. 


03) more details , answering Will

 This page provides more details addressing some of Will's questions.


   2) fig 2: well, 500 chns is not a very "natural" unit, but I wonder
      what corresponds to 50 chns (e.g., the region of fluctuation
      250-300) ... I need to check my electronics readout diagrams
      again, or maybe folks more expert will comment

Fig 1.

Zoom-in of the god-to-bad region of BSMDE

Fig 2. 

'Good' strips belong to barrel module 2, crate 2, sitting at ~1 o'cloCk on the WEST


Fig 3. 

'BAD' strips belong also  to barrel module 2, crate 2, sitting at ~1 o'cloCk on the WEST



04) bad CAP 123

 Study of pedestal correlation for BSMDE

Goal: identify source of the band below main pedestals. 

Figs 1,2 show pedestals 'breathe' in correlated way for channels in the same crate, but this mode is decoupled between crates. It may be enough to use individual peds for all CAPS to reduce this correlation.

Fig3 shows CAP=123 has bi-modal pedestals. FYI, CAPS 124,125 were excluded because they also are different.


Based on Fig1 & 3 one could write an algo identifying event by event in which mode CAP=123 settled, but for now I'll discard CAP123 as well.

 All plots are made based on 500K d-Au events from the run 8336052.


Fig 0
Example of pedestal residua for BSMDE strips 1-500, after CAPS 124 and 125 were excluded.

Fig 1
Correlation between pedestal residua for neighbor strips. Strip 100 is used on all plots on the X-axis

Fig 2
Correlation between pedestal residua for strips in different crates. Strip 100 is used on all plots on the X-axis

Fig 3
Squared pedestal residua for strips [1,150] were summed for every event and plotted as function of CAP ID (Y-axis).

Those strips belong to the same module #1 . X-axis shoes SQRT(sum) for convenience. CAP=123 has double pedestal.


05) BSMDE saturation, dAu, 500K minB eve

 Input: 500K d-Au events from run 8336052,

Method : drop CAPS 123,124,125, subtract single ped for all other CAPS.


Fig 1 full resolution, only 6 modules , every module contains 150 strips.

Fig 2 All 18K strips (120 modules), every module contain only 6 bins, every bin is sum of 25 strips. 

 h->RebinX(25), h->SetMinimum(2), h->SetMaximum(1e5)

06) QAed relative gains BSMDE, 3M d-Au events , ver1.0

Version 1 of relative gains for BSMDE, d-AU 2008.


INPUT: 3M d-AU events from day ~336 of 2007.

Method: fit slopes to ADC =ped+30,ped+100.

The spectra,  fits of pedestal residuum, and slopes were QAed.

Results: slopes were found for 16,577 of 18,000 strips of BSMDE.


Fig1   Good spectrum for strip ID=1. X-axis ADC-ped, CAPs=123,124,124 excluded.

Fig2 TOP:  slopes distribution (Y-axis) vs. stripID within given module ( X-axis). Physical eta=0.0 is at X=0, eta=1.0 is at X=150.

BOTTOM: status tables with marked eta-phi location excluded 1423 strips of BSMDE by multi-stage QA of the spectra. Different colors denote various failed tests.


Fig3 Mapping of known BSMDE topology on chosen by us eta-phi 2D localization. Official stripID is shown in color.



07) QA method for SMD-E, slopes , ver1.1

Automatic QA of BSMDE minB spectra. 


  1. example of good spectra (fig 0)
  2. QA cuts definition (table 1) + spectra (figs 1-7)
  3. Result:
    1. # of bad strips per module. BSMDE modules 10,31,68  are damaged above  50%+. (modules 16-30 served by crate 4 were not QAed). 
    2. eta-phi distributions of: slopes, slope error (fig 9) , pedestal, pedestal (fig 10) width _after_ QA
    3. sample of good and bad plots from every module, including modules 16-30 (PDF at the end)

The automatic  procedure doing QA of  spectra was set up in order to preserve only good looking spectra as shown in the fig 0 below. 

Fig 0   Good spectra for random strips in module=2. X-axis shows pedestal residua. It is shown to set a scale for the bad strips shown below. 


INPUT: 3M d-AU events from day ~336 of 2007.

All spectra were pedestals subtracted, using one value per strip, CAPS=123,124,125 were excluded. Below I'll use term 'ped' instead of more accurate pedestal residuum.

Method: fit slopes to ADC =ped+40,ped+90 or 5*sig(ped) if too low.

The spectra,  fits of pedestal residuum, and slopes were QAed.

QA method was set up as sequential series of cuts, upon failure later cuts were not checked.

Note, BSMD rate 4 had old resistors in day 366 of 2007 and was excluded from this analysis.
This reduces # of strips from 18,000 to 15,750 . 


Table 1 Definition of QA cuts
cut# cut code description # of discarded strips figure
1 1 at least 10,000 entries in the MPV bin 4 -
2  2  MPV position within +/-5 ADC channels  57 Fig 1
3 4  sig(ped) of gauss fit in [1.6,8] ADC ch 335 Fig 2
4 8  position of mean gauss within +/- 4 ADC  11 Fig 3
5 16  yield from [ped+40,ped+90] out of range 441 Fig 4
6 32  chi2/dof from slop fit in [0.6,2.5] 62 Fig 5
7 64  slopeError/slop >16% 4 Fig 6
8 128  slop within [-0.015, -0.05] 23 Fig 7
-  sum  out of processed 15,750 strips discarded  937 ==> 5.9%  



Fig 1 Example of strips failing QA cut #2, MPV position out of range , random strip selection


Fig 2a Distribution of width of pedestal vs. eta-bin

Fig 2b Example of strips failing QA cut #3, width of pedestal out of range , random strip selection

Fig 3a Distribution of pedestal position vs. eta-bin

Fig 3b Example of strips failing QA cut #4, pedestal position out of range , random strip selection

Fig 4a Distribution of yield from the slope fit range vs. eta-bin

Fig 4b Example of strips failing QA cut #5, yield from the slope fit range out of range , random strip selection

Fig 5a Distribution of chi2/DOF from the slope fit vs. eta-bin

Fig 5b Example of strips failing QA cut #6, chi2/DOF from the slope fit out of range , random strip selection

Fig 6a Distribution of err/slope vs. eta-bin

Fig 6b Example of strips failing QA cut #7, err/slope out of range , random strip selection

Fig 7a Distribution of slope vs. eta-bin

Fig 7b Example of strips failing QA cut #8, slope out of range , random strip selection


Fig 8a Distribution of # of bad strips per module. 

BSMDE modules 10,31,68  are damaged above  50%+. Ymax was set to 150, i.e. to the # of eat strips per module. Modules 16-30 served by crate 4 were not QAed. 

Fig 8b 2D Distribution of # of bad strips indexed by eta & phi strip location. Z-scale denotes error code from the 2nd column from table 1.

Fig 9 2D Distribution of slope indexed by eta & phi strip location.
TOP: slopes. There is room for gain improvement in the offline analysis. At fixed eta (vertical line) there should be no color variation.
BOTTOM error of slope/slope.

Fig 10 2D Distribution of pedestal and pedestal width indexed by eta & phi strip location.
TOP: pedestal
BOTTOM: pedestal width.

08) SMD-E gain equalization , ver 1.1

Goal : predict BSMD-E relative gain corrections for every eta bin 

Method : find average slope per eta slice, fit gauss, determine average slope : avrSlope(iEta)

Gain correction formula is used only for extreme deviations:  

  • gainCorr_i = slope_i/avrSlope(iEta),  i =1,..,18,000
  • if( fabs(1-gainCorr)<0.15) gainCor=1.0  // do not correct

Fig 1 Example of 2 eta slices


Fig 2 TOP: Slope distribution vs. eta-bin, average marked by crosses

BOTTOM: predicted gain correction. Correction=1 for strips w/ undetermined gains. 

Fig 3 Predicted gain correction. Correction=1 for ~14K of 18K strips.

Fig 4 The same predicted gain correction vs. stripID.

09) QA of SMD-P slopes, ver1.1

Automatic QA of BSMD-P minB spectra. 


  1. example of good spectra (fig 0)
  2. QA cuts definition (table 1) + spectra (figs 1-7)
  3. Result:
    1. # of bad strips per module. BSMD-P modules 1,4,59,75,85  are damaged above  50%+. (modules 16-30 served by crate 4 were not QAed). 
    2. eta-phi distributions of: slopes, slope error (fig 9) , pedestal, pedestal (fig 10) width _after_ QA
    3. sample of good and bad plots from every module, including modules 16-30 (PDF at the end)

The automatic  procedure doing QA of  spectra was set up in order to preserve only good looking spectra as shown in the fig 0 below. 

Fig 0   Good spectra for random strips in module=2. X-axis shows pedestal residua. It is shown to set a scale for the bad strips shown below. 


INPUT: 3M d-AU events from day ~336 of 2007.

All spectra were pedestals subtracted, using one value per strip, CAPS=123,124,125 were excluded. Below I'll use term 'ped' instead of more accurate pedestal residuum.

Method: fit slopes to ADC =ped+40,ped+90 or 5*sig(ped) if too low.

The spectra,  fits of pedestal residuum, and slopes were QAed.

QA method was set up as sequential series of cuts, upon failure later cuts were not checked.

Note, BSMD rate 4 had old resistors in day 366 of 2007 and was excluded from this analysis.
This reduces # of strips from 18,000 to 15,750 . 


Table 1 Definition of QA cuts
cut# cut code description # of discarded strips figure
1 1 at least 10,000 entries in the MPV bin 2 -
2  2  MPV position within +/-5 ADC channels  10 Fig 1
3 4  sig(ped) of gauss fit in [0.75,8] ADC ch 32 Fig 2
4 8  position of mean gauss within +/- 4 ADC  0 Fig 3
5 16  yield from [ped+40,ped+90] out of range 758 Fig 4
6 32  chi2/dof from slop fit in [0.55,2.5] 23 Fig 5
7 64  slopeError/slop >10% 1 Fig 6
8 128  slop within [-0.025, -0.055] 6 Fig 7
-  sum  out of processed 15,750 strips discarded  831 ==> 5.2%  



Fig 1 Example of strips failing QA cut #2, MPV position out of range , random strip selection


Fig 2a Distribution of width of pedestal vs. strip # inside the module. For the East side I cout strips as -1,-2, ...,-150.

Fig 2b Example of strips failing QA cut #3, width of pedestal out of range , random strip selection

Fig 3 Distribution of pedestal position vs. strip # inside the module 

Fig 4a Distribution of yield from the slope fit range vs. eta-bin

Fig 4b Example of strips failing QA cut #5, yield from the slope fit range out of range , random strip selection

Fig 5a Distribution of chi2/DOF from the slope fit vs. eta-bin

Fig 5b Example of strips failing QA cut #6, chi2/DOF from the slope fit out of range , random strip selection

Fig 6 Distribution of err/slope vs. eta-bin

Fig 7a Distribution of slope vs. eta-bin

Fig 7b Example of strips failing QA cut #8, slope out of range , random strip selection


Fig 8a Distribution of # of bad strips per module. 

BSMD-P modules 1,4,59,75,85  are damaged above  50%+. Ymax was set to 150, i.e. to the # of eat strips per module. Modules 16-30 served by crate 4 were not QAed. 

Fig 8b 2D Distribution of # of bad strips indexed by eta & phi strip location. Z-scale denotes error code from the 2nd column from table 1.

Fig 9 2D Distribution of slope indexed by eta & phi strip location.
TOP: slopes.  At fixed eta (horizontal line) there should be no color variation. red=dead strips
BOTTOM error of slope/slope. white=dead strip

Fig 10 2D Distribution of pedestal and pedestal width indexed by eta & phi strip location.
TOP: pedestal. dead strip have 0 residuum.
BOTTOM: pedestal width. white marks dead strips

10) SMD-P gain equalization , ver 1.1

Goal : predict BSMD-P relative gain corrections for every eta bin 

Method : find average slope per eta slice, fit gauss, determine average slope : avrSlope(iEta)

Gain correction formula is used only for extreme deviations:  

  • gainCorr_i = slope_i/avrSlope(iEta),  i =1,..,18,000
  • if( fabs(1-gainCorr)<0.10) gainCor=1.0  // do not correct

Fig 1 Example of 2 eta slices


Fig 2 LEFT: Slope distribution vs. eta-bin, average marked by crosses

RIGHT: predicted gain correction. Correction=1 for strips w/ undetermined gains. 

Fig 3 Predicted gain correction. Correction=1 for ~14K of 18K strips.

Fig 4 The same predicted gain correction vs. stripID.

12) investigating status of P-strips

The  plot below merges what we found w/ Matt in BSMDP West with  what  Oleg told us so far about know broken Anode wires.
Plot show is 2D location of all 9K strips. It is half of this plot shown before.
In color are various failure modes detected by our software processing minB spectra.
One narrow bar denotes one strip.
Module # is printed on the right.
Anode wire range is printed on the top.
Black labels A1, A3, etc are from Olegs table of known broken Anode wires from year 2007.
Conclusions for day 336 of 2007:
a) we do not see good signal from broken anode wires on BSMD-P West.
b) we see more broken anode wires/problems BSMD-P West
  module36: Anode12
 m54: A12
 m24: completely dead
 m30: mostly dead
 m29: odd strips dead
 m23: most of the odd strips dead
c) BSMD-P East is terra incognita - no  external info about any problems there
Problems listed in b) ,c) seems to be new for day 336 of 2007

Fig 1. West BSMD-P


Fig 2. East BSMD-P




13) ver 1.2 : SMD-E, -P, status & relative gains, no Crate4

Automatic BSMD-E, -P   relative calibration and status tables. 

The second pass through both SMDE, SMDP was performed, learning from previous mistakes.

Main changes:

  • relax most of the QA cuts
  • smooth raw spectra to reduce significance 1-2 channels wide  of spikes and deeps in raw spectra
  • extend slop fit range to ped +[30,100]
  • still do not use crate 4 - it has to many problems
  • reduce margin for gain correction - now 10%+ deviation is corrected.  

INPUT: 3M d-AU events from day ~336 of 2007.

All spectra were pedestals subtracted, using one value per strip, CAPS=123,124,125 were excluded. Below I'll use term 'ped' instead of more accurate pedestal residuum.

Method: fit slopes to ADC =ped+30,ped+100 or 5*sig(ped) if too low.

The spectra,  fits of pedestal residuum, and slopes were QAed.

Note, BSMD rate 4 had old resistors in day 366 of 2007 and was excluded from this analysis.
This reduces # of strips from 18,000 to 15,750 . 


Table 1 Definition of QA cuts, all plots (PDF1) 
cut# cut code description # of discarded E strips # of discarded P strips figure in PDF1
1 1 at least 10,000 entries in the MPV bin 4 ? -
2 2  sig(ped) of gauss fit <~13 ADC ch 13 11 Fig 1
3 4  position of mean gauss within +/- 4 ADC  10 8 Fig 2
4 8  yield from [ped+30,ped+100] out of range 513 766 Fig 3
5 16  chi2/dof<2.3 from slop fit  6 1 Fig 4
6 32  slopeError/slop >10% 5 0 Fig 5
7 64  slope in range 19 6 Fig 6
-  sum  out of processed 15,750 strips discarded  635 ==> 4.0%  789 ==> 5.0%  



Relative gain corrections for every eta bin 

Method : find average slope per eta slice, fit gauss, determine average slope : avrSlope(iEta)

Gain correction formula is used only for extreme deviations:  

  • gainCorr_i = slope_i/avrSlope(iEta),  i =1,..,18,000
  • if( fabs(1-gainCorr)<0.10) gainCor=1.0  // do not correct

PDF2 plots  shows: 

  • Fig 1  SMDE status table, distribution per module
  • Fig 2  SMDP status table, distribution per module
  • Fig 3  SMDE  gain corrections,  changed 3408 strips=22%
  • Fig 4  SMDP  gain corrections,  changed 2067 strips=13%

Summary of BSMDE,P status tales and gains , ver 1.2 

14 Eval of BSMDE status tables for pp 2008, day 49,50


 from _private_ production w/o zero BSMD suppression we look at pedestal residua for raw spectra for minb events.

chain="DbV20080703 B2008a ITTF IAna ppOpt VFPPV l3onl emcDY2 fpd ftpc  
trgd ZDCvtx NosvtIT NossdIT analysis Corr4 OSpaceZ2 OGridLeak3D  
beamLine BEmcDebug"


The only QA was to require  MPV of the spectrum is below 100, one run contains ~80K events.

Fig 1

Good spectra look like this:


Fig 2. Run 9049053, 80K events,

9,292 strips out of 15,750 tested were discarded by condition MPV>100 eve

TOP: MPV value from all strips. White means 0 (zero) counts. Crate 4 was not evaluated.
BOTTOM: status table: red=bad, white means MPV>100 events

Fig 3. Run 9050022, 80K events,

9,335 strips out of 15,750 tested were discarded by condition MPV>100 eve

TOP: MPV value from all strips. White means 0 (zero) counts
BOTTOM: status table: red=bad, white means MPV>100 events

Fig 4. Run 9050088, 80K events,

9,169 strips out of 15,750 tested were discarded by condition MPV>100 eve

TOP: MPV value from all strips. White means 0 (zero) counts
BOTTOM: status table: red=bad, white means MPV>100 events

15 stability of BSDM peds, day 47 is good

 Peds from run minB 17 were used as reference

Fig1 . pedestal residua for runs 17,29,31

Fig2 . pedestal residua for run 31, full P-plane

Fig3 . pedestal residua for run 31, full E-plane

Fig4 . pedestal residua for run 31, zoom in E-plane

Fig5 . pedestal residua for run 29, West, E-plane red, P-plane black, error=ped error


15a ped stability day 47, take 2

 On August 8, BSMD peds in the offline DB where corrected for day 47.

Runs minb 34 & 74 were used to determine and upload DB peds.

Below I evaluated pedestal residua for 2 runs : 37 & 70, both belonging to the same RHIC fill.

I have used 500 zero-bias events from runs 37 & 70, for the official production w/o zero suppression.

All strips for which  mTables->getStatus(iEP, id, statPed,"pedestal"); returns !=1 and all events using CAP123,124,125 were dropped.

Fig 1,2 show big picture: all 38,000 strips.

Fig 3 is zoom in on some small & big problems.

Fig 4 & 5 illustrates improvement if run-by-run pedestal is used. 

Fig 1, run=9047037


Fig 2, run=9047070


Fig 3, run=9047070, zoom in


Private peds were determine for 16 runs for day 47 and used appropriately. Below is sum of ped residua from all 16 runs, from zero bias events.

Fig 4, run=9047001,...,83 zoom in


Fig 5, run=9047001,...,83 full range


16) Time stability by fill of BSMD pedestals

I calculated the pedestals for every PP fill for 2008. This plot shows the pedestal per stripID and fill index. The Z-axis is the value of the pedestal. Only module 13 is shown here, but the full 2D histogram (and others) are in the attached root files.


17) Absolute gains , take1

 Goal: reco isolated gammas from bht0,1,2 -triggered events 

Method: identify isolated EM shower and match BSMD cluster energy to tower energy, as exercised earlier on 4) demonstration of absolute calib algo on single particle M-C 

INPUT events: 7,574 events triggered by barrel HT0,1,2 (id 220500 or 220510 or 220520) from run 9047029.

Cluster finder algo (sliding window, 1+3+1 strips),  smd cluster threshold set at 5 keV,  use only barrel West.

Tower cluster is defined as 3x3 patch centered on the tower pointed by the SMD peak.

Assumed BSMD calibration:  

  • ene(GeV)= (adc-ped)*1e-7, one constant for all barrel
  • pedestals, status tables hand tuned, some modules are disabled, but crate 4 is on

Results for ~3,8K barrel triggered events (half of 7,6K was not used)

Fig 1, Any  Eta-cluster

TOP: a) Cluster (Geant) energy;

b) Cluster RMS, peak at 0.5 is from low energy pair of isolated strips with almost equal energy

c) # of cluster per event, 

BOTTOM: X-axis is eta location, 20 bins span eta [-1,+1]. d) cluster ene vs. eta, e) cluster RMS vs. eta,

f) cluster yield vs. eta & phi, white bands are masked modules.

Fig 2, Any  Phi-cluster

see Fig 1 for details


Fig 3, Isolated EM shower

TOP: a) cluster loss on subsequent cuts, b) # of accepted EM cluster vs. eta location,

c) ADC distribution of 3x3 tower cluster centered at SMD cluster. In principle you should see there 3 edges from bht0, bht1, and bht2 trigger.

BOTTOM: X-axis is eta location, 20 bins span eta [-1,+1].d) Eta-cluster , e) phi-cluster energy, f) hit tower ADC .


Fig 4a,b, Calibration plots

TOP: BSMD Eta vs. Phi  as function of pseudorapidity.
BOTTOM: BSMD vs. BTOW as function of pseudorapidity.

2  eta location of 0.1, 0.5  of reco EM cluster  are shown in 3 panels (2x2)

1D plots are ratios of the respective 2D plots.

The  mean values of 1D fits are  relative gains of BSMDP/BSMDP and  BSMD/BTOW .


Fig 4c, Same as above, eta=0.9


18 Absolute gains, take 2

 Goal: reco isolated gammas from bht0,1,2 -triggered events 

Method: identify isolated EM shower and match BSMD cluster energy to tower energy, as exercised earlier on 4) demonstration of absolute calib algo on single particle M-C 

INPUT events: 100K events triggered by barrel HT0,1,2 (id 220500 or 220510 or 220520) from day 47, runs 1..83

Cluster finder algo (sliding window, 1+4+1 strips),  smd cluster threshold set at 10 keV,  use only barrel West, BSMD CR=4 masked out.

Tower cluster is defined as 3x3 patch centered on the tower pointed by the SMD peak, must contain 90% of energy from 5x5 cluster.

Default pedestals from offline DB used.

Assumed BSMD calibration: see table 1 column J+K  

Results for ~25K barrel triggered events (7/8 of 100K was not used)

 Fig 1 is above

Fig 2, Eta strips, any cluster

Fig 3 Phi strips, any cluster

Fig 4  isolated cluster (different sort). Plot c has huge peak at 0 - X-axis is chopped. Similar but smaller peak is in fig d. Magenta are event with bht0 and bht2 trigger.

Fig 5  isolated cluster :

Left: eta & phi plane coincidence--> works,

Right: eta & phi & tower 3x3>150 fials for modules 30-60, I have mapping problem?? 

Fig 6  Example of Eta vs. Phi  and SMD vs. Tower calibrations for eta bins 0.15, 0.5, and 0.85.

19) Absolute BSMD Calibration, table ver2.0, Isolated Gamma Algo description

 BSMD calibration algo has been developed based on M-C response of BSMD & towers to single gammas.

Executive summary:

The purpose of BSMD absolute calibration summarized at this drupal page is to reconstruct integrated energy deposit (dE) in BSMD based on measured ADC.
By integrated dE in BSMD I mean sum over few strips forming EM cluster, no matter what is the cluster shape.
This calibration method accounts for the varying absorber in front of BSMD and between eta & phi planes.
This calibration will NOT help in reconstruction:  
- full energy of EM particle which gets absorbed in BEMC ( shower development after BSMD layer does not matter for this calibration).
- partial energy of hadrons passing or showering in BEMC
- correct for the incident angle of the particle passing through detector
- saturation of BSMD readout. I only state up to which  loss (DE) the formula used in reconstruction:
      dE/GeV= (rawAdc-ped) * C0 * (1 +/- C1etaBin)
- determine sampling fraction (SF) of BSMD with high accuracy 

Below you will find brief description of the algo, side by side comparison of selected plots for M-C and real data, finally PDF with many more plots.

Proposed absolute calibration coefficients are show in table 2.


Part 1

Description of algorithm finding isolated gammas in the Barrel.

Input events

  • M-C :  single gamma per event, 6 GeV ET, flat in eta, phi covers 3 barrel modules 12,13,14, geometry=y2006
  • DATA: BHT0,1,2 triggered pp 2008 events from day 47, total 100K, individual triggers: 44K, 33K, 40K, respectively
    events were privately produced w/ zero suppression.

Raw data processing based on muDst

  • M-C : BSMD - take geant energy deposit  ~100 keV range, towers - take ADC*0.493 to have nominal calibration of 4070 ADC=60 GeV ET.
  • Data : BSMD - use private  pedestals & status tables for day 47, use custom calibration
    use BSMD calibration dE/GeV= (rawAdc-ped) * C0 * (1 +/- C1etaBin), where '+' is for Phi-plane and '-' for eta plane, see table below
    skip strips 4 sigma above ped or with energy below 1keV, strip to strip relative gains NOT used , data from CAPs=123,124,125 were not used
     towers- take ADC as is, no offline gains correction.

Cluster finder algo (seed is sliding fixed window), tuned on M-C gamma events

  • work with 150 Eta-strips per module or 900 Phi-strips at fixed eta
  • all strips are marked as 'unused'
  1. sum  dE in fixed window of 4 unused strips, snap at location which maximizes the energy
  2. if sum below 10 keV STOP searching for clusters in this band
  3. add energy from one strip on each side, mark all 1+4+1 strips as 'used'
  4. compute energy weighted  cluster position and RMS
  5. goto 1

This cluster finder process full Barrel West, more details about clustering is in one cluster topology , definition of 'barrel cell' 

Isolated EM shower has been selected as follows, tuned on gamma events,

  • select isolated eta-cluster in every segment of 15 eta strips.
  • require cluster center is at least 3 strips away from edges  of this segment (defined by eta values of 0.0, 0.1, 0.2,....0.9, 1.0)
  • require there is only one phi-cluster in the same 0.1x0.1 eta.phi cell
    • require phi-cluster center is at least 3 strips from the edges
  • find hit tower matching to the cross of eta & phi cluster
  • sum tower energy from 3x3 patch centered on hit tower
    • require 3x3 tower  ADC sum >150 ADC (equivalent to 2.2 GeV ET, EM)
  • sum tower energy from 5x5 patch centered on hit tower
    • require 3x3 sum/ 5x5 sum >0.9  
  • require RMS of Phi & Eta-cluster  is above 0.2 strips

 Below is listing of all cuts used by this algo:

  useDbPed=1; // 0= use my private peds
  par_skipSpecCAP=1; // 0 means use all BSMD caps
  par_strWinLen=4; (3)  // length of integration window, total  1+4+1, in strips
  par_strEneThr=1.e-6;  (0.5e-6) // GeV, energy threshold for strip to start cluster search
  par_cluEneThr=10.0e-6; (2.0e-6) // GeV, energy threshold for cluster in window
  par_kSigPed=4.; (3) // ADC threshold
  par_isoRms=0.2;  (0.11) // minimal smd 1D cluster RMS 
  par_isoMinT3x3adc=150; //cut off for low tower response
  par_isoTowerEneR=0.9; //  ratio of 3x3/5x4 cluster
(in red are adjusted values for MIP or ET=1GeV cluster selection)  

 Table 1 Tower cluster cut defines energy of isolated gammas.

3x3 tower ET (GeV), trigger used MIP, BHT0,1,2 1.0, BHT0,1,2

3.4, BHT0

4.7, BHT1

5.5, BHT2

7, BHT2

3x3 tower ADC sum range 15-30 ADC 50-75 ADC 170-250 ADC 250-300 ADC 300-380 ADC 400-500 ADC
3x3 energy &  RMS (GeV) @ eta=[0.1,0.2] 0.34 +/- 0.06 0.92 +/- 0.11 3.1 +/- 0.3 4.1 +/- 0.2 5.1 +/- 0.3 6.6 +/- 0.4
3x3 energy &  RMS (GeV) @ eta=[0.4,0.5] 0.37 +/- 0.07 1.0 +/- 0.11 3.4 +/- 0.4 4.6 +/- 0.3 5.6 +/- 0.4 7.3 +/- 0.5
3x3 energy &  RMS (GeV) @ eta=[0.8,0.9] 0.47 +/- 0.09 1.3 +/- 0.16 4.3 +/- 0.4 5.7 +/- 0.3 7.1 +/- 0.5 9.3 +/- 0.6


Table 2 shows assumed calibration.   

Contains relative calibration  of eta vs. phi plane, different for M-C vs. data,
and single absolute DATA normalization of the ratio of SMD (Eta+Phi) cluster energy vs. 3x3 tower cluster at eta=0.5 .

Table 3 shows what comes from data & M-C analysis using calibration from table 2.


Part 2

Side by side comparison of M-C and real data. 

Fig 2.1 BSMD "Any cluster" properties

TOP : RMS vs. energy, only Eta-plane shown, Phi-plane looks similar
BOTTOM: eta -phi distribution of found clusters. Left is M-C - only 3 modules were 'populated'. Right is data, white bands are masked modules or whole BSMD crate 4



Fig 2.2  Crucial  cuts after coincidence & isolation was required for a pair BSMD Eta & Phi clusters 

TOP :  3x3 tower energy (black), hit-tower energy (green) , if 3x3 energy below 150 ADC cluster is discarded
BOTTOM: eta dependence of 3x3 cluster energy. M-C has 'funny' calibration - there is no reason for U-shape, Y-value at eta=0.5 is correct by construction.

Fig 2.3  None-essential cuts, left by inertia 

TOP :  ratio of 3x3 tower energy to 5x5 tower energy ,  rejected if below 0.9 
BOTTOM:  RMS of Eta & Phi cluster must be above 0.2, to exclude single strip clusters

Part 3

Examples of relative response of BSMD Eta vs. Phi AFTER  calibration above is applied. 

I'm showing examples for 3 eta slices of 0.15, 0.55, 0.85 -  plots for all eta bins  are available as PDF, posted in Table 2 at the end.

The red vertical line marks the target calibration, first 2 columns are aligned by definition, 3rd column is independent measurement confirming calibration for data holds for ~40% lower gamma energy.

Fig 3.1 Phi-cluster vs. Eta cluster for eta range [0.1,0.2]. M-C on the left, data in the middle, right.

Fig 3.2 Phi-cluster vs. Eta cluster for eta range [0.4,0.5]M-C on the left, data in the middle, right.

Fig 3.3 Phi-cluster vs. Eta cluster for eta range [0.8,0.9]M-C on the left, data in the middle, right.

Fig 3.4 Phi-cluster vs. Eta cluster for eta range [0.9,1.0]M-C on the left, data in remaining columns.


Part 4

Absolute response of BSMD (Eta + Phi) vs. 3x3 tower cluster,  AFTER  calibration above is applied. 

I'm showing eta slices [0.4,0.5] used to set absolute scale. The red vertical line marks the target calibration, first 2 columns are aligned by definition, 3rd column is independent measurement  for gammas with ~40% lower --> BSMD response is NOT proportional to gamma energy.

Fig 4.1 Phi-cluster vs. Eta cluster for eta range [0.4,0.5]. Only data are shown.

Fig 4.2 Absolute BSMD calibration for eta range [0.0,0.1] (top) and eta range [0.1,0.2] (bottom) . Only data are shown.
Left: Y-axis is BSMD(E+P) cluster energy, y-error is error of the mean; X-axis 3x3 tower cluster energy, x-error is RMS of distribution . Fit (magenta thick) is using only to 4 middle points - I trust them more. The MIP point is too high due to necessary SMD cluster threshold, the 7GeV point has very low stat. There is no artificial point at 0,0. Dashed line is extrapolation of the fit.
Right: only slope param (P1) from the left is used to compute full BSMD Phi & Eta-plane calibration using formulas:

slope P1_Eta=P1/2./(1-C1[xCell])/C0
slope P1_Phi=P1/2./(1+C1[xCell])/C0
Using C1[xCell],C0 from table 2.

Fig 4.3 Absolute BSMD calibration for eta range [0.2,0.3] (top) and eta range [0.3,0.4] (bottom) . Only data are shown, description as above.

Fig 4.4 Absolute BSMD calibration for eta range [0.4,0.5] (top) and eta range [0.5,0.6] (bottom) . Only data are shown, description as above.

Fig 4.5 Absolute BSMD calibration for eta range [0.6,0.7] (top) and eta range [0.7,0.8] (bottom) . Only data are shown, description as above.

Fig 4.6 Absolute BSMD calibration for eta range [0.8,0.9] (top) and eta range [0.9,0.95] (bottom) . Only data are shown, description as above.

I'm showing the last eta bin because it is completely different - I do not understand it at all. It was different on all plots above - just reporting here.

Fig 4.7 Expected BSMD gain dependence on HV, from  Oleg document The 2008 working HV=1430 V (same for eta & phi planes) - in the middle of the measured gain curve.

 Part 5

Possible extensions of this algo.

  1. cover also East barrel (for the cross check)
  2. include vertex correction in projecting SMD cluster to tower (perhaps)
  3. study energy resolution of eta & phi plane - now I just compensated relative gains but the total BSMD energy is simply sum of both planes
  4. last eta bin [0.9,1.0] is completely different, e.g. there is no MIP peak in the 2D fig 2.2 - BTOW gain (HV) is factor 2 or more way too high in this 2 bins 
    Inspect right plot on figures 4.2,...,4.6, in particular note at what gamma energy the blue line reaches ADC of 1000 counts. Look at this pattern vs. eta bin. On the last plot it should happen at gamma energy of ~5 GeV but in reality it is at ~10 GeV.    
  5. crate 4 (unmodified) would have different gains - excluded in this analysis
  6. Speculation: those multiple peaks in raws BSMD spectra (seen by others) could be correlated with BHT0,1,2 triggers
  7. Scott suggestion: more detailed study of BSMD saturation could use BSMD cluster location for fiducial cut forcing gamma to be in the tower center and use just the hit tower. This needs more stats. This analysis uses 1 day of data and ends up with just ~100 entries per energy point.
  8. non-linear BSMD response does not mean we can reco cluster position with accuracy better than 1 strip.



Fig 5.1 BSMD cluster energy vs. eta of the cluster.



Fig 5.2 hit tower to 3x3 cluster energy for accepted clusters. DATA, trigger BHT2, gamma ET~5.5 GeV.



Fig 5.3 hit tower to 3x3 cluster energy for accepted clusters. M-C, single gamma ET=6 GeV, flat in eta .


20 BSMD saturation

 The isolated BSMD cluster algo allows to select different range of tower energy cluster as shown in Fig.1

Fig 1. Tower energy spectrum, marked range [1.2,1.8] GeV.

In the analysis 5 energy tower slices were selected: MIP, 1.5 GeV, and around BHT0,1,2 thresholds.

Plots below show example of calibrated BSMD (eta+phi) cluster energy vs. tower cluster energy. (I added point at zero with error as for next point to constrain the fit) 

Fig 2. BSMD vs. tower energy for eta of 0.15, 0.55, and 0.85.

I'm concern we are beyond the middle of BSMD dynamic range for ~6 GeV (energy) gammas at eta 0.5. Also one may argue we se already saturation.

If we want BSMD to work up to 40 GeV ET we need to think a lot how to accomplish that.

Below is dump of one event contributing to the last dot on the middle plot. It always help me to think if I see real raw event.

  i=526, smdE-id=6085 rawADC=87.0 ped=71.4  adc=15.6 ene/keV=0.9
  i=527, smdE-id=6086 rawADC=427.0 ped=65.0  adc=362.0 ene/keV=20.0
  i=528, smdE-id=6087 rawADC=814.0 ped=71.8 adc=742.2 ene/keV=41.0
  i=529, smdE-id=6088 rawADC=92.0 ped=66.4  adc=25.6 ene/keV=1.4

  i=422, smdP-id=6086 rawADC=204.0 ped=99.3  adc=104.7 ene/keV=7.8
  i=423, smdP-id=6096 rawADC=375.0 ped=98.5  adc=276.5 ene/keV=20.3
  i=424, smdP-id=6106 rawADC=692.0 ped=100.1  adc=591.9 ene/keV=47.3

2D cluster
bsmdE CL  meanId=6086 rms=0.80 ene/keV=66.80 inTw 1632.or.1612 
bsmdP CL  meanId=6106 rms=0.68 ene/keV=75.45 inTw 1631.or.1632 

  id=1631 rawADC=43.0 ene=0.2 ped=30.0,  adc=13.0
  id=1632 rawADC=401.0 ene=6.9 ped=32.4  adc=368.6
  id=1633 rawADC=43.0 ene=0.1 ped=35.5   adc=7.5

tow3x3 sum=405.7 ADC


1) M-C : response of BSMD , single particles (Jan)

 Below are studies of BSMD response and calibration algo based on BMSD response to single particle M-C

1) BSMD-E clusters, sliding max, fixed width

 Goal: study SMDE energy resolution and cluster shape for single particles M-C

Input: single particle per event, fixed ET=6 GeV, flat eta [-0.1,1.1], flat  |phi| <5 deg, 500 eve per sample, Geant geometry y2006

Cluster finder algo (sliding fixed window), tuned on electron events

  • work with 150 Eta-strips per module
  • sum geant dE in fixed window of 4 strips
  • maximize the sum, compute energy weighted  cluster position and RMS inside the window
  • algo quits after first cluster found in given module 

Example of BSMDE response for electon:

McEve BSMD-E dump, dE is Geant energy sum from given strip, in GeV

  dE=1.61e-06  m=104 e=12 s=1 stripID=15462  

  dE=2.87e-05  m=104 e=13 s=1 stripID=15463

  dE=8.35e-06  m=104 e=14 s=1 stripID=15464

  dE=1.4e-06  m=104 e=15 s=1 stripID=15465

 ALL plots below have energy in keV , not MeV - I'll not change plots.


Fig 1. gamma - later, job crashed.

Fig 2. electron


Fig 3. pi0


Fig 4. eta


Fig 5. pi minus


Fig 6. mu minus

2) BSMDE , 1+3+1 sliding cluster finder

 Goal: test SMDE cluster finder  on single particles M-C

Input: single particle per event, fixed ET=6 GeV, flat eta [-0.1,1.1], flat  |phi| <5 deg, 5k eve per sample, Geant geometry y2006

Cluster finder algo (seed is sliding fixed window), tuned on pi0 events

  • work with 150 Eta-strips per module
  • all strips are marked as 'unused'
  • use only module 13, covering ~1/3 of probed phase space
  1. sum geant dE in fixed window of 3 unused strips, snap at location which maximizes the energy
  2. if sum below 5 keV STOP searching for clusters in this module
  3. add energy from one strip on each side, mark all 1+3+1 strips as 'used'
  4. compute energy weighted  cluster position and RMS
  5. goto 1

Example of BSMDE response for pi0:

strID=1932 u=0 ene/keV=0
strID=1933 u=1 ene/keV=0    +
strID=1934 u=1 ene/keV=2.0  *
strID=1935 u=1 ene/keV=48.2 *X
strID=1936 u=1 ene/keV=3.9  *
strID=1937 u=1 ene/keV=0.8  +
strID=1937 u=0 ene/keV=0
strID=1938 u=0 ene/keV=0
strID=1939 u=2 ene/keV=1.5  +
strID=1940 u=2 ene/keV=8.2  *
strID=1941 u=2 ene/keV=28.1 *X
strID=1942 u=2 ene/keV=13.8 *
strID=1943 u=2 ene/keV=4.0  +
strID=1944 u=0 ene/keV=5.6  
strID=1945 u=0 ene/keV=0.5
strID=1946 u=0 ene/keV=0
strID=1947 u=0 ene/keV=0




any cluster found in the module, all events

Fig 1a

only events with exactly 2 found clusters 

Fig 1b


. Fig 2a Fig 2b


. Fig 3a Fig 3b



3) same algo applied to full East BSMDE,P


Smd cluster finder with sliding window of 3 strips + one strip on each end (total 5 strips) applied to all 9000 BSMDE,P strips, one gamma per event





4) demonstration of absolute calib algo on single particle M-C

 Goal: determine absolute calibration of BSMDE,P planes

Method: identify isolated EM shower and match BSMD cluster energy to tower energy

INPUT events: single particle per event, fixed ET=6 GeV, flat eta [-0.1,1.1], flat  |phi| <5 deg, 5k eve per sample, Geant geometry y2006

Cluster finder algo (seed is sliding fixed window), tuned on pi0 events

  • work with 150 Eta-strips per module or 900 Phi-strips at fixed eta
  • all strips are marked as 'unused'
  • use only module 13, covering ~1/3 of probed phase space
  1. sum geant dE in fixed window of 3 unused strips, snap at location which maximizes the energy
  2. if sum below 5 keV STOP searching for clusters in this module
  3. add energy from one strip on each side, mark all 1+3+1 strips as 'used'
  4. compute energy weighted  cluster position and RMS
  5. goto 1

This cluster finder process full Barrel West, more details about clustering is in one cluster topology , definition of 'barrel cell' 

Isolated EM shower has been selected as follows, tuned on gamma events,

  • select isolated eta-cluster in every segment of 15 eta strips.
  • require cluster center is at least 3 strips away from edges  of this segment (defined by eta values of 0.0, 0.1, 0.2,....0.9, 1.0)
  • require there is only one phi-cluster in the same 0.1x0.1 eta.phi cell
  • require phi-cluster center is at least 3 strips from the edges
  • find tower matching to the cross of eta & phi cluster
  • require this tower has ADC>100

Example of EM cluster passing all those criteria is below:

smdE: ene/keV= 40.6   inTw 451.or.471
 cell(15,12),   jStr=7 in xCell=15
id=1731  ene/keV=4.9  *
id=1732  ene/keV=34.3  X *
id=1733  ene/keV=1.5  *
---- end of SMDE dump

smdP: ene/keV= 28.5  inTw 471.or.472
  cell(15,12),   jStr=7 in xCell=15
id=1746  ene/keV=2.7  *
id=1756  ene/keV=22.0  X *
id=1766  ene/keV=3.7  *
---- end of SMDE dump

muDst BTOW
  id=451, m=12 rawADC=12.0 
* id=471, m=12 rawADC=643.0
  id=472, m=12 rawADC=90.0 
  id=473, m=12 rawADC=10.0 

 Results for gamma events

will be show with more details. The following PDF files contain full set of plots for all other particles.



# of eve  plots
gamma 25K  PDF
e- 50K  PDF
pi0 50K  PDF
eta 50K  PDF
pi- 50K  PDF



Fig 1, Any  Eta-cluster, single gamma,  25K events

TOP: a) Cluster (Geant) energy; b) Cluster RMS, c) # of cluster per event, 

BOTTOM: X-axis is eta location, 20 bins span eta [-1,+1]. d) cluster ene vs. eta, e) cluster RMS vs. eta, f) cluster yield vs. eta & phi.

Fig 2, Any  Phi-cluster, single gamma,  25K events

see Fig 1 for details


Fig 3, Isolated EM shower, single gamma,  90K events

TOP: a) cluster loss on subsequent cuts, b) # of accepted EM cluster vs. eta location, c) ADC distribution of hit tower (some wired gains are in default M-C), tower ADC is in ET

BOTTOM: X-axis is eta location, 20 bins span eta [-1,+1]. d) Eta-cluster , e) phi-cluster energy, f) hit tower ADC .


Fig 4, Calibration plots, single gamma,  90K events.

TOP: BSMD Eta vs. Phi  as function of pseudorapidity.
BOTTOM: BSMD vs. BTOW as function of pseudorapidity.

3  eta location of 0.1, 0.5, 0.9 of reco EM cluster  are shown in 3 panels (2x2)

1D plots are ratios of the respective 2D plots.

The  mean values of 1D fits are  relative gains of BSMDP/BSMDP and  BSMD/BTOW , determine for 10 slice in pseudorapidity. Game is over :).


Fig 5, Same as above, eta=0.1, single pi0, 50K events.


Fig 6, Same as above, eta=0.1, single pi minus, 50K events.


Below are PDF plots for all particles:

Correction - label on the X-axis for 1D plots is not correct. I did not apply log10() - a regular ratio is shown, sorry.

5) Evaluation of BSMD dynamic range needed for the W program at STAR, ver 1.0

M-C  study of BSMD response to high energy electrons


Attachment 1:

Fig 1 & 2  reminds actual (pp data based) calibration for 2 eta location of 0.1 and 0.8, presented earlier.

Table 1 shows  M-C simulation of average cluster energy (deposit in BSMD plane), its spread, and  width as function of electron ET, separately for eta- & phi-planes of BSMD.
As expected, BSMD sampling fraction (SF, red column)  is not constant but drops with energy of electron.
The BSMD SF(ET) deviates from constant by less then 20% - it is a small effect.

Fig 3,4,5 show expected BSMD response to M-C electrons with ET of 6,20, and 40 GeV. Only for the lowest energy  the majority of EM showers fit in to the dynamic range of BSMD, which ends for energy deposit of about 60 keV per plane.
I was trying to be generous and draw the red line at DE~90 keV .
The rms of BSMD cluster is about 0.5 strips, so majority of energy is measured by just 2 strips (amplifiers). Such narrow cluster lowers  saturation threshold.

Fig 6, shows BSMD cluster energy for PYTHIA W-events.
Fig 7 shows similar response to PYTHIA QCD events.

Compare area marked with red oval - there is strong correlation between BSMD energy and electron energy and would be not wise to forgo it in the e/h algo.  


The attached slides show 2008 HV setting of BSMD would lead to full saturation of BSMD response for electrons from W decay with ET as low as 20 GeV , i.e. would reduce BSDM dynamic range to 1 bit.0


For the reference:

* absolute BSMD calibration based on 2008 pp data.

* current BSMD HV are set very high , leading to saturation of BSMD at gamma energy of 7-10 GeV, depending on eta and plane. (Lets ignore difference between E & ET for this discussion, for now).

*  STAR priorities for 2009 pp run presented at Apex:

* Attachment 2,3 show BSMD-E, -P response for electrons with  ET: 4,6,8,10,20,30,40,50 GeV and to Pythia W, QCD events (in this order)

Definition of absolute BSMD calibration


Definitions of quantities used for empirical calibration of BSMD.

Revised January, 26, 2009

A) Model of the physics process (defines quantities: E, eta, smdE, smdEp, smdEe, C0, C1)

  1. gamma particle with fixed energy E enters projectively EMC at fixed pseudo-rapidity eta. Eta is defined in detector ref. frame.
  2. EM showers develops and BSMD (consisting of 2 planes) captures smdEtot of shower energy. Single plane captures smdE=0.5*smdEtot. The SMD cluster energy from single plane is denoted as smdE.
  3. SMD consist  of 2 planes : eta-plane closer to IP and the outer phi-plane. Each plane captures non-equal fraction ofenergy  deposited in BSMD: smdEp, smdEe, respectively.  

    The following relation holds:
                 smdEp(E,eta) =smdE(E) * [1-C1(eta)] 
                 smdEe(E,eta) =smdE(E) * [1+C1(eta)] 

    where  theta-dependent coefficient C1 accounts for all physical processes differentiating fraction of captured shower energy by eta vs. phi-planes along Z-direction. 
    allows reconstruction of full BSMD energy deposit independent on gamma angle theta if cluster energy in both plane is measured 
  4. BSMD Cluster energy is measured in each plane by few consecutive strips which:
    1. response is linear and
    2. strip-to-strip local  hardware gain variation is negligible (the "long-wave" is accounted for in C1(theta))
      Note, there are 4 low gain strip (id=50,100) in the eta-plane , seen in fig 2 of 08) SMD-E gain equalization , ver 1.1, which require ADC to be rescaled appropriately.

  5. The overall conversion constant C0=6.5e-8 (GeV/ADC chan) allows reconstruction of BSMD cluster energy in given plane based on the sum of ADCs from all strips participating in the cluster  
             smdEp(E,eta)=C0* sum{ ADC_i - ped_i}, over cluster of few strips , similar formula for smdEp(E,eta)=....
    The value of C0 was determined based on 19) Absolute BSMD Calibration, table ver2.0, Isolated Gamma Algo description, table 2. Gammas with ET=6 GeV were thrown at EMC and resulting SMD cluster ADC sum was matched to the average value seen for 2008 pp data.
  6. To summarize
    The reconstructed cluster energy in each plane with use of C0 & C1 should have eta dependence 

                 smdE(E) =C0* sum{ ADC_i - ped_i}/[1-C1(eta)] for phi-plane cluster

                 smdE(E) =C0* sum{ ADC_j - ped_j}/[1+C1(eta)]  for eta-plane cluster

    Those 2 quantities are well suited to place cuts. 

B) Determination of C1(eta) was based on 19) Absolute BSMD Calibration, table ver2.0, Isolated Gamma Algo description, from crates 1,2,and 4. 

Data analysis was done for 10 pseudo-rapidity  ranges [0,0.1], [0.1,0.2] ,..., as shown in table 2, row labeled 'DATA'. 

For practical application analytical approximation is provided

    C1(eta)= C1_0 + C1_1*|eta| + C1_2*eta*eta

symmetric versus positive/negative pseudo-rapidity.  

The numerical values of expansion coefficients are: C1_0=0.014, C1_1=0.015, C1_2=0.333


C) Modeling of BSMD response in STAR M-C

  1. find  geantDE geant energy deposit for given BSMD strip
  2. undo simulated by GEANT +/-7% difference between eta/phi planes (see 19) Absolute BSMD Calibration, table ver2.0, Isolated Gamma Algo description, row 'M-C') 
  3. compute ADC for every i-th strip & plane
        ADCp_i= geantDEp/[1-C1(eta)]/C0 
        ADCe_i= geantDEe/[1+C1(eta)]/C0
    1. If NO saturation is assumed that is all - use ADC-values in reconstruction.
    2. To simulate full ADC saturation at 1024 assume pedestal is at ADC=100 and saturate values of ADCp_i, ADCe_i at 924. Then proceed to reconstruction.  


Mapping, strip to tower distance

For every strip we find the closest tower and determine the distance between tower center and strip center.

Both plots show strip ID on the X-axis, and tower ID on the Y-axis. Error in Y is distance between centers in CM.

It is not true 15 eta strips covers every 2 towers! It is only approximate since strip pitch is constant bimodal and tower width changes continuously.

There is still small problem, namely strip Z is calculated at R_smd and tower Z is calculated at the entrance of the tower

leading to clear paralax error - we are working on this. 

Fig 1.

Top plots is for SMDE for module 1. Note E-strip always spans 2 towers and we used tower IDs in one module.

Bottom plots shows phi strips for module 1. 



Fig 2.

Top plots is for SMDE for modules 1-4. 

Bottom plots shows phi strips for modules 1-4.




Run 10 BSMD Calibrations

Parent page for BSMD Run 10 Calibration

BSMD Status Table in run10 AuAu200GeV runs


We started this task by looking at BSMD in Run 10 with some MuDst files, and found the pedestals probably need to be QA-ed as well.



Then we started to look for Non-zero-suppressed BSMD data, and found that we have to run through the daq files to produce the NZS data files to produce the NZS data. The daq files are stored on HPSS, and we have to transfer them onto RCF. The transferred daq files were then made into root files with Willim's BSMD online monitering codes.


We decided to use same critiria and status codes as Willim used for run09 pp500GeV.


We discovered that a modification is needed to the critiria of code bit 3 (the ratio of the integral over a window to the integral over all, i.e. the pedestal integral ratio) We found about half of the BSMD strips fail the criteria of this ratio > 0.95, but nearly most of them satisfy ratio > 0.90, so the critiria is loosed to 0.90. We think this is a reasonable difference between run09 pp and run10 AuAu collisions.


The daq files are huge in size, on the order of TB for one day. In order to not disturb the run10 data production, we had to only copy 1/10~1/20 of the daq files.


After a long period of transffering and root files making, almost all the days between Jan/02/2010 and Mar/17/2010 are done.

We found that another criteria has to be modified, because we use NZS data for the QA of the tail of ADC spectrum. The definition of the tail ranges and the limits are adjusted. Three ranges of the tail part of ADC are defined,

Range 1:peak+6*rms to peak+6*rms+50 channels
Range 2:6*rms+50 channels to 6*rms+150 channels
Range 3:6*rms+150 channels to 6*rms+350 channels

The entries (hits) in these three ranges are counted, and the ratios to all the entries in the whole spectrum are calculated. The limits for good ratios are selected based on the ratios distribution trough out all the days. They are

@font-face {
font-family: "Cambria";
}p.MsoNormal, li.MsoNormal, div.MsoNormal { margin: 0in 0in 0.0001pt; font-size: 12pt; font-family: "Times New Roman"; }div.Section1 { page: Section1; }

Range 1: 3.35~80 x0.001

Range 2: 0.95~40 x0.001

Range 3: 0.25 ~ 20 x0.001

See the attached newlimits.docx for more details and plots.

Also, bit 0 of the status code is supposed to indicate whether a channel is bad or not. Not every problem is fatal, i.e cause the channel to be regarded as bad.

Originally, only if all the 3 ratios are beyond the limits, a fetal condition is met; we addjusted this to be if more than one, i.e. >=2, out of the 3 ratios are beyond the limits, a fetal condition is met. One can also treat any channel with a code not equal to 1 as bad, regardless what the bit 0 is.



A final report with sample codes in one day was presented to and approved by EMC2 group.


Note: The map file used in bsmd montoring in run10 was with some inconsistence with the acctual hardware. An after-burn map correction was done by the EMC software coordinator, Justin.

Note: Up to now, no corrections are made to pedestals. The bad strips caused by bad pedestals are rouphly 1/3~1/4 of all the bad strips.

Wenqin Xu


Run 9 BSMD Calibration

Parent page for BSMD Run 9 Calibration

01 Status of BSMDE,P at the end of pp 500 GeV run, April of 2009

Summary of BSMD performance on April 6. Input : 200K events tagged by L2W clust ET>13 GeV, days 85-94, ~all events, only ZS data are shown.

Attached PDFs shows zoom in spectra for individual modules. 1st page is summary, next I show 3 modules per row, 5 rows per page. Even pages shows zoom-in for low ADC<100, odd pages shows full ADC scale. Common maxZ=1000 is used for all plots , except page 1. 

02 offline QA of BSMD pp 500, ver1 (Willie+Jan)

 BSMD QA algorithm and results for pp 500, tune optimized for high energy  energy response

  1. QA method, details are given in Willie's blog
    Fig 1. Typical good/bad strips from the E-plane and with wide pedestals. 
    • Input: all available events from fills 10399, 10402, 10403, 10404, 10407, 10412, 10415 added together
    • evaluate shape of pedestal residua for  NZS data captured on-line by Willie's daq reader  (Blue filled histo)
    • evaluate yield in high energy range (ADC ~300,500,800) using ZS data from L2W triggered events (Magenta line-only)
    • ignored: satellite spikes around  pedestal at ADC ~32, those come from correlated noise and (most likely) such events will be discarded.
    • Example of such spectra for few strips is shown in fig 1.
    • Encoding of BSMD status bits extends existing convention to use LSB=1 for good strips and LSB=0 for bad strips. We used bits 1,2,3 to tag pedestal problems and bits 5,6,7 to tag yield problems. 
    • More plots with individual strips is in attachment A,B,C,D.
  2. Bad strip is defined as having : bad pedestal or god pedestal but no yield above it.

    Fig 2. Distribution of bad strips from both planes, details about each plane separately is in attachment E.
  3. The remaining issues:
    1. of tagging 'spiked' events (or modules?) needs to be investigated.
    2. study time dependence
  4. For the reference this directory contains PDF files with plots from all 120 BSMD modules.


Fig 3. # of bad strips per module.


03 correlated, small ADC spikes in BSMD (Jan)

Study of small ADC spikes in BSMD 


  •  all available events from fills 10399, 10402, 10403, 10404, 10407, 10412, 10415 added together
  • pedestal residua for  NZS data captured on-line by Willie's daq reader  (Blue filled histo)
  •  ZS data from L2W triggered events (Magenta line-only)

The following plots support those observation:

  1. spikes are symmetric on both sides of pedestals peak, separated by 2^N ADC counts, narrower than pedestal peak, (Fig1)
  2. spikes are correlated in even ID (or odd) strips the same plane, correlation is local, Fig 2 
  3. spikes are correlated between P-plane & E-plane strips, Fig 3
  4. energy deposit in BSMD increases probability of spikes, see peak/valley for blue vs. magenta in fig 1b.
  5. bands are visible at larger ADC, as shown by Oleg, not sure what data and how many events, fig 4 
  6. perhaps fig 1c shows yet another pathology, because it does not obey odd/even rule in fig 1a & 1b.


Fig 1a. Example of spikes delADC=16, in the vicinity of strip 1525-P, all strips from module 11 are shown in attachment A.

Fig 1b. Example of spikes delADC=32, in the vicinity of strip 1977-P, all strips from module 14 are shown in attachment B, module 22 looks similar.

Fig 1c. Example of spikes delADC=128, in the vicinity of strip 4562-P, all strips from module 31 are shown in attachment C, modules 51,52,57  look similar

Fig 2. Phi-Phi plane correlation of P-strip 1979 with (odd)  P-strips: 1977..1994. Attachment D contains correlation of P-strips [1977-80] with  24  strips in proximity. 

Fig 3. Phi-Eta plane correlation of P-strip 1979 with (odd)  E-strips: 1977..1994. Attachment E contains correlation of P-strips [1977-80] with  24  strips in proximity. 


Fig 4.Oleg observed this stripes in raw BSMD ADC spectrum, not sure what data.

2009 BSMD Relative Gains Information

The pdf posted here has a good overview of the computation of the slope for each strip, discussing the method and the various ways in which strips were marked as bad.  This page discusses the computation of the actual relative gains and statuses that went into the database.

The code used to compute the relative gains is archived at /star/institutions/mit/wleight/archive/bsmdRelGains2009/.

DELETE - Run 9 BSMD Status Update 3 (4/24)

After looking more closely at the crate 1 channels I was forced to make serious revisions to status bit 2 from the previous update.  The new status bit 2 test is as follows:

First, I scan through the strip ADC distribution looking for peaks.  A peak is defined as a channel that is greater than or equal to the four or two channels to either side (if the sigma of the fit to the strip ADC distribution is greater than or less than six, respectively), has a content that is greater than 5% of the maximum of the strip ADC distribution, and has a depth greater than 5% of the maximum of the strip ADC distribution.  The depth is calculated by first calculating the difference between the peak content and the channel content for each of the four or two channels on either side of the peak.  The maximum of these differences is obtained for the left and right sides separately, and the depth is then equal to the lesser of these two maxima.

If the strip has more than one peak and the maximum of the depths is greater than 20% of the maximum of the strip ADC distribution, then the strip is given bad status 2.  If the strip has only one peak (which is then necessarily the maximum of the entire distribution) but the distance between that peak and the peak obtained from the gaussian fit is greater than 75% of the sigma from the gaussian fit, the strip is given bad status 2 as well.  Attached is a pdf that has only the pedestal plots for all channels from crate 1.

Edit: I forgot that the BSMD crates don't increase with module number: what is labeled as crate 1 is actually crate 2, as that is the crate that has the first 15 modules, and the attachment labeled as crate 2 is the 2nd 15 modules and so actually crate 1.

2nd edit: This is now out of date, please see the new update.

DELETE - Run 9 BSMD Status Update 4 (4/27)

After further investigations -- specifically looking at strips that had a significant secondary peak, entirely separated from the main peak, with a max of ~40, which were not being caught by my cuts -- I have again revised my criteria for status bit 2.  Again, I begin by looking for peaks.  If a peak candidate is less than three sigma from the peak of the strip ADC distribution (strip and peak both taken from the gaussian fit), the same cuts are imposed: the candidate must be greater than the four (if sigma>6) or two (if sigma<6) channels on on either side of it, it's content must be greater than 5% of the maximum of the strip ADC distribution, and the depth must be at least 5% of the maximum of the strip ADC distribution.  If the strip has two such peaks with the maximum of the depths greater than 20% of the maximum of the strip ADC distribution, or has only one peak but that peak is at least one sigma away from gaussian fit peak, it is given bad status 2.  Note the only change here is that the previously a strip with only one peak could be marked bad if it was 75% of sigma away from the gaussian fit peak.

Most of the changes have to do with candidates that are at least three sigma from the gaussian fit peak.  In this case the cuts are relaxed: the bin content need only be .5% of the max, not 5%, though it still must be at least 10, and the peak depth is required to only be at least 5% of the peak itself, not of the max.  A more than three-sigma peak has the same requirements for the number of channels it must be greater than: however, none of those channels can have value 0.  Any strip with a candidate that passes these criteria is automatically given bad status 2. 

Pdfs for crates 1 and 2 are attached (but note that the crate 1 and crate 2 pdfs contain the first and second 15 modules, respectively, and therefore crate 1 should actually be labeled crate 2 and crate 2 is really crate 4).

DELETE - Run 9 BSMD Status Update 5 (4/30)

Edited on 5/1 to reflecte new status bit assigments for bits 3 and 4.

The current BSMD status bits are as follows:

Bit 2: Bad pedestal peak/multiple pedestal peaks.  This is described in more detail here.  Examples can be found in crate2_ped.pdf pp 207 and 314 and crate4_ped.pdf p 133.

Bit 3: Pedestal peak has bad sigma, sigma<1 or sigma >15

Bit 4: Chi squared value from gaussian fit is greater than 1000 (i.e., pedestal has a funny shape)

Bit 5: Strip is exactly identical to the previous strip

Bit 6: The ratio of the integral of channels 300-500 to the total integral does not fall between .0001 and .02

Bit 7: The ratio of the integral of channels 500-800 to the total integral does not fall between .00004 and .02

Bit 8: The ratio of the integral of channels greater than 800 to the total integral does not fall between .00005 and .02

Note that this means that dead channels have status 111xxxx0->448 (or greater).

The attached pdfs crate2 and crate4.pdf have the pedestal distributions, taken from NZS data, and the overall distributions, taken from ZS L2W data, overlayed; crate2_ped and crate4_ped.pdf have only the pedestal distributions.  The NZS data used was taken from my monitoring for fills 10415-10489.  The L2W data came from fills 10383-10507.  Additionally, at the beginning of each module is a summary page that has plotted the distributions for the ratios used to determine bad status bits 6, 7, and 8, and the overal distribution of status vs. strip for eta and phi.

Finally, there are a couple of possible new problems.  Page 18 in crate4_ped.pdf has several examples of pedestal distributions that have shoulders.  Page 20 has a few examples of pedestal distributions with a small, skinny peak perched on top of a large, broad distribution.  At the moment I have no bad status bit for either of these, and any peak with either of these features would almost certainly not be marked bad (even though I did manage to catch one of the ones on page 20).

Edit: Scott suggested during the phone meeting today that perhaps the problem of a small peak on a broad distribution was due to time variation of the pedestal width, and in the plot below you can see that he was correct: the strip initially has an extremely wide pedestal which then shrinks down suddenly.  Futhermore, looking at one of the strips that had a sort of shoulder to it, you can see that this is just a less-pronounced version of the double peak problem seen before: the pedestal goes up by 10 for a much shorter time frame, thus producing a shoulder rather than a second peak.  This suggests that, as Scott said, these channels should still be usable, and that once we begin breaking status down by time these funny shapes should be less of a problem.

DELETE - Run 9 BSMD Status Update 6 (5/4)

As Matt says that the maximum status is 255, I have dropped the old status bit 5 as (it was unused).  Also, I have loosened the dead strip cuts based on looking at module 55 (see pages 203 or 205 in the attached crate1.pdf, for instance).  The status bits are now as follows:

Bit 2: Bad pedestal peak/multiple pedestal peaks.

Bit 3: Pedestal peak has bad sigma, sigma<1 or sigma >15

Bit 4: Chi squared value from gaussian fit is greater than 1000 (this applies only for strips that do not have bad status 2 already)

Bit 5: The ratio of the integral of channels 300-500 to the total integral does not fall between .0005 and .02

Bit 6: The ratio of the integral of channels 500-800 to the total integral does not fall between .0002 and .02

Bit 7: The ratio of the integral of channels greater than 800 to the total integral does not fall between .0002 and .02

Below is a plot of status vs. eta and phi for BSMDE and BSMDP strips.  Note that strips with all three of bits 5, 6, 7 bad (generally, dead strips) are given the value 8 in this plot to distinguish them from strips that may have just one of those bits bad.  As some strips may have more than one bad status bit, for clarity I ranked the potential bad statuses in the order 2, 8, 7, 6, 5, 4, 3 (i.e., approximately in order of importance) and plotted for each strip only the highest-ranked status.


Additionally, I found a problem I had not seen before.  On page 207 of the attached crate1.pdf you can see that in the L2W data some strips have a large peak out in the tail of the ADC distribution.  However, as all these strips are caught by my code it's not a serious problem.

Final Run 9 200 GeV BSMD Status

In essence, the 200 GeV status tables were calculated the same way as the 500 GeV tables were.  Please see here for details.

Final Run 9 500 GeV BSMD Status - Willie Leight

BSMD Pedestals and Status for Run 9 pp 500 Data (June 2009, uploaded to offline DB)

The BSMD status analysis for the 500 GeV data proceeds as follows:

  1. Each strip is assigned a status for the whole run from an analysis of fills 10399, 10402, 10403, 10404, 10407, 10412, and 10415.  Pedestals are analyzed using NZS data taken by the BSMD online monitoring, which reads NZS data from evp and subtracts off pedestals which are updated each time a new BSMD pedestal run is taken.  Because NZS data is essentially minbias, high energy tails are analyzed using L2W-triggered data.  Status bits are described in detail here
  2. Once each strip has an assigned status, those strips that are not marked as bad move on to the second step.  Here the strips are examined fill-by-fill: for each fill the strip pedestal is QAed by re-applying the pedestal cuts (but not the tail cuts due to lack of statistics), and a new status for that fill is determined.
  3. Next, a pedestal correction is calculated.  The pedestal correction is just the MPV of the pedestal residua if the MPV is greater than the RMS of the pedestal residua. 
  4. Finally, we upload a number of tables to the database: for each BSMD plane there is one that contains a universal status for every strip, one for each fill containing a status for every strip, and one for each fill containing the RMS and pedestal correction for every strip. 

Attached is a pdf that presents the results of this study, including examples.

All code and root files are archived at /star/institutions/mit/wleight/archive/2009-pp500-bsmdStatus/.

Table 1: Pedestal correction, RMS, and status vs. fill for each module (Crates 1-4 are the West Barrel)

Cr 1 Mod 46 Mod 47 Mod 48 Mod 49 Mod 50 Mod 51 Mod 52 Mod 53 Mod 54 Mod 55 Mod 56 Mod 57 Mod 58 Mod 59 Mod 60
Cr 2 Mod 1 Mod 2 Mod 3 Mod 4 Mod 5 Mod 6 Mod 7 Mod 8 Mod 9 Mod 10 Mod 11 Mod 12 Mod 13 Mod 14 Mod 15
Cr 3 Mod 31 Mod 32 Mod 33 Mod 34 Mod 35 Mod 36 Mod 37 Mod 38 Mod 39 Mod 40 Mod 41 Mod 42 Mod 43 Mod 44 Mod 45
Cr 4 Mod 16 Mod 17 Mod 18 Mod 19 Mod 20 Mod 21 Mod 22 Mod 23 Mod 24 Mod 25 Mod 26 Mod 27 Mod 28 Mod 29 Mod 30
Cr 5 Mod 61 Mod 62 Mod 63 Mod 64 Mod 65 Mod 66 Mod 67 Mod 68 Mod 69 Mod 70 Mod 71 Mod 72 Mod 73 Mod 74 Mod 75
Cr 6 Mod 76 Mod 77 Mod 78 Mod 79 Mod 80 Mod 81 Mod 82 Mod 83 Mod 84 Mod 85 Mod 86 Mod 87 Mod 88 Mod 89 Mod 90
Cr 7 Mod 91 Mod 92 Mod 93 Mod 94 Mod 95 Mod 96 Mod 97 Mod 98 Mod 99 Mod 100 Mod 101 Mod 102 Mod 103 Mod 104 Mod 105
Cr 8 Mod 106 Mod 107 Mod 108 Mod 109 Mod 110 Mod 111 Mod 112 Mod 113 Mod 114 Mod 115 Mod 116 Mod 117 Mod 118 Mod 119 Mod 120


Table 2: BSMD spectra for 150 eta and 150 phi strips used for status determination for each module (for fills listed above).  Bad strips are identified with the status (in hex): strips with red status are marked bad, strips with green failed a cut but are not necessarily bad.  Note that these spectra are shifted up by 100 on the X-axis so that the pedestal is centered around 100 rather than 0.

Cr 1 Mod 46 Mod 47 Mod 48 Mod 49 Mod 50 Mod 51 Mod 52 Mod 53 Mod 54 Mod 55 Mod 56 Mod 57 Mod 58 Mod 59 Mod 60
Cr 2 Mod 1 Mod 2 Mod 3 Mod 4 Mod 5 Mod 6 Mod 7 Mod 8 Mod 9 Mod 10 Mod 11 Mod 12 Mod 13 Mod 14 Mod 15
Cr 3 Mod 31 Mod 32 Mod 33 Mod 34 Mod 35 Mod 36 Mod 37 Mod 38 Mod 39 Mod 40 Mod 41 Mod 42 Mod 43 Mod 44 Mod 45
Cr 4 Mod 16 Mod 17 Mod 18 Mod 19 Mod 20 Mod 21 Mod 22 Mod 23 Mod 24 Mod 25 Mod 26 Mod 27 Mod 28 Mod 29 Mod 30
Cr 5 Mod 61 Mod 62 Mod 63 Mod 64 Mod 65 Mod 66 Mod 67 Mod 68 Mod 69 Mod 70 Mod 71 Mod 72 Mod 73 Mod 74 Mod 75
Cr 6 Mod 76 Mod 77 Mod 78 Mod 79 Mod 80 Mod 81 Mod 82 Mod 83 Mod 84 Mod 85 Mod 86 Mod 87 Mod 88 Mod 89 Mod 90
Cr 7 Mod 91 Mod 92 Mod 93 Mod 94 Mod 95 Mod 96 Mod 97 Mod 98 Mod 99 Mod 100 Mod 101 Mod 102 Mod 103 Mod 104 Mod 105
Cr 8 Mod 106 Mod 107 Mod 108 Mod 109 Mod 110 Mod 111 Mod 112 Mod 113 Mod 114 Mod 115 Mod 116 Mod 117 Mod 118 Mod 119 Mod 120


Table 3: Fills used in this study.

#      Fill        Date          Begin run      End run   LT/pb
1 F10383 2009-03-18 R10076134 R10076161 0.00
2 F10398 2009-03-20 R10078076 R10079017 0.08
3 F10399 2009-03-20 R10079027 R10079086 0.22
4 F10402 2009-03-21 R10079129 R10079139 0.04
5 F10403 2009-03-21 R10080019 R10080022 0.01
6 F10404 2009-03-22 R10080039 R10080081 0.09
7 F10407 2009-03-22 R10081007 R10081056 0.05
8 F10412 2009-03-23 R10081096 R10082095 0.23
9 F10415 2009-03-24 R10083013 R10083058 0.24
10 F10426 2009-03-25 R10084005 R10084024 0.11
11 F10434 2009-03-26 R10085016 R10085039 0.18
12 F10439 2009-03-27 R10085096 R10086046 0.26
13 F10448 2009-03-28 R10087001 R10087041 0.29
14 F10449 2009-03-28 R10087051 R10087097 0.32
15 F10450 2009-03-29 R10087110 R10088036 0.29*
16 F10454 2009-03-29 R10088058 R10088085 0.15*
17 F10455 2009-03-30 R10088096 R10089023 0.29*
18 F10463 2009-03-31 R10089079 R10090027 0.20*
19 F10464 2009-03-31 R10090037 R10090047 0.08*
20 F10465 2009-03-31 R10090071 R10090112 0.13*
21 F10471 2009-04-02 R10091089 R10092050 0.30
22 F10476 2009-04-03 R10092084 R10093036 0.28
23 F10478 2009-04-03 R10093057 R10093085 0.08
24 F10482 2009-04-04 R10093110 R10094024 0.55
25 F10486 2009-04-05 R10094063 R10094099 0.52
26 F10490 2009-04-05 R10095019 R10095057 0.40
27 F10494 2009-04-06 R10095120 R10096027 0.61
28 F10505 2009-04-07 R10096139 R10097045 0.39
29 F10507 2009-04-08 R10097086 R10097153 0.29
30 F10508 2009-04-08 R10098029 R10098046 0.17
31 F10517 2009-04-09 R10099020 R10099078 0.32**
32 F10525 2009-04-10 R10099185 R10100032 0.68
33 F10526 2009-04-10 R10100049 R10100098 0.37
34 F10527 2009-04-11 R10100164 R10101020 0.82
35 F10528 2009-04-11 R10101028 R10101040 0.31
36 F10531 2009-04-12 R10101059 R10102003 0.86
37 F10532 2009-04-12 R10102031 R10102070 0.76
38 F10535 2009-04-13 R10102094 R10103018 0.86
39 F10536 2009-04-13 R10103027 R10103046 0.43

* Crate 2 was off for this fill

** This fill had no BSMD data

Final Run 9 BSMD Absolute Calibration

The Run 9 BSMD absolute calibration was made using few-GeV TPC-identified electrons from pp500 running, and has two pieces.  The first is a new CALIBRATION table in the database which will be used in the EMC slow simulator to improve the agreement of of MC ADC with data.  This table starts by combining the previously-determined strip-by-strip relative gains with the existing values in the table.  This is then multiplied by the ratio of the slope of a linear fit to the mean cluster ADC distribution from few-GeV isolated data electrons to the same slope in simulated electrons, where the slope is calculated in four different eta bins.  The second piece is a new GAIN table in the database which allows ADC values to be converted to energy deposited in the BSMD.  This table was determined by combining the strip-by-strip relative gains with a similar ratio as above, but using mean cluster energy deposited in the BSMD instead of reconstructed ADC values (the electron samples used for data and MC were the same) and it is calculated in ten eta bins instead of four.  Both tables are currently in the database with flavor "Wbose2": it is hoped that eventually the CALIBRATION table will migrate to flavor "ofl", but the GAIN table will have to remain "Wbose2" because it is currently used (with values all equal to 1) in some codes to determine the change in the BSMD calibration over time.  While producing two tables which are in some ways overlapping and one of which can never be flavor "ofl" is not an ideal solution, it allows us to avoid making any modifications to currently existing code (in particular the StEmcSimulator) and allows people who prefer to think of reconstructed energy from BSMD ADCs as being the full particle energy instead of the energy deposited in the BSMD to continue as they were with no change.  For more details, please see:

1. Overview of the method

2. Final cut list and data-MC comparison

3. Overall Summary

Additionally, a link to the 2009 BSMD Calibration note will be added here once it is completed.

See also a brief presentation on why we chose not to include the BSMD gas pressure in our analysis.

Run 9 BSMD Status Update 1 (4/19)

I use two datasets to QA BSMD channels: zero-suppressed data from L2W events (fills 10383-10507) and non-zero-suppressed data from online monitoring (fills 10436-10507) (note that at the moment I am not examining the time dependence of BSMD status).  NZS data is used to QA the pedestal peak of a channel, while high-energy ZS data is used to QA the tail.

Next, the ZS data are compared to the ZS data from the previous channel to check for copycat channels.  Then three quantities are calculated: the ratios of the integrals from 300-500, 500-800, and 800-the end of the spectrum to the total integral of the channel.  Each of these quantities must then fall within the following cuts: .0001-.02, .00004-.02, and .00005-.02 respectively.  Here is a sample distribution:

Also, the spectra for the strips in module 3, with status, are attached.  I have not had a chance to look closely at any other modules yet.

details about known hardware problems

Attached file  'SMD_07.xls'  contain  my notes from run 7, the only things that might be useful for
 you is in the red color, permanently disconnected anode wires and affected
 strips (again this is not SoftIds). I think that I cut out one more wire
before Run8 started, but for that I need to check logbook.



BSMD Wire Support Effects on GAIN

Here is a note from Oleg Tsai (and attached file "wiresup.pdf" below) concerning source
measurements of the BSMD gain behavior near the nylon wire supports:

On Fri, 18 Jul 2008, wrote:

>    Attached plot will help you to understand what you see close to
>  strips 58 and 105. There are two nylon wire supports in the chamber
>  at distances 34.882" and 69.213" from the (eta=0 end of the chamber,
>  not from the real eta 0). Gain drops near these supports. You can
>  see this in your plots also. The attached plot shows counting rate vs
>  strip id for a typical chamber. Don't pay attention to channels
>  near 0 and 150 - these effects are due to particular way co60 source
>  was collimated (counting profile was close to 0.1/0.2/0.4/0.2/0.1)
>  0.4 in central strip. From that I estimated that eta strips
>  56-60 and 104-107 should have calib. coefficients
>  (.95,.813,.875,.971,.984) (.99,.89,.84,.970.), I don't remember
>  if I was using counting rate vs HV to derive these numbers...
>  (this is my third and final attempt :-))


details of SMD simulator, simu shower zoom-in

Fig 1. Geant simu of EM shower of one electron with ET=10 GeV at eta=0.


  • one phi-strip is parallel to cavities, extends over 1/10 of the cavity length, and integrates over 2 consecutive cavities.
  • one eta-strip is perpendicular to cavities, extends over 1/150 of the cavity length, and integrates over all 30 cavities in the module.

 Hi Jan,

the only documentation I know of is the code itself --  
hopefully you'll consider it human-readable.  Look at  
StEmcSimpleSimulator::makeRawHit() in StEmcSimulatorMaker.  We use the  
kSimpleMode case.  The GEANT energy deposition is multiplied by a  
sampling fraction that's a second-order polynomial in pseudorapidity,  
and then we take pedestals, calibration jitter, etc. into account.   
The exact parameters of the sampling fraction are defined in the  
constructor for StEmcSimpleSimulator.  I don't remember how they were  

 also meant to add that the width broadening is OFF by  
default.  To turn it on one needs to do

emcSim->setMaxCrossTalkPercentage(kBarrelEtaStripId, aNumber);

 The "width broadening" only occurs  

for eta strips and was implemented by Mike Betancourt in  
StEmcSimulatorMaker::makeCrossTalk().  He wrote a blog post about it:




Maybe I should note that the cross talk I implemented was to account  
for the capacitive cross talk between the cables carrying the eta  
strip signals to the readout, and not for any effects related to the  
energy deposition.


Hi Jan,
Well, Oleg should probably make the definitive reply, but I think it is like this:
The amplification happens only at the wire, it is independent of the positions of the primary ionization. Of course, there is a little effect from a small amount of recombination or capture of the charge on impurities, and there must be a (hopefully small) effect from the dependence of the mean pulse shape on the position of the ionization and the dependence of the effective gain of the electronics on the mean pulse shape. But these things can't amount to much, I would think. (Of course, I don't want to discourage you from looking in the data to confirm it!)


 These are all quite true, small effects which will be difficult 
 to see. The bigger effect is reading out one time bucket.
 I have made some estimates before test run 98 (?) or so, see this PS

 if you look at numbers still very small effect which is unpractical
 to measure.

Hi, Yes indeed, I don't know why I neglected to think of the simple effect of drift time, but it is certainly going to be a much bigger effect (~10% if I read your fig.3 correctly?) than the other two. (Perhaps still too small to see in the data, I don't know...). Anyway, given the data volume and already limited readout speed of the BSMD I am pretty sure there is no prospect to ever read more than the one fixed time sample from BSMD; this is probably something to live with. [But it is not impossible to have 2 or 3 point readout, and if we want to seriously consider it it should be brought up ~now, well that is in case we are given the green light to work on BSMD readout "mini-upgrade". If not, well it will just wait until then. But keep in mind, more points readout would offer slightly better gain accuracy but will complicate offline and calibrations too, probably you really don't want it anyway!]


p.s. Jan I don't know if it adds anything to the wider discussion on BSMD gain/cal but if you feel so you may surely post to hn.

p.p.s. Oleg, an important question - in your note you don't specify exactly how you obtain the drift time... I mean, yes you show a drift velocity curve, but really of course you must mean there was a calculation such as with garfield to get a drift time out of this... _So_, was that calculation done with the magnetic field on? [The wires are parallel to the magnetic field, right? So it will make possibly a very big difference in drift times.] Jan, do you/others realize the BSMD gain will probably have some systematic dependence on the magnetic field, including the sign thereof? So if you care about gain calibration it should be separated out according to the state of STAR magnet, fortunately there are only a few running states, right?


one cluster topology , definition of 'barrel cell'

 One dimensional  BSMD cluster finder is insensitive to single dead strips and module boundaries for the phi strip.

However certain class of Phi-strip clusters (marked as red) are artificial split and reco as 2 phi-clusters.

One could use the Eta-strip cluster to recover from such phi-plane split if occupancy is low and relative scale of eta & phi cluster energy known.

 Plots below also introduce a concept of 'barrel cell' which has approximate size of 0.1 in eta & phi physical units and is aligned with barrel modules.  'barrel cell' is the smallest common unit in eta-phi space for SMD and BTOW tower topologies. 

'Barrel cell' has 2 coordinates : x[0,19] and y[0,59] . If such object is already defined for the Barrel,  uniform for East & West let me know and I'll adjust numbering scheme. 

Back to recovery of split phi cluster, shown below as red oval.  Green clusters are shown to 'calibrate' yourself to this type of representation.  

Fig 1.

Fig 2.





BTOW - Calibration Procedure

Here you will find the calibration procedure for the BTOW (as of 2013). 

Additional documentation about BTOW gain calibrations in previous years can be found here: 
Report from the STAR EMC Calibrations Workshop (2008)
2006 BEMC Tower Calibration Report
2009 BEMC Tower Calibration Report
As well as in BEMC > Calibrations section on Drupal here

1) Generating Pedestal/Status Tables

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 "" 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:

ssh-agent >
ssh -X -A % using your own username, of course
ssh -X -A
ssh -X -A

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

% after logging in you should be in /ldaphome/onlmon/
mkdir emcstatus2013 % make a directory for the appropriate year
cd emcstatus2013
mkdir pp500 % make a directory for the species/energy
cd pp500
cp ../../emcstatus2012/pp500/ ./ % copy files from a previous year
cp ../../emcstatus2012/pp500/ ./
cp ../../emcstatus2012/pp500/l2status2012.sqlite3 ./l2status2013.sqlite3
cp ../../emcstatus2012/pp500/empty.sqlite3 ./
cp ../../emcstatus2012/pp500/mapping.sqlite3 ./
cp ../../emcstatus2012/pp500/star_env ./
mkdir db
mkdir db/bemc
mkdir db/eemc
mkdir histoFiles
mkdir /onlineweb/www/emcStatus2013 % make the directories where the online files will be written by
mkdir /onlineweb/www/emcStatus2013/pp500
mkdir /onlineweb/www/emcStatus2013/pp500/pdf
mkdir /onlineweb/www/emcStatus2013/pp500/details
cd /onlineweb/www
ln -s emcStatus2013 emcStatus % make a softlink from emcStatus to the current year's directory
cd -

Now you should go through and and change each instance of the year and species/energy to the current ones.  Also there are some lines in 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 "" 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:

source star_env

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 (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 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 (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

2012-06-07 00:26:36 PID: 21394 INFO medianHits = 635
2012-06-07 00:26:36 PID: 21394 INFO begin status computation
2012-06-07 00:28:05 PID: 21394 INFO end status computation -- found 122 bad channels
2012-06-07 00:28:05 PID: 21394 INFO begin endcap status computation
2012-06-07 00:28:05 PID: 21394 INFO 04TB07 status=136 nonzerohists=22
2012-06-07 00:28:05 PID: 21394 INFO 06TA07 status=136 nonzerohists=18
2012-06-07 00:28:05 PID: 21394 INFO 08TB07 status=136 nonzerohists=21
2012-06-07 00:28:06 PID: 21394 INFO 11TA12 status=0 nonzerohists=60
2012-06-07 00:28:06 PID: 21394 INFO end status computation -- found 11 bad endcap channels
2012-06-07 00:28:10 PID: 21394 INFO current state has been saved to disk
2012-06-07 00:28:10 PID: 21394 INFO creating PostScript file
2012-06-07 00:29:09 PID: 21394 INFO calling pstopdf
2012-06-07 00:29:42 PID: 21394 INFO removing ps file
2012-06-07 00:29:43 PID: 21394 INFO creating endcap PostScript file
2012-06-07 00:29:52 PID: 21394 INFO calling pstopdf
2012-06-07 00:29:57 PID: 21394 INFO removing ps file
2012-06-07 00:29:58 PID: 21394 INFO Finished writing details webpage for F16732_R13108069_R13108080
2012-06-07 00:30:00 PID: 21394 INFO goodnight -- going to sleep now

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)

2) QAing the Pedestal/Status Tables

Once the ped/stat tables have been generated, they must be QAed.  I do the QA in two parts:

1) I spot check the pdf files by eye.  I pick about 5 or 6 fills evenly spaced throughout the run and go through each page of the pdf files looking for any strange-looking towers (for example, towers with stuck bits are pretty easy to see, and they don't always get caught by the algorithm).  Yes, this takes a while, but we don't have to look at the pdfs for every fill!
For examples of the bad channels you are looking for, have a look at Suvarna's nice QA of the tables last year:

2) The status and pedestal information is stored in the sqlite database file, and we can spin over this quickly in order to look at the data over many runs/fills.  I have attached a script which is used to analyze the database file l2status2013.sqlite3.  The first step is to download l2status2013.sqlite3 somewhere *locally* where you can look at it, and save in the same place. In you should change line 27 to the appropriate run range that you are analyzing, and change 2012-->2013 if necessary.  Then all you need to do to run the code is something like:

This python code allows you to look at the statuses and pedestals from run to run.  At the moment I make lists of the statuses and pedestals for each tower (in the variables u and y -- sorry for my horrible naming scheme!), and then I can print these lists to the screen or graph them.  At the moment I have the code so that it prints the statuses for any tower that has status 1 some, but not all, of the time (line 138).  This script can be used to find channels which change status frequently over the course of the run... for example, sometimes there are channels which are right on the edge of satisfying the criteria for being marked as "cold" and therefore their status alternates 1 18 1 1 18 18 1 1 18 1 18 etc. Then we can look at the pdf files to see if the tower always looks cold, or if its behavior really changes frequently.  If it is truly cold, then at that point we can either adjust the criteria for being marked as cold, or hard-code the channel as status 18 (I typically just hard-code it).
Also I can look at the histograms histoPedRatio and histoPedRatioGood (which are saved out in histogramBEMCfill.root), which are plots of the ratio of the pedestal for a given run to the pedestal of the first run as a function of tower id.  histoPedRatio is filled for every tower for every run (unless the pedestal for that tower in the first run is zero), and histoPedRatioGood is only filled if the tower's status is 1.  I haven't needed to cut out any towers based on these plots, but I think they would be a good way to find any towers whose pedestals are fluctuating wildly over time (or maybe you might want want to plot the difference, not the ratio).
So you can take a look at the code and play around with it so that it allows you to do the QA that you think is best.

If you look at, you can see where I've hard-coded a bunch of channels I thought were bad (the lines which hard-code bad channels are commented out right now because I prefer to start from scratch each year).  I've pasted the code here too:

            ## hard code few bad/hot channels
            #if int(tower.softId)==939 : ##hard code hot channel
            #    tower.status |= 2
            #if (int(tower.softId)==3481 or int(tower.softId)==3737) : ##hard code wide ped
            #    tower.status |= 36
            #if (int(tower.softId)==220 or int(tower.softId)==2415 or int(tower.softId)==1612 or int(tower.softId)==4059): ##hard code stuck bit
            #    tower.status |= 72
            if (int(tower.softId)==671 or int(tower.softId)==1612 or int(tower.softId)==2415 or int(tower.softId)==4059) : ##hard code stuck bit (not sure which bit, or stuck on/off)
                tower.status |= 8
            if (int(self.currentFill) > 16664 and (int(tower.softId)==1957 or int(tower.softId)==1958 or int(tower.softId)==1977 or int(tower.softId)==1978 or int(tower.softId)==1979 or int(tower.softId)==1980 or int(tower.softId)==1997 or int(tower.softId)==1998 or int(tower.softId)==1999 or int(tower.softId)==2000 or int(tower.softId)==2017 or int(tower.softId)==2018 or int(tower.softId)==2019 or int(tower.softId)==2020)) : ##hard code stuck bit
                tower.status |= 8
            if (int(tower.softId)==410 or int(tower.softId)==504 or int(tower.softId)==939 or int(tower.softId)==1221 or int(tower.softId)==1409 or int(tower.softId)==1567 or int(tower.softId)==2092) : ##hard code cold channel
                tower.status |= 18
            if (int(tower.softId)==875 or int(tower.softId)==2305 or int(tower.softId)==2822 or int(tower.softId)==3668 or int(tower.softId)==629 or int(tower.softId)==2969 or int(tower.softId)==4006) : ##either cold or otherwise looks weird
                tower.status |= 18

Some of these channels are persistently problematic, so I expect that your list of bad channels will look similar to mine from previous years.

It may take a few iterations of generating the tables, finding bad towers, tweaking the code or hard-coding the bad channels, regenerating the tables, etc before you are satisfied with the quality of the tables.  Once you have run one last time and are satisfied with the quality of the tables you have generated, they are ready to be uploaded to the database by the software coordinator. 

3) Uploading Pedestal/Status Tables to the Database

Once the ped/stat tables have been QAed satisfactorily, the values need to be uploaded to the database. 

First, the files in /db/bemc/ need to be moved to RCF, where the upload will take place.  This can be done with the following commands:

ssh-agent >
ssh -X -A % using your own username
rterm -i
mkdir bemcUpload2013 % make a directory to work in
mkdir bemcUpload2013/tables
cd bemcUpload2013/tables/
scp'/ldaphome/onlmon/emcstatus2013/pp500/db/bemc/*.txt' ./
cd ../

The scripts bemcPedTxtUpload.C and bemcStatTxtUpload.C are used to perform the upload.  They take as input the name of a file which contains a list of the files to be uploaded.  To create the file lists:

% in bemcUpload2013/
mkdir lists
cd tables
ls bemcStatus*.txt > ../lists/bemcStatus.list
ls bemcPed*.txt > ../lists/bemcPed.list
cd ../

Once the file lists have been created, the scripts can be run with:

setenv DB_ACCESS_MODE write
root4star bemcStatTxtUpload.C
root4star bemcPedTxtUpload.C


1) The upload scripts (bemc*TxtUpload.C) contain return statements to prevent accidental uploads.  Make sure everything is working properly by running the scripts with the return statements included (nothing will be uploaded to the db) first.  When you are sure that you're ready to upload, then comment out the return statements.  After uploading, don't forget to uncomment the return statements! 
2) Try uploading one table first, and then check that it is uploaded correctly (see below), before uploading all the tables for the whole run.  If a table is uploaded wrongly, it can be disactivated by the software team, but this is not something we want to do often.  (In the case of a single table, it may be more efficient to just upload the correct table with a timestamp one second after the incorrect table.)
3) Reminder: this is not a task many people should need to do but should be limited to one or two "experts", who will be given special DB writing priviledges by Dmitry Arkhipkin (  

Uploaded tables can be viewed with the online BEMC DB browser.  I find it helpful to spot-check some tables to make sure they have been uploaded correctly.  I find a table with the browser, copy it into an text file, and compare it to the text file I uploaded (in tables/).  For the status tables, this can be done with a simple diff command.  For the pedestal tables, the script checkPeds.C can be used. 

At the beginning of the run (after physics has been declared, L2 is running, etc), it is good to generate a set of ped/stat tables and upload them to the database one second after the initialized values (for example, at 20131220.000001).  (Reminder: The procedure for initializing the timeline with ideal values can be found here.)  This can be done with the bemc*TxtUpload.C scripts; you will see a commented-out line that shows how to set the timestamp manually.  It is good to do this periodically throughout the run, especially if something changes with the detector or beam configuration, so that FastOffline reconstruction can pick up decent DB values.  Each time, the tables should be uploaded one second after the previous tables, so that when we upload the fully-QAed tables at the end of the run, the temporary ones will no longer be picked up. 

4) Relative Gain Calibration with MIPs

Getting Started

1) The code needed to perform the gain calibrations can be checked out from CVS and compiled. In your working directory, do:

cvs co StRoot/StEmcPool/StEmcOfflineCalibrationMaker/

You can move the required files to your working directory, or make soft links. You need the following files, which are in the macros/ directory:
-- bemcCalibMacro.C
-- btow_mapping.20030401.0.txt
-- CalibrationHelperFunctions.cxx
-- CalibrationHelperFunctions.h
-- electron_drawfits.C
-- electron_histogram_maker.C
-- electron_master.C
-- electron_master_alt.C
-- electron_tree_maker.C
-- geant_fits.root
-- mip_histogram_fitter.C
-- mip_histogram_maker.C

Some of the files have lists of triggers which need to be hard-coded in for each year.  In particular, in bemcCalibrationMacro.C you should ensure that the correct trigger list is present, and the trigger IDs for the HT triggers need to be written in StEmcOfflineCalibrationMaker.cxx.  (In most cases I have already typed in the values for Run 11, but they are commented out while the Run 9 values are commented in.)  If you want to use the TOF information (in Run 11 and beyond), there are some lines of code that need to be commented in in StEmcOfflineCalibrationMaker.cxx. 

Generating Trees

2) Generate the list of runs with the following command (for Run 9) -keys "runnumber" -distinct -cond "production=P11id,filetype=daq_reco_MuDst,sanity=1,trgsetupname=production2009_200GeV_Single,filename~st_physics,tpx=1,emc=1,storage!=HPSS" -limit 0 | sort -u > runlist.txt

or similar for other years.

3) Run, which will execute the bemcCalibMacro.C macro.  Make sure that the correct catalog query lines are commented in/out in the submit script.  Also ensure that the appropriate directories exist ($workingDir, $schedDir, $outDir, $logDir, $scriptDir) as specified at the top of the submit script.

This macro creates trees which store primary tracks which will be further analyzed for the calibration.  For each primary track we write out the track information from the TPC, the EMC information for the 3x3 tower cluster around the track, the TOF information (in Run 11 and beyond), and the trigger information. 

The trees created by this step are stored on HPSS here:
Run 9: /home/aohlson/bemcCalib2009_x.tar where x=0,...,9
Run 11: /home/aohlson/bemcCalib2011_05_x.tar where x=0,...,14 and /home/aohlson/bemcCalib2011_07_x.tar where x=0,...,18

MIP calibration

The relative gain calibration is obtained by finding the MIP peak in each of the 4800 BEMC towers. 

The MIP energy deposit has the following functional form, which was determined from test beam data and simulations:
MIP = (264 MeV)×(1+0.056η2)/sin(θ)

From this expression we can calculate a calibration constant
C = 0.264×(1+0.056η2)/(ADCMIP×sin(θ))
where ADCMIP is the location of the MIP peak in the ADC spectrum.  This allows us to combine towers at the same η and thus find the absolute gain calibration in each crate-slice using electrons (see next section).

The procedure for obtaining the MIP calibration is as follows...
4) Make the MIP histograms with which executes mip_histogram_maker.C  Ensure that the correct output filenames are specified in the submit script.

Events with |vz| < 30 cm are selected, and any towers that have multiple tracks associated with them are excluded.  We select tracks with p > 1 GeV/c, and require that they enter and exit the same tower.  We require that the towers surrounding the central tower do not contain a large energy deposition.  We require that ADC-ped > 1.5*pedRMS.  After these track quality cuts we fill histograms with the ADC-ped values for each tower. 

5) Make a list of the output files from step (4) called mips.list.  Run mip_histogram_fitter.C

We fit each histogram with a gaussian on a pedestal; the histograms and fits are shown in mip.pdf. If the fit values fail basic quality cuts (such as if the mean is < 5), then the tower is assigned a bad status (!=1).  These fits are marked as red in mip.pdf.  For each tower we record the mean and sigma of the gaussian fit, and the status.

6) Check mip.pdf by eye to look for any other towers which were obviously bad.  Write a function like isBadTower2009(int id) (see examples in the code) which identifies these bad towers so that they can be assigned a bad status.  You can either put this function in mip_histogram_fitter and re-run it, or you can put it in the electron codes.  Note that most of the towers with bad MIP peaks were marked as bad (cold/hot/stuck bit) towers when the status/pedestal tables were originally computed. 

5) Absolute Gain Calibration with Electrons

Electron calibration

The absolute gain calibration is done by identifying electrons and finding the E/p peak for small groupings of towers.  It is desirable to find the E/p peak for as small groupings as possible.  In 2006 the calibration was done in rings in η, while in 2009 it was done for "crate-slices", which are groups of 8 towers in the same crate in the same η ring. 

The procedure is as follows...

7) Make the electron trees with which will execute electron_tree_maker.C  Ensure that the correct output filenames are specified in the submit script.

The macro electron_tree_maker.C makes slimmer trees of electron candidates which satisfy the following criteria:
-- event vertex |vz| < 60
-- track must come from reconstructed vertex (ranking >= 0)
-- 1.5 < p < 20 GeV/c
-- nhits >= 10
-- matched tower status = 1
-- dE/dx > 3e-6
-- ADC-ped > 1.5*pedRMS
In this macro, if the electron track points towards a HT trigger tower then it is assigned htTrig = 2

In the old calibration: Make a list of the output files from step (5) called electrons.list.  Run electron_master.C.
---- OR ----
In the new calibration: Run, which executes electron_master_alt.C (make sure that the input/output filenames and directories are correct).  Hadd the resulting output files, and use this file as the input to electron_drawfits.C

In this macro even more stringent cuts are placed on the electron candidates:
-- ADC-ped > 2.5*pedRMS
-- track must enter and exit the same tower
-- p < 6 GeV/c
-- track does not point towards a tower which fired the HT trigger (htTrig != 2)
-- dR < 0.025 (distance from the center of the tower)
-- dE/dx > 3.4e-6
-- the maximum Et in the 3x3 cluster of towers must be in the central tower
-- there are no other tracks pointing to the central tower

The resulting histograms of E/p in each crate-slice are drawn and fit with a Gaussian plus a first-order polynomial.  If the calibration is already correct, then the E/p peak should be at 1.  The deviation from unity establishes the absolute gain calibration which, combined with the relative gain calibration from the MIP procedure, defines the overall BEMC gain calibration.

Run 12 BTOW Calibration

 This is parent page that will hold all informationa about the run12 BEMC gain calibration

200 GeV Calibration

 This calibration was done with the 200 GeV proton-proton data collected in 2012. The calibration trees are backed up on HPSS and can be found here:


where XX = 0, 1, 2, .... , 34

Run 3 BTOW Calibration

I plan on "Drupalizing" these pages soon, but for now here are links to Marco's slope calibration and Alex's MIP and Electron calibrations for the 2003 run:

Marco's tower slope calibration

Alex's MIP calibration

Alex's electron normalization

Run 4 BTOW Calibration


The recalibration of the BEMC towers for Run 4 includes the following improvements:

  • recovery of 158 swapped towers
  • identification and removal of 38 towers with possible light leakage / electronics problems
  • identification and removal of 24 towers with bad p/E distributions
  • MIP calibration restricted to low-multiplicity events from minimum-bias data
  • isolation requirement imposed on MIP candidates


  • p0 * 4066 = 28.5 GeV full-scale at zero rapidity (assuming pedestal~30).
  • 2191/2400 = 91.3% of the towers have nonzero gains.
  • Despite the differences in the cuts used, the final gains are similar to the ones currently found in the DB; a histogram of (newgain-dbgain)/newgain for the towers present in both calibrations yields a mean of 0.019 and an rms of 0.03896.


The offline calibration of the BEMC towers for Run 4 is accomplished in three steps. In the first step, MIPs are collected for each tower and their pedestal-subtracted ADC spectra are plotted. The MPV of the distribution for each tower is translated into a gain using an equation originally established by test-beam data (SN 0433). In the second step, electrons are collected for each eta-ring and the ratio of their momentum and energy (with the energy calculated using the MIP gains from step 1) is plotted as a function of the distance between the track and the center of the tower. The calculated curve is fit to a GEANT simulation curve, allowing extraction of scale factors for the MIP gains in each eta ring. Finally, all electrons in all eta-rings are grouped together and the ratio of their energy and momentum (E/p) is plotted, with the energy calculated from the rescaled gains in the second step. The distribution is fit with a Gaussian and a scale factor is applied so that this Gaussian is centered exactly on 1.000.

Catalog query:

<inputURL="||P05ib||P05ic,sanity=1,tpc=1,emc=1, trgsetupname=ProductionMinBias||productionLow||productionMid||productionHigh,filename~physics, filetype=daq_reco_mudst,magscale~FullField,storage!~HPSS,runnumber>=5028057" nFiles="all" />

Working directories:



MIP Cuts:

  • track momentum > 1
  • track enters, exits same tower
  • 1 track / tower
  • (ADC - ped) > 2*pedRMS
  • trigger == 15007 (mb data)
  • abs(z-vertex) < 30
  • reference multiplicity < 57 (60-100% centrality)
  • isolation cut (all neighboring towers satisfy (ADC-ped) < 2*pedRMS)

Electron Cuts:

  • 1.5 < track momentum < 20
  • track enters, exits same tower
  • 1 track / tower
  • # track points > 25
  • 3.5 < dEdx < 4.5 keV/cm
  • (ADC - ped) > 2*pedRMS
  • trigger != 15203 (excludes most ht-triggered electrons; should have been trigger == 15007 to get mb-only data)
Adam Kocoloski, 14 Feb 2006


Run 5 BTOW Calibration


The final BTOW calibration for Run 5 offers the following improvements over previous database calibrations:

  • recovery of 194 swapped towers
  • identification and exclusion of 51 towers with correlated firing problems
  • identification and exclusion of 33 towers with p/E~0.6
  • exclusion of 58 towers with PMTs replaced by Stephen and Oleg during the shutdown
  • isolation cut removes background from MIP spectra, identifies correlated towers
  • 30 cm vertex cut introduced to reduce path length differences among MIPs
  • uniform scale factor (1.04613) introduced after eta ring electron normalization to set E/p==1 when integrated over all towers

p0 = 0.00696912 for the fit parameter implies an <ET> = 28.3 GeV on the west side, but the gains do not seem to be well described by the 1/sin(theta) fit

3997/4240 = 94.3% of commissioned towers have nonzero gains


The offline calibration of the BEMC towers for Run 5 is accomplished in three steps. In the first step, MIPs are collected for each tower and their pedestal-subtracted ADC spectra are plotted. The MPV of the distribution for each tower is translated into a gain using an equation originally established by test-beam data (SN 0433). In the second step, electrons are collected for each eta-ring and the ratio of their momentum and energy (with the energy calculated using the MIP gains from step 1) is plotted as a function of the distance between the track and the center of the tower. The calculated curve is fit to a GEANT simulation curve, allowing extraction of scale factors for the MIP gains in each eta ring. Finally, electrons in all eta-rings that pass through the center of a tower are grouped together and the ratio of their energy and momentum (E/p) is plotted, using the energy calculated from the rescaled gains in the second step. The ditribution is fit with a Gaussian and a scale factor is applied so that this Gaussian is centered exactly on 1.000.

Catalog query:

<input URL=",tpc=1,emc=1, trgsetupname=ppProduction||ppTransProduction||ppProductionMinBias, filename~st_physics,filetype=daq_reco_mudst,storage!~HPSS" nFiles="all" />

Working directories:


The 2005 directory contains jobs run using Dave Relyea's offline pedestals (the bulk of the data), while the earlyfiles directory uses online pedestals for runs before April 26th that are not included in the offline pedestal calculations.

MIP Cuts:

  • track momentum > 1
  • track enters, exits same tower
  • 1 track / tower
  • (ADC - ped) > 2*pedRMS
  • abs(z-vertex) < 30
  • isolation cut (all neighboring towers satisfy (ADC-ped) < 2*pedRMS)
  • no trigger selection (previous statement of mb-only triggers was in error)

Electron Cuts:

  • 1.5 < track momentum < 20
  • track enters, exits same tower
  • 1 track / tower
  • # track points > 25
  • 3.5 < dEdx < 4.5 keV/cm
  • (ADC - ped) > 2*pedRMS
  • no trigger selection

For More Information:

Detailed information on this and other BTOW calibrations, including tower-by-tower MIP and p/E spectra and a summary of outstanding issues, is available at

The calibration summarized here has the timestamp 20050101.000001.

First Calibration using CuCu data

Runs used: 6013134 (13 Jan) - 6081062 (22 Mar)

The procedure for performing the relative calibration can be divided into 3 steps:

  1. Create a histogram of the pedestal-subtracted ADC values for minimum-ionizing particles in each tower
  2. Identify the working towers (those with a clearly identifiable MIP-peak)
  3. Use the peak of each histogram together with the location of the tower in eta to calculate a new gain
  4. Create new gain tables and rerun the data, this time looking for electrons
  5. Use the electrons to establish an absolute energy scale for each eta-ring

Using Mike's code from the calibration of the 2004 data, an executable was created to run over the 62GeV CuCu data from Run 5, produce the 2400 histograms, and calculate a new gain for each tower. It was necessary to check these histograms by hand to identify the working towers. The output of the executable is available as a 200 page PDF file:

2005_mip_spec.pdf (2400 towers - 21.6 MB)

Towers marked red or yellow are excluded from the calibration. Condensed PDFs of the excluded towers are available at the bottom of the page ("bad" and "weird"). In all, we have included 2212 / 2400 = 92% of the towers in the calibration.

Systematic Behavior of the Gains

The first plot in the top left shows the excluded towers (white blocks) in eta_phi space

In the second plot we collect the towers into 20 eta-rings (delta-eta = 0.05) and look at the change in gain as we move out in eta. This plot shows the expected increase in gain as we move into the forward region (except for eta-rings 19 and 20).

Finally we look at each individual eta-ring for for systematic variations in azimuth. There appears to be some structure around phi=0.2 and phi=3.

Electron Calibration Status

We have made an attempt to realize the absolute energy scales using electrons. Unfortunately, there does not appear to be a sufficient number of electrons in the processed 62GeV data to do this for each eta-ring. We will revisit this later when more statistics are available, but in the meantime we have established the following workaround:

  1. Fit the average gains of the first 17 eta-rings with a function that goes as 1/sin(theta)
  2. Caclulate the expected gains for eta-rings 18, 19, and 20 from this function
  3. Scale the forward eta-rings accordingly

The results of this procedure are seen in an updated plot of gain vs. eta:

Here are new bemcCalib and bemcStatus .root files created using these rescaled gains:




The text file is a list of tower-gain pairs. A gain of zero indicates a tower that has been masked out. Finally, we have a plot of p/E summed over all eta:

Update: Addition of the East BEMC Towers

We have calculated new gains for the 1200 towers in the east half of the barrel that were turned on by March 22. Only data from March 22 were used in this calibration. The results can be found in 2005_mip_spec_newtowers.pdf




The gains for towers 1-2400 are the same as before. These files include those entries, as well as new gains for towers 2401-4800. No attempt has been made to get an absolute energy scale for the east towers, so we still see the drop in gain for large eta:

Implementation of Tower Isolation Cut

Originally posted 11 October 2005

Previously we had calibrated the BEMC using data from all triggers. We now have enough data to restrict ourselves to minimum-bias triggers. Additionally, we have implemented a cut that requires the pedestal-subtracted ADC value of neighboring towers to be less than twice the width of the pedestal. This cut does an excellent job of removing background, especially in the high-eta region:

The cut is used in the bottom plot. Unfortunately there is also a small subset of towers where the isolation cut breaks the calibration:

Again the cut is used in the bottom plot. We have decided to use the isolation cut when possible, and use the full minimum-bias data in the case of the (55) towers for which the cut breaks the calibration. This new calibration is able to recover ~30 towers that were previously too noisy to calibrate. We are in the process of reviewing the remaining bad towers found in 2005_MinBiasBadTowers.pdf. Towers 671,1612, and 4672 appear to have problems with stuck bits in the electronics, and there are a few other strange towers, but the majority of these towers just seem to have gains that are far too high. We plan on reviewing the HV settings for these towers. An ASCII file of the bad towers is attached below.

Recalibration Using pp data

Originally posted 26 September 2005

Catalog query:
input URL=",tpc=1,emc=1,trgsetupname=ppProduction,filename~st_physics,filetype=daq_reco_mudst,storage=NFS" nFiles="all"

note: 3915/4240 = 92.3% of the available towers were able to be used in the calibration. Lists of bad/weird towers in the pp run are available by tower id:

The relative calibration procedure for pp data is identical to the procedure we used to calibrate the barrel with CuCu data (described below). The difference between pp and CuCu lies in the electron calibration. In the pp data we were able to collect enough electrons on the west side to get an absolute calibration. On the east side we used the procedure that we had done for the west side in CuCu. We used a function that goes like 1/sin(theta) to fit the first 17 eta rings, extrapolated this function to the last three eta rings, and calculated the scale factors that we should get in that region. Here is a summary plot comparing the cucu and pp calibrations for the 2005 run:


Comparing the first two plots, one notices immediately that many of the pp gains on the east (eta < 0) side are quite high. A glance at the last plot on the summary canvas reveals a collection of towers with phi < -pi/2 that have unusually high gains. These towers were added during the pp run and hence their gains are based on nominal HV values without any iteration (thanks Mike, Stephen). If we mask out those towers in the summary plot, the plots look much more balanced:


The bottom plot clearly shows that the final pp gains are ~10% higher than the gains established from the mip calibration using the cucu data. Moreover, the cucu data closely follows a 1/sin(theta) curve, while the curve through the pp data is flatter. This is revealed in the shape of the bottom plot. Note that we never scaled the gains near eta=-1 for the cucu data, which is why there is still a significant drop-off in the ratio of the mean gains in that region.

New calibration and status tables (including the gains for the new towers that were turned on during pp running) are available at




It should be noted that the scale factors we used to get the final gains near eta=-1 on the east side were calculated without the new towers since they were throwing off the fit function. However, those new towers still had their final gains scaled before we produced the calibration and status tables.

Systematic Uncertainty Studies

In the 2003+2004 jet cross section and A_LL paper we quoted a 5% systematic uncertainty on the absolute BTOW calibration.  For the 2005 jet A_LL paper there is some interest in reducing the size of this systematic.

I went back to the electron ntuple used to set the absolute gains and started making some additional plots.  Here's an investigation of E_{tower} / p_{track} versus track momentum.  I only included tracks passing directly through the center of the tower (R<0.003) where the correction from shower leakage is effectively zero.

Full set of electron cuts (overall momentum acceptance 1.5 < p < 20.):

dedx>3.5 && dedx<4.5 && status==1 && np>25 && adc>2*rms && r<0.003 && id<2401

I forgot to impose a vertex constraint on these posted plots, but when I did require |vz| < 30 the central values didn't really move at all.

Here are the individual slices in track momentum used to obtain the points on that plot:

Electrons with momentum up to 20 GeV were accepted in the original sample, but there are only ~300 of them above 6 GeV and the distribution is actually rather ugly.  Integrating over the full momentum range yields a E/p measurement of 0.9978 +- 0.0023, but as you can see the contributions from invididual momentum slices scatter around 1.0 by as much as 4.5%

Next Steps?  -- I'm thinking of slicing versus eta and maybe R (distance from center of tower).

Run 6 BTOW Calibration


This is not the final calibration for the 2006 data, but it's a big improvement over what's currently in the DB.  It uses MIPs to set relative gains for the towers in an eta ring, and then the absolute scale is set by electron E/p.

Isolation Cut Failures

This is a problem that we encountered in 2005, where several pairs of towers had good-looking spectra until the isolation cut was applied, and then quickly lost all their counts.  Well, all of the towers that I had tagged with this problem in 2005 still have it in 2006, with one exception.  Towers 1897 and 1898 seem to have miraculously recovered, and now towers 1877 and 1878 appear to have isolation failures.  Perhaps this is a clue to the source of the isolation failures?


everything I could find on nov07:

<input URL=",sanity=1,tpc=1,emc=1,trgsetupname= ppProduction||ppProductionTrans||ppProductionLong||pp2006MinBias||ppProductionJPsi||ppProduction62||ppProductionMB62, filename~st_physics,filetype=daq_reco_mudst" nFiles="all" />


Same as 2005.  All MIP fits are basic Gaussians over the range 5..250 ADC-PED.  Electron fits are Gaussian + linear in a very crude attempt to estimate hadronic background.

Working Directory:



The gains look pretty balanced on the east side and west side.  Note that I didn't multiply by sin(theta), so we expect an eta-dependence here.  The widths plot is interesting because it picks out one very badly behaved crate on the east side at phi=0. I believe it is 0x0C, EC24E (towers 4020-4180).  The tower fits are attached below if you're interested.  Bad towers are marked in red.

Electron Normalization:

E/p plots for all 40 eta-rings (first 20 on west side, 21-40 on east side) are attached below.  In general, the electrons indicate a 9-10% increase in the MIP gains is appropriate.  In the last two eta rings on each side, that number jumps to 20% and 40%.  This is more or less consistent with the scale factors found in the 2003 calibration (the last time we used a full-scale energy of 60 GeV.  If I scale the MIP gains and plot the full-scale E_T I get the plot on the left.  Fitting the eta dependence with a pol0 over the middle 36 eta rings results in a ~62 GeV scale and a nasty chi2.

So after scaling with the electrons it looks like we are actually a couple of GeV high on the absolute scale.  I'll see if this holds up once I've made the background treatment a little more sophisticated there.  I also have to figure out what went wrong with the electrons out at the edges.  I didn't E/p would be that sensitive to the extra material out there, but for some reason the normalization factors out there are far too large.  Next step will be to comapre this calibration to one using electrons exclusively.


Calibration Uncertainty:

Here are some links that address different parts of the calibration uncertainty that are not linked from this page:

eta dependence

Online Work

Steve's caiibrations page contains most of the details:

Some files of slopes, etc. that I produced are currently stored at

MIP check on 2006 Slope Calibration



~300k events processed using fastOffline:
Run 7079034 ~189K
Run 7079035 ~115K

Number of events with nonzero primary tracks = 109k / 309k = 35%

Still a few problems with pedestal widths in the database, although now they appear to be restricted to id > 4200. If I don't cut on adc>2*rms, the software id distribution of MIPs looks pretty isotropic:

The distribution of primary tracks also looks a lot better:

I was able to calculate MIP gains for each of the 40 eta-rings. The plot at the top fits a line to the full-scale transverse energies extracted from the gains (excluding the outer two eta-rings on each side). For the error calculations I used the error on the extraction of the mean of the MIP ADC peak and propagated this through the calculation. This is not exactly correct, but it's a pretty close approximation. In a couple of cases the error was exceedingly small (10^-5 ADC counts), so I forced it to an error of 1 GeV (the fit failed if I didn't).

As you can see in the text file, an error of 1 ADC in the MIP peak leads to an error of 3 GeV in the full-scale transverse energy. Therefore I would say that pedestal fluctuations (1-2 ADCs) give an additional error of 5 GeV to my calculations, which means that the majority of these eta-rings are consistent with a 60 GeV full-scale.


  • A straight-line fit yields 56 GeV as the average full-scale transverse energy of the towers
  • We have enough stats; errors are dominated by pedestal fluctuations leading to a 5 GeV uncertainty
  • Tower response is flat in E_t across eta-rings (excluding last two rings where MIPs fail)
  • Good job Stephen and Oleg!

The First Attempt

Note: The first attempt at this analysis was plagued by poor TPC tracking and also problems with corrupted BTOW pedestal widths in the database. I'm including the content of the original page here just to document those problems.

250k events processed using fastOffline:

Run 7069023 100K
Run 7069024 100K
Run 7069025 50K

Number of events with nGlobalTracks > 0 = 30166 (12%)

On the left you see the software id distribution of slope candidates (adc-ped>3*rms, no tracking cuts). There's a sharp cutoff at id==1800. But before you go blaming the BEMC for the missing MIPs, the plot on the right shows eta-phi distribution of global tracks without any EMC coincidence. The hot region in red corresponds to 0<id<1800:

As it turns out, the missing slope candidates are likely due to wide pedestals. The pedestal values look fine, but if I plot pedrms for id<1800 and id>1800 using the slope candidates that did survive:

Is it possible that the TPC track distribution is connected to this problem?

2006 Gain uniformity

Using the gains we calculated for 2006 tower by tower from the MIPs and then corrected with the electron eta rings, I calculated how it differed from the ideal gain assuming containment of an EM shower with 60 GeV ET. After removing bad towers, we can fit the distribution of this ratio to a gaussian and we find there is approximately a 6% variation in the gains.


Calibration Uncertainty Calculation


The uncertainty on the 2006 BTOW Calibration is 1.6%. This value is the combination of a 1.3% overall uncertainty and a 0.9% uncertainty caused by variations in the different crates. This uncertainty should be treated as a measure of the bias in the 2006 Calibration.


Attached is a document how the calibration uncertainty for 2006 will be calculated:

  • Eliminate dependence on simulations through tighter fiducial volume cuts
  • Reduce trigger bias by explicitly avoiding electrons matched to trigger HTs or TPs
  • Validate modeling of E/p backgrounds. Confirm that the fit is unbiased by checking
    consistency of low-background and high-background samples.
  • Confirm that crate timing does not systematically bias the energy reconstruction.

The uncertainty on the calibration will be assigned as the maximum between |E/p −1.0| and the uncertainty on the peak position.


We did some initial studies to determine the magnitude of each of these effects, and then we generated calibration trees covering the entire 200 GeV pp run from 2006. The code used to generate these trees is available in StRoot/StEmcPool/StEmcOfflineCalibrationMaker.

We made the following cuts on the tracks to select good electrons and an unbiased sample.

List 1:

  • 3.5 < dEdx < 4.5
  • abs(vertexZ) < 30
  • 1.5 < p < 15 GeV
  • dR (from tower center to track projection) < 0.004 (in units of deta,dphi)
  • tower_id == tower_id_exit of projection
  • Energy of highest neighbor < 0.5 * track energy

After making these cuts, we fit the remaining sample to a gaussian plus a first order polynomial, based on a study of how to fit the background best.

Figure 1 uses an isolation cut to find a background rich sample to fit:

Figure 2 shows the stability of the E/p location (on the y-axis) between our fit and just a gaussian for different windows in dEdx (x-axis)

Figure 3 shows the E/p location (y-axis) for different annuli in dR (x-axis/1000), which motivated our dR cut to stay in a flat region:

After making all of these cuts, we fit E/p to the entire sample of all our electrons. We then add different cuts based on the trigger information to see how that might affect the bias. We looked at four scenarios:

List 2:

  1. All electrons after stringent cuts
  2. Electrons from events that were NOT HT/HTTP triggered
  3. Electrons from events that were only HT/HTTP triggered
  4. Electrons from HT/HTTP events with trigger turnon tracks (4.5 < p < 6.5 GeV) removed

From these scenarios we chose the largest deviation from E/p = 1.0 as the overall uncertainty on the calibration. This happens to be scenario 3, working out to 1.3%.

Figure 4: E/p for different scenarios

 We also observed a possible crate systematic by fitting E/p for each crate separately.

Figure 5 E/p for each crate:

 According to the chi^2, there is a non statistical fluctuation. To figure out how much that is, we compared the RMS of these points to that when the data is randomly put into 30 partitions. It turns out that all of it is due to that one outlier, crate 12. Since crate 12 contributes 1/15 to each eta ring that it touches, the deviation of this point from the fit causes an uncertainty of 0.9%. This additional uncertainty increases the total uncertainty to 1.6%.

Side Note - Linearity:

After removing HT/HTTP events, we took a look at this plot of p (y-axis) vs E/p (x-axis). By eye, it looks pretty flat, which we verified by splitting into p bins.

Figure 6 p vs E/p

Figure 7 E/p vs p

 Eta Dependence:

There was some question about whether there was eta dependence. This was investigated and found to be inconsequential:

Figure 8: Divided the sample into 3 separate time periods. Period 1 goes is before run 7110000. Period 2 is between runs 7110000 and 7130000. Period 3 is after run 7130000. The deviations are below 1.6%.

Figure 9: Agreement between east and west barrel:

 Figure 10: ZDC Rate vs. energy/p

Figure 11: E/p fits for three different regions in ZDC rate: 0 - 8000, 8000-10000, 10000-20000 Hz.

Comparison of Electron and MIP Calibrations

This page compares the new tower calibration performed using only electron E/p to the calibration using last year's algorithm.  The two calibrations are found to be consistent within 120 MeV in E_T.

I've also attached the tower-by-tower plots of electron E/p so you can see the results for yourself.  I'll write up a more complete description of the calibration algorithm shortly.

Comparison of Online and Offline Calibrations


This page compares the online and first offline calibrations.  The online calibration table was generated during data-taking using a single long run processed through fastOffline production and uploaded on March 30th.  It uses slopes to set the relative gains in an eta-ring and then normalizes the eta-rings using MIPs.  The first offline calibration uses a significant fraction of the produced transverse and late longitudinal runs.  It sets the relative gains using MIP peaks and then uses electron E/p to set the absolute scale.  It was uploaded on December 7th.

Body Counts:

138 additonal towers are masked in this first offline calibration, leaving 4517 good towers.  1 tower (2916) was masked before but is now listed as OK.  To be honest, I have no idea why it was masked in the online calib; its slope looks fine to me.


The electron E/p scaling in the offline calibration increased the gains by an approximately uniform 10 percent (more at the edges).  This effect is seen in the following plot of offline E_T - online E_T, integrated over all towers that were good in both calibrations:

Now, the interesting thing is the relative changes of offline-online for the east side and the west side.  If I only plot the location of towers whose gains increased by more than 20% I get

There were only 12 towers whose gains decreased by 20%; all of them were on the west side. Finally here's a plot of the E_T change of the remaining towers:

I think the message here is clear:  the gains on the east side have increased more than the gains on the west side!  It's possible that the use of the online calibration in previous Run 6 jet studies is at least partially responsible for the obsereved east-west jet asymmetry.

To get quantitative about this effect we have to go to 1D.  I've attached a PDF of eta-ring by eta-ring histograms like the first one on this page.  The first two pages are the east side; the next two are the west side.  I've found it easiest to analyze if you set your Reader to view two pages at a time; then you'll be comparing towers with the same absolute value of pseudorapidity when you flip.  The conclusion is pretty clear: at midrapidity the difference in offline - online E_T floats around 5 - 8 GeV on the east side, but it's only about 2 - 5 GeV on the west side.

Gain Stability Check

I've updated my codes to do a more systematic investigation of the stability of the gains.  Instead of trying to get sufficient tower-by-tower statistics for different time periods, I'm looking at MIP peaks for single runs integrated over all towers.  Here's the plot:

Features of note include the bump covering the first couple of days after the shutdown, the bunch of runs on day 123/4 with very low average peaks, and the general decreasing slope (consistent with towers losing high voltage).  I also ran this plot for west and east separately:

I'm running jobs now to do electron selection instead of MIPs.  I think that I can probably still do this as a function of run, but certainly I'll have sufficient stats to  plot vs. fill if necessary.

Goal:  Compare the tower slopes and MIP peaks from the following three periods to check for stability.
  1. Day < 104 (97-99)
  2. 104 < Day < 134 (114-119)
  3. Day > 134 (134-139)
I just chose those periods arbitrarily.  I still have to generate the slope histograms for the longitudinal running, but of course I can extend the study to do that if it proves interesting.  Now, I filled these histograms without doing any trigger selection or status table cuts, so I wouldn't expect them to be the cleanest things in the world.  Consider it a "first look", if you like.  Anyway, here are gaussian fits to histograms of (slopeA-slopeB)/slopeA for all 4800 towers for each of the three combinations.  We see a 2.7% shift towards flatter slopes between days 97-99 and 114-119.  Note that this period includes the 10 day accident shutdown (104-114).  The slopes spread out quite a bit between periods 2 and 3, and there's also a small 1% shift towards flatter slopes.

The next set of plots compare gains extracted from MIP peak positions where the MIP peaks are generated using subsets of the Run.  Comparing before and after the shutdown yields a mean difference of 110 MeV with a width of 3 GeV.  This difference is significantly less than 1 percent.  The comparison between middle and late (essentially a comparison between transverse and late longitudinal running) indicates a 1.5 percent drop in the gains with a 2.3 GeV sigma.

Run 7 BTOW Calibration

Online Work

Steve T's page:

First Iteration

March 27, 2007

Steve and Oleg took 600k fast events in runs 8086057, 8086058, and 8086060 to calculate the tower slopes.  Here's a summary plot of tower slopes vs. eta:

I've attached two list of slopes for each tower at the bottom of the page.  The columns are

id -- flag -- slope -- error -- chi2 -- ndf

where the flag is determined by

if(ndf < 30) x                        //empty, stuck bit
else if(chi2 > 200.) ?               //worth a closer look
else if(slope outside 4*RMS) *   //probably needs HV adjustment
else blank                             //channel OK at 4*RMS level

The file slopes_noflags.txt has the same data as the first file, but it omits all the flag information so that it can be read into a macro easily.  Flagged channels are also listed in red in the mega-PDF

Second Iteration

Same procedure as  First Iteration.  Took 600k events in runs 8089017, 8089019, 8089021.  This time the processing went smoothly and I was able to analyze ~all the events that were taken.  Here's the summary of slopes vs. eta:

I've attached at the bottom of the page lists of slopes for individual towers.  The format is the same as before, although I've adjusted the chi2 cut to 300 because of the additional statistics and I've also adjusted the 4*RMS slope cut to take into account the updated mean and RMS values from the plot above.

Third Iteration

Data gathered from runs 8090021, 8090022, 8090023.  The only change I made to the code was to tweak the parameters of the pedestal fit a little bit, since I noticed a couple of towers where it failed.

Fourth Iteration

Data gathered from Runs 8091003, 8091005, 8091007.  Same analysis codes as in Third Iteration

Fifth Iteration

Runs:  8092080, 8092081, 8092083

Seventh Iteration

Run 8095073, 600k events.

This summary plot highlights swapped towers in red.  As Steve pointed out, we weren't adjusting the HV of these tubes correctly in most of the previous iterations.

Run 8 BTOW Calibration (2008)

 2008 BTOW calibrations 

  1. BTOW HV used in 2008 are in the file 2008_i2a.csv, this file will contain a few towers
    (<50)which might have been set to zero at a later date


01 statistical analysis of 2008 HV

 Goal: study eta dependence of 2008 BTOW HV

Fig 1 Eta-phi distribution of HV

Formulas used to map tower ID in to eta-phi location
    int id0=id-1;
    int iwe=0; // West/East switch
    if(id>2400) iwe=1;
    int id0=id0%2400;
    int iphi=id0/20;
    int ieta=id0%20;
    if(iwe==0) ieta=ieta+20;
    else ieta=19-ieta;

Fig 2 Batch 1, Eta-phi distribution of HV

eta=0.05  mean HV=821 +/- 5  sigHV=60
eta=0.15  mean HV=820 +/- 5  sigHV=60
eta=0.25  mean HV=815 +/- 5  sigHV=62
eta=0.35  mean HV=811 +/- 5  sigHV=66
eta=0.45  mean HV=817 +/- 5  sigHV=66
eta=0.55  mean HV=820 +/- 5  sigHV=57
eta=0.65  mean HV=820 +/- 5  sigHV=59
eta=0.75  mean HV=806 +/- 5  sigHV=62
eta=0.85  mean HV=807 +/- 5  sigHV=58
eta=0.95  mean HV=829 +/- 5  sigHV=65


Fig 3 Batch 2, Eta-phi distribution of HV

eta=0.05  mean HV=759 +/- 6  sigHV=56
eta=0.15  mean HV=760 +/- 7  sigHV=62
eta=0.25  mean HV=756 +/- 6  sigHV=53
eta=0.35  mean HV=763 +/- 6  sigHV=55
eta=0.45  mean HV=756 +/- 7  sigHV=58
eta=0.55  mean HV=760 +/- 6  sigHV=54
eta=0.65  mean HV=743 +/- 6  sigHV=52
eta=0.75  mean HV=754 +/- 6  sigHV=54
eta=0.85  mean HV=754 +/- 7  sigHV=64
eta=0.95  mean HV=769 +/- 7  sigHV=59


Fig 4 Batch 3, Eta-phi distribution of HV

eta=-0.95  mean HV=730 +/- 4  sigHV=57
eta=-0.85  mean HV=723 +/- 4  sigHV=57
eta=-0.75  mean HV=727 +/- 4  sigHV=59
eta=-0.65  mean HV=718 +/- 4  sigHV=58
eta=-0.55  mean HV=723 +/- 4  sigHV=58
eta=-0.45  mean HV=720 +/- 4  sigHV=56
eta=-0.35  mean HV=727 +/- 4  sigHV=54
eta=-0.25  mean HV=724 +/- 4  sigHV=60
eta=-0.15  mean HV=735 +/- 4  sigHV=59
eta=-0.05  mean HV=729 +/- 4  sigHV=60


02 BTOW swaps ver=1.3

Example of MIP peak for BTOW towers pointed by TPC MIP track: Spectra for 4800 towers (raw & MIP) are in attachment 1.


Method of finding MIP signal in towers:

 Table 1

BTOW swaps, very likely, ver 1.3, based on 2008 pp data, fmsslow-production
 266 --> 286 , 267 --> 287 , 286 --> 266 , 287 --> 267 , 389 --> 412 ,
 390 --> 411 , 391 --> 410 , 392 --> 409 , 409 --> 392 , 410 --> 391 ,
 411 --> 390 , 412 --> 389 , 633 --> 653 , 653 --> 633 , 837 --> 857 ,
 857 --> 837 ,1026 -->1046 ,1028 -->1048 ,1046 -->1026 ,1048 -->1028 ,
1080 -->1100 ,1100 -->1080 ,1141 -->1153 ,1142 -->1154 ,1143 -->1155 ,
1144 -->1156 ,1153 -->1141 ,1154 -->1142 ,1155 -->1143 ,1156 -->1144 ,
1161 -->1173 ,1162 -->1174 ,1163 -->1175 ,1164 -->1176 ,1173 -->1161 ,
1174 -->1162 ,1175 -->1163 ,1176 -->1164 ,1753 -->1773 ,1773 -->1753 ,
2077 -->2097 ,2097 -->2077 ,3678 -->3679 ,3679 -->3678 ,3745 -->3746 ,
3746 -->3745 ,4014 -->4054 ,4015 -->4055 ,4016 -->4056 ,4017 -->4057 ,
4054 -->4014 ,4055 -->4015 ,4056 -->4016 ,4057 -->4017 ,4549 -->4569 ,
4569 -->4549 ,

 Details for all swaps are shown in attached 2.


Other problems found during analysis, not corrected for, FYI


03 MIP peak analysis (TPC tracks, 2008 pp data)

I examined runs from 2008 pp (list attached below) to create calibration trees (using StRoot/StEmcPool/StEmcOfflineCalibrationMaker). The code loops over the primary tracks in the event and selects the global track associated with it, if available. If the track can be associated to a tower and has outermomentum > 1 GeV, it is saved.

I then loop over those tracks and choose ones that fall within a certain criteria:

  • p > 1
  • adc - ped > 1.5 * ped_rms
  • tower_entrance_id = tower_exit_id
  • only a single track points to the tower
  • neighoring towers have small amounts of energy

We can sum over all runs to produce MIP spectrum in 4445 towers. Of those, 4350 pass current QA requirements. An example MIP spectrum with fit is shown below. All MIP peaks can be seen in the attached PDF. It's important to note that the uncertainty on the MIP peak location with these statistics is on average 5%. This number is a lower limit on the calibration coefficient uncertainty that can only be improved with statistics.


Fig 1. Typical MIP peak. Plots like this for all 4800 towers are in attachment 1.

The following plot shows MIP peak location in ADCs (in eta, phi space) of all of towers where such a peak could be found.

Fig 2. MIP Peak (Z-axis) for all towers

This plot shows the status codes of the towers. White are the towers that had 0 entries in their histograms. Red are the good towers (pushed them off scale to see the rest of the entries). Towers in the outermost eta bin received different treatment. The fit range was between [6,100] for those towers (vs [6,50] for the rest). The cuts applied for QA were slightly loosened. The rest of the codes follow this scheme:

  • bit 1: entries in histogram > 0
  • bit 2: sigma of fit below threshold (15,20)
  • bit 4: mean of fit above 5 ADCs
  • bit 8: difference of fit mean and MPV in fit range below threshold (5,10)

Fig 3. status of towers

 Spectra of towers rejected by rudimentary automatic QA were manually inspected and 91 were found to contain reasonable MIP peak and have bin re-qualified as good. PLots for those towers are in attachment 2.  

04 relative tower gains based on MIPs (gain correction 1)

 Determination of relative gains BTOW gains based on MIP peak for the purpose of balancing HV for 2009 run


  • use fitted 03 MIP peak analysis (TPC tracks, 2008 pp data)
  • find average MIP value for 40 eta bins
  • West barrel:  preserve absolute average MIP peak position in the , compute gain correction to equalize all towers at given eta to the average for this eta
  • East barrel: enforce absolute average MIP peak to agree with the West barrel, correct relative gains in the similar way.

In this stage of calibration process 4430 towers with well visible MIP peak were use. The remaining 370 towers will be called 'blank towers' . There are many reasons MIP peak doe snot show up e.g. dead hardware. ~60 of the 'blank towers' are 02 BTOW swaps ver=1.3- as identified earlier and not corrected in this analysis.  


Fig 1. Left: MIP peak (Z-axis) was found for 4430 towers shown in color. White means no peak was found - those are "blank towers".  Right: eta-phi distribution of blank towers.  On both plots East (West)  barrel is show on etaBins [1-20], (21,40).

The (iEta, iPhi ) coordinates were computed based on softID as follows:

   int jeta= 1+(id-1)%20; // range [1-20]
   int jphi= 1+(id-1)/20; // range [1-240]
   if(jphi<=120) { // West barrel
      keta=jeta+20; kphi=jphi;
   } else { // East barrel
      keta=-jeta+21; kphi=jphi-120;


Fig 2. Average MIP position as function of eta bin. West-barrel gains are higher even of average.


Gain corrections (GC1) were computed as
     GC1(iEta,iPhi)= MIP(iEta,iPhi) / avrMip(iEta)

For the East-barrel we used values of avrMip(iEta)from symmetric eta-bins from the West barrel.

If computed correction was between [0.95,1.05] or if towers was "blank"   GC1=1.00 was used.

Fig 3. Left distribution of gain corrections GC1(iEta).  Right: value of   GC1(iEta,iPhi).


Attached spreadsheet contains computed  GC1(softID) in column 'D'  together with  MIP peak parameters (columns H-P) for all 4800 towers. Below is just first 14 towers.

Used .C macro is attached as well.

05 Absolute Calibration from Electrons

We use the MIP ADC location calculated in part 03 to get a preliminary measure of the energy scale for each tower.

The following formula from SN436 provides the calibration coefficient:

C =

where E = C * (ADC - ped).

For the electron sample I select tracks with:

  • 1.5 < p < 6.0 (GeV)
  • dR < 0.0125 (from center of face of tower in eta/phi space)
  • adc - ped > 2.5 * ped_rms in tower
  • nHits > 10
  • nSigmaElectron > -1

Here is one of the E/p distributions. Note the error on the mean is about 2%, which is about average.


For each electron we calculate E/p and sum over eta rings. Here is the peak of E/p for each eta bin. The error bars show the error on the mean value, and the shaded bar is the sigma. I fit over the range [-0.9,0.0] and [0.0,0.9] separately. The fit for the east reports the mean is 0.9299 +/- 0.0037. For the west, I get 0.9417 +/- 0.0035.


The location of the E/p peak tells us the correction that needs to be applied to the calibration coefficients of towers in each eta ring to get the correct absolute energy.


Reference plot (electron showers):

06 Calculating 2009 HV from Electron Calibrations

The ideal gain for each tower satisfies the following relation, where E_T = 60 GeV when ADC is max scale (~4095 - ped):


We want to calculate the total energy deposited in a tower, which is the following in the ideal case:


 In reality, we calculate the calibration according to the following formula:


where there is an electron correction for each eta ring, and the MIP location is determined for all towers.

Thus, to have ideal gains, we want the following relation to hold


To make this relation true, we need to adjust the high voltage for each tower according to the following relation:


We can check the changes using slopes.

07 BTOW absolute gains 'ab initio'

 Summary of intended BTOW HV change, February 24, 2009


We will NOT change average gain of West BTOW for eta bins[1,18]. For all other eta bins we will aim at the average West Btow marked as red dashed line.

 Full presentation is in attachment 1.

Detailed E/P spectra for 40 eta bins are in attachment 2 & 3.

08 Completed Calibration and Uncertainty

The 2008 Calibraton has been uploaded into the database. I was able to find calibration coefficients for 4420 towers. Of the remaining towers, 353 were MIPless and 27 had spectrums that I could not recover by hand.

This year, differently from previous years, known sources of bias are removed. If an event had a nonHT trigger, the tracks from that event were used for the calibration (even if it had an HT trigger). Most of the triggers were fms slow triggered events. Each eta ring was calibrated separately, and then a correction for each crate was applied. After these corrections, I once again made the cuts on the electrons more stringent. No deviation from E/p =1 was found. With the biases eliminated, we now quote a systematic variance instead of a systematic bias as the uncertainty on the calibration.

The source of this uncertainty are the uncertainties on various fits used for each calibration, namely the MIP peak for each tower, the absolute calibration for each eta ring, and the correction for each crate. These uncertainties are highly correlated. I have completed this calibration by recalculating the calibration table 3,000 times varying the MIP peaks, the eta ring corrrections and the crate corrections each time. Using this method, I was able to determine the correlated uncertainty for each calibrated tower. This uncertainty is, on average, 5%.

This uncertainty is different than the systematic bias quoted for 2005 and 2006. It is a true variance on the calibration. To use this uncertainty, analyzers should recalculated their analysis using test tables generated for this purpose. The variance in the results of these multiple analyses will give a direct measure of the uncertainty due to the calibration scale uncertainty. These tables will be uploaded to the database with the names "sysNN". They should be used before clustering, jet finding, etc.

Run 9 BTOW Calibration

Parent page for BTOW 2009 Calibrations

01 BTOW HV Mapping

We started at the beginning of the run to verify the mapping between the HV cell Id and the softId it corresponds to. To begin, Stephen took 7 runs with all towers at 300V below nominal voltage except for softId % 7 == i, where i was different for each run. Here are the runs that were used:

softId%7 Run Number Events
1 10062047 31k
2 10062048 50k
3 10062049 50k
4 10062050 50k
5 10062051 50k
6 10062060 100k
0 10062061 100k


We used the attached file 2009_i0.txt (converted to csv) as the HV file. This file uses the voltages from 2008 and has swaps from 2007 applied. Swaps indentified were not applied and will be used to verify the map check.

File 2009_i0c.txt contains some swaps identified by the analysis of these runs.

File 2009_i1c.txt contains adjusted HV settings based on the electron/mip analysis with same mapping as 2009_i0c.txt.

Final 2009 BTOW HV set on March 14=day=73,  Run 10073039 , HV file: 2009_i2d.csv  

02 Comparing 2007, 2008 and 2009 BTOW Slopes

We have taken two sets of 1M pp events at sqrt(s)=500 GeV. For future reference, the statistical error on the slopes is typically in the range of 3.7%.  I give a plot of the relative errors in the 5th attachment.


  • Run 10066160 HVFile = 2009_i1c.csv (2009 HV)
  • Run 10066163 HVFile = 2009_i0c.csv (2008 HV)

    plus we have

  • 2007 Data HVFile = 2007_i8.csv (2007 HV)

    Comparing the overall uniformity of the gain settings, I give the distribution of slopes divided by the average over the region |ETA|<0.8 for 2007, 2008 and 2009 (First three attachments)

    I find that there is little difference in the overall uniformity of the slopes distribution over the detector...about +/-5%. I also give a plot showing the average slopes in each eta ring for the three different voltage settings in each year 2007. 2008 and 2009. (4th attachment) As you can see, the outer eta rings were overcorrected in 2008. They are now back to nearly the same positions as in 2007.


    Here is my measurement of 'kappa' from 2007 data.  I get from 7-8, depending on how stringent the cuts are.  I think this method of determining kappa is dependent on the ADC fitting range.  In theory, we should approach kappa~10.6 as we converge to smaller voltage shifts.





    So which ones should we adjust?  Here is a fit of the slope distribution to a gaussian.


     As we can see, the distribution has an excess of towers with slopes >+/-20% from the average.   I checked that these problem towers are not overwhelmingly swapped towers (15/114 outliers are swapped towers; 191/4712 are swapped towers).  Here is an eta:phi distribution (phi is SoftId/20%120, NOT angle!).  The graph on the left gives ALL outliers, the graph on the right gives outliers with high slopes only (low voltage).  There are slightly more than expected in the eta~1 ring, indicating that the voltages for this ring are set to accept few particles than the center of the barrel.



    So Oleg Tsai and I propose to change only those outliers which satisfy the criteria:

    |slope/ave_slope - 1|>0.2  && |eta|<0.8.  (Total of 84 tubes)

    We then looked one-by-one thru the spectra for all these tubes (Run 10066010) and found 12 tubes  (not 13 as I stated in my email) with strange spectra:

    Problem Spectra

    Bad ADC Channels: Mask HV to Zero

    We then calculated the proposed changes to the 2009_i1c.csv HV using the exponent kappa=5.  Direct inspection of the spectra made us feel as though the predicted voltage changes were too large, so we recomputed them using kappa=10.48.  We give a file containing a summary of these changes:

    Proposed HV Changes (SoftId SwappedID Slope(i1c) Ave Slope Voltage(i1c) New Voltage


    (We have identified 3 extra tubes with |eta|>0.8 which were masked out of the HT trigger to make it cleaner....we propose to add them to list to make a total of 87-7 = 80 HV changes.)


    PS.  We would also like to add SoftId-3017 HV800 -> 650.  This make 81 HV changes.




    A word about stability of the PMT High Voltage and these measurements.  I compared several pairs of measurements in 2007 taken days apart.  Here is an intercomparison of 3 measurements (4,5 and 7) taken in 2007.  The slopes have a statistical accuracy of 1.4%, so the distribution of the ratio of the two measurements should have a width of sqrt(2)*1.4 = 2% The comparison of the two measurements is just what we expect from the statistical accuracy of the slope measurements.





     Comparing the two recent measurements in 2009, we have a set of about 600 tubes with a very small voltage change.  The slopes were measured with an accuracy of 3.7%, so the width of the slope ratio distribution should be sqrt(2)*3.7% =5.2%.  Again, this is exactly what we see.  I do not find any evidence that (a large percentage of) the voltages are unstable!






























    03 study of 2009 slopes (jan)

     Purpose of this study is to evaluate how successful was our firts attempt to compute new 2009 HV for BTOW.

    Short answer: we undershoot by a factor of 2 in HV power- see fig 4 left.

    Input runs: 10066160 (new HV) and 10066163 (old HV) 

    Fig 1. Pedestal distribution and difference of peds between runs - perfect. Peds are stable, we can use the same slope fit range (ped+20,ped+60) blindly for old & new HV.


    Fig 2. Chosen HV change and resulting ratio of slopes - we got the sign of HV change correctly!

    Fig 3. Stability test. Plots as in fig 2, but for a subset of towers we change HV almost nothing (below 2V) but yield was large. One would hope slope stay put. They don't.  This means either slopes are not as reliable as we think or HV is not as stable as we think.  

    Fig 4.  Computed 'kappa' :  sl2/sl1=g1/g2=V1/V2^kappa for towers with good stats and HV change of at least 10 Volts, i.e. the relative HV change is more than 1%.  Right plot shows kappa as function of eta - no trend but the distribution is getting wider - no clue why?

    Fig 5.  Computed 'kappa' as on fig 4. Now negative, none physical values  of kappa are allowed.


    04 Spectra from Problem PMT Channels

    We set the HV = 800 Volts for all channels which have been masked out, repaired, or otherwise had problems in 2008.  I have examined the spectra for these channels and give pdfs with each of these spectra:


    I identify 37 tubes which are dead, 39 tubes which can be adjusted, and 1 with a bit problem.  We should pay careful attention to these tubes in the next iteration.


    05 Summary of HV Adjustment Procedure

    Summary of process used to change the HV for 2009 in BTOW:HV Files: Version indicates interation/mapping (numeral/letter)

    1) 2009_i0.csv      HV/Mapping as set in 2008.  Calibration determined from 2008 data electrons/MIPS.

    2) 2009_i0d.csv      Map of SoftId/CellId determined by taking 6 data sets with all voltages set to 300 V, except for SoftId%6=0,1,2,3,4,5,6, successively. (link to Joe's pages)

    3) 2009_i1d.csv       HV change determined from 2008 data electrons/MIPS (g1/g2)=(V2/V1)**k, with k=10.6 (determined from LED data).

    4) 2009_i2d.csv        Slopes measured for all channels.  Outliers defined as |slope/<slope> -1|>0.2 (deviation of channel slope from average slope over barrel >20%:Approx 114 channels. Outliers corrected according to (s1/s2)=(V1/V2)**k as above.  Hot towers HV reduced by hand. (Approx 10 towers)

    06 comparison of BTOW status bits L2ped vs. L2W , pp 500 (jan)

     Comparison of BTOW status tables generated based on minB spectra collected by L2ped ( conventional method) vs. analysis of BHT3 triggered , inclusive spectra.

    1. Details of the method are given at BTOW status table algo, pp 500 run, in short status is decided based on ADC integral [20,80] above pedestal.
    2. the only adjusted param is 'threshold' for  Int[20,80]/Neve*1000. Two used values are 1.0 and 0.2.
    3. For comparison I selected 2 fills: F10434 (day 85, ~all worked) and F10525 (day99, 2 small 'holes' in BTOW) - both have sufficient stats in minB spectra to produce conventional status table.
    4. Matt suggested the following assignment of  BTOW status bits (value of 2N is given)
      • good -->stat=1
      • bad, below thres=0.2 --> stat=2+16 (similar to minB  cold tower)
      • bad, below thres=1.0 --> stat=512 (new bit, stringent cut for dead towers for W analysis) 
      • stuck low bits --> stat=8 (not fatal for high-energy response expected for Ws)
      • broken FEE (the big hole) in some fills, soft ID [581-660] --> stat=0


    Fig 1. Fill F10343 thres=1.0 (red line)

    There are 108 towers below the red line, tagged as bad. Comparison to minB-based tower QA which tagged 100 towers. There are 4 combinations for tagging bad towers with 2 different algos. Table 1 shows break down, checking every tower. Attachments a, b show bad & good spectra.

    Table 1, Fill F10434,
    QA thres=1.0
      minB=ok minB=bad
    BHT3=ok 4692 0
    BHT3=bad 8 100
    QA thres=0.2
      minB=ok minB=bad
    BHT3=ok 4696 0
    BHT3=bad 4 100


    Conclusion 1: some the additional 8 towers tagged as bad based on BHT3 spectra are either very low HV towers, or optical  fiber is partially broken. If those towers are kept for W analysis any ADC recorded by them would yield huge energy. I'd like to exclude them from W analysis anyhow.   

    To preserve similarity to minB-based BTOW status code Matt agreed we tag as bad-for-everybody all towers rejected by BHT3 status code using lower threshold of 0.2. Towers  between BHT3 QA-thresholds [0.2,1.0] will be tagged with new bit in the offline DB and I'll reject them from W-analysis if looking for W-signal but not necessary if calculating the away side ET for vetoing of away side jet.



    Table 2, Fill F10525, 2 'holes' in BTOW
    QA thres=1.0
      minB=ok minB=bad
    BHT3=ok 4653 1
    BHT3=bad 19 127
      minB=ok minB=bad
    BHT3=ok 4662 2
    BHT3=bad 10 126


    Spectra are in attachment c). Majority of towers for which this 2 methods do not agree have softID ~500 - where this 2 holes reside (see 3rd page in PDF)

    Tower 220 has stuck lower bits, needs special treatment - I'll add detection (and Rebin()) for such cases.


    Automated generation of BTOW status tables for  fills listed in Table 3  has been done, attachment d) shows summary of all towers and examples of bad towers for all those fills.

     Table 3
         1  # F10398w  nBadTw=112 totEve=12194 
         2  # F10399w  nBadTw=111 totEve=22226 
         3  # F10403w  nBadTw=136 totEve=3380 
         4  # F10404w  nBadTw=115 totEve=9762 
         5  # F10407w  nBadTw=116 totEve=7353 
         6  # F10412w  nBadTw=112 totEve=27518 
         7  # F10415w  nBadTw=185 totEve=19581 
         8  # F10434w  nBadTw=108 totEve=15854 
         9  # F10439w  nBadTw=188 totEve=21358 
        10  # F10448w  nBadTw=190 totEve=18809 
        11  # F10449w  nBadTw=192 totEve=18048 
        12  # F10450w  nBadTw=115 totEve=14129 
        13  # F10454w  nBadTw=121 totEve=6804 
        14  # F10455w  nBadTw=113 totEve=16971 
        15  # F10463w  nBadTw=114 totEve=12214 
        16  # F10465w  nBadTw=112 totEve=8825 
        17  # F10471w  nBadTw=193 totEve=21003 
        18  # F10476w  nBadTw=194 totEve=9067 
        19  # F10482w  nBadTw=114 totEve=39315 
        20  # F10486w  nBadTw=191 totEve=37155 
        21  # F10490w  nBadTw=154 totEve=31083 
        22  # F10494w  nBadTw=149 totEve=40130 
        23  # F10505w  nBadTw=146 totEve=37358 
        24  # F10507w  nBadTw=147 totEve=15814 
        25  # F10508w  nBadTw=150 totEve=16049 
        26  # F10525w  nBadTw=147 totEve=50666 
        27  # F10526w  nBadTw=147 totEve=32340 
        28  # F10527w  nBadTw=149 totEve=27351 
        29  # F10528w  nBadTw=147 totEve=22466 
        30  # F10531w  nBadTw=145 totEve=9210 
        31  # F10532w  nBadTw=150 totEve=11961 
        32  # F10535w  nBadTw=176 totEve=8605 
        33  # F10536w  nBadTw=177 totEve=10434 


    07 BTOW status tables ver 1, uploaded to DB, pp 500

     BTOW status tables for 39 RHIC fills have been determined (see previous entry) and uploaded to DB.

    To verify mayor features are masked I process first 5K and last 5K  events for every fill , now all is correct. # plots below show example of pedestal residua for not masked BTOW towers, 5K L2W events from the end of the fill. Attachment a) contains 39 such plots (it is large and may crash your machine).

    Fig 1, Fill 10398, the first on, most of tower were  working



    Fig 2, Fill 10478, in the middle, the worst one

    Fig 3, Fill 10536, the last one, typical for last ~4 days, ~1/3 of acquired LT




    08 End or run status

    Attached are slopes plotted for run 10171078 which was towards the end of Run 9.

    09 MIP peaks calculated using L2W stream

    The MIP peaks plotted in the attachment come from the L2W data. 4564 towers had a good MIP peak, 157 towers did not have enough counts in the spectra to fit, and 79 towers had fitting failures. 52 were recovered by hand for inclusion into calibration.

    Also attached is a list of the 236 towers with bad or missing peaks.

    I compared the 157 empty spectra with towers that did not have good slopes for relative gains calculated by Joe. Of the 157 towers, 52 had good slopes from his calculation. Those are in an attached list.

     Fig 1 MIP peak position:

    10 Electron E/p from pp500 L2W events

    I ran the usual calibration code over the L2W data produced for the W measurement.

    To find an enriched electron sample, I applied the following cuts to the tracks, the tower that the track projects to, the 3x3 tower cluster, and the 11 BSMD strips in both planes under the track:

    central tower adc - pedestal > 2.5*rms

    enter tower = exit tower

    track p < 6 and track p > 1.5

    dR between track and center of tower < 0.025

    track dEdx > 3.4 keV/cm

    bsmde or bsmdp adc total > 50 ADC

    no other tracks in the 3x3 cluster

    highest energy in 3x3 is the central tower


    The energies were calculated using ideal gains and relative gains calculated by Joe Seele from tower slopes.

    The corrections were calculated for every 2 eta rings and each crate. The corrections for each 2 rings were calculated first and then applied. The analysis was rerun, then the E/p was calculated for each crate.

    The calibration constants will be uploaded to a different flavor to be used with the preliminary W analysis.

    Fig. 1 E/p spectrum for all electrons

    Fig. 2 p vs E/p spectrum for all electrons

    Fig. 3 BSMDP vs BSMDE for all electrons


    Fig. 4 corrections by eta ring

    Fig. 5 Crate corrections

    Fig. 6 difference between positrons (blue) and electrons (red):


    Update: I reran the code but allowed the width of the gaussian to only be in the range 0.17 - 0.175. This region agrees with almost all of the previously found widths within the uncertainties. The goal was to fix a couple fits that misbehaved. The updated corrections as a function of eta are shown below.

    Fig. U1


    Update 09/30/2009: Added 2 more plots.

    Fig. V1 East vs. West (no difference observed)

    Fig. V2 slices in momentum (not much difference)

    Attached are the histograms for each ring and crate.

    11 BTOW crate gains based on L2W-ET triggered ADCs

    12 Correcting Relative gains from 500 GeV L2W

    After examining the Z invariant mass peak calculated using the L2W data stream with the offline calibration applied, it seemed like there was a problem. The simplest explanation was that the relative gains were reversed, so that hypothesis was tested by examining the Z peak with the data reversed.

    The slopes were also recalculated comparing the original histogram to histograms corrected with the relative gains and the inverse of the relative gains.

    In the following two figures, black is the original value of the slopes, red has the relative gain applied, and blue has the inverse of the relative gain applied.

    Fig 1 Means of slope by eta ring with RMS

    Fig 2 RMS of slope by eta ring

    The E/p calculation improves after making the change to the inverse of the relative slopes because the effect of outliers is reduced instead of amplified.

    Fig 3 E/p by eta ring with corrected relative gains



    After last week's discussion at the EMC meeting, I recalculated all of the slopes and relative gains.

    Fig 4 Update Slope RMS calculation

    I then used these relative gains to recalculate the absolute calibration. Jan used the calibration to rerun the Z analysis.

    Fig 5 Updated Z analysis

    The updated calibration constants will now supercede the current calibration constatns.

    13 Updating Calibration using the latest L2W production

    I recalculated the Barrel calibration using the latest L2W production, which relies on the latest TPC calibration. It is suggested that this calibration be used to update the current calibration.

    Fit Details:

    Negative Peak location: 0.941

    Negative Sigma: 0.14

    Positive Peak location: 0.933

    Positive Sigma: 0.17


    <p> = 3.24 GeV

    Fig 1. E/p for all electron (black), positive charged (blue), negative charged (red)


    14 200 GeV Calibration

    I selected 634 runs for calibration from the Run 9 production, processing over 300M events. The runs are listed in this list, with their field designation.

    The MIP peak for each tower was calculated. 4663 towers had MIP peaks found. 38 were marked as bad. 99 were marked as MIPless. The MIP peak fits are here.

    The electrons were selected using the following cuts:

    • |vertex Z | < 60 cm
    • vertex ranking > 0
    • track projection enters and exits same tower
    • tower status = 1
    • 1.5 < track p < 10.0 GeV/c
    • tower adc - pedestal > 2.5 * pedestal RMS
    • Scaled dR from center < 0.02
    • 3.5 < dE/dx < 5.0
    • No other tracks in 3x3 cluster
    • No energy in cluster > 0.5 central energy
    • Track can only point to HT trigger tower if a non-HT trigger fired in the event

    Fig. 1: Here is a comparison of all electrons from RFF (blue) and FF (red):

    The RFF fit mean comes to 0.965 +/- 0.001. The FF fit mean comes to 0.957 +/- 0.001. The total fit is 0.957 +/- 0.0004.

    Fig. 2 Comparison of electron (red) positron (blue):

    Positron fit results: 0.951 +/- 0.001. Electron fit results: 0.971 +/- 0.001

    Calibration was calculated using MIPs for relative calibration and absolute calibration done for eta slices by crate (30 crates, 20 eta slices per crate).

    The outer ring on each side was calibrated using the entire ring.

    2 towers were marked bad: 2439 2459 due to a peculiar E/p compared to the other in their crate slice. It is suggested this is due to bad bases.

    Fig 3 Crate Slice E/p correction to MIPs (eta on x axis, phi on y axis):

    New GEANT correction

    A new geant correction was calculated using new simulation studies done by Mike Betancourt. The energy and pseudorapidity dependence of the correction was studied, and the energy dependence is small over the range of the calibration electron energies.

    A PDF of the new corrections are here.

    Is it statistical?

    From this plot, it can be seen that most of the rings have a nonstatistical distribution of E/p values in the slices. The actual E/p values for each ring (for arbitrary slice value) can be seen here.

    Comparison to previous years

    Fig 4 Eta/phi of (data calibration)/(ideal calibration)

    Fig 5 Eta ring average of (data calibration)/(ideal calibration)


    • FF vs RFF (partially examined)
    • positive vs negative (partially examinced)
    • eta/phi dependence of geant correction, direction in eta/phi
    • dR dependence of calibration
    • comparison to previous year




    These pages describe how to use the BEMC database.  There is a browser-based tool that you can use to view any and all BEMC tables available at:

    Frequently Asked Questions

    How do I use the database as it looked at a particular time?

    You might be interested in this tip if e.g. you want to repeat an analysis performed before additional tables were added to the BEMC database.  Add the following lines of code to your macro after St_db_Maker is instantiated, and change myDate and myTime as appropriate:

    Int_t myDate = 20051231;
    Int_t myTime = 235959;

    How do I force St_db_Maker to use the event time I specify?

    If you're running over simulation files, where the event timestamp is not a meaningful quantity (at least, it's not meaningful for the BEMC database), you need to choose a particular event timestamp that best represents the state of the BEMC during the data-taking period to which you're comparing the simulations.  A list of timestamps is being compiled at Simulation Timestamps.  Add the following lines of code to your macro, and change myDate and myTime as appropriate:
    Int_t myDate = 20051231;
    Int_t myTime = 235959;

    Calibrations Database

    All calibration information is stored in the STAR database.  We have the following tables for BEMC calibrations:
    • For the BTOW and BPRS detectors:
      • St_emcCalib - this table contains absolute gain information for each channel
      • St_emcPed - this table contains pedestal values for each channel
      • St_emcGain - this table contains a gain correction factor vs. time for each channel (not currently used)
      • St_emcStatus - this table contains the final status for each channel
    • For the BSMDe and BSMDp detectors:
      • St_smdCalib - this table contains absolute gain information for each channel
      • St_smdPed - this table contains pedestal values for each channel
      • St_smdGain - this table contains a gain correction factor vs. time for each channel (not currently used)
      • St_smdStatus - this table contains the final status for each channel
    The tables are stored in the STAR database under the directory /Calibrations/emc/y3[DETNAME] and are called bemcCalib, bemcPed, bemcGain, and bemcStatus in the case of the BTOW detector.

    To get a pointer for those tables in an analysis maker do:
    TDataSet *DB = GetInputDB("Calibrations/emc/y3bemc"); // for towers

    St_emcCalib *table = (St_emcCalib*) DB->Find("bemcCalib");
    emcCalib_st *struct = table->GetTable();

    Important Information About Pedestal Tables

    In order to save space and make the download faster, PEDESTALS and RMS are saved as SHORT.  So, the real pedestal value is PED/100.  Similarly, in order to save tables in the database you have to multiply the real pedestal by 100.  The same goes for the RMS.

    SMD has different pedestals for different capacitors.  Only 3 pedestal values are saved:
    • Pedestal 0 is the average of 126 capacitors
    • Pedestal 1 is the pedestal value for capacitor 124
    • Pedestal 2 is the pedestal value for capacitor 125
    Capacitor numbers for the BSMD can be retrieved from an StEmcRawHit by using the calibrationType() method:
    unsigned char cap = (char) rawHit->calibrationType();
    if(cap > 127) mCap[i][did-1]-=128;

    Status Information

    The St_emcStatus and St_smdStatus tables contain final status codes for each tower.  The final status is a combination of installation/run status, pedestal status and calibration status.  The final status has a bit pattern as follows:
    • 0 - not installed
    • 1 - installed / running
    • 2 - calibration problem
    • 4 - pedestal problem
    • 8 - other problem (channel removed, dead channel, etc.)
    So, status==1 means the channel is installed and running OK.  Status==7 means that the channel is installed but that we have a calibration problem and a pedestal problem.

    To check individual bits of the final status do
    • (status&1) == 1 means tower is installed
    • (status&2) == 2 means a calibration problem
    • (status&4) == 4 means a pedestal problem
    • (status&8) == 8 means another problem

    Tables Structure

    /* emcCalib.idl
    * Table: emcCalib
    * description: //: Table which contains all calibration information
    struct emcCalib {
    octet Status[4800]; /* status of the tower/wire (0=problem, 1=ok) */
    float AdcToE[4800][5]; /* ADC to Energy */
    /* emcPed.idl
    * Table: emcPed
    * description: * //: Table which contains pedestal information for emctower ADCs
    struct emcPed {
    octet Status[4800]; /* status of the emc tower(0=problem, 1=ok) */
    short AdcPedestal[4800]; /* ADC pedestal of emc tower x 100 */
    short AdcPedestalRMS[4800]; /* ADC pedestal RMS of emc tower x 100 */
    float ChiSquare[4800]; /* chi square of Pedestal fit */
    /* emcGain.idl
    * Table: emcGain
    * description: //: Table which contains gain correction information
    struct emcGain {
    octet Status[4800]; /* status of the tower/wire (0=problem, 1=ok) */
    float Gain[4800]; /* Gain Variation */
    /* emcStatus.idl
    * Table: emcStatus
    * description: // which emc towers are up and running
    struct emcStatus {
    octet Status[4800]; /* */
    /* smdCalib.idl
    * Table: smdCalib
    * description: //: Table which contains all calibration information
    struct smdCalib {
    octet Status[18000]; /* status of the tower/wire (0=problem, 1=ok) */
    float AdcToE[18000][5]; /* ADC to Energy */
    /* smdPed.idl
    * Table: smdPed
    * description: * //: Table which contains pedestal information for shower max ADCs
    struct smdPed {
    octet Status[18000]; /* status of the smd stripe (0=problem,1=ok) */
    short AdcPedestal[18000][3]; /* ADC pedestals of smd strip x 100 */
    short AdcPedestalRMS[18000][3]; /* ADC pedestals RMS of smd strip x 100 */
    /* smdGain.idl
    * Table: smdGain
    * description: //: Table which contains gain information
    struct smdGain {
    octet Status[18000]; /* status of the tower/wire (0=problem, 1=ok) */
    float Gain[18000]; /* Gain Variation */
    /* smdStatus.idl
    * Table: smdStatus
    * description: // which smds are up and running
    struct smdStatus {
    octet Status[18000]; /* */

    Control Room

    We use a crontab on to update the trigger database tables as well as the "offline" pedestals throughout the run.  Here's the relevant portion of /etc/crontab:

    00 4 * * * emc /home/emc/online/emc/pedestal/job

    00 * * * * emc /home/emc/online/emc/trigger/job
    10 * * * * emc /home/emc/online/emc/trigger/job
    20 * * * * emc /home/emc/online/emc/trigger/job
    30 * * * * emc /home/emc/online/emc/trigger/job
    40 * * * * emc /home/emc/online/emc/trigger/job
    50 * * * * emc /home/emc/online/emc/trigger/job

    Pedestal Job

    The job runs every day at 4:00 AM and executes the script


    which in turn calls the root4star macro


    This macro calculates pedestals for all 4 subdetectors and uploads the tables to the STAR database.  A local backup copy of each table is stored in


    Trigger Job

    The job runs $EMCONLINE/trigger/updateTriggerDB every ten minutes.  If the file $EMCONLINE/trigger/RUNMODE contains STOP, the job will do nothing.  $EMCONLINE/trigger/startTriggerDB and $EMCONLINE/trigger/stopTriggerDB can be used to change the content of RUNMODE.  The updateTriggerDB shell script contains some decent documentation which I've reproduced here:

    # this script checks if ANY of the BEMC trigger
    # configuration had changed. If so, it updated the
    # database with the new trigger configuration
    # it runs as a cronjob every 5-10 minutes in the star01
    # machine
    # this script follows the steps bellow
    # 1. check the file RUNMODE. If content is STOP, exit the
    # program. This is done if, for some reason, we
    # want to stop the script from updating the DB
    # 2. SCP the config_crate* and pedestal_crate* files
    # from machine
    # 3. SCP the trigegr masks from machine
    # 4. Copy these files to the sc3 and startrg2 directories
    # 5. Compare these files to the files saved in the sc3.saved
    # and startrg2.saved directories
    # 6. If there is no difference, clear the sc3 and startrg2
    # directories and exit
    # 7. If ANY difference was found, copy the contents of the
    # sc3 and startrg2 directories to sc3.saved and startrg2.saved
    # Also saves the directory with timestamped names in the
    # backup directory
    # 8. runs the root4star macro that create the tables from
    # the files in those directories and save them to the DB
    # It also creates plain text file bemcStatus.txt with the same information
    # for the trigger people and Pplots
    # 9. clear the sc3 and startrg2 directories and exit
    # you can also run it by hand with the command
    # updateTriggerDB TIMESTAMP FORCE
    # where TIMESTAMP is on the format
    # YYYYMMDD.hhmmss
    # if FORCE = yes we force saving the DB
    # this procedure overwrites the RUNMODE variable
    # AAPSUAIDE, 12/2004

    Basically the job is always checking for changes to the trigger pedestals, status tables, and LUTs and uploaded a new table if any changes are found.

    Mapping DB Proposal


    We propose to add a new set of tables to the Calibrations_emc database that will track the electronics mapping for the BEMC, BSMD, and BPRS and allow for an alternative implementation of StEmcDecoder.


    The existing BEMC electronics mapping code (StDaqLib/EMC/StEmcDecoder) has become difficult to maintain. Each time we discover something about the BEMC that requires an update to our lookup tables we have to decipher the algorithms that generate these lookup tables, and more often than not our first guess about how to add the new information is wrong.

    StEmcDecoder is also inefficient because it doesn’t track the validity range of the current lookup tables and so it rebuilds the tables every event. Analysis jobs spend a non-neglible amount of CPU time rebuilding these decoder tables.

    The information in the decoder is critical for BEMC experts, but the interface to that information is less than ideal. StEmcDecoder does not even have CINT bindings. An SQL interface would allow for much easier debugging.

    For the End User

    We are preserving the StEmcDecoder interface and reimplementing it to use the DB tables. Offline users should see a seamless transition. StEmcDecoder also plays an important role in the online p-plots. We’ll need to find a solution that allows access to the DB tables in that framework.

    For Experts

    The new mapping tables will contain a row for each detector element, so we expect that querying the tables using SQL will prove to be a valuable debugging tool. A simplified query might look like:

    SELECT elementID,m,e,s FROM bemcMapping WHERE triggerPatch=5 and beginTime='2007-11-01 00:00:00';

    which would yield

    | elementID | m | e | s |
    | 1709 | 43 | 9 | 2 |
    | 1710 | 43 | 10 | 2 |
    | 1711 | 43 | 11 | 2 |
    | 1712 | 43 | 12 | 2 |
    | 1729 | 44 | 9 | 1 |
    | 1730 | 44 | 10 | 1 |
    | 1731 | 44 | 11 | 1 |
    | 1732 | 44 | 12 | 1 |
    | 1749 | 44 | 9 | 2 |
    | 1750 | 44 | 10 | 2 |
    | 1751 | 44 | 11 | 2 |
    | 1752 | 44 | 12 | 2 |
    | 1769 | 45 | 9 | 1 |
    | 1770 | 45 | 10 | 1 |
    | 1771 | 45 | 11 | 1 |
    | 1772 | 45 | 12 | 1 |
    16 rows in set (0.12 sec)

    Previously, we needed to write one-off compiled programs to export this kind of information out of the decoder.

    Draft IDLs

    struct emcMapping {
    octet m; /* module 1-120 */
    octet e; /* eta index 1-20 */
    octet s; /* sub index 1-2 */
    unsigned short daqID; /* ordering of elements in DAQ file 0-4799 */
    octet crate; /* electronics crates 1-30 */
    octet crateChannel; /* index within a crate 0-159 */
    octet TDC; /* index in crate 80, 0-29 */
    unsigned short triggerPatch; /* tower belongs to this TP 0-299 */
    octet jetPatch; /* tower belongs to this JP 0-11 */
    unsigned short DSM; /* just integer div TP/10 0-29 */
    float eta; /* physical pseudorapidity of tower center */
    float phi; /* physical azimuth of tower center */
    char comment[255];
    struct smdMapping {
    octet m; /* module 1-120 */
    octet e; /* eta index 1-150 (eta), 1-10 (phi) */
    octet s; /* sub index 1 (eta), 1-15 (phi) */
    octet rdo; /* readout crate 0-7 */
    unsigned short rdoChannel; /* index in crate 0-4799 */
    octet wire; /* wire number 2-80 */
    octet feeA; /* A value for FEE 1-4 */
    float eta; /* physical pseudorapidity of strip center */
    float phi; /* physical azimuth of strip center */
    char comment[255];
    struct prsMapping {
    octet m; /* module 1-120 */
    octet e; /* eta index 1-20 */
    octet s; /* sub index 1-2 */
    octet PMTbox; /* PMT box 1-30 (West), 31-60 (East) */
    octet MAPMT; /* MAPMT # for this element in PMTbox 1-5 */
    octet pixel; /* index inside MAPMT 1-16 */
    octet rdo; /* readout crate 0-3 */
    unsigned short rdoChannel; /* index in readout crate 0-4799 */
    octet wire; /* wire number 1-40 */
    octet feeA; /* A value for FEE 1-2 */
    octet SCA; /* switched capacitor array 1-2 */
    octet SCAChannel; /* index inside SCA 0-15 */
    octet powerSupply; /* 1-2 */
    octet powerSupplyModule; /* 1-15 */
    octet powerSupplyChannel; /* 0-14 */
    float eta; /* physical pseudorapidity of tower center */
    float phi; /* physical azimuth of tower center */
    char comment[255];

    I also proposed MySQL schemata on my blog, but I guess in STAR these IDLs define the schema.

    Performance Estimates

    I’ve temporarily installed tables on our MIT mirror and filled them with data describing the 2008 BEMC electronics mapping. Here are the stats:

    *************************** 1. row ***************************
    Name: bemcMapping
    Engine: MyISAM
    Version: 10
    Row_format: Dynamic
    Rows: 4800
    Avg_row_length: 55
    Data_length: 268732
    Max_data_length: 281474976710655
    Index_length: 163840
    Data_free: 0
    Auto_increment: 4801
    Create_time: 2008-11-14 16:03:51
    Update_time: 2008-11-14 16:05:45
    Check_time: NULL
    Collation: latin1_swedish_ci
    Checksum: NULL
    *************************** 2. row ***************************
    Name: bprsMapping
    Engine: MyISAM
    Version: 10
    Row_format: Dynamic
    Rows: 4800
    Avg_row_length: 70
    Data_length: 336036
    Max_data_length: 281474976710655
    Index_length: 165888
    Data_free: 0
    Auto_increment: 4801
    Create_time: 2008-11-14 17:52:53
    Update_time: 2008-11-14 17:59:40
    Check_time: 2008-11-14 17:52:53
    Collation: latin1_swedish_ci
    Checksum: NULL
    *************************** 3. row ***************************
    Name: bsmdeMapping
    Engine: MyISAM
    Version: 10
    Row_format: Dynamic
    Rows: 18000
    Avg_row_length: 52
    Data_length: 936000
    Max_data_length: 281474976710655
    Index_length: 604160
    Data_free: 0
    Auto_increment: 18001
    Create_time: 2008-11-14 16:03:51
    Update_time: 2008-11-18 01:48:36
    Check_time: NULL
    Collation: latin1_swedish_ci
    Checksum: NULL
    *************************** 4. row ***************************
    Name: bsmdpMapping
    Engine: MyISAM
    Version: 10
    Row_format: Dynamic
    Rows: 18000
    Avg_row_length: 52
    Data_length: 936000
    Max_data_length: 281474976710655
    Index_length: 604160
    Data_free: 0
    Auto_increment: 18001
    Create_time: 2008-11-14 16:03:51
    Update_time: 2008-11-18 02:13:36
    Check_time: NULL
    Collation: latin1_swedish_ci
    Checksum: NULL
    4 rows in set (0.11 sec)

    This information is supposed to be static, even from year-to-year. In reality, we discover some details about the mapping each year which will require updates to some of these rows. There should certainly be no intra-run changes, so StEmcDecoder will need to retrieve 4800+4800+18000+18000 rows from the DB for each BFC and user job.

    The equivalent C++ array sizes (excluding the comment field as I’m not sure how its handled) will be 101 KB (4800*21) for BEMC, 115 KB (4800*24) for BPRS and 288 KB (18000*16) for each SMD plane.

    Pedestals / Status Tables

    Code for the calculation of the BTOW & BSMD status tables has been made publicly accessible. BTOW status code is in StRoot/StEmcPool/CSMStatusUtils. The following studies of pedestals and status tables have been performed:


    Dave S. - status

    Thorsten - 62 GeV AuAu status tables
    Oleksandr - 200 GeV AuAu pedestals
    Oleksandr - 62 GeV AuAu pedestals

    Oleksandr - dAu status tables
    Oleksandr - pp status tables


    Priscilla - SMD pedestals

    Frank - SMD status for pp (bug found in code
    Frank's code used to generate status tables from MuDsts

    200 GeV AuAu SMD status - taken by Martijn
    Marcia - 200 GeV AuAu SMD pedestals
    Subhasis - 62 GeV AuAu SMD & PSD pedestals

    Martijn - dAu SMD status


    This is CSMStatusUtils, which outputs the status of either calorimeter to text and root status files.  Documentation is by Dave Relyea.  The code can be found at


    I was given code from both Joanna and Thorsten to figure out the status of the calorimeter towers over all pp production runs.  I merged the two sets of code, and and created a package called CSMStatusUtils.

    The first piece of code in CSMSU takes every run and fills a 2-d histogram of ALL channels vs hit number (in ADC counts, from 0 to 150).  A second routine then combines these histograms from run subsets into single histograms for each run.  From the second routine and on down, the EEMC and BEMC are done entirely separately; the code needs to be run twice, once for each detector.

    The code has an algorithm which then takes runs in each fill and combines them until the average number of hits above pedestal for all channels is greater than 100.  If runs are left over at the end of a fill, their statistics are added to prior runs in the fill.

    For each combined set of runs, the code puts each channel through a series of tests.  It finds the pedestal (and writes it out to a file, btw) and determines if the pedestal is abnormally wide, or whether it falls outside acceptable limits (ADC channels 0 to 3, or 147 to 150).  It compares all towers' mean number of hits (ten sigma) above pedestal, and then flags towers which have 10x as many hits as the average, or 40x fewer.  Finally, it looks for stuck bits (either on or off) in the 1, 2, 4, or 8 position, and flags channels with stuck bits.

    The code writes out a table (in text format) for each set of runs with the status of each channel clearly marked.  This table is also written in ROOT format, to be read by existing BEMC algorithms.  Also written is a hot tower plot, so the hot tower results can be eyeballed.  The code can also write out gif files of the spectra of every channel that failed a status test, so long as the number of channels in a given run set that failed the test is less than 25 (**for 2004 pp, gif files were not written out**).  Finally, the code creates a nice html file containing links to html subfiles detailing the channel status for each run set, which in turn link to the gif files.

    As a final step, the code takes the text files and creates a new series of text status files with the results in differential format, meaning channels whose status didn't change from run set to run set are omitted.  However, since some channels fall very near the thresholds of certain status tests (for instance, channels whose pedestals sit at 2.9 ADC counts), I make the requirement that the channel's status must not have changed more than ten percent of the time over all runs sets, excluding runs in which all channels were bad (for nominal production running, this needs to be done, of course!).  If it has, it is marked bad once at the beginning, and then does not appear in any of the differential files.

    To run CSMSU, the first step is to use the FileCatalog to create a list of all the files you wish to analyze.  The command I use is typically something like: -keys 'path,filename' -cond 'production=P04ik,tpc=1,emc=1, trgsetupname=productionPP||productionPPnoEndcap||pp||PP,filename~st_physics,filetype=daq_reco_mudst' -onefile -limit 100000 -distinct > allthephysicsfiles

    Note that the output format I use is just 'path,filename', and I keep the :: delimiter that the FileCatalog uses.  My next step is to call

    CSMSU/scripts/analysis0 allthephysicsfiles


    which takes the "allthephysicsfiles" file from FileCatalog, splits it up into groups of 20 miniruns, and submits the entire processing job to batch.  Note - if I knew how to use the XML submission scripts, I would, but the online documentation for them doesn't mention how to code up your macro (.C) file such that the XML header file will work.  No matter.

    PLEASE NOTE: Each minirun will generate about a 200k file.  This adds up to ENORMOUS disk space for large runs.  The 2004 pp run takes up about 1.4 Gig.  The 2004 Au-Au run would be even larger.  Thus, I really need to learn how to
    use the XML submission scripts.


    After all miniruns have been processed, the next step is to combine them into runs.  The script "analysis1" does this.  

    Next, you want to run the actual status code on the files.  The script "analysis2" does this.  PLEASE NOTE:  this macro requires an x window, as root needs to be able to Draw certain things.  I don't know how to do this in batch,
    so I always run this interactively.  It's not a good solution, but for now, it's a solution.

    Finally, you want to generate the ".root" status files and the concatenated status files (to alert you to changes in calorimeter tower status).  The script "analysis3" does this.


    This page gives a brief overview of the code Frank Simon developed to create SMD Status Tables from MuDSTs.

    Some features and limitiations of the code:

    • Create one status table per fill for each SMD plane (if enough statistics are available)
    • all triggers are used to maximize statistics (this can be a potential problem if there are hot trigger towers)
    • pedestals are taken from the data base (MuDST SMD data are zero-suppressed)
    • db-readable status tables can be created. Currently there are only to status flags implemented: good and bad. Adding more "variety" is straigth forward
    • can be used with the STAR scheduler, no specific ordering of the input files required (although some structure in the job submission is recommended, see below)

    Basic ideas behind the code:

    • based on Daves tower status code, but: there are some very important differences
    • One job runs over several MuDST files, when a new fill number is encountered, a new output file is opened. That way, the jobs can be run with the STAR scheduler and they can use files on distributed storage, since no particular ordering of the input files is needed
    • for each fill, a file with 18000 channel TH2Fs storing amplitude information for each SMD channel is created (this method of dealing with random file order is a bit disk space hungry, so make sure enough space is available (~ 10 GB for 2005 pp); this can be deleted after the next step), other information such as time stamps and pedestals are stored in text files
    • As a next step, the large number of files created by jobs on MuDSTs is consolidated into one file per fill
    • Status tables are created from each of those files (one per fill, if statistics are sufficient, otherwise no status table for that fill is created)
    • db readable files are produced from these status tables

    Running the code

    • Copy and compile the code in StRoot/StBSMDStatusMaker
    • Copy the macro that runs the code: RunStatus.C
    • Create scheduler scripts to submit your jobs. For pp2005, 50 jobs per job seems to give jobs with useful runtimes. In order to not get a totally randomized fill distribution in your jobs, submit them by day. A macro that creates a .csh that you can use to submit jobs by day is CreateSubmitScript.C, a template job describtion (you have to modify tha paths to suit your needs) is pp2005Template.xml
    • Submit your jobs
    • Once all jobs are done, create a list of all output files via ls * > FileList.list in the directory where your output ended up
    • Consolidate data using the file list: run macro DoAdding.C after compiling AddHistograms.C (via .L AddHistograms.C++), this macro takes the directory where the files are located and the file list as arguments. This creates three files per fill: Fill*.root containing the histograms, Fill*.ped containing pedestal db information and Fill*.time containing the (approximate) start time of the fill
    • Create a list of root files via ls Fill*.root > FileList.list and convert it into a list of fill numbers using the macro GetListOfFills.C. This maco takes the file list and a file name for the fill number list as argument
    • Perform the status table creation. For that, compile the shared library StatusTools.C (via .L StatusTools.C++), then run the macro ProcessList.C, with arguments RunList (created previously) and the directory where the Fill* files are located. The output of this is a number of files per fill (root file, flag file and time stamp file). The flag and the time stamp file are needed to create the db readable status table, the root file contains histograms created during the analysis process.
    • Create db readable status tables. This is done by running the macro WriteStatusFiles.C. This takes the directory where the flag and timestamp files are located as an argument. Two important notes:
      • This macro needs the full STAR environment (all other steps above except the running of jobs can be done on standalone machines)
      • The order in which the flag and time files are written (created) is crucial, since gSystem->GetDirEntry() is used to loop over all files. So care has to be taken if the files are copied from somewhere else
    • Copy the db readable files to the database location in StarDb, and test them! Use TestStatusFiles.C for example.

    For questions, please don't hesitate to contact me at!

    Simulation Timestamps

    All 4800 perfect:

    Run 5 pp, selected by Spin PWG:

    some more info from Frank on detailed SMD status:
    if (dbTime == 1) db1->SetDateTime(20050423,042518); //2005 stat1
    else if (dbTime == 2) db1->SetDateTime(20050521,100745); //2005 stat2
    else if (dbTime == 3) db1->SetDateTime(20050529,210408); //2005stat3
    else db1->SetDateTime(20050610,120313); //2005, Jumbo
    Run 6 pp:

    Table Insertion Timeline

    This page keeps a log book of all the BEMC database modifications. Please use this information in order to make sure about the version of the tables you are grabbing from DATABASE. The table is sorted by EntryTime.

    If you'd like to run an analysis using the database as it looked at some particular time, use the method
    St_db_Maker *dbMaker = new St_db_Maker("StarDb", "MySQL:StarDb");
    Int_t myDate = 20051231;
    Int_t myTime = 235959;

    You can use the BEMC DB Browser to look at all the tables in the database

    EntryTime Tables Note
    1 2005-11-03 pp2005 bemcCalib table
    with timestamp = 2005-03-22 00:00:01
    was uploaded to the database
    Adam's calibration table
    for pp2005. Click here for details
    2 2005-12-07 pp2005 offline bemcStatus
    with timestamp between
    2005-04-19 11:36:11 and 2005-06-24 08:58:25
    were uploaded to the database
    Dave's status tables
    for the pp2005 run
    3 2006-02-08 pp2005 online bemcPed
    with timestamp between
    2005-04-19 05:37:10 and 2005-06-10 23:38:20
    were deactivated
    Corruption problems
    reported by Dave
    4 2006-02-09 pp2005 offline (Dave's) bemcPed
    with timestamp between
    2005-04-19 05:37:10 and 2005-06-10 23:38:20
    were uploaded to the database
    Replacement for
    pp2005 bemcPed tables
    5 2006-02-09 pp2004 online bemcPed
    with timestamp between
    2004-05-05 01:41:40 and 2004-05-14 23:21:19
    were deactivated
    Bad tables reported by Joanna
    with large RMS values and
    missing channels. Click here for details
    6 2006-02-09 pp2004 offline (Dave's) bemcPed
    with timestamp between
    2004-05-05 01:41:40 and 2004-05-14 23:21:19
    were uploaded to the database
    Replacement for
    pp2004 bemcPed tables
    7 2006-02-22 AuAu and pp 2004 bemcCalib table
    with timestamp 2004-01-01 00:04:00
    was uploaded to database
    Improvements in calibration by
    Adam Kocoloski.
    Click here for details
    8 2006-02-22 CuCu 2005 bemcCalib table
    with timestamp 2005-02-01 00:00:01
    was uploaded to database
    Improvements in calibration by
    Adam Kocoloski.
    Click here for details
    9 2006-02-22 pp 2005 bemcCalib table
    with timestamp 2005-03-22 00:00:02
    was uploaded to database
    Improvements in calibration by
    Adam Kocoloski.
    Click here for details
    This is a copy of the table saved in row number 8.
    This is necessary because there were calibration
    tables saved for pp2005 run
    10 2006-03-07 Saved perfect status tables
    (bemc, bsmde, bsmdp and bprs)
    for run 6 with timestamp
    2006-01-01 00:00:00
    First order status tables necessary for
    fast production and pp2006 vertex finder
    11 2006-03-30 Saved initial BTOW calibration for pp2006
    with timestamp
    2006-03-11 08:27:00
    First calibration for pp2006 (online).
    Based on eta-slices MIP peaks and
    slopes equalization.
    Click here for details
    12 2006-04-19 A set of perfect status tables
    (bemc, bsmde, bsmdp and bprs)
    was saved in DB for the CuCu2005
    with timestamp
    2005-01-01 00:00:00
    This makes sure that the 2004 status tables are not picked for any analysis/production
    done with the 2005 CuCu data while
    there is no detailed status tables
    13 2006-04-20 A perfect status table for BTOW, including only the
    west side of the EMC
    was saved in DB for the
    with timestamp
    2005-01-01 00:00:01
    Added to replace previous perfect status
    table that includes the full detector because
    the east side was being commissioned
    14 2006-06-16 Offline BSMD status tables for 2005 pp running. Event timestamps are between 2005-04-16 06:48:09 and 2005-06-23 19:38:42
    Tables produced by Frank Simon.
    Click here for details
    15 2006-06-21 Offline BTOW status tables for 2005 pp running. Event timestamps are between 2005-04-19 11:36:11 and 2005-05-14 09:17:59
    These tables should have been / were uploaded back in row 2. It's not clear what happened to them.
    16 2006-06-21 Online BTOW pedestals for 2006 pp running. Event timestamps are between 2005-03-02 08:40:15 and 2005-06-19 04:41:18
    BTOW pedestals were calculated and saved to the DB automatically during the run. Unfortunately the tables were corrupted during the upload, so we need to upload these tables again with +1 second timestamps.
    17  2006-08-15
    BSMD pedestals for Run 6.
    18 2006-08-16
    BTOW status for Run 6.
    ~1 table/fill.  Should be good enough for vertex finding during production, but not necessarily the final set of tables.  Details
    19 2006-10-17
    Perfect BPRS status table for 2006 run
    Begin time 2006-01-01
    20 2006-11-10  BTOW status for Run 5 CuCu
    Link needs to be updated with a summary page.  Details
    21 2006-11-21
    Fixed timestamps for Run 5 pp status
    See starsoft post
    22 2006-11-30
    Fixed timestamps for Run 5 pp peds
    See starsoft post
    Offline BTOW calibration for Run 6
    Run 6 BTOW Calibration
    Final BTOW status tables for trans,long2
    Corrected 3 Run6 tower peds in few runs
    Hypernews discussion
    Final BSMD Run6 status tables

    Trigger Database

    This database stores all BEMC trigger information such as trigger status, masks and pedestals used to obtain the high tower and patch sum information.  The database is updated online while taking data.  We have the following table formats:

    • St_emcTriggerStatus - this table contains status/mask information for the trigger
    • St_emcTriggerPed - this table contains the pedestal and bit conversion scheme used in the trigger
    • St_emcTriggerLUT - this table contains the lookup table information.  Because the LUT is very large it is encoded in simple formulae.  The FormulaTag entry specifies the formula used for each patch.
    The tables are stored in the STAR database under the directory /Calibrations/emc/trigger and are called bemcTriggerStatus and bemcTriggerPed.  To access those tables from an analysis maker do:

    TDataSet *DB = GetInputDB("Calibrations/emc/trigger");

    St_emcTriggerStatus *table = (St_emcTriggerStatus*) DB->Find("bemcTriggerStatus");
    emcTriggerStatus_st *struct = table->GetTable();

    Important Information About Pedestal Tables

    In order to save space and make the download fast, PEDESTALS and RMS are saved as SHORT.  So, the real pedestal value is PED/100.  Similarly, in order to save tables in the database you have to multiply the real pedestal by 100. The same goes for the RMS.

    The pedestal table also includes the 6-bit conversion scheme used to generate the high tower and patch sum information.

    Status Information

    The St_emcTriggerStatus table contains the status information for each single tower, high tower and patch sum (patch sum is the sum in the 4x4 patches.  It is *not* the jet patch).  The status is a simple 0/1 that reflects the masks that are being applied to the electronicss where

    • 0 - masked out
    • 1 - included in trigger

    Tables Structure

    * Table: emcCalib
    * description: //: Table which contains the trigger masks
    struct emcTriggerStatus
    octet PatchStatus[300]; // Patch sum masks. the index is the patch number
    octet HighTowerStatus[300]; // High tower masks. the index is the patch number
    octet TowerStatus[30][160]; // Single masks. the indexex are the crate number and position in crate
    * Table: emcTriggerPed
    * description: * //: Table which contains pedestal information and 6 bits conversion used in trigger
    struct emcTriggerPed
    unsigned long PedShift; // pedestal shift
    unsigned long BitConversionMode[30][10]; // 6 bits conversion mode. the indexex are the crate number and position in crate
    unsigned long Ped[30][160]; // pedestal value. the indexex are the crate number and position in crate
    * Table: emcTriggerLUT
    * description: * //: Table which contains each patch LUT information
    struct emcTriggerLUT
    unsigned long FormulaTag[30][10]; // formula tag for each [crate][patch]
    unsigned long FormulaParameter0[30][10]; // Parameter 0 for the LUT formula in [crate][patch]
    unsigned long FormulaParameter1[30][10]; // Parameter 1 for the LUT formula in [crate][patch]
    unsigned long FormulaParameter2[30][10]; // Parameter 2 for the LUT formula in [crate][patch]
    unsigned long FormulaParameter3[30][10]; // Parameter 3 for the LUT formula in [crate][patch]
    unsigned long FormulaParameter4[30][10]; // Parameter 4 for the LUT formula in [crate][patch]
    unsigned long FormulaParameter5[30][10]; // Parameter 5 for the LUT formula in [crate][patch]

    BEMC Online Trigger Monitoring

    During data taking the BEMC trigger information is monitored, and changes in the configuration (new pedestals, masks, etc.) are recorded.  The code relevant to this online trigger monitoring was developed by Oleksandr, and is checked into CVS here (usage instructions in the README file).  The scripts execute via a cronjob on the online machines on the starp network.  In particular, there exists directories with results from previous years at /ldaphome/onlmon/bemctrgdb20XX/ on

    The final location for this information is in the offline DB, and the definitions for the tables are given here.  These DB tables are used by the StBemcTriggerSimu in the StTriggerUtilities package to replicate the BEMC trigger conditions for a particular timestamp. 

    The DB tables can be uploaded while taking data or stored in ROOT files to be uploaded after data taking is complete.  To upload all the tables stored in ROOT files during data taking only a simple script is needed employing StBemcTablesWriter to read in a list of files and upload their information to the DB.  This script (uploadToDB.C) is checked into the macros directory of in CVS here.  

    Yearly Timestamp Initialization

    Yearly Timestamp Initialization

    This page will document the yearly timestamp initialization requested by the S&C group (Run 12 for example).  The purpose is to set initial DB tables for "sim" and "ofl" flavor in sync with the geometry timeline for each year.  The geometry timeline is documented here.


    The timestamps chosen for BEMC initialization are in the table below

      Simulation Real Data
    Run 10 2009-12-12 2009-12-25
    Run 11 2010-12-10 2010-12-20
    Run 12 2011-12-10 2011-12-20


    The "sim" tables used for initialization are ideal gains, pedestals and status tables.

    The "ofl" tables used for initialization are the best known gains from previous years, and a reasonable se of pedestals and status tables from a previous year.  Obviously they will be updated once the run begins and better known values are available.


    To simplify the initialization process from year to year, a macro (attached below) was written which copies DB tables from previous years to the current initialization timestamp. 



    BEMC_FEE_Repairs (BSMD)

    Here (below) are the BSMD FEE repair record spreadsheets from Phil Kuczewski.

    The one with label "BEMC_FEE_Repairs-2010.xls" is most recent, including repairs in 2010

    (although on 9/8/10 Oleg says that 1 more SAS was already replaced and there likely will be 2 more)


    Information about how the BEMC detectors are indexed (Pre run14)

    Oleksandr's Spreadsheet of Towers' Layout (Excel)
    Oleksandr's Spreadsheet of Towers' Layout (PDF)

    For run 14 there were signal cable swaps for PMT boxes 13->14, 15->16, and 45->46. The updated tower maps are here:

    Run14 Tower Layout (Excel)
    Run14 Tower Layout (PDF)

    In these new spreasheets, the yellow, light blue, and light gray boxes are where the swaps are. On the outsides, the PMT boxes are labeled (PMB) and you can clearly see the swaps. As an example, here's how it would work:

    Soft Id's 3521, 3522, 3523, 3524, ...., 3461, 3462, 3463, 3464 were swapped with
                 3441, 3442, 3443, 3444, ...., 3381, 3382, 3383, 3384

    BSMDE 2010 mapping problem and solution

    All the details of the mapping problem can be found in this ticket.  This page is a summary of the problem, solution, and the implementation.

    During Run 10 a problem with the BSMD mapping was discovered (details here).  It was decided to continue taking data with the 2 fibers swapped for future running, and simply correct the mapping in the DB to reflect the hardware configuration before production.  The mapping for the BSMD phi plane (BSMDP) was corrected (completely swapped 2 fibers in the DB) before produvtion to match the Run 10 hardware configuration, so there were no problems with BSMDP mapping in production. 


    The correction to the BSMD eta plane (BSMDE) mapping, however, was incomplete and did not swap the 2 fibers in the DB completely.  Ahmed found this mapping problem in "Phase I" of the 200GeV QM production (production series P10ij).  All Run 10 data produced in the P10ih and P10ij production series have this BSMDE mapping issue. 


    a)  For "Phase II"  of the Run 10 data production in the P10ik production series an updated DBV was used to include the correct mapping  for both the BSMDE and BSMDP planes.  This data should be analyzed as usual, with no need for a patch.

    b)  In an effort to recover the data produced with the BSMDE mapping problem (P10ih and P10ij) a patch was included in the SL10k and future libraries to correctly swap the BSMDE channels as an afterburner using StEmcDecoder. 


    The implementation of part b) of the solution above is similar to the patch for previous tower mapping problems.  The software patch includes 3 libraries StEmcDecoder, StEmcADCtoEMaker, StEmcRawMaker.

    1. StEmcDecoder will use the non-corrected map by default, although it is possible to know the correction that should be applied for each channel using the method

      StEmcDecoder::GetSmdBugCorrectionShift(int id_old, int& shift)

      where id_old is the non-correct software id and shift is the shift that should be applied to the id. In this case:

       id_corrected = id_old + shift
    2. StBemcRaw (in StEmcRawMaker) was updated with a method


      That enables (true) or disables (false) the on-the-fly correction. The default options are:

      for StEmcRawMaker -> false (map correction IS NOT applied for P10ih or P10ij PRODUCTION)
      for StEmcADCtoEMaker ->true (map correction IS applied for USER ANALYSIS of P10ih or P10ij produced MuDsts)

      IMPORTANT: If you run your analysis with StEmcADCtoEMaker The StEmcRawHits in StEmcCollection will be automatically have the map FIXED!!!! This is not the case if you use StEmcRawMaker or StMuEmcCollection for analysis.
    The consequences (only for P10ih and P10ij data):

    1. muDST data is saved with the non-corrected software id

      If you read muDST data directly, without running ADCtoEMaker you need to correct the ids by hand. The following code is an example how to do that correction. You need to use StEmcDecoder to get the correct id

      StEmcDecoder* decoder = new StEmcDecoder(date, time); // date and time correspond to the event timestamp
      StMuEmcCollection* muEmc = muMk->muDst()->muEmcCollection(); // get the MuEmcCollection from muDST
      //...................  BSMDE  ....................
      if(det == BSMDE) {
      	for(Int_t j=0;j<nh;j++)	{
      		StMuEmcHit* hit=muEmc->getSmdHit(j,det);
              	ID = hit->getId();
              	ADC = hit->getAdc();
              	CAP = hit->getCalType();
             		int shift = 0;    
          		newID = ID + shift;      // newID is correct softID for this hit
      		if(newID < 0) continue;  // mask lost channels
      		// user code starts here
      	} }

    2. StEmcCollection (StEvent format) after you run StEmcADCtoEMaker at analysis level is created with correct software id.
    3. Lost Channels  :  There are 498 strips which are masked by the patch (correct softID returned by decoder is -2e4) because the correct hits for that channel are not saved in the muDst at all, due to the mapping in the DB used during production.
    4. Database :  Entries are not yet uploaded for Run 10 BSMD data, but the intention is that they will be uploaded with the correct softId mapping so no patch will be needed to get the DB.



    BTOW map problem and solution

    If you are not familiar with the map problem follow this discussion in the emc-list. Basically, bacause of swapped fiber optics or swapped signal cables some of the towers are not in the software_id position they are supposed to be. This corresponds to more or less 100 swaps (most in the west side) that corresponds to about 200 towers.

    Some of the swapped towers could be fixed because they originated from swapped signal cables. When the swap happened at fiber optics level they were left as they are because the fibers are difficult to access and are frigile. In this case, and for previous runs, a software patch was made in order to recover the swapped towers.

    The list of swapped towers can be found here:

    The software patch is implemented in 3 libraries: StDaqLib (StEmcDecoder), StEmcRawMaker and StEmcADCtoEMaker and the idea is the following
    1. for 2006 (and future) data StEmcDecoder will have the correct map and all database and productions will be done correctly. In this case the patch is invisible for the user.
    2. for 2004/2005 data, because of the large amount of tables in database and because of the many productions that were done, the patch in StEmcDecoder, is turned OFF by default. This was done because changing the database and old productions is too much trouble at this point. In this case, the patch works in the following way:
      1. StEmcDecoder will use the non-corrected map by default, although it is possible to know the correction that should be applied for each tower using the method

        StEmcDecoder::GetTowerBugCorrectionShift(int id_old, int& shift)

        where id_old is the non-correct software id and shift is the shift that should be applied to the id. In this case:

         id_corrected = id_old + shift
      2. StBemcRaw (in StEmcRawMaker) was updated with a method


        That enables (true) or disables (false) the on-the-fly correction. The default options are:

        for StEmcRawMaker -> false (map correction IS NOT applied for PRODUCTION)
        for StEmcADCtoEMaker ->true (map correction IS applied for USER ANALYSIS)

        IMPORTANT: If you run your analysis with StEmcADCtoEMaker The StEmcRawHits in StEmcCollection will be automatically have the map FIXED!!!! This is not the case if you use StEmcRawMaker or StMuEmcCollection for analysis.

    The consequences (only for 2004/2005 data):

    1. muDST data is saved with the non-corrected software id

      If you read muDST data directly, without running ADCtoEMaker you need to correct the ids by hand. The following code is an example how to do that correction. You need to use StEmcDecoder to get the correct id

      StEmcDecoder* decoder = new StEmcDecoder(date, time); // date and time correspond to the event timestamp
      StMuEmcCollection* emc = muMk->muDst()->muEmcCollection(); // get the MuEmcCollection from muDST

      //...................  B T O W   ....................
      for (int idOld = 1; idOld <= 4800 ; idOld++) 
          int rawAdc= emc->getTowerADC(idOld);
          int shift = 0;   
      idNew = idOld + shift;

      // user code starts here

    2. Database is saved with non-corrected software id
    3. StEmcCollection (StEvent format) after you run StEmcADCtoEMaker at analysis level is created with correct software id.
    4. StBemcTables. To enable the tower map bug, use the flag kTRUE in StBemcTables constructor. See examples bellow
      // This method returns values for NON-CORRECTED IDs (old ids, as the tables are saved in DB)
      tables = new StBemcTables();
      float pedestal, rms;
      tables->getPedestal(BTOW, idOld, 0, pedestal, rms);

      // This method returns values for CORRECTED IDs
      tables = new StBemcTables(kTRUE); // Use kTRUE to enable the BTOW map correction in StBemcTables. Default is kFALSE
      float pedestal, rms;
      tables->getPedestal(BTOW, idNew, 0, pedestal, rms);

    Marcia's BPRS mapping page

    This page was written by Marcia Maria de Moura in January 2005 and ported into Drupal in October 2007

    We are interested in determine in which sequence the measurements of the pre-shower "cells" come into the DAQ system.

    The path from the detector to the DAQ system is not so trivial. There are many connections and they are all tagged but, sometimes, in order to allow a better assembly of the system, the final sequence in which the data from the cells is sent to DAQ is not an ordinary one.

    In order to ilustrate better what is the mapping for the pre-shower, we show the correlation of some connections and also the correlation with the towers.

    In figure 1 we show part of the barrel EMC corresponding to three modules. The modules are presented from η=0 to η=1. The coloured boxes are the towers. The four rows correspond to a photomultiplier box (PMB). One PMB corresponds to one entire module plus two halves of neighbor modules on each side of the central one. In the left side of the figure there is the legend for the series of conectors ST1,ST2,ST3 and ST4 for the towers. In the figure it is shown how this connectors are related to the towers.

    Figure 1 - Correlation of PMT connectors and towers' positions. For a larger view, click on figure.

    In figure 2 we show an example of numbering for towers for the PMB 11W (W stands for west). This numbering is the one used for analysis and we call it software id. By analogy, we aplly the same numbering for the pre-shower cells. For the complete numbering of towers and pre-shower cells, see EMC distribution.

    Figure 2 - Example of tower numbering for PMB 11W

    In the case of the pre-shower cells, the light is not send to the same photomultiplier tubes as the ones for towers, but to sets of Multi-Anode Photomultipliers (MPMT). There are five sets of MPMT's in each PMB and the conecctors for that are identified by MP1, MP2, MP3 MP4 and MP5. In figure 3 we show the correlation of MPX connections to the pre-shower cells, also for PMB 11W. The distribution looks similar but actually the rows are different from figure 2. In the right side of the figure is indicated which is the correspondence in rows with the figure 2. From Vladimir Petrov we obtained how the MPX connectors are related to some eletronics ids (FEE number, SCA number and SCA channel) which are correlated to the muxwire number. The muxwire number is the one that determines the sequence of data to DAQ. In figure 3 it is shown the muxwire, just below the software id.

    From all the eletronics parameters above, the algorythm to associate the software id with the data from DAQ was determined, and is in the StEmcDecoder. In previous attempts. some information about the electronics ids was not updated, which caused to a wrong mapping in the first place. One parameter of the algorythm, an offset (PsdOffset_tmp[40])was wrongly determined. The electronics ids information has been updated and the algorythm has been corrected. In table 1 and 2 we show the values of some parameters for PMB 11W. They are analogous to other PMB's and the only thing that changes is the software id, but the distribution in position is the same. Among the many parameters in table 1 and 2, the updated offset values that are used in the StEmcDecoder are displayed.

    Of course there are aditional parameters in the algorythm but there is no meaning in explaining all of it here. For more details, go to StEmcDecoder STAR Computing software guide.

    The following image has the power supply number, module, and channel for PMT box 11 on both east and west.

    Service Tasks



    BSMD Calibration Studies

    Description:  The calibration coefficients for the BSMD were derived from old test beam studies.  They are set so that the energy of an SMD cluster should be equal to the energy of the tower above it.  One way to check this is to select low-energy electrons and plot SMD energy vs. tower energy.  Initial studies could be accomplished on a month timescale.

    Assigned to: 
    Willie Leight (MIT)

      In Progress.

    BPRS Calibration Studies

    Description:  We have no offline calibration coefficients for the preshower.  While the absolute energy scale is not overly important, we need to verify that the channels are well-calibrated relative to each other

    Assigned to:  Rory Clarke (TAMU)

    Status:  In Progress -- see link

    Neutral Pion Tower Calibration Algorithm

    Description:  Current BTOW calibrations rely on the TPC to a combination MIP/electron-based analysis.  A calibration using neutral pions would be complementary and possibly more precise.

    Assigned to:  Alan Hoffman (MIT)

    Status:  In Progress.

    Trigger Simulator

    Description:  The goal here is to extend the existing BEMC trigger simulator to support "exact" trigger simulation using the logic that we actually use online, to include L2 triggers, and to integrate this simulator with ones provided by other subdetectors.

    Assigned to:  Jan Balewski (IUCF -- Endcap and L2), Renee Fatemi (UK -- BEMC), and Adam Kocoloski (MIT -- BEMC)

    Status:  In Progress

    Control Room Software Maintenance

    Description:  We'll hopefully be replacing most of the BEMC Control Room computing hardware before Run 8, and we'll need someone to check that everything still works as before.  Additionally, we need to fix the code that auto-uploads DB tables (should be an easy fix), and we should work on uploading BSMD pedestal tables that include separate values for CAP == 124 and 125.

    Assigned to:  ???

    Online BTOW Status Table Generation Using L2

    Description:  L2 can accumulate sufficient statistics in real time to allow us to record BTOW status tables without waiting for fastOffline or full production.  "Real-time" status tables in the DB will allow for better fastOffline QA and could decrease the amount of time needed to analyze the data.

    Assigned to:  ???



    STAR DB Browser Maintenance

    Description:  Not really BEMC-specific, but Dmitri Arkhipkin is looking for a maintainer for the STAR DB Browser, which is a very useful tool for people working on the BEMC.

    Assigned to:  ???

    Database-Driven BEMC Mapping

    Description:  We use the StEmcDecoder class to generate time-dependent mapping tables on-the-fly.  I'd like to investigate using a DB to store this information.  First step would be to decide on a schema (i.e. is each tower a single row, or do we do the old trick of storing an entire mapping as a blob?).  Next we would populate the DB with tables that cover all the possible StEmcDecoder configurations (~20 or so).  It may be that we never use this DB for more than browsing the mapping; even so, it could still prove to be a useful tool.  On the other hand, we may decide to use it instead of the decoder for some uses.  Minimal MySQL knowledge would be helpful, but not required.

    Assigned to:  ???

    Run 7 BTOW Calibration

    Description:  Begin with MIP + electron calibration procedure used in previous years and investigate refinements.  Typically a couple months of work.

    Assigned to:  Matthew Walker (MIT)

    Status:  Waiting on Production.

    Run 7 BTOW Status

    Description:  Track tower status and upload DB tables for offline analysis.  Timescale of ~1 month plus occasional updates, corrections.  A set of tables are currently in the DB, but these ignore hot towers.

    Assigned to:  ???

    Run 7 BSMD Status

    Description:  Track SMD status and upload DB tables for offline analysis.  Timescale of ~1 month plus occasional updates, corrections.

    Assigned to:  ???

    Run 7 BPRS Status

    Description:  Adapt the existing BTOW status code for the preshower and use it to generate DB tables for offline analysis.

    Assigned to:  Matt Cervantes (TAMU)

    Status:  In Progress




    BPRS Mapping Update

    Description:  The BPRS mapping needs to be fixed to take into account the tower swaps we discovered in Run 5, plus any other problems that might turn up with the increased acceptance and statistics we have now.

    Assigned to:  Rory Clarke (TAMU)

    Status:  Complete -- mapping checked into CVS to fix Run 6 and Run 7 data at analysis level (StEmcADCtoEMaker).

    Single-Pass Embedding with Calorimeters

    Description:  BEMC embedding is typically done as an afterburner on the regular embedding.  This has the advantage of allowing multiple configurations to be run without needing to redo the full TPC embedding, but we should also support the standard embedding mode of a single BFC chain.

    Assigned to: 
    Wei-Ming Zhang (KSU)

    Status:  Complete

    Run 6 BTOW Calibration

    Description:  Perform MIP + electron calibration using Run 6 data.  Investigate electron-only and pi0-based calibrations.

    Assigned to:  Adam Kocoloski (MIT)

    Status:  Complete -- see Run 6 BTOW Calibration

    Run 6 BTOW Status

    Description:  Track tower status and upload DB tables for offline analysis.  Timescale of ~1 month plus occasional updates, corrections.

    Assigned to:  David Staszak (UCLA)

    Status:  Complete -- (link goes here)

    Run 6 BSMD Status

    Description:  Develop standard code to track SMD status and upload DB tables for offline analysis.  Investigate possibility of SMD status codes for individual capacitors

    Assigned to:  Priscilla Kurnadi (UCLA)

    Status:  Complete -- (link goes here)

    Of course, many others have contributed to the calibrations and physics program of the BEMC over the years.  You know who you are.  Thanks!

    --Adam Kocoloski


    The main EMC offline reconstruction chain consists of:  
    • StEmcAdcToEMaker - This maker gets ADC values for all EMC sub detectors and applies the calibration to get the proper energy value.
    • StPreEclMaker - This maker does clustering in all EMC sub detectors.
    • StEpcMaker - This maker matches the clusters in EMC sub detectors to get the final EMC point.
    To have this chain working properly, some others programs are necessary. The full offline reconstruction chain is shown in the schema below:

    Aside from Drupal, one can also find some very old BEMC documentation at


    Second most important step in EMC data reduction is to find clusters from EMC data.

    Main code performing EMC clustering is located in StRoot/StPreEclMaker and StRoot/StEpcMaker

    The main idea behind the BEMC cluster finder is to allow multiple clustering algorithms. With that in mind, any user can develop his/her own finder and plug it in the main cluster finder.

    In order to develop a new finder the user should follow the guidelines described in this page.

    Display Macro

    A Small cluster finder viewer was written for the BEMC detector. In order to run it, use the macro:


    This macro loops over events in the muDST files, runs the BEMC cluster finder and creates an event by event display of the hits and clusters in the detector. This is an important tool for cluster QA because you can test the cluster parameters and check the results online. It also has a method to do statistical cluster QA over many events.

    The commands available are:

    setHitThreshold(Int_t det, Float_t th)

    This method defines the energy threshold for displaying a detector HIT in the display. The default value in the code is 0.2 GeV. Values should de entered in GeV.  The parameters are:

    • Int_t det = detector name. (BTOW = 1, BPRS = 2, BSMDE = 3 and BSMDP = 4)
    • Int_t th = hit energy threshold in GeV. 


    This method displays the next event in the queue.

    qa(Int_t nevents)

    This method loops over many events in order to fill some clusters QA histograms. The user needs to open a TBrowser n order to access the histograms.  The parameters are:

    • Int_t nevents = number of events to be processed in QA 


    Displays a small help in the screen.

    How to write a new Cluster Finder

    To create a new algorithm it is important to understand how the cluster finder works.


    This file defines a simple enumerator for the many possible cluster algorithms. In order to add a new algorithm the user should add a new position in this enumerator

    StPreEclMaker.h and .cxx

    The cluster finder itself (StPreEclMaker) is a very simple maker. This maker is responsible only for creating the finder (in the Init() method) and call some basic functions in the Make() method.


    This method just instantiates the finder. In the very beginning of Init() method, the code checks which algorithm is being requested and creates the proper finder.


    The Make() method grabs the event (StEvent only) and exits if no event is found. If the event is found it calls 4 methods in the finder. These methods are:

    • mFinder->clear(); // to clear the previous event local cluster
    • mFinder->clear(StEvent*); // to clean any old cluster or pointer in StEvent
    • mFinder->findClusters(StEvent*); // to find the clusters in this event
    • mFinder->fillStEvent(StEvent*); // to fill StEvent with the new clusters
    • mFinder->fillHistograms(StEvent*); // to fill QA histograms

    The modifications the user should do in StPreEclMaker.cxx are only to add the possibility of instantiating his/her finder in the StPreEclMaker::Init() method.

    Creating a new cluster algorithm

    Before creating a new cluster algorithm it is important to know the basic idea behind the code.  The basic classes are


    There is an internal data format for the clusters in the code. The clusters are StEmcPreCluster which are derived from plain ROOT TObject. StEmcPreCluster is more complete than the regular StEvent cluster object (StEmcCluster) because it has methods to add and remove hits, split and merge clusters and well set matching id between different detectors.


    This is a placeholder for the StEmcPreCluster objects that are created. This object derives from the regular ROOT TList object. It has methods to create, add, remove and delete StEmcPreClusters. StEmcPreCluster objects that are created or added to the collections are owned by the collection so be careful.


    This is the basic finder class. Any cluster algorithm should inherit from this class. It already create the necessary collections for the clusters in each detector.

    To create a new finder algorithm you should define a finder class that inherits from the StEmcVirtualFinder and overwrite the method findClusters(StEvent*). Lets suppose you want to create a StEmcMyFinder algorithm. You should create a class with, at least, the following:

    #ifndef STAR_StEmcMyFinder
    #define STAR_StEmcMyFinder

    #include "StEmcVirtualFinder.h"

    class StEvent;

    class StEmcOldFinder : public StEmcVirtualFinder

    virtual ~StEmcOldFinder();
    virtual Bool_t findClusters(StEvent*);




    #include "StEmcMyFinder.h"
    #include "StEvent.h"
    #include "StEventTypes.h"


    // initialize your stuff in here
    Bool_t StEmcMyFinder::findClusters(StEvent* event)
    // check if there is an emc collection

    StEmcCollection *emc = event->emcCollection();
    if(!emc) return kFALSE;

    // find your clusters

    return kTRUE;

    The method findClusters(StEvent*) is the method that StPreEclMaker will call in order to find clusters in the event. All the StEmcVirtualFinder methods are available for the user.

    The user has 4 pre cluster collections available. They are named


    where det =1, 2, 3 and 4 (btow, bprs, bsmde and bsmdp)

    How to deal with clusters and collections

    Lets suppose you identified a cluster in a given detector. How do I work with StEmcPreCluster objects and the collections? Please look at the code itself to be more familiar with the interface. The next lines will give basic instructions with the most common tools:

    To create and add a cluster to the collection for the detector ´det´
    StEmcPreCluster *cl = mColl[det-1]->newCluster();

    This line creates a cluster in the collection and returns its pointer.

    To remove and delete a cluster from a collection
    mColl[det-1]->removeCluster(cl); // cl is the pointer to the cluster


    mColl[det-1]->removeCluster(i); // i is the index of the cluster in the collection

    This will remove AND delete the cluster.

    To get the number of clusters in a collection

    To add hits to a StEmcPreCluster (pointer to the cluster is called ´cl´)

    where hit is a pointer to a StEmcRawHit object.

    To add the content of a pre cluster ´cl1´ to a cluster ´cl´

    The added cluster ´cl1´ is not deleted. This is very useful if you identified a spitted cluster and would like to merge them.

    How to do matching in the cluster finder?
    Depending on the cluster finder algorithm one can do clusters in one detector using the information in the other detector as seed. In this sense, it is important do have some kind of matching available in the cluster finder. In the original software scheme, StEpcMaker is the maker responsible for matching the clusters in the BEMC sub detectors. This maker is still in the chain.

    Because of StEpcMaker, we CAN NOT create StEmcPoints in the cluster finder. This should be done *ONLY* by StEpcMaker. In order to have a solution for that, StEmcPreCluster object has a member that flags the cluster with matching information. This is done by setting a matching id in the cluster. Use the methods matchingId() and setMatchingId(Int_t).

    The matching id is an integer number. If matching id = 0 (default value), no matching was done and the matching will be decided in StEpcMaker. If matching id is not equal to 0, StEpcMaker will create points with clusters with the same matching Id.

    Using this procedure, we can develop advanced matching methods in the cluster finder algorithm.

    How to plug your finder into the cluster finder

    In order to plug your algorithm to the cluster finder you need to change two files in the main finder

    This file defines an enumerator with the cluster finders. To add your algorithm in this enumerator add an entry in the enumerator definition, for example:

    enum EmcClusterAlgorithm
    { kEmcClNoFinder = 0, kEmcClDefault = 1, kEmcClOld = 2, kEmcMyFinder = 3};

    You should change the Init() method in StPreEclMaker in order to instantiate your finder. To instantiate your StEmcMyFinder object, add, in the Init() method of StPreEclMaker:

    if(mAlg == kEmcClOld) mFinder = new StEmcOldFinder();
    if(mAlg == kEmcMyFinder) mFinder = new StEmcMyFinder();


    Original cluster algorithm (kEmcClOld)

    This page describes the original cluster finder algorithm. In order to use this algorithm you should set with the algorithm kEmcClOld.

    Salient features of the method implemented in the program are,

    • Clustering have been performed for each sub detector separately.
    • Currently clusters are found for each module in the sub detectors. There are some specific reasons for adopting this approach especially for Shower Max Detectors (SMD's). For towers, we are still discussing how it should be implemented properly. We have tried to give some evaluation results for this cluster finder.
    • There are some parameters used in the code with their default values. These default values are obtained after preliminary evaluation, but for very specific study it might be necessary to change these parameters. 
    • The output is written in StEvent format.

    Cluster algorithm

    • Performs clustering module by module
    • Loops over hits for each sub detector module
    • Looks for local maximums

    Cluster parameters

    • mEnergySeed – minimum hit energy to start looking for a cluster
    • mEnergyAdd -- minimum hit energy to consider the hit part of a cluster
    • mSizeMax – maximum size of a cluster
    • mEnergyThresholdAll – minimum hit energy a cluster should have in order to be saved

    Neighborhood criterion

    Because of the difference in dimension and of readout pattern in different sub detectors, we need to adopt different criterion for obtaining the members of the clusters.

    • BEMC: Tower gets added to the existing cluster if it is adjacent to the seed. Maximum number of towers in a cluster is governed by the parameter mSizeMax. It should be noted that BEMC, which takes tower as unit is 2-dimensional detector and by adjacent tower, it includes the immediate neighbors in eta and in phi.
    • BSMD: As SMDs are basically one-dimensional detector, so the neighborhood criterion is given by the condition that for a strip to be a neighbor, it has to be adjacent to any of the existing members of the clusters. Here also maximum number of strips in a cluster is governed by mSizeMax parameter.

    Cluster Object

    After obtaining the clusters, following properties are obtained for each cluster and they are used as the members of the cluster object.

    • Cluster Energy (Total energy of the cluster member).
    • Eta cluster (Mean eta position of the cluster).
    • Phi cluster (Mean phi position of the cluster).
    • Sigma eta, Sigma phi (widths of the cluster in eta nd in phi).
    • Hits (Members of the cluster).

    Some Plots

    BSMDE clusters for single photon events

    Performance Evaluation

    Note:  This is a rather old study that I found on BEMC public AFS space and ported into Drupal.  I don't know who conducted it or when.  -- A. Kocoloski

    On the subject of reconstruction made by cluster finder and matching, evaluation has been developed  to determine how good is the reconstruction, efficiency, purity, energy and position resolution of reconstructed particles originally generated by simulation data.

    Cluster finder is being evaluated at the moment using single particle events, which favors the evaluation of efficiency and purity. In this case, we can define efficiency and purity for single particle events as:

    • efficiency - ratio between the number of events with more than 1 cluster and the total number of events.
    • purity - ratio between the number of events with only 1 cluster and the number of events with at least one cluster.

    There are other quantities that could be used for evaluation. They are:

    • energy ratio - ratio between the cluster energy and the geant energy.
    • position resolution - difference between cluster position and particle position.

    All these quantities can be studied as a function of the cluster finder parameters,  mSizeMax, mEnergySeed and mEnergyThresholdAll. The results are summarized below.

    BTOW Clusters

    mEnergyThresholdAll evaluation

    Nothing was done to evaluate this parameter.

    mEnergySeed evaluation

    The purity as a function of mEnergySeed gets better and the efficiency goes down as this parameter increases.  Some figures (the others parameters were kept as minimum as possible) are shown for for different values of mSizeMax for single photons in the middle of a tower with pt = 1,4,7 and 10 GeV/c.

    The following plots were generated using energy seeds of 0.1 GeV (left), 0.5 GeV (middle), and 1.5 GeV (right).  Full-size plots are available by clicking on each image:

    Eta dfference

    Phi difference

    Number of clusters

    Energy ratio

    mSizeMax evaluation

    Nothing was done to evaluate this parameter.

    BSMD Clusters

    mEnergyThresholdAll evaluation

    Nothing was done to evaluate this parameter.

    mEnergySeed evaluation

    The purity as a function of mEnergySeed gets better and the efficiency goes down as this parameter increases.  Some figures (the others parameters were kept as minimum as possible) are shown for for different values of mSizeMax for single photons in the middle of a tower with pt = 1,4,7 and 10 GeV/c.

    The following plots were generated using energy seeds of 0.05 GeV (left), 0.2 GeV (middle), and 0.8 GeV (right).  Full-size plots are available by clicking on each image:

    Eta Difference (BSMDE only)

    Eta difference RMS as a function of photon energy for different seed energies:

    Phi Difference (BSMDP only)

    Phi difference RMS as a function of photon energy for different seed energies:

    Number of clusters for BMSDE

    Number of clusters for BSMDP:

    BSMDE efficiency and purity as a function of seed energy

    BSMDP efficiency and purity as a function of photon energy for different seed energies

    mMaxSize evaluation

    The efficiency and purity as a function of mSizeMax get better as this parameter increases but for values greater than 4 there is no difference. Some figures (the others parameters were kept as minimum as possible) are shown for for different values of mSizeMax for single photons in the middle of a tower with pt = 5 GeV/c.

    Point Maker

    After obtaining the clusters for 4 subdetectors, we need to obtain the information about the incident shower by making the proper matching between clusters from different subdetectors.

    It should be mentioned that, because of the better energy resolution and higher depth BEMC is to be used for obtaining the energy of the shower. SMDs on the other hand will be used for obtaining the position of the showers because of their better position resolution.

    Currently Preshower detector (PSD) has not been included in the scheme of matching, so we discuss here the details of the method adopted for matching other 3 sub detectors.

    Following steps are adopted to obtain proper matching:

    • The clusters obtained from different sub detectors are sorted to obtain the clusters in a single subsection of the SMD phi.
      • Each module of SMD phi consists of 10 subsections. 
        • Each subsection consists of 15 strips along eta, giving phi positions of the clusters for the eta-integrated region of 0.1. 
      • In SMD eta same subsection region consists of 15 strips along phi and the same region consists of 2 x 2 towers. 
    • In the present scheme of matching, we match the clusters obtained in 3 sub detectors in each of this SMD phi subsection.
    • There are two levels of matching:
      • SMD eta - SMD phi match
        • First matching aims to obtain the position of the shower particle in (eta, phi). Because of the integration of signals in SMD etas in the SMD phi subsection region, (i.e.. each SMD eta strip adds the signal in 0.1rad of phi and each SMD phi strip adds the signal in delta eta=0.1 region.) For this type of configuration of detectors, we have decided to get the position matching for each SMD phi subsection. Even though for cases like 1 cluster in SMD eta and 1 cluster in SMD phi in the subsection, we have mostly unique matching of (eta, phi), but for cases where SMD eta/SMD phi subsection consists of more than 1 cluster (see figure) then the possibility of matching does not remain unique. the task is handled from the following standpoint, The number of matched (eta, phi) pairs are taken as minimum of (number of clusters in SMD eta, number of clusters in SMD phi). The (eta, phi) assignment for the pairs are given considering the pair having minimum of (E1-E2)/(E1+E2), where E1, E2 are the cluster energy of SMD eta and SMD phi clusters.
      • Position - energy match
        • It should be mentioned that position/energy matching is done only when there exists a cluster in BEMC for the subsection under study. Because of the large dimension of towers, the clusters obtained in BEMC is made up of more than one incident particles. In case of AuAu data, where particle density is very large, the definition of clusters in towers become ambiguous, especially for low energy particles. In the present scheme, as we have discussed earlier, we have followed the method of peak search for finding clusters, where maximum cluster size is 4 towers. 4 towers make the region of one SMD phi subsection, so we have obtained the energy for the pairs obtained in (SMD eta, SMD phi) from the cluster energy of BEMC cluster in the same subsection. For the cases where we have 1 cluster in BEMC, 1 cluster in SMD eta, 1 cluster in SMD phi, we assign the BEMC cluster energy to (eta, phi) pairs. But for the cases when the number of matched pairs is more than one, then we need to split the BEMC cluster energy. Presently it is done according to the ratio of the strengths of (eta, phi) pair energies. This method of splitting has the drawback of using SMD energies, where energy resolution is worse compared to BEMC energy resolution.

    Codes for the point maker are found in StRoot/StEpcMaker


    The cluster finder can run in many different chains. The basic modes of running it are:

    1. bfc chain: This is the usual STAR reconstruction chain for real data and simulation.
    2. standard chain: this is the most common way of running the cluster finder. The cluster finder runs with real data and simulated data.
    3. embedding chain

    There are some rules a user needs to follow in order to run the cluster finder properly:

    1. Include the file $STAR/StRoot/StPreEclMaker/EmcClusterAlgorithm.h in order to define the cluster algorithm enumerator
    2. Need to load the shared libraries
    3. StPreEclMaker should run *AFTER* the BEMC hits are created (StADCtoEMaker or StEmcSimulatorMaker)
    4. The cluster algorithm should be defined *BEFORE* Init() method is called
    5. Any change in the cluster parameters should be done *AFTER* Init() is called.

    The following is an example on how to run the cluster finder in a standard chain:

    // include the definitions of the algorithms
    #include "StRoot/StPreEclMaker/EmcClusterAlgorithm.h"

    class StChain;
    StChain *chain=0;

    void DoMicroDst(char* list = "./file.lis",
    int nFiles = 10, int nevents = 2000)

    // create chain
    chain = new StChain("StChain");

    // Now we add Makers to the chain...
    maker = new StMuDstMaker(0,0,"",list,"",nFiles);
    StMuDbReader* db = StMuDbReader::instance();
    StMuDst2StEventMaker *m = new StMuDst2StEventMaker();
    St_db_Maker *dbMk = new St_db_Maker("StarDb","MySQL:StarDb");

    StEmcADCtoEMaker *adc=new StEmcADCtoEMaker();

    StPreEclMaker *ecl=new StPreEclMaker(); // instantiate the maker
    ecl->setAlgorithm(kEmcClDefault); // set the algorithm
    ecl->setPrint(kFALSE); // disables printing


    StEmcOldFinder* finder = (StEmcOldFinder*)ecl->finder(); // gets pointer to the finder
    finder->setEnergySeed(1,0.8); // change some setting in the finder

    int n=0;
    int stat=0;
    int count = 1;
    TMemStat memory;

    while ( (stat==0 || stat==1) && n<nevents)
    stat = chain->Make();

    Data Format

    BEMC data is always available using standard StEvent collections.  This is true regardless of whether one is analyzing simulations or real data, or whether the actual input file is in a geant.root,  event.root, or mudst.root format.  The appropriate BEMC maker (StEmcADCtoEMaker for real data, StEmcSimulatorMaker for simulations) will create an StEvent in-memory if necessary and fill the BEMC collections wth the correct data.

    Three different types of calorimeter objects are available:

    StEmcRawHit -- a hit for a single detector element (tower, smd strip, or preshower channel)

    StEmcCluster -- a cluster is formed from a collection of hits for a single BEMC subdetector (tower / smd-eta / smd-phi / preshower)

    StEmcPoint -- a point combines StEmcClusters from the different subdetectors.  Typically the SMD clusters are used to determine the position of points, and in the case of e.g. pi0 decay photons they also determine the fraction of the tower cluster energy assigned to each photon.  The absolute energy scale is set by the tower cluster energy.  Current point-making algorithms do not use the preshower information.

    For more information see the StEvent manual.


    Update:  New B/EEMC embedding framework from Wei-Ming Zhang currently in peer review

    The present BEMC embedding works as an afterburner that must be done after the TPC embedding.  Wei-Ming Zhang is working on a version that work in parallel with the TPC embedding.  Here's the current workflow:

    During TPC embedding

    In this step, only real EMC data is processed with all of the TPC embedding.  In the end, there are two files:
    1. .event.root - This file contains the TPC reconstructed tracks (real data + simulation) and BEMC reco information (real data only)
    2. .geant.root - This files contains the simulated tracks (TPC + EMC simulated data)
    Once again, no BEMC embedding is done at this level.  The chain that process the BEMC real data is the same as the one used for production (StEmcRawMaker, StPreEclMaker and StEpcMaker)

    After TPC embedding

    This is where the BEMC embedding happens.  The idea is to get the output from the TPC embedding (.geant.root and .event.root files) and mix the BEMC simulated data with the real BEMC data.  The mixing is performed by StEmcMixerMaker and the main idea is to add the simulated ADC values to the real event ADC values.  In order to do that we need to follow some simple rules:
    1. We have to simulate the ADC values with the same calibration table used for the real data
    2. We cannot add pedestals or noise to the simulated data.  The real data already include the pedestals and noise.  If we simulate them we will end up overestimating both quantities.
    3. We should embed simulated hits only for the towers with status==1.
    The macro that runs the embedding can be found at StRoot/StEmcMixerMaker/macros/doEmcEmbedEvent.C.  The basic chain that runs in this macro is
    1. StIOMaker - to read the .event.root and .geant.root files
    2. St_db_Maker - to make the interface with the STAR database and get the BEMC tables
    3. StEmcADCtoEMaker - reprocesses the real BEMC data and fills an StEvent object with the calibrated real data.
    4. StEmcPreMixerMaker - this is a simple maker whose only function is to make sure the chain timestamp is set using the real data event time.  This is very important to make sure the tables are correctly retrieved from the database.
    5. StMcEventMaker - builds an StMcEvent object in memory.  This is necessary because the simulator maker needs to get the BEMC simulated data in this format.
    6. StEmcSimulatorMaker - this maker gets the StMcEvent in memory that contains the BEMC simulated hits and does a slow simulation of the detector, generating the ADC values with the correct calibration tables.  At this point we have two StEmcCollections in memory: the one with the real BEMC data from step 3, and the one with the simulated data from the simulator maker.
    7. StEmcMixerMaker - this maker gets the two StEmcCollections and adds the simulated one to the real data.  This is a simple ADC_total = ADC1 + ADC2 for each channel in each detector.  Only simulated hits belonging to channels that were good in the real data are added.
    8. StEmcADCtoEMaker - reconstructs the event once more.  This step gets the new ADC values and recalibrates them.
    9. StPreEclMaker - reconstructs the clusters with the embedded hits.
    10. StEpcMaker - reconstructs the points
    11. StAssociationMaker - does the TPC association
    12. StEmcAssociationMaker - does the BEMC association
    13. Add your own analysis maker
    The embedding flow is illustrated in the following diagram:



    To treat many-particle events (pp and AuAu), we need to know which particle generated which cluster/point before evaluating the reconstructed clusters and points.  StEmcAssociationMaker accomplishes this by matching the many clusters and points in a given event with the respective simulated particles.

    Association Matrix

    In order to associate the clusters/points to the corresponding particles, the Association software creates matrices.  The matrix columns correspond to the reconstructed clusters/points and the lines correspond to the particles.  We have three kinds of matrices:
    • Simple Matrix - matrix elements are 0 or 1.
    • Particle Fraction Matrix - matrix elements are the fraction of the total particle energy in a cluster.
    • Cluster Fraction matrix - matrix elements are the fraction of energy of a cluster that comes from a given particle.

                    Simple Matrix                      Particle Fraction Matrix                 Cluster Fraction Matrix

    A simple example using association matrices is presented below.  In the case of double photon events, we plot the purity of the measured clusters in SMD eta as a function of the photon distance.  The purity is obtained from the "Cluster Fraction" Association Matrix.

    How to Use

    In order to follow the same scheme done in StAssociationMaker we save the association information in multimaps.  Multimaps make it very easy for the user to get the association information for a given StMcTrack, cluster or point.  Detailed documentation for StAssociationMaker is available <a href="">here</a>.  There are essentially four multimaps defined for the BEMC:
    1. multiEmcTrackCluster - correlates the StMcTrack with StEmcClusters
    2. multiEmcClusterTrack - corrrelates the StEmcCluster with StMcTracks
    3. multiEmcTrackPoint - correlates the StMcTrack with StEmcPoints
    4. multiEmcPointTrack - correlates the StEmcPoint with StMcTracks
    The following sample code can be used to access one of these multimaps provided StEmcAssociationMaker is available in the chain:
    StEmcAssociationMaker *emcAssoc = GetMaker("EmcAssoc");
    if(!emcAssoc) return;
    multiEmcTrackCluster *map = emcAssoc->getTrackClusterMap(1);
    if(!map) return;
    for(multiEmcTrackClusterIter j=map->begin(); j!=map->end(); j++)
    StMcTrack* track = (StMcTrack*)(*j).first;
    StEmcClusterAssociation* value = (StEmcClusterAssociation*)(*j).second;
    if(track && value)
    StEmcCluster *c = (StEmcCluster*) value->getCluster();
    cout <<" McTrack = "<<track<<" GeantId = "<<track->geantId()
    <<" pt = "<<track->pt()<<" TReta = "<<track->pseudoRapidity()
    <<" Cl = "<<c<<" E = "<<c->energy()<<" eta = "<<c->eta()
    <<" phi = "<<c->phi()
    <<" FrTr = "<<value->getFractionTrack()
    <<" FrCl = "<<value->getFractionCluster()<<endl;
    For a detailed example of how to use the BEMC multimaps please have a look at the StEmcAssociationMaker::printMaps() method.


    The BEMC makers available in STAR include:

    StEmcADCtoEMaker - This maker converts plain ADC values in energy. It subtracts pedestals, applies calibrations and creates the StEmcRawHits in StEvent. This maker also checks for corrupted headers. The input data format for this maker can be ANY of the formats below:

    • DAQ format (from DAQ files)
    • StEmcRawData format (StEvent)
    • StEmcCollection (StEvent)
    • StMuEmcCollection (muDST)

    A light version of this maker (StEmcRawMaker) runs during production. StEmcRawMaker uses only DAQ or StEmcRawData format as input.
    StPreEclMaker - This maker implements clustering of the BEMC detectors.
    StEpcMaker - This maker matches the clusters in the BEMC detectors making what we call an StEmcPoint. It also matches tracks with points, if the input format is StEvent.
    StEmcTriggerMaker - This maker simulates the BEMC level 0 trigger response using the plain ADC information from the towers. It works both with real and simulated data and it applies exactly the same trigger algorithm as in the BEMC hardware.
    StEmcSimulatorMaker - This is the slow BEMC simulator.  It takes an StMcEvent as input and fills the StEmcRawHit collections of StEvent with simulated ADC responses for all subdetectors.
    StEmcCalibrationMaker - This is the maker used for BEMC calibration. It has methods to calculate pedestals for all the BEMC detectors as well as detector equalization, based on spectra shape and MIP analysis. This maker runs online as our online pedestal calculator.
    StEmcMixerMaker - This maker is the basic BEMC embedding maker. It mixes hits from two StEvent objects in the memory. The hits from the second StEvent are mixed in the first one.  It can run in a standard BFC embedding chain or as an afterburner (afterburner mode requires an event.root file from non-BEMC embedding plus a geant.root file containing BEMC information for simulated particles to be embedded).


    Documentation provided by Renee Fatemi

    1. Apply online trigger algorithm to simulated data
    2. Apply "software trigger" to triggered data
    3. Ensure that the same code is used for case 1. and 2.

    How the Code Works:
    StEmcTriggerMaker is the class that provides the user access functions to the trigger decisions. The workhorse is the StBemcTrigger class. StEmcTriggerMaker passes a StEvent pointer from either StEmcADCtoEMaker (real data) or StEmcSimulatorMaker (simulated data). The code accesses all offline status/ped/calibrations from StBemcTables, which are set in the macro used to run the code (ideal status/gain/ped can also be set). Code uses StEmcCollection to access ADC for all WEST BEMC channels which are not masked out with the status code and perform FPGA+L0 trigger on 12 bit ADC and 12 bit PED.

    Access Function Examples:
    // if event fulfills trigger return 1 else return 0 problems return -1
    int is2005HT1() {return mIs2005HT1;}
    int is2005JP1() {return mIs2005JP1;}

    // The ID of the candidate HT (JP)
    int get2005HT1_ID() {return HT1_ID_2005;}
    int get2005JP1_ID() {return JP1_ID_2005;}

    // The DSM ADC of the candidate HT (JP)
    int get2005HT1_ADC() {return HT1_DSM_2005;}
    int get2005JP1_ADC() {return JP1_DSM_2005;}

    // The number of towers(patches) and the id’s which fulfill the trigger
    void get2005HT1_TOWS(int, int*);//array of tow ids passing HT1_2005 trig
    int get2005HT1_NTOWS() {return numHT1_2005;}//# tows passing HT1_2005 trig
    void get2005JP1_PATCHES(int, int*);//array of patches passing JP1_2005
    int get2005JP1_NPATCHES() {return numJP1_2005;}//# patches passing JP1_2005

    These access functions exist for 2003 HT1, 2004 HT1+JP1, 2005 HT1+HT2+JP1+JP2

    //get trigger info
    for (int i=0;i<numHT1_2005;i++){
    int towerid=-1;

    Conceptually this code was designed from a software/analysis user point of view. Consequently I do not explicitly calculate and store all levels of DSM logic (it is unnecessary). From my understanding this is precisely what the StEmcTriggerDetector class was written to do -- return all DSM levels. It propagates all of the trigger information to the MuDst. BUT the problem is that this class is not propagated to the simulation (as far as I can tell). Even if it was propagated we probably wouldn’t want to take this option because it limits the usefulness of the simulation, whereas the StEmcTriggerMaker allows flexibility in applying the trigger algo to any simulation set. It is certainly possible code up the 2006 part of StEmcTriggerMaker to return all BEMC and EEMC trigger patch information at all levels of DSM, but it doesn’t exist in the current code.


    These are not Makers but codes that prove useful for BEMC analyses.  The headings indicate where the codes can be found in the STAR source code repository.



    This utility converts the daq indexes for any BEMC detector (crate number, position in the crate, etc) in software ids (softId, module, eta, sub).

    It also converts the Level-0 BEMC trigger patches ids in the corresponding tower crate number and index in the crate. It is quite useful to determine the correspondent tower that fired the trigger


    This class is used to convert softId in real eta and phi position in the detector and vice-versa. Also converts softId in module, eta and sub indexes that are used in StEvent.

    It has methods to get geometrical information of the BEMC, such as number of channels, radius, etc. This is a very important utility in the BEMC software.


    Utility to project tracks in the BEMC detector


    Utility to load the database tables and get any information from them. It works only in makers running in the chain and has methods to return pedestal, calibrations, gain and status values for all the BEMC detectors. To use it do, in your maker:

    // in the constructor. Supposing you have a private
    // member StBemcTables *mTables;
    mTables = new StBemcTables();

    // in the InitRun() or Make() method
    // this method loads all the BEMC tables
    // it is necessary to have St_db_Maker running

    // Getting information
    // for example, getting pedestal and RMS for the
    // BTOW Detector softId = 100
    float ped = mTables->pedestal(BTOW, 100);
    float rms = mTables->pedestalRMS(BTOW, 100);


    This class inherits from StBemcTables and is useful for performing all kinds of more advanced BEMC DB operations, including uploading tables if you've got the privileges for it.

    I'm not sure if anyone is actually using the rest of these, nor am I confident that they actually work in DEV.  Feel free to leave some feedback if you have some experience with them. -- Adam


    Utility to subtract hadronic energy from EMC towers. It uses StEmcHadDE to subtract the hadronic energy in the calorimeter in a event by event basis.


    Utility to calculate hadronic energy profile in the BEMC. It calculates the amount of energy deposited by a single hadron as a function of its momentum, position in the detector and distance to the center of the tower.


    This utility calculates high voltages for the towers for a given absolute gain.


    Basic EMC neural network interface.


    Event filter for BEMC (StEvent and StMcEvent only)

    This utility has a collection of tools to do event filtering in the BEMC. Some of the filters available are:

    • basic event filter: vertex, multiplicity, etc
    • tower filters: tower isolation filter, number of tracks in tower, energy cuts, tower energy and associated pt cuts, etc.

    Useful Documents

     A full list of attached documents is available below, but I wanted to highlight a few here:

    BEMC Technical Design Report (PDF)


    Run 9 BSMD Online Monitoring Documentation

    For run 9, BSMD performance was monitored by looking at non-zero-suppressed events.  The code is archived at /star/institutions/mit/wleight/archive/bsmdMonitoring2009/.  This blog page will focus on the details of how to run the monitoring and the importance of various pieces of code involved in the monitoring.  The actual monitoring plots produced are discussed here.

    A few general notes to begin:

    Since the code all sat in the same directory constantly, a number of directories have been hard-coded in.  Please make sure to change these if necessary.

    The code for actually reading in events is directly dependent on the RTS daq-reader structure: therefore it sits in StRoot/RTS/src/RTS_EXAMPLE/.

    All compilation is done using makefiles.

    Brief Description of the Codes:

    This section lists all the pieces of code used and adds a one- or two-sentence description.  Below is a description of the program flow which shows how everything fits together.  Any other code files present are obsolete.

    In the main folder: The central script that runs everything.

    onlBsmdPlotter.cxx and .h: The code that generates the actual monitoring plots.  To add new plots, create a new method and call it from the doQA method.

    makeOnlBsmdPlots.C: Runs the onlBsmdPlotter code.

    GetNewPedestalRun.C: Finds the newest BSMD pedestal run by querying the database.

    onlBsmdMonConstants.h: Contains some useful constants. Deletes surplus files (postscript files that have been combined into pdfs, for instance).  This script is NOT run by and must be run seperately.

    In the folder StRoot/RTS/src/RTS_EXAMPLE/

    bsmdPedMonitor.C: Reads the pedestal file from evp and fills and saves to file the pedestal histograms, as well as generating ps and txt files describing the pedestals.

    makeMapping.C: Creates a histogram that contains the mapping from fiber and rdo to softId and saves it to mapping.root.  Unless the mapping changes or the file mapping.root is lost there is no need to run this macro.

    onlBsmdMonitor.C: Reads BSMD non-zero-suppressed events as they arrive and creates a readBarrelNT object to fill histograms of pedestal-subtracted ADC vs. softId and capId, as well as rates and the number of zero-suppressed events per module.  When the run ends, it saves the histograms to file and quits.

    readBarrelNT.C and .h: This class does the actual work of filling the histograms: used by onlBsmdMonitor.C.

    testBsmdStatus.C: Checks the quality of the most recent pedestal run and generates QA ps files.

    rts_example.C: This is not used but serves as the template for all the daq-reading code.

    Program Flow:

    The central script,, has a number of options when it is started:

    Script Options

    -p: print.  This is a debugging option: it causes the code to print the ADC value for every channel.

    -n: number of events (per run).  Occasionally it is useful to limit the number of (non-zero-suppressed) events the monitoring program looks at for tests.  During actual monitoring, we wished to catch all possible events so the script was always initialized with -n 1000000: the actual number of non-zero-suppressed events in a run is a few hundred at most.

    -t: this option is not used in the current version of the code.

    -r: raw data.  This option was added during testing when online reading of pedestal files had not been implemented: if it is turned on then the code will not attempt to subtract pedestals from the data it reads.

    -v: mpv cut.  If a channel has MPV greater than this value, it is considered to have a bad MPV.  The default is 5.

    -m: mountpoint.  For monitoring, the mounpoint is always set to /evp/.  During tests, it may be useful not to have a mountpoint and read from a file instead, in which case no mountpoint will be given.

    The standard initialization of the script for monitoring is then:

    python -n 1000000 -m /evp/

    Usually the output is then piped to a log file.  For testing purposes, as noted above, the -m option can be left off and the mountpoint replaced with a file name.  (Side note: if neither a mountpoint nor a file name is given, the code will look for the newest file in the directory /ldaphome/onlmon/bsmd2009/daqData/, checking to be sure that the file does not have the same run number as that of the last processed run.  This last option was implemented to allow for continuous processing of daq files but never actually used.)

    The main body of the monitoring script is an infinite loop.  This loop checks first to see what the current BSMD pedestal run is: if it is newer than the one currently used, the script processes it to produce the pedestal histograms that will be used by the data processing code.  This process happens in several steps:

    Pedestal Processing

    Step 1: The script calls the C macro GetNewPedestalRun.C, passing it the time in Unix time format.  The macro then queries the database for all pedestal runs over the last week.  Starting with the most recent, it checks to see if the BSMD was present in the run: if so, the number of that run is written to the file newestPedRunNumber.txt and the macro quits.

    Step 2: The script opens newestPedRunNumber.txt and reads the run number there.  It then checks to see if the pedestals are up-to-date.  If not, it moves to step 3.

    Step 3: The script moves to StRoot/RTS/src/RTS_EXAMPLE/ and calls bsmdPedMonitor, passing it the evp location of the newest pedestal run, /evp/a/runnumber/ (bsmdPedMonitor does take a couple of options but those are never used).  The main function of bsmdPedMonitor is to produce a root file containing three histograms (BSMDE, BSMDP, BPRS) each of which has a pedestal value for each softId-cap combination.  The pedestal monitoring code starts by reading in the BSMD and BPRS status table (StatusTable.txt) and the mapping histogram (from the file mapping.root) which gives the mapping from fiber and rdo to softId.  Then it goes into an infinite loop through the events in the file.  In a pedestal file, the pedestals are stored in the event with token 0: therefore the code rejects events with non-zero token.  Once it has the token-0 event, it loops through the fibers, grabs the pedestal and rms databanks for each fiber, and fills its histograms.  Finally the code generates a text file that lists every pedestal and several ps files containing the pedestals plotted vs softId and cap.

    Step 4: The script calls testPedStatus.C, passing it the root file just generated.  This macro checks for each good channel to make sure that the pedestals and rms just obtained are within certain (hardcoded) limits.  If the number of channels that have pedestal or rms outside of these limits is above a (hardcoded) threshold for a given crate, that crate is marked as bad.  A ps file is generated containing a table in which crates are marked as good or bad with green or red and several more with softId vs cap histograms in which bad pedestals are marked in red.

    Step 5: The postscript files are combined into pdfs (one for the pedestals and one for the statuses), which are, along with the text file, copied to the monitoring webpage.  The index.html file for the monitoring webpage is updated to reflect that there are new pedestals and to link to the files generated from the new pedestal file.  Finally, the variable containing the number of the old pedestal run is changed to that of the current pedestal run.

    The next step is to call onlBsmdMonitor, which reads the events as they arrive.  This code has several options:

    Daq Reading Options:

    -d: allows you to change the buillt-in rts log level.

    -D: turns on or off printing: corresponds to -p from the script.

    -m:  mountpoint, the same as -m from the script.

    -n: nevents, the same as -n from the script.

    -l: last run, which tells the code what the last run was so that it knows when a new run is starting.

    -r: raw data, same as -r from the script.

    The script thus picks what options to give to onlBsmdMonitor from the options it was given, as well as from the value it has recorded for the last run number (1 if the script is starting up).  Output from onlBsmdMonitor is piped to a log file named currentrun.log.  OnlBsmdMonitor also consists of an infinite loop.  As the loop starts, it gets the current event, checks to see if we are in a new run, and if so that this new run has the BSMD in.  If so, it initializes a new instance of the class readBarrelNT, which does the actual processing, and then processes the event.  If instead this is an already-occuring run, it checks to make sure that we have a new event, and if so processes it.  If we are in between runs or the event is not new, the loop is simply restarted, in some cases after a slight delay.  The main task of onlBsmdMonitor is to obtain histograms of pedestal-subtracted ADC vs softId and capId for the BPRS, BSMDE, and BSMDP and save them to a root file.  It also histograms the rate at which events are arriving and the number of zero-suppressed events per module.  The root file also contains a status histogram which is obtained from file StatusTable.txt.  When the run is over, the histograms are written to file and onlBsmdMonitor quits, writing out a line to its log file to indicate its status at the point at which it ends.

    The script now looks at the last line of the log file.  If this line indicates that the run had no BSMD, a new entry in the monitoring webpag's table is created to reflect this fact.  If not, the script first checks to see if we are in a new day: if so, a new line for this day is added to the webpage and a new table is started.  The script then extracts the number of non-zero-suppressed BSMD events, the total number of events in the run, the number of ZS events, and the duration of the run from the last line of the log file.  If the run is shorter than a (hardcoded) length cutoff, has no NZS BSMD events, or has fewer NZS BSMD events then a (hardcoded) threshold, the appropriate new line in the table is created, with each of the values obtained from the log file entered into the table, a link to the runlog added, and the problem with the run noted.  If the run passes all quality checks, makeOnlBsmdPlots is called.  This code generates the actual monitoring plots: the script then takes the resulting ps files, combines them into a pdf, and creates a new entry in the table with all the run information, a link to the pdf, a link to the run log, and a link to pedestal QA pdf.  The plotting code requires to be given the mpv cut value and the elapsed time, as well as the name of the root file containing the histogram for the runs.  Any new monitoring plots that are desired can be added by adding a method to create them to onlBsmdPlotter.h and onlBsmdPlotter.cxx and calling them in the method doQA.  Having thus completed a run, the loop restarts.

    Some BSMD hardware documents

    Some BSMD hardware documents, below


     Barrel Time-of-Flight Detector

    BTOF Operations (incl. slow controls)

     Barrel Time-of-Flight Operations

    1. TOF Gas: Bottle Switchover Procedure
    2. Slow Controls
    3. On-call Experts
    4. TOF Error Handling

    On-call expert

    Last updated: March 24th 2010 

    How To Clear TOF Errors

     TOF on-call expert for this week:  Yi Zhou (cell: 631-965-6132)

                                                            Frank Geurts (Apartment: 631-344-1042)


    Important Notes: 

    The Anaconda window should always running at the TOF Station!  Do Not Close this window.

    Shift crews must check the Warning and Error sections of the Anaconda window after every new run is begun. Warnings will automatically cleared when runs are begun. If an Error is not cleared automatically when a new run is begun, see sections 4 and 1 below. 

    For all TOF alarms or errors, leave a note in the shift log.  Be detailed so the experts will understand what happened and you actually did.

    Never click the red 3 button in the Anaconda window or power cycle a tray during a run, only when the run is stopped.


    Additional actions: 

    1. Electronics errors and/or bunchid errors
      Stop the run and determine which tray has the issue (there likely will be a yellow LV current alarm). Clear all (other) errors in Anaconda by pressing the red (3) button. The affected tray will most likely turn gray in Anaconda. In Anaconda, turn off "Auto-Refresh" (in "Command" menu). Go to the main voltage control GUI, turn the LV for that tray off, wait 10 seconds, and then turn the LV for that tray on again. Wait 60 seconds. Then click the red (3) button in the Anaconda window. The tray status should turn green. Turn on "Auto-Refresh" again. Start a new run. Make a note in the shift log. If the problem isn't fixed, then call the expert. 


    2. Yellow alarm at LV power supply associated with a tray.
      First, check TOF QA plots and look for electronic errors or bunchid with electronic errors. If there are errors, then follow step 1. Otherwise don't call an expert, just make a note in the shift log.


    3. Missing tray or half-tray in TOF online plots (specifically Multiplicity plots), follow procedure 1.


    4. In the TOF_MON GUI (Anaconda II):
      1. If you see red errors and/or the online plots indicate problems, stop and restart run. If error doesn't get cleared by this, make sure that all of the small LV circles in the main voltage GUI are green. If not, follow procedure 1 above. Otherwise, call the expert.
      2. If you see yellow alarms, no need to call experts, these clear automatically at the beginning of the next run.
      3. If it is grey alarm, click the "Refresh" button (left of the "1" button) to see if this clears it, otherwise follow procedure 1.


    5. TOF readout 100% DAQ errors and one of the RDO 1-4 lights on the TOF DAQ receiver is not responding (LED is black instead of blue or purple). The cure is to stop the run, mark it bad, and start a new run. Nothing else is required. This has worked 100% of the time so far. Make a note in the shift log.


    6. Gas alarm on FM2, which is for iso-butane gas.
      When it's cold, the pressure on FM2 will decrease and may cause alarms. In this case, no need to call expert. 


    7. If you see the LV off, i.e. dots are blue. (In the normal situation, the dots are green, indicating the LVs are on), please call expert.


    8. TOF HV slow control lost communication, please leave a note in the shift log, and follow the procedure in the trouble shooting of HV manual to fix it. Call expert for help in case you do not fix the problem.


    Slow Controls

    Slow Controls Detector Operator Manuals

     by Betrand J.H. Biritz (linked version: Jan.5, 2010)

     EPICs interface


    HV manual


    LV manual



    Run 15 TOF+MTD Operations Documents

    Run 15 TOF + MTD Operations Documents


    This page is dedicated to hosting documents  to aide in the operation of the TOF, MTD, and VPD subsystems.  Listed below are a list of the documents attached to this page and a brief description.  The .docx files are listed to update the documents as needed.

    The first part of the document describes how to restart the canbus interface and the processes dependent on it (recoveryd and anaconda).
    The second part adds a powercycle of the interface to the procedure.

    Expert_Knowledge_Base.pdf (document formerly known as Etc.pdf)
    A collection of tidbits for TOF+MTD folk.  Not quite intended for det. operators.

    This guides the detector operator on how to restart an HVIOC for the MTD.
      If you want to get super fancy with restarting IOCs, you might want to check their saved states in the ~/HV/HVCAEN*/iocBoot/save_restore_module/*.sav* and see what the IOC is initializing with.  The same thing applies for the LV (MTD/LV/LVWiener*/iocBoot/save_restore_module/) and TOF.

    Instructions for the detector operator on performing a LV powercycle.

     This document describes how to check and restart recoveryd.

    Responding_To_DAQ_Powercycle_Requests_Monitoring_And_Clearing_Errors.pdf (Formerly known as General_Instructions)
      This document is used as a guide to respond to DAQ powercycle requests and monitoring and clearing errors given by DAQ.

     The document decribes how to monitor the freon and what to do when it runs out.

    To guide the detector operator through a TOF HVIOC restart.

    Instructions for the detector operator on performing a LV powercycle.


    Run 16 TOF+MTD Operations Documents

    This page holds TOF and MTD operations documents used during Run-16. Previous versions and possibly current versions may be found on Run-15's equivalent page. [ie: If you do not see the document attached to the bottom of this page, it has not been updated since last run and may be found on the Run-15 page.]

    Run 16 TOF + MTD Operations Documents


    This page is dedicated to hosting documents  to aide in the operation of the TOF, MTD, and VPD subsystems.  Listed below are a list of the documents attached to this page and a brief description.  The .docx files are listed to update the documents as needed.

    The first part of the document describes how to restart the canbus interface and the processes dependent on it (recoveryd and anaconda). (This document has been updated since Run-15)
    The second part adds a powercycle of the interface to the procedure.

    Expert_Knowledge_Base.pdf (This document has been updated since Run-15)
    A collection of tidbits for TOF+MTD folk.  Not quite intended for det. operators.

    This guides the detector operator on how to restart an HVIOC for the MTD.
      If you want to get super fancy with restarting IOCs, you might want to check their saved states in the ~/HV/HVCAEN*/iocBoot/save_restore_module/*.sav* and see what the IOC is initializing with.  The same thing applies for the LV (MTD/LV/LVWiener*/iocBoot/save_restore_module/) and TOF.

    Instructions for the detector operator on performing a LV powercycle.

    MTD_LVIOC_Restart.pdf  (This document is new since Run-15)
    To guide the detector operator through a MTD LVIOC restart.

     This document describes how to check and restart recoveryd.

    General_Instructions.pdf (This document has been updated since Run-15) (The document formerly known as "The document Formerly known as General_Instructions" or Responding_To_DAQ_Powercycle_Requests_Monitoring_And_Clearing)
      This document is used as a guide to respond to DAQ powercycle requests and monitoring and clearing errors given by DAQ.

     The document decribes how to monitor the freon and what to do when it runs out.

    TOF_HVIOC_Restart.pdf  (This document has been updated since Run-15)
    To guide the detector operator through a TOF HVIOC restart.

    TOF_LVIOC_Restart.pdf  (This document is new since Run-15)
    To guide the detector operator through a TOF LVIOC restart.

    Instructions for the detector operator on performing a LV powercycle.


    Run19 TOF and MTD operation instruction documents

     This page summarizes all the documents for the BTOF and MTD operation.

    Run20 TOF and MTD operation instruction documents

    This page summarizes all the documents for the BTOF and MTD operation during Run 20.

    Attached files:

    • version 1/6/20 by Zaochen Ye

    Know issues:

    Run21 BTOF MTD operation instruction documents


    • The instructions for the control room can be found at STAR operation page:
      • STAR Operation (BTOF/MTD/ETOF) both .doc and .pdf file are attached 
    • Expert Knowledge Manual (Only for Oncall Expert)


    TOF Error Handling

    Last updated: March 23nd 2010 

    TOF Error Handling

     TOF on-call expert for this week: Bill Llope (Apartment: 631-344-1042, Cell: 713-256-4671)


    The Anaconda window should always be running on the TOF work station. It keeps a log of important operating conditions and automatically clears most type of electronics errors at the beginning of each run.

    The most important indication of the TOF system "health" are the online plots. They should be checked after the beginning of each run.

    Shift crews should check the Warning and Error sections of the Anaconda window to see that Warnings and Errors are being cleared automatically at the beginning of each run.

    Please make a note of all TOF alarms or any error not automatically cleared by Anaconda in the shift log. Please include enough information so the experts can understand what happened and what you actually did.

    Never click the red 3 button in the Anaconda window or power cycle a tray during a run, only when the run is stopped.


    Additional actions: 

    1. Electronics errors and/or bunchid errors
      Stop the run and determine which tray has the issue (there likely will be a yellow LV current alarm). Clear all (other) errors in Anaconda by pressing the red (3) button. The affected tray will most likely turn gray in Anaconda. In Anaconda, turn off "Auto-Refresh" (in "Command" menu). Go to the main voltage control GUI, turn the LV for that tray off, wait 10 seconds, and then turn the LV for that tray on again. Wait 60 seconds. Then click the red (3) button in the Anaconda window. The tray status should turn green. Turn on "Auto-Refresh" again. Start a new run. Make a note in the shift log. If the problem isn't fixed, then call the expert. 


    2. Yellow alarm at LV power supply associated with a tray.
      First, check TOF QA plots and look for electronic errors or bunchid with electronic errors. If there are errors, then follow step 1. Otherwise don't call an expert, just make a note in the shift log.


    3. Missing tray or half-tray in TOF online plots (specifically Multiplicity plots), follow procedure 1.


    4. In the TOF_MON GUI (Anaconda II):
      1. If you see red errors and/or the online plots indicate problems, stop and restart run. If error doesn't get cleared by this, make sure that all of the small LV circles in the main voltage GUI are green. If not, follow procedure 1 above. Otherwise, call the expert.
      2. If you see yellow alarms, no need to call experts, these clear automatically at the beginning of the next run.
      3. If it is grey alarm, click the "Refresh" button (left of the "1" button) to see if this clears it, otherwise follow procedure 1.


    5. TOF readout 100% DAQ errors and one of the RDO 1-4 lights on the TOF DAQ receiver is not responding (LED is black instead of blue or purple). The cure is to stop the run, mark it bad, and start a new run. Nothing else is required. This has worked 100% of the time so far. Make a note in the shift log.


    6. Gas alarm on FM2, which is for iso-butane gas.
      When it's cold, the pressure on FM2 will decrease and may cause alarms. In this case, no need to call expert. 


    7. If you see the LV off, i.e. dots are blue. (In the normal situation, the dots are green, indicating the LVs are on), please call expert.


    8. TOF HV slow control lost communication, please leave a note in the shift log, and follow the procedure in the trouble shooting of HV manual to fix it. Call expert for help in case you do not fix the problem.


    TOF On-call expert

    Last updated: February 8th 2010


    TOF on-call expert for this week:Lijuan Ruan, Yi Zhou, Geary Eppley and Jo Schambach


    Expert information is also below:

    Today through Thursday (Feb 09-Feb 11th):
    Feb 12th 0:30-7:30 shift is included.
    Lijuan Ruan: 510-637-8691 (cell)
    I will leave for APS meeting on Friday morning.

    Friday-Saturday (Feb 12th - 13th):
    Feb 14th 0:30-7:30 shift is included.
    Yi Zhou: 631-344-1014 (apt #), 631-344-7635 (office).

    Sunday-Monday (Feb 14th-15th):
    Feb 16th 0:30-7:30 shift is included.
    Geary Eppley: 713-628-2738 (cell)

    Jo will arrive on the night of Feb 15 th, so for Feb 16th shift, please call
    Jo Schambach: 631-344-1042 (Apt #) for help.


    For all TOF alarms, leave a note in the shift log. Additional actions:


    1. Gas alarm on FM2, which is for iso-butane gas.
      When it's cold, the pressure on FM2 will be changed, this will lead to the flow of isobutene dropping, thus give us alarms. In this case, no need to call expert. We expect isobutene to run out sometime in Feb.


    2. Temperature alarms on the LV powersupply, no need to call expert.


    3. Electronic errors or bunchid errors with electronic errors
      Stop the run and determine which tray has the issue (there might be a yellow LV current alarm). Turn the LV off, wait 10 seconds and then turn the LV on again. After waiting 10 seconds click the red 3 button in the Anaconda window, the tray status should turn green. Start a new run - if the problem isn't fixed then call the expert.


    4. Yellow alarm at LV poweruspply associated with a tray.
      First, check TOF QA plots and look for electronic errors or bunchid with electronic errors. If there are then follow step 3, otherwise don't call but make a note in the shift log.


    5. Missing tray on online plots, call expert.


    6. If you see the LV off, the dots are blue. (In the normal situation, the dots are green, indicating the LVs are on), please call expert.


    7. In the TOF_MON GUI:
      1. If you see red errors, stop and restart run. If error doesn't get cleared by this, call expert.
      2. If you see yellow alarms, no need to call experts.
      3. If it is grey alarm, call the expert.


    8. TOF HV slow control lost communication, please leave a note in the shift log, and follow the procedure in the trouble shooting of HV manual to fix it. Call expert for help in case you do not fix the problem.

    TOF noise rate pattern


    BTOF Hardware

     BTOF Hardware & Electronics

    • Bad Tray History (Aug. 20, 2021)
    • Tray 102 has a bad POS HV cable. It is behind the TPC support and cannot be repaired.

      Run 10 start  58

            end    10
      Run 11 start  25
            end    25
      Run 12 start  95
            end    95
      Run 13 start  46 106
            end    46 106
      Run 14 start  20  22  35 103
            end    20  22  35  78 103
      Run 15 start  38  41
            end    38  41
      Run 16 start 105
            end   105
      Run 17 start  36  45  80
            end    36  45  80  91 116
      Run 18 start   8  43 116
            end     2   8  40  43 116
      Run 19 start  30  34             (water leak on THUB NW trays 21-50)
            end    22  25  27  30  34  67  97
      Run 20 start  22  25  67
            end     8  22  25  48  64  67  88 101 118 119
      Run 21 start   8  22  48  64  67  88 101 118 119
            end     8  22  48  49  64  67  88 101 118 119

      pp500/510 history:

      Run  9  10 pb-1
         11  37 pb-1
         12  82 pb-1
         13 300 pb-1
         17 320 pb-1
         22 400 pb-1 (BUR)

      Current bad trays:

       8 - 8:0 bunch id error, 8:1 missing
      22 - no canbus
      48 - 48:0,1 missing
      49 - no canbus
      64 - TDIG 59 no response
      67 - may be ok now
      88 - 88:0 missing
      101 - 101:0 missing, 101:1 bunch id error
      118 - bad LV connection, seems ok now
      119 - 119:0 HPTDC 0x6 error

    • BTOF Electronics
    • Low Voltage Power Supplies:
      • Wiener PL512 Technical Manual
      • default SNMP community names for all TOF and MTD power supplies: {tof-pub, tof-priv, admin, guru}:

        [geurts@tofcontrol ~]$ snmpwalk -v 2c -m +WIENER-CRATE-MIB -c guru tof-lvps1 snmpCommunityName
        WIENER-CRATE-MIB::snmpCommunityName.public = STRING: "tof-pub"
        WIENER-CRATE-MIB::snmpCommunityName.private = STRING: "tof-priv"
        WIENER-CRATE-MIB::snmpCommunityName.admin = STRING: "admin" = STRING: "guru"

      • power supply hostnames: see Tray Mapping documents
    • Network Power Switches:

    TOF HV Hardware

    This page is intended to host information about TOF's high voltage equipment.

    A1534s (HV Supply Boards)

    The A1534 is the HV Supply board that is inserted into our SY1527(MTD:SY4527 ).

    Currently used boards(03/01/2016) for TOF + MTD: serial number and firmware version

    TOF(counting from 0):
    slot 1(-): 54, 3.01
    slot 3(+): 56, 2.02
    slot 5(-): 55, 2.02
    slot 7(+): 57, 2.02

    MTD(counting from 0):
    slot 1(-): 66, 04.
    slot 3(+): 69, 3.01
    slot 5(-): 71, 04.
    slot 7(+): 61, 03.
    slot 9(-): 59, 3.01

    Spare(-): serial number 58

    Bad boards:
    #59(Neg) - channel 3 bad (ch. 0-5) [occurred ~2/5/16 in SY4527 while in slot 1, was replaced with #66 on 2/17/16, then reinstalled in slot 9]

    #66(Neg) - channel 3 bad (ch. 0-5) [occurred ~6/16/15 in SY1527LC spare while in slot 5, then installed and bl30,1 no data but reading back values when in slot 1 in 02/17/16]
    -Email thread MTD BL 15-17 HV on MTDops 6/22-6/26/15.
    -Not sure if this board was repaired between run15+16 and then failed again.

    #58(Neg) - possible bad channel 3 (ch.0-5). I think this was swapped in for #66 ~6/16/15(spare SY1257LC) and out for #71 ~2/02/16 (SY4527). Would have been in slot 5
    Unaware of the positive spares available.

    BTW: reoccurring issues on MTD BL15-17 from at least 1/17/2015 [slot 5 channel 3] and 5/11/2014, 1/31/2014...

    Also some board repair history:

    Forum: TOF sub-system forum
    Re: HV boards in need for repair (Bertrand H.J. Biritz)
    Date: 2010, Jul 27
    From: W.J. Llope

    Hi Bertrand, since there are so many bad boards now - Geary and I agree that we
    should probably send them all in together a.s.a.p...

    thanks, cheers,

    On Jul 26, 2010, at 7:34 PM, Bertrand H.J. Biritz wrote:

    > Hi All,
    > Just wanted to open the discussion on how to proceed with the HV board repairs.
    > In total there are three boards in need of repair, with board 54 already having been sent in:
    > Board 54: Channel 0 is arching [In use and fixed for TOF. Would explain the updated firmware.-joey ]
    > Board 58: Channel 0 has ~130V offset and channel 3 no longer works [Could be a reoccurring issue with channel 3...?or explain why it failed, if it was the one swapped above-joey]
    > Board 56: Channel 5 no longer works [In use on TOF--repaired.-joey]
    > Board 58 is powering the East negative side of TOF (and MTD) while board 56 is for the East positive side of TOF (and MTD). We no longer have enough spares to make up for the lose of these boards.
    > During last weeks TOF phone conference Geary said board 58 should be sent in for repair once the last noise rate data run was taken.
    > Does the fact that an additional board is in need of repair change this and should board 56 be sent in at the same time as well?
    > CAEN will be entering their three week summer holiday beginning of August. My unfounded guesstimation for getting the boards back is end of September at the earliest.
    > Bertrand
    > -------------------------------------------------------------
    > Visit this STAR HyperNews message (to reply or unsubscribe) at:

    TOF NPS Maps

    This page hosts the mapping of TOF NPSs.

    MTD NPSs page can be found here:

    Version control:
    • list updated: February 4, 2021
    • includes MTD and eTOF NPS mappings

    NPS [login protocol] (comment)
    plug: name (comment) 

    sample instruction:
    apc>olStatus all
    E000: Success
    2: TOCK
    3: THUB_LVPS PL512 LV supply, also powers VPD
    4: ZDC_TCIM
    5: unused
    6: unused
    7: unused
    8: unused

    A1: CAEN_HV
    A2: UPS (tofcontrol & systec?)
    A3: Start-box fans (VPD)
    A4: TOF_THUB_fans
    B1: tofcontrol_pc
    B2: can_if_1-8
    B3: can_if_9-16
    B4: unused 

    tofnps1[telnet] (LV for west trays)
    1: trays_1-12_W1
    2: trays_14-24_W2
    3: trays_25-36_W3
    4: trays_37-48_W4
    5: trays_49-60_W5
    6: empty
    7: empty
    8: empty 

    tofnps2[telnet] (LV for east trays)
    1: trays_61-72_E1
    2: trays_73-84_E2
    3: trays_85-96_E3
    4: trays_97-108_E4
    5: trays_109-120_E5
    6: empty
    7: empty
    8: stp_conc_1 (cf. trigger group)

    1: MTD LV 1: 25-6
    2: MTD LV 2: BL 7-13, 24
    3: MTD LV 3: BL 14-22
    4: MTD-HV (CAEN)

    etof-nps [telnet]
    Plug | Name             | Password    | Status | Boot/Seq. Delay | Default |
     1   | _12V_LVPS-A      | (defined)   |   ON   |     0.5 Secs    |   ON    |
     2   | _12V_LVPS-B      | (defined)   |   ON   |     0.5 Secs    |   ON    |
     3   | mTCA-P13-Backup  | (defined)   |   ON   |     0.5 Secs    |   ON    |
     4   | mTCA-P11-Primary | (defined)   |   ON   |     0.5 Secs    |   ON    |
     5   | mTCA-P12-Primary | (defined)   |   ON   |     0.5 Secs    |   ON    |
     6   | mTCA-P14-Backup  | (defined)   |   ON   |     0.5 Secs    |   ON    |
     7   | _12V_LV-RKP-Chas | (defined)   |   ON   |     15 Secs     |   ON    |
     8   | RaspPi-LV-Cntrl  | (defined)   |   ON   |     15 Secs     |   ON    |

    BTOF Calibrations

    Barrel Time-of-Flight Detector Calibrations Overview


    TOF Calibration Requirements


    Links to several older calibration details with historical data

    Run 8 - 10 time resolutions
    Run 8 - 10 BTOF time resolutions

    TOF MRPC Prototype resolutions

     TOF MRPC prototype time resolutions

    Run 10 - 200 GeV Calibrations

    Run 10 Calibrations


    Run 10 200 GeV FF

    [This a test page for now.  Soon to be edited.]


    The calibration began with ntuples generated from a preproduction:

        log files on /star/rcf/prodlog/P10ih_calib1/log/daq

    The ntuples can be found:

    28 files (61810 events):
    316 files (2398210 events):
    77 files (497944 events) - not properly closed:

    The 77 files not properly closed were merged with hadd to properly close them.

    Then the ntuples were used for the start side(vpd) calibration.  The code package used for this is attached and can be found here:

    To run the start side calibration: ./doCalib filelist traynumber

    Tray number for start side can be any tray number, I recommend 0.   Start side calibration used a 20% outlier cut.  This can be selected in doCalib.cpp and changing the value pCut =0.20.

    The outlier removes the upper 20% of slowest hits--highest leading edge times.

     Produced from the start side calibration is pvpdCali.dat and pvpdCali.root.  These files are used to shift the vpdvz offset between the east and west vpd, and ultimately, the vpd's calibration parameters that are loaded into the database.  To shift the offset, perform a Gaussian fit to VzCorr2->ProjectionY() and take that mean value.  This is the VzOffset.   Apply it to the convertVpd.C macro ( on the line: 2454.21696153-VzOffset.  This macro generates pvpdCali_4DB.dat.  These are the parameters loaded into the database. 

    Now apply the shift to pvpdCali.root so that T0's are properly corrected for the stop side(TOF) calibration.   This is done with the code in this package:

    To run the code: use ./doCalib filelist traynumber .  The traynumber does not matter, use 0 again.  Be sure this is the same file list as before and that the generated pvpdCali.root and pvpdCali_4DB.dat files are in the same directory.  This way the VzOffset is applied.  An updated pvpdCali.root is produced.

     Typically, the pvpdCali.root is then used in the stop side calibration.  But because we are doing a cell based calibration, we wanted to increase statistics.  This caused an increase in IO from disk and delayed calibration since data for all trays is cycled over regardless of which tray is being calibrated.  To get around this, we used a splitting macro that reads in the ntuples and pvpdCali.root, and then it splits the ntuples into TDIG based files with the startside information stored with it.  The splitting macro is attached to this page here:

    The board based ntuples are then used to calibrate on a cell level for each board.  This is done with this code package:


    To run it: ./doCalib filelist traynumber boardnumber.  Here tray number is 0-119 and board number is 0-959.  It is important that the proper board is selected from the given tray number.  For example tray 0 has boards 0-7, tray 1 has boards 8-15 and so on.

    Produced among other files are tray_$tray#_board_$board#_$iteration#.dat files.  These files are added together for all trays and create the parameter files used for the database.  To add them together, the macros addZtdig.C, addT0Ttdig.C, and addt0tig.C were used( and generated zCali_4DB.dat, totCali_4DB.dat, and t0_4DB.dat respectively.  

    To check the produced calibration parameters, use a check macro that reads in matchmaker produced ntuples and applies the parameters (  The result is a .root file that can be used QA checking.  The macro needs to be edited to find the proper parameters and the proper name for an output file. It works with './checknew filelist_location'    In addition, there are other methods for QA checking.

    The calibration was performed over:

    Run #        -events
    > 11004071   -623835
    > 11009017   -497717
    > 11015019   -499030
    > 11020023   -500001
    > 11026034   -500001
    > 11035026   -699977
    > total:3320561 events.

    ---Issues that came up during the calibration procedure---

    First off is the outlier rejection.  Not inserting the outlier rejection in all stages of the start side calibration caused issues.  This was seen when shifting the T0s for the stopside calibration and in comparing different QA checking macros.  This can lead to 40ps differences in the time.  Also, there is  a slight difference in the way the outlier is handled in the calibration procedure versus the vpdcalibmaker.  This difference of T0s averages out over events to be on the order of 2-3 ps. We kept this difference in place for 200, because this method used in the  production of 39 earlier in the year.

       Other differences  include the selection criteria for events.  Needed to replace dcaZ with vertexZ since in heavy ion the primary vertex is filled and more reliable(dcaZ was used in pp where the primary vertex was not always filled).  Same with dcaX and dcaY to vertexX and vertexY respectively.  Also dropped the if(sqrt(pow(tofr->vertexX,2)+pow(tofr->vertexY,2))>rCut) cut.  This is because by selecting a primary vertex with vertexZ, this should have already been applied in order to be a primary vertex.


    Another minor one was in the QA macro calculating the vpdMean.  Turns out it was being handled incorrectly, but okay now.  Originally it looked like (bad structure):Old vpdMean

    And with the fix, it became:

    fixed vpdMean


    Run 10 200GeV RFF

    Place holder.  Two samples used.

    Run 11 - 19 GeV Calibration

    Place holder.  Board+cell based calibration.

    Run 11 - 62 GeV Calibration

    Place holder.  40ns.

    Run 17 calibrations

     Run 17 Calibrations

    Run 18 Calibrations

    Isobar Calibrations

    27 GeV Calibrations

    First Half ( days - 141)

    Second Half (days 142-168)

    • VPD calibration QA
    • BTOF alignment
    • BTOF T0
    • Comments:
      • BTOF slewing and Local-Z re-used from past full calibration (Run16)
      • calalgo=1 (startless mode, VPD is not used for the BTOF start time)

    Fixed Target Calibrations 

    Run 19 Calibrations

     Run 19 Calibrations

    19.6 GeV Calibrations

    • VPD Calibration QA
    • BTOF alignment 
      • xqa
      • yqa
    • BTOF T0
      • SummaryQA
    • Comments:
      • BTOF slewing and Local-Z re-used from past full calibration (Run16)
      • calalgo=1 (startless mode, VPD is not used for the BTOF start time)

    Fixed Target Calibrations 

    Run 20 Calibrations

     Run 20 Calibrations

    TOF/VPD Calibration How-To's


    Trigger Window Determination

    Here is documentation on how to determine the trigger windows for ToFs 120 trays and the 2 start detectors.

    I determined the trigger windows on run 13037090.  To do this, I used StRoot.tar.gz and extracted it to my work directory.  Then changed directory to StRoot/RTS/src/RTS_EXAMPLE and ran  This creates the executable rts_example from rts_example.C.  Both and rts_example.C have been customized from the typical StRoot version to translate information given in a .daq file into a useful .root file.  To run rts_example, I use run_test.csh.  This is essentially:

    starver SL11e

    rts_example -o tof_13037090.root -D tof inputfilepath/st_physics_13037090_raw_1010001.daq

    where tof_run#.root is your output file and .daq is your input file.

    Then the trigger windows are determined from the .root file by running over it with plot_trgwindow.C.

    To do this:


    .x plot_trgwindow.C("run#");

    run number is important because this is how the script knows to read in tof_run#.root.

    Produced is a .dat file that lists the high and low limits for each tray's trigger window and a postscript that shows the new limits in blue for each tray and if defined inside plot_trgwindow.C, red lines for the old trigger window limits(testrun11.dat in this example).

    Attached to this page is the StRoot.tar.gz package, run_test.csh, plot_trgwindow.C, old trigger window limits, new trigger window limits, and a postscript displaying the limits on top of the data.  (I put them in zip containers due to the file attachment restrictions.)

    VPD Slewing corrections for bbq & mxq


    1. Acquiring VPD gain setting data

    At the sc5.starp station, there are two GUIs on the upVPD monitor:

    "large GUI" shows all the channel values, and where one powers them on/off...
    "small GUI" selects between different gain sets A, B, C, & default...

    start with the VPD HV **off**

    once there is a decent non-VPD-based trigger and stable beam:

    1. on small GUI, click "! upVPD HV A" button
    2. on large GUI, click in lower left corner to power on upVPD HV
    3. wait until all channels are "green" (~20 sec).
    4. make sure the values (upper left corner of large GUI,
         leftmost column) are as expected
    5. wait ~1min for PMTs to settle (or take some other test run)
    6. start run: TRG+DAQ+TOF only, 300k events.
         use string "upVPD HV A" in the shiftlog entry
    7. power off HV (large GUI lower left corner)
    8. wait until channels reach 0 (~20 sec)

    9. on small GUI, click "! upVPD HV B" button
    10. on large GUI, click in lower left corner to power on upVPD HV
    11. wait until all channels are "green" (~20 sec).
    12. make sure the values (upper left corner of large GUI,
         leftmost column) are as expected
    13. wait ~1min for PMTs to settle (or take some other test run)
    14. start run: TRG+DAQ+TOF only, 300k events.
         use string "upVPD HV B" in the shiftlog entry
    15. power off HV (large GUI lower left corner)

    16. on small GUI, click "! upVPD HV C" button
    17. on large GUI, click in lower left corner to power on upVPD HV
    18. wait until all channels are "green" (~20 sec).
    19. make sure the values (upper left corner of large GUI,
         leftmost column) are as expected
    20. wait ~1min for PMTs to settle (or take some other test run)
    21. start run: TRG+DAQ+TOF only, 300k events.
         use string "upVPD HV C" in the shiftlog entry
    22. power off HV (large GUI lower left corner)

    23. on small GUI, click "! DEFAULT" button.
    24. power on the VPD HV. 

    Do not use the small GUI anymore. In fact, feel free to close it!

    At this point, I will get the data from HPSS, calculate the new gains, and then upload them to sc5. 

    make sure the shift log says which gain set (A, B, or C) was used for a given run 

    2. Calculate VPD Gains

    1. Get DAQ files containing gain fit runs
    Copied Run 160390{19, 22, 23} over from hpss : /home/starsink/raw/daq/2015/039/16039019/st_physics_16039019_raw_0000001.daq   /star/data03/daq/jdb/pp200/vpdGainFit/
    2. Running DaqDoer:
    ./daqdoer /star/data03/daq/jdb/pp200/vpdGainFit/st_physics_16039019_raw_0000001.daq
    What kind of Data?
    0=beam,  save trigger detector info, no trees...
    1=noise, save TOF/MTD hits trees, no coarse counter cut...
    2=beam,  save **MTD** hits trees, w/ coarse counter cut...
    3=beam,  no coarse counter cut for trigger time plots (TOF&MTD)...

    0->online->gainfit, 1->noise, 2->mtdview (_mtd), 3->thub (_tof)
    0 >> enter
    Enter run string for output file name
    (16039019) Run# >> enter
    let it work and it will produce a file daqdoer_***.root
    - Rename it to be daqdoer_run#.root if not already
    3. Run the Online Plot Maker
    - cd into online working dir
    - move daq files from daqdoer into dd/
    - ensure that daq files have name daqdoer_run#.root
    - run make to ensure online is fully built
    - Run online util with "-r run#" :
    ./online -r 16039019
    and output will be something like
    ..... Main ... krun = 16039019
    ..... online::online kRunUse = 16039019
    Error in <TTree::SetBranchAddress>: unknown branch -> p2p_sin
    ..... online::loop Opening online_16039019.root
    ..... online::loop Nentries = 300000
    1 Processing 0  run 16039019 16039019
    and it will produce 3 files 
    1. online_run#.root
    2. (example attached)
    3. online_run#.pdf
    Repeat this on the files from all 3 gain runs { A, B, C}
    4. Running gainfit.C Macro
    1. Copy from{A, B, C}.save to working dir
    2. Copy the online_run#*.root to working dir
    3. Open gainfit.C and change the run# in each filename to match the 3 you are using
    4. Run the GainFit.C macro: root -l gainfit.C
    - Will produce gainfit.root and (example attached )
    5. Export the newvpdhv to a text file with correct format
    6. Fill in the 6 tof only trays using the correlation plot on left of page 4 in - in the past this has ben roughly equivalent to adding ~160V to the hv calculated with <ADC> only. ( right now I am doing this step by hand but it would be better to write a script - TODO)
    7. The gains should undergo a sanity check - none should be too low or too high (above ~2100 V )


    5. Upload the gains to the auto-loaded file on
    - Make sure that the VPD HV is **OFF** before uploading - otherwise the HV values will not be set properly.
    - autoload location :
    6. Have someone ( lijuan’s team ) take new runs with the “good” gain settings to set the TAC and MXQ offsets.
    7. VPD is commissioned 

    3. Collect data for VPD Slewing corrections

    1. Data should be taken using a VPD based trigger
    2. For AuAu collisions ~ 100K minimum events are needed
    3. For pp200 ~200K events were needed
    4. As soon as the data is acquired (or even before ) make arrangments with Lidia for the fast offline production to be started. It needs to start immediately

    4. Perform VPD Slewing corrections for bbq & mxq crates

    1. Plot the TAC{East} - TAC{West} + 4096 vs. TPC vz to determine the TAC to ps conversion factor. Bbq and Mxq are not neccessarily the same - so check both.

    2. Create calibration tuples from MuDsts - these contain just the VPD data, TPC z vertex etc. that we need.
    Current tuple maker is at : /star/institutions/rice/jdb/calib/ntupler/

    3. Setup a config file for slewing corrections - set data uri, bbq or mxq datasource and output filenames for qa and parameters

    4. Run the slewing jobs 
    5. Check the QA and if there is time before uploading have Shuai check the resolution.
    6. Upload parameter files to in the ~staruser/ location with names like (m)vpd_slew_corr.<date>.txt for bbq (mxq)
    7. check the md5sums of the two files you just made and compare them to the original parameter files - sometimes the line-endings get scrambled
    7. Make a soft link from 
     (m)vpd_slew_corr.<date>.txt to (m)vpd_slew_corr.txt for bbq (mxq).
    8. Have Jack run the script to write slewing corrections to crates.

    5. Check VPD plots - if everything looks good then you are done

    QA from run15 pA200 is attached for the full statistics runs

    BTOF Offline Reconstruction

    BTOF Offline Reconstruction

    Known/solved issues:

    • P18ih (Run 9 pp500): TpcRefSys issue keeps BTOF geometry from getting correctly set up
      • this affects all runs before 2013 (see StBTofGeometry.cxx)
      • fixed in SL19d library
      • quick fix: run BTOF afterburner on MuDSTs to recreate BTOF matching and calibrations
    • SL17h/SL17i: Optimized libraries missing west BTOF geometry.


    PPV with the use of BTOF

    This area contains the study on the Pileup-Proof Vertex (PPV) finder with the use of hits from Barrel Time-Of-Flight (BTOF).



    This list the items that need to be implemted or QAed to include BTOF information in the PPV.

    Coding: - almost done, need review by experts

    1) BTOF hits (StBTofHitMaker) to be loaded before PPV - done

    2) BTOF geometry need to be initialized for the PPV - done

        As PPV is executed before the StBTofMatchMaker, I think in the future, the BTOF geometry will be firstly initialized in PPV in the chain and added to the memory. StBTofMatchMaker will then load this directly w/o creating its own BTof geometry.

    3) Creation of BtofHitList - done

        The BTOF part is rather segmented accroding to tray/module/cell, but BTOF modules don't have the same deta coverage. The binning is segmented according to module numbers.

        The justification of match and veto is different from other sub-systems as we now allow one track to project onto multiple modules considering the Vz spread and track curvature.

        Define: Match - any of these projected modules has a valid BTOF hit.   Veto - At least one projected module is active and none of the active projected modules has a valid BTOF hit.

    4) Update on TrackData VertexData to include BTOF variables - done

    5) Main matching function: matchTrack2BTOF(...) - done

        Currently, the match/veto is done at the module level. I set a localZ cut (|z|<3cm currently and also possibly remove cell 1 and 6 to require the track pointing to the center of the module). But this can be tuned in the future. Also whether we need to to match at the cell level can also be discussed.

    6) Update on StEvent/StPrimaryVertex, add mNumMatchesWithBTOF - done (need update in CVS)

    7) A switch to decide whether to use BTOF or not. - done (but need to add an additional bfc option)

    The lastest version is located in /star/u/dongx/lbl/tof/NewEvent/Run9/PPV/StRoot

    QA: - ongoing


    MC simulation study

    Default PPV for PYTHIA minibias events in y2009

    The first check is to test the default PPV and check whether the result is consitent with those from Vertex-Group experts.

    GSTAR setup

    geometry y2009

    BTOF geometry setup:  btofConfig = 12 (Run 9 with 94 trays)

    vsig  0.01  60.0
    gkine -1 0 0 100 -6.3 6.3 0 6.29 -100.0 100.0

    PYTHIA setup

    MSEL 1         ! Collision type
    MSTP (51)=7
    MSTP (82)=4
    PARP (82)=2.0
    PARP (83)=0.5
    PARP (84)=0.4
    PARP (85)=0.9
    PARP (86)=0.95
    PARP (89)=1800
    PARP (90)=0.25
    PARP (91)=1.0
    PARP (67)=4.0

    BFC chain reconstruction options

    trs fss y2009 Idst IAna l0 tpcI fcf ftpc Tree logger ITTF Sti VFPPV NoSvtIt NoSsdIt bbcSim tofsim tags emcY2 EEfs evout -dstout IdTruth geantout big fzin MiniMcMk eemcDb beamLine clearmem

    Just for record about the PPV cuts:

    StGenericVertexMaker:INFO  - PPV::cuts
     MinFitPfrac=nFit/nPos  =0.7
     MinTrkPt GeV/c =0.2
     MinMatchTr of prim tracks =2
     MaxZrange (cm)for glob tracks =200
     MaxZradius (cm) for prim tracks &Likelihood  =3
     MinAdcBemc for MIP =8
     MinAdcEemc for MIP =5
     bool   isMC =1
     bool useCtb =1
     bool DropPostCrossingTrack =1
     Store # of UnqualifiedVertex =5
     Store=1 oneTrack-vertex if track PT/GeV>10
     dump tracks for beamLine study =0


    Total 999 events PYTHIA mb events were processed. Among these, 990 events have at least one reconstructed vertex (frac = 99.1 +/- 0.3 %). The following plot shows the "funnyR" plot of the vertex ranking for all found vertices.

    Clearly seen is there are lots of vertices with negative ranking. If we define the vertices with positive ranking are "good" vertices, the left plot in the following shows the "good" vertex statistics

    Only 376 events (frac 37.6 +/- 1.5 %) have at least one "good" vertex. The middle plot shows the Vz distributions for MC input and the reconstructed first "good" vertices. However, if you look at the right plot which shows the Vz difference between reconstructed vertex and the MC input vertex, not only all good vertices are well distributed, most of any-found vertices even with negative ranking are within 1cm difference.

    If we define the "good" vertex is |Vz(rec)-Vz(MC)|<1cm, as Jan Balewski studied in this page: then 962 events (frac 96.3 +/- 0.6 %) have at least one "good" vertex.

    One note about the bfc log, I notice there is a message as the following:


     BTOW status tables questionable,
     PPV results qauestionable,

      F I X    B T O W    S T A T U S     T A B L E S     B E F O R E     U S E  !!
     chain will continue taking whatever is loaded in to DB
      Jan Balewski, January 2006

    The full log file is /star/u/dongx/institutions/tof/simulator/simu_PPV/code/default/test.log


    Update 9/10/2009

    With including BTOF in the PPV, please find the vertex ranking distributions below. (Note: only 94 trays in y2009)

    The # of events containing at least one vertex with ranking>0 is 584 (frac. 58.5 +/- 1.6 %). This number is more close to what I have in mind the vertex finding efficiency for pp minibias events. So the early low efficiency was due to missing CTB, while BTOF now is acting like CTB ???


    Update 9/22/2009

    After several rounds of message exchange with Jan, Rosi etc, I found several places that can be improved.

    1) Usually we use the BBC triggered MB events for study. So in the following analysis, I also only select the BBC triggered MB events for the vertex efficiency study. To select BBC triggered events, please refer to the code $STAR/StRoot/StTriggerUtilities/Bbc on how to implement it.

    2) Use ideal ped/gain/status for BEMC in the simulation instead of the pars for real data. To turn on this, one need to modify the bfc.C file: add the following lines for the db maker in the bfc.C (after line 123)

        dbMk->SetFlavor("sim","bemcPed"); // set all ped=0 <==THIS
        dbMk->SetFlavor("sim","bemcStatus");  // ideal, all=on
        dbMk->SetFlavor("sim","bemcCalib"); // use ideal gains

    These two changes significantly improves the final vertex efficiency (I will show later). The following two are also suggested, although the impact is marginal.

    3) Similarly use ideal ped/gain/status for EEMC.


    4) Use ideal TPC RDO mask. You can find an example here: /star/u/dongx/institutions/tof/simulator/simu_PPV/test/StarDb/RunLog/onl/tpcRDOMasks.y2009.C

    With these updates included, the following plot shows the # of good vertex distribution from 500 PYTHIA mb events test.

    The vertex efficiency is now raised to ~50%. (OK? low?)

    Just as a check on the BBC efficiency, here I accepted 418 events with BBC triggers out of 500 events in total. Eff = 83.6 +/- 1.7 %, which is reasonable.


    MC study on PPV with BTOF in Run 9 geometry

    This MC simulation study is to illustrate the performance of PPV vertex finder with BTOF added under different pileup assumptions. All the PPV coding parts with BTOF included are updated in this page.

    The geometry used here is y2009 geometry (with 94 BTOF trays). Generator used is PYTHIA with CDF "TuneA" setting. The details of gstar setup and reconstruction chain can be found here. The default PPV efficiency for this setup (with BBC trigger selection) is ~45-50%.

    The triggered event selected are BBC triggered minibias events. The simulation has included the TPC pileup minibias events for several different pileup conditions. The pileup simulation procedure is well described in Jan Balewski's web page.  I choose the following pileup setup:

    mode BTOF back 1; mode TPCE back 3761376; gback 470 470 0.15 106. 1.5; rndm 10 1200

    A few explanations:

    1. 'mode BTOF back 1' means try pileup for BTOF only in the same bXing
    2. '3761376' means for TPC try pileup for 376 bXing before , in, and after trigger event. TRS is set up to handle  pileup correctly. Note, 376*107=40 musec - the TPC drift time.
    3. gback is deciding how pileup events will be pooled from your minb.fzd file.
      • '470' is # of tried bXIngs back & forward in time.
      • 0.15 is average # of added events for given bXIng, drawn with Poisson distribution - multiple interactions for the same bXing may happen if prob is large. I choose this number to be 0.0001, 0.02, 0.05, 0.10, 0.15, 0.20, 0.30, 0.40, 0.50 for different pileup levels.
      • 106. is time interval , multiplied by bXIng offset and presented to the peilup-enabled slow simulators, so the code know how much in time analog signal needs to be shifted and in which direction.
      •  1.5 if averaged # of skipped events in minb.fzd file. Once file is exhausted it reopens it again. If you skip too few soon your pileup events start to repeat. If you skip too much you read inpute file like creazy
    4. 'rndm' is probably seed for pileup random pileup generator

    Here shows the results:

    • Vertex efficiency

    Fig. 1: Vertex efficiencies in different pileup levels for cases of w/ BTOF and w/o BTOF.

    Here: good vertex is definited as vertex with positiving ranking. real vertex is definited as good vertex && |Vz-Vz_MC|<1 cm.

    • # of BTOF/BEMC Matches

    Fig. 2: # of BTOF/BEMC matches for the first good & real vertex in different pileup levels.

    • Ranking distributions

    Fig. 3: Vertex ranking distributions in each pileup level for both w/ and w/o BTOF cases.


    • Vertex z difference

    Fig. 4: Vertex z difference (Vzrec - VzMC) distributions in different pileup levels for both w/ and w/o BTOF cases. Two plots in each row in each plot are the same distribution, but shown in two different ranges.

      pileup = 0.0001 pileup = 0.02 pileup = 0.05





      pileup = 0.10 pileup = 0.15 pileup = 0.20
    w/o BTOF



      pileup = 0.30 pileup = 0.40 pileup = 0.50





     To quantify these distributions, I use the following two variables: Gaussian width of the main peak around 0 and the RMS of the whole distribution. Fig. 5 and 6 show the distributions of these two:

    Fig. 5: Peak width of Vzrec-VzMC in Fig. 4 in different pileup levels.


    Fig. 6: RMS of Vzrec-VzMC distributions in different pileup levels.

    • CPU time

    The CPU time in processing pileup simulation grows rapidly as the pileup level increases. Fig. 7 shows the CPU time needed per event as a function of pileup level. The time shown here is the averaged time for 1000 events splitted into 10 jobs executed on RCF nodes. I see there is a couple out of these 10 jobs took significantly shorter time than others, and I guess this is due to the performance on different node. But I haven't confirmed it yet.

    Fig. 7: CPU time vs pielup levels


    Update on 12/23/2009

    There were some questions raised at the S&C meeting about why the resolution w/ TOF degrades at low pileup cases. However, as we know, including BTOF would increase the fraction of these events finding a good vertex. While this improvement is mainly on those events with fewer # of EMC matches that will not be reconstructed with one good vertex if BTOF is not included (see the attached plot for the comparison between w/ and w/o BTOF at 0.0001 pileup level). Events entering into Fig. 5 are any of those who has at least one good vertex. In the case of w/ BTOF, many events with only 1 or 0 EMCs matches can have one reconstructed vertex because of BTOF matches included. While tracks with small pT can reach BTOF easier than BEMC. So one would expect the mean pT of the tracks from these good vertices if we include BTOF would be smaller (not sure how big quantitatively), then resulting in worse projection uncertainty to the beamline, thus these event sample will have slight worse Vz resolution.

    I don't have a better idea to pick up the same event sample in the case of w/ BTOF as that in the case of w/o BTOF rather than I select the number of BEMC matches >=2 for the vertices that will be filled in my new Vz difference plot. Fig. 8 shows the same distribution as that in Fig. 5 but with nBEMCMatch>=2.


    One can see the change is in the right direction, but still it seems not perfect from this plot for very low pileup cases. I also went back to compare the reconstructed vertices event-by-event, here are some output files:
    /star/u/dongx/lbl/tof/simulator/simu_PPV/ana/woTOF_0.0001.log and wTOF_0.0001.log
    The results are very similar except a couple of 0.1cm movements in some events (I attribute this to the PPV step size). Furthermore, in the new peak width plot I show here, for these very low pileup cases, the difference between two are even much smaller 0.1cm, which I expect to be the step size in the PPV.


    Test with real data

    The PPV with BTOF included is then tested with Run 9 real data. The detail of the coding explanation can be found here.

    The PPV is tested for two cases: w/ BTOF and w/o BTOF and then I make comparisions later. The data files used in this test are (1862 events in total):



    (Note that in 500 GeV runs, many of the triggered events are HT or JP, presumably with higher multiplicity compared with MB triggers.) And the chain options used in the production are:

    pp2009a ITTF BEmcChkStat QAalltrigs btofDat Corr3 OSpaceZ2 OGridLeak3D beamLine -VFMinuit VFPPVnoCTB -dstout -evout

    Production was done using the DEV lib on 11/05/2009. Here shows the results:

    Fig. 1: The 2-D correlation plot of # of good vertices in each event for PPV w/ TOF and w/o TOF.

    Fig. 2: The ranking distributions for all vertices from PPV w/ and w/o TOF

    Fig. 3: Vz correlation for the good vertex (ranking>0) with the highest ranking in each event for PPV w/ and w/o TOF. Note that, if the event doesn't have any good vertex, the Vz is set to be -999 in my calculation, which appears in the underflow in the histogram statstics.

    Fig. 4: Vz difference between vertices found in PPV w/ TOF and w/o TOF for the first good vertex in each event if any. The 0.1 cm step seems to come from the PPV.


    Update on 4/5/2010:

    I have also run some test with the 200 GeV real data. The test has been carried out on the following daq file


    All the rest setup are the same as described above. Here are the test results:

    Fig. 5: The 2-D correlation plot of # of good vertices in each event for PPV w/ TOF and w/o TOF (200 GeV)

    Fig. 6: The ranking distributions for all vertices from PPV w/ and w/o TOF (left) and also the correlation between the funnyR values for the first primary vertex in two cases. (200 GeV)

    Fig. 7: Vz correlation for the good vertex (ranking>0) with the highest ranking in each event for PPV w/ and w/o TOF (200 GeV).

    Fig. 8: Vz difference between vertices found in PPV w/ TOF and w/o TOF for the first good vertex in each event if any (200 GeV)


    The above tests with real data have shown the expected PPV performance with inclusion of BTOF hits.


    BTOF Simulations


    Barrel TOF/CTB Geometry Configurations

    The definitions of Barrel TOF/CTB geometry configurations are shown here:

    BtofConfigure = 1;      /// All CTB trays

    BtofConfigure = 2;      /// All TOFp trays

    BtofConfigure = 3;      /// big TOFp path (trays from 46 to 60), rest are CTB trays

    BtofConfigure = 4;      /// Run-2: one TOFp tray (id=92), rest CTB

    BtofConfigure = 5;      /// Run-3: one TOFp (id=92) tray and one TOFr (id=83) tray, rest CTB

    BtofConfigure = 6;     /// Full barrel MRPC-TOF

    BtofConfigure = 7;      /// Run-4: one TOFp (id=93) tray and one TOFr (id=83) tray, rest CTB

    BtofConfigure = 8;      /// Run-5: one TOFr5 (id=83) tray, rest CTB

    BtofConfigure = 9;      /// Run-6: same as Run-5

    BtofConfigure = 10;    /// Run-7: same as Run-5

    BtofConfigure = 11;    /// Run-8: Five TOFr8 trays (id=76-80), rest CTB

    BtofConfigure = 12;    /// Run-9: 94 installed trays, rest slots are empty


    TOF selections in different geometry tags should be in the followints:

    year 2002:     Itof=2;    BtofConfigure=4;

    year 2003:     Itof=2;    BtofConfigure=5;

    year 2004:     Itof=2;    BtofConfigure=7;

    year 2005:     Itof=4;    BtofConfigure=8;

    year 2006;     Itof=5;    BtofConfigure=9;

    year 2007:     Itof=5;    BtofConfigure=10;

    year 2008:     Itof=6;    BtofConfigure=11;

    year 2009:     Itof=6;    BtofConfigure=12;

    All geometry in UPGRxx should use BtofConfigure=6 (full TOF configuration).

    TOF Simulation Resolution Database

        unsigned short resolution[23040]; // The BTOF time resolution for a given cell used in simulation.
        octet algoFlag[120]; // information about granularity of parameters 0-cell by cell, 1-module by module, 2-TDIG, 3-tray
    This table will be updated whenever the Calibrations_tof::* tables are updated, generally once per RHIC Run
    *table is not indexed
    The size of one row is 2*23040 + 1*120 = 46200 bytes (also verified by compiling and checking).
    Write Access:
    'jdb' - Daniel Brandenburg (Rice University)
    'geurts' - Frank Geurts (Rice University)
    See below the full .idl file
    /* TofSimResParams.idl:
    * Table: tofSimResParams
    * description: Parameters used to set the BTOF time resolution in simulation
    * author: Daniel Brandenburg (Rice University)
    struct tofSimResParams{
    unsigned short resolution[23040];         /* Cell Res in picoseconds*/
    octet algoFlag[120];             /* granularity of parameters*/
    /* End tofSimResParams.idl */


    These pages describe how to use the Barrel TOF (including VPD) database.

    One can use the following browser to view the TOF tables:

    More information on how to access the various (TOF) databases can be found in the Offline DB Structure Explorer at the following link:



    Add a flag in vpdTotCorr.idl for noVPD start calibration switch

    In low energy runs, the VPD acceptance and efficiency becomes a potential issue. We are planning to develop a barrel TOF self calibration algorithm based on only the hits on the barrel trays (we call it non-vpd-start calibration). The calibration constant structures should be similar as the conventional calibration using vpd for the start time. But certainly the algorithm in applying these constants will be different. We thus need to introduce an additional flag in the calibration table to tell the offline maker to load the corresponding algorithm then. The proposed the change is on the vpdTotCorr.idl table. The current structure is like this:

    struct vpdTotCorr {
      short tubeId;   /* tubeId (1:38), West (1:19), East (20:38) */
      float tot[128]; /* edge of tot intervals for corr */
      float corr[128];   /* absolute corr value */

    We would like to add another short variable "corralgo", then the modified idl file should be like this:

    struct vpdTotCorr {
      short tubeId;   /* tubeId (1:38), West (1:19), East (20:38) */
      float tot[128]; /* edge of tot intervals for corr */
      float corr[128];   /* absolute corr value */
      short corralgo;     /* 0 - default vpd-start calibration algorithm */
                                 /* 1 - non-vpd-start calibration algorithm */

    We will make the corresponding modifications to the StVpdCalibMaker and StBTofCalibMaker to implement the new calibration algorithm.


    Proposal of new TOF tables for Run9++ (Jan. 2009)

    We are proposing to create several new TOF tables for future full barrel TOF runs.

    Draft IDLs:

    /* tofINLSCorr
     * Tables: tofINLSCorr
     * description: // INL correction tables information for TOF TDIGs (in short)

    struct tofINLSCorr {
      short tdigId;         /*  TDIG board serial number id  */
      short tdcChanId;      /*  tdcId(0:2)*8+chan(0:7)       */
      short INLCorr[1024];  /*  INL correction values        */

    INDEX: trayCell [ table: trayCellIDs ], range: [1 .. 30000]

    Note: This table is an updated one from the previous tofINLCorr. Considering the considerable I/O stream load for this table in future full system, we changed the precision of the correction values from float to short (the value will be stored as (int)(val*100)). From the intial test, we won't lose any electronic resolution.

    /* tofGeomAlign
     * Tables: tofGeomAlign
     * description: // tof alignment parameters for trays, trayId will be
     *              // indicated as the elementID (+1) in data base

    struct tofGeomAlign {
      float z0;     /* offset in z */
      float x0;     /* offset in radius */
      float phi0;   /* offset in phi (local y direction) */
      float angle0; /* tilt angle in xy plane relative to ideal case */

    INDEX: trgwin [ table : trgwinIDs ], range : [1..122]

    Note: This table contains the necessary geometry alignment parameters for real detector position shifting from the ideal position in GEANT. The trayId will be indicated as the elementID in the database.

    /* tofStatus
     * Tables: tofStatus
     * description: // tof status table

    struct tofINLCorr {
      unsigned short status[24000];    /*  status code */

    INDEX: None

    Note: TOF status table. The definition of the status code is being finalized.

    /* tofTrgWindow
     * Tables: tofTrgWindow
     * description: // tof trigger timestamp window cuts to select physical hits

    struct tofTrgWindow {
      unsigned short trgWindow_Min;    /*  trigger time window cuts */       
      unsigned short trgWindow_Max;    /*  trigger time window cuts */

    INDEX: trgwin [ table: trgwinIDs ], range: [ 1 .. 122 ]

    Note: TOF trigger time window cuts to seletect physical hits. There will be 120 (trays) + 2 (E/W Vpds) elements in total.

    Load Estimate

    tofINLSCorr:  There will be one row for each channel. In total for full barrel system, there will be ~24000 rows. We also have some spare boards, to have all in one place, the maximum # of rows is better to set as 30000. The total load size for DB I/O will be ~30000*1024*2 Byte ~ 60 MB

    tofGeomAlign:  There will be 120 rows in each fill. The load size is negligible.

    tofStatus:    All channels are combined in a single array.

    tofTrgWindow:  120+2 elements.



    Shift Crew Documentation:
         * Run Control Documentation
         * Online JEVP Histogram Documentation

    RTS READER Documentation

    RTS_READER on Google Docs

    Detector Upgrades

    This Drupal section is reserved for R&D detectors. Each detector would
    be moved to the root area whenever ready.

    Event Plane Detector


    Event Plane Detector group:

    • Daniel Cebra (Davis)
    • Xin Dong (LBNL)
    • Geary Eppley (Rice)
    • Frank Geurts (Rice)
    • Mike Lisa (OSU)
    • Bill Llope (WSU)
    • Grazyna Odyniec (LBNL)
    • Robert Pak (BNL)
    • Alex Schmah (LBNL)
    • Prashanth Shanmuganathan (Kent)
    • Subhash Singha (Kent)
    • Mikhail Stepanov (Purdue)
    • Xu Sun (LBNL)
    • Aihong Tang (BNL)
    • Jim Thomas (LBNL)
    • Isaac Upsal (OSU)
    • Fuqiang Wang (Purdue)
    • Wei Xie (Purdue)
    • Rosi Reed (Lehigh)

    Available R&D funds: 30k

    R&D proposal:

    Task Responsible
    Timeline Resources
    GEANT4 simulation

    • Detector response function (input of different particles,
    • energies, angles, scintillator materials, scintillator
    • geometries, etc.)
    • Do we need wave length shifting fibres?
    • Light guides.
    Issac Upsal (OSU), Alex Schmah (LBNL) 08/14 - 09/14 none
    Tile geometry optimization

    • Minimizing the amount of different tiles.
    • Event plane resolution for new geometry.
    • Centrality resolution for new geometry.
    Subhash Singha (Kent)
    Mikhail Stepanov (Purdue)
    09/14 - 10/14 none
    Radiation tests of SiPMs

    • Estimation of expected radiation for BES II.
    • Comparison to BNL radiation tests (Akio).
    • Setup of radiation test for prototope detector.
    Daniel cebra (UCD)    
    Specifications of scintillators

    • Compare scintillator specs. 
    • Survey of possible vendors.
    Specifications of SiPMs

    • Compare SiPM specs.
    • Survey of possible vendors.
    • Survey of what other experiments have used.
    Setup of readout system

    • Simple readout system for basic tests.
    • Advanced readout system for prototype.
    • QT boards, PXL readout,...
    Setup of basic test system

    • Cosmic tests.
    • Test of readout system.
    • Comparison to GEANT4 simulation.
     Mikhail Stepanov (Purdue)    
    Development of wrapping technique

    • Optimized for  about 2000 tiles.
    Development of techniques to install wave length shifting fibres

    • + connection to light guides and/or SiPMs
    Mechanical construction for prototype

    • Two sector prototype.
    Integration into STAR trigger system

    • Survey of requirements.
    • Contact STAR trigger group.
    Trigger requirements (simulation/calculation)

    • For fixed target collisions.
    • Background suppression.
    Daniel Cebra (UCD)    

    Observable/Trigger Detector specification
    Fixed target  

    EPD Conference Files

    EPD presentations and posters for various conferences

    EPD meeting page

    This is the page for the EPD meetings. I suppose we could add a subpage for each individual meeting, that way only files relevant to that meeting would appear there.

    Isaac, work faster!

    EPD meeting April 13, 2016

    Agenda copied from Alex's email:

    Hi All,
    We have a brief EPD meeting today to discuss:
    - EPD review: To do (so far)
    - Fiber to SiPM coupling (status)
    - aob

    Attached is Isaac's talk on the SiPM board design.

    EPD meeting April 20, 2016

    EPD meeting April 20, 2016

    Hi All,
    We have our EPD meeting today:
    - Review report: Summary and to do
    - How to proceed with the proposal (to be submitted by May 5th)
    Title:          STAR Event Plane Detector Meeting
    Community:      STAR
     Meeting type: Open Meeting (Round Table)

     Meeting Access Information:
            SeeVoghRN Application
            Mobile App :  Meeting ID: 101 3768   or  Link:

    EPD meeting August 10, 2016


    EPD meeting July 20, 2016


    EPD meeting July 20, 2016


    EPD meeting July 20, 2016


    EPD meeting July 20, 2016


    EPD meeting July 20, 2016


    EPD meeting June 22, 2016


    EPD meeting June 22, 2016


    EPD meeting October 12, 2016


    EPD meeting October 12, 2016


    EPD meeting October 12, 2016


    EPD meeting October 12, 2016


    EPD meeting October 12, 2016



    This is a test page ...


    Preview of the 2006/12 review findings

    The panel recommends simulation
    and optimization of the following possible configuration, one of which should
    be chosen; either

    • Two layers of active pixel sensors followed
      radially outward by a layer of ALICE
      style pixels (the HPD) located at a slightly larger radius than its present
      location, followed by the existing STAR SSD.
    • Two layers of active pixel sensors followed
      radially outward by the IST1 and IST2 layers both at somewhat smaller radii
      than presently proposed, followed by the existing STAR SSD.

    In the event the existing SSD can
    not be counted on as part of the future mid-rapidity tracking system, the panel
    recommends the following configuration be optimized:

    • One IST layer (IST2) should remain approximately
      at its present location to recoup the functionality of the SSD. Inside this
      tracking layer, two layers of active pixel sensors should be followed radially
      outward by either a layer of ALICE
      style pixels at the present location of the HPD or a second IST layer (IST1) moved somewhat further in.

    Tracking Upgrade Review Material

    The TUP Review is scheduled for Dec. 7th, 2006, and will consist of material from the HFT, IST and HPD groups. The draft charge for the review will be similar to the HFT review charge, archived here: Tracking Review Committee Charge.

    The datasets for the upgrade reviews are archived here.

    Hit Occupancy
    Pion Efficiency (pt, &eta)
    Ghosting (pt, &eta, centrality, pileup)
    Pion Acceptance
    Hits X,Y
    Hit Occupancy
    Inter-hit distance (r,centrality)
    Cluster Finding Eff. (centrality)
    Residuals (r,eta,pt,z,centrality)
    DCA (pt,centrality,signal)
    Hit Occupancy
    Pion Efficiency (pt, &eta)
    Ghosting (pt, &eta, centrality, pileup)
    Pion Acceptance
    Hits X,Y
    Hit Efficiency
    Inter-hit distance (r,centrality)
    Cluster Finding Eff. (centrality)
    Residuals (r,eta,pt,z,centrality)
    DCA (pt,centrality,signal)



    Hit Occupancy
    Pion Efficiency (pt, eta)
    Pion Acceptance (pt, eta)
    Ghosting (pt, eta, centrality, HFT pileup)
    Hits X,Y * * * *
    Hit Efficiencies X,Y * * * *
    Inter-hit distance (r,centrality)
    Cluster Finding Eff. (centrality)
    Residuals (r,eta,pt,z,centrality)
    DCA (pt,centrality,signal)
    Secondary vertex Resolution
    (D trajectory verctor, phi, centrality)

    IST presentation

    Residual and Pull plots (HowTo)

    Sti has a nice utility for providing Pull and residual plots for all detectors. The chain option is "StiPulls". The resulting ntuple is written to the .tag.root file.

    Among other things, the ntuple stores the (position of the hit - position of the track) in the variables ending in "Pull". It should be noted that the variable contains this difference (or residual), and NOT the difference scaled by the error. This is left for the user. There are several branches of the pulls tree; one for global tracks, one for primary tracks, and one filled only during the outside-in pass of tracking.

    The outside-in pass is stored in the branch mHitsR, as described in Victor's post. The information stored here is the residual between hit and track positions, before the hit is added to the track. This information is useful for evaluating the progresion of the track error as the tracker steps in toward the vertex. It's also essential for those of us trying to evaluate potential detector configurations.

    So, to evaluate the track residual, on can simply use the root command prompt:

    root> StiPulls->Draw("mHitsR.lYPul>>residual","mHitsR.lXHit<5. && mHitsR.lXHit>2.2")

    This will give you a histogram "residual" which has residuals in &phi for hits from the inner HFT only ( 2.2cm< inner HFT < One can also use the detector id, which is also stored in the tree.

    For residuals as a function of Pt, one can try:
    root> StiPulls->Draw("mHitsR.lYPul:mHitsR.mPt>>residualPt","mHitsR.lXHit<5. && mHitsR.lXHit>2.2")
    This gives you a plot comparable to the pointing resolutions derived in Jim's hand calculations.

    This page is a compilation of posts to the ittf hypernews list (Victor's original post, Mike's requested changes, and Victor's response), as well as documents provided by the STAR S&C group (StiPullEvent, StiPullHit, and StiStEventFiller).

    Tracking Review Committee Charge

    The charge to the Review Committee for evaluation of the HFT proposal is archived here. The online document can be found under

    The Review Committee is asked to review the proposed tracking upgrades to STAR and to comment on the following:

    1. Scientific Merit: Will the proposed detectors significantly extend the physics reach of STAR? Is the science that will be possible with the addition of this upgrade sufficiently compelling to justify the proposed scope of the project?

    2. Technology Choice and Technical Feasibility: Are the proposed technologies appropriate, viable, and robust; are there outstanding R&D or technical issues which must be resolved before proceeding to a fully detailed construction plan covering technical, cost, and schedule issues?

    3. Technical specifications: Are the physics-driven requirements for this detector sufficiently understood, and will the proposed mechanical and electronics implementations meet those requirements? Is the proposed design reasonably optimized? Is the proposed scope of the upgrade justified by the physics driven requirements?

    4. Detector Integration: Is the impact of integrating this detector into STAR understood and manageable: are there potential "show-stoppers" with regard to mechanical support, utilities, cabling, integration into trigger, DAQ, etc.?

    5. Resources, Cost, and Schedule: Is the costing of the detector realistic; is the basis of estimate sound; has the full scope been included in the estimate; is the level of contingency realistic? Does there appear to be sufficient manpower to carry the project out successfully – including manpower for developing calibration and analysis software? Is the technically driven schedule achievable?

    eTOF Proposal

     A proposal to install CBM TOF detectors on the east pole tip for BES-II


    an Upgrade to Inner Sectors of STAR Time Projection Chamber

    proposal draft (with link to bookpage)

    SDU iTPC blog (Qinghu Xu)

    Chinese iTPC project (part of Project 973 for RHIC physics)


    STAR TPC 2003 NIMA paper

    mailing list: (

    September 2016 NP iTPC review

    September 2017 DOE Progress Review

      A talk on the iTPC was given to the instrumentation group on December 03 by FV. The talks is attached to this page.




    An upgrade to Inner Sectors of Time Projection Chamber

    The iTPC was developed into a proposal. The technical design report is available as a STAR note SN0644.

    Historical remarks:

    We propose to upgrade the inner sectors of the STAR TPC to increase the segmentation on the inner pad plane and to renew the inner sector wires which are showing signs of aging. The upgrade will provide better momentum resolution, better dE/dx resolution, and most importantly it will provide improved acceptance at high rapidity to |eta|<1.7 compared to the current TPC configuration of |eta|<~1.0. In this proposal, we demonstrate that acceptance at high rapidity is a crucial part of STAR’s future as we contemplate forward physics topics such as p-A, e-A and the proposed phase II of the Beam Energy Scan program (BES II). Unlike the outer TPC sectors, the current inner TPC pad row geometry does not provide hermetic coverage at all radii. The inner pads are 11.5 mm tall yet the spacing between rows is variable but always greater than 5 cm, resulting in "missing rows". Approximately, only 20% of the path length of the charged particle traversing the TPC inner sector has been sampled by the electronics readout.  

    internal review: 


    New Electronics

    Mechanic design of strongback

    optimize strongback for more electronics readout channels and for reducing materials.

    Drawings from the original TPC design

    prototype iTPC strongback machining at UT Austin:
    machining strongback 10/15/2013

    TPC insertion tool:

    Multiple Wire Proportional Chambers

    Fabrication of wire chambers

    Pad size vs anode wire distance to padplance  
    STAR Note #0263

    Design of a prototype mini-drift TPC at SDU:

    tools for measuring wire tension:

    wire tension parameters:

    Physics motivations

    Searching for the possible tri-critical point in the QCD phase diagram is one of the major scientific tasks in heavy-ion physics.

    Elliptic flow of identified particles has been used to study the properties of the strongly interacting Quark-Gluon Plasma.

    Directed flow (v1) excitation functions have been proposed as promising observables for uncovering evidence of crossing a first-order phase transition, based on hydrodynamic calculations.

    In addition to the above highlights of physics impact of the iTPC upgrade, the upgrade improves the tracking efficiency at low momentum.

    The upgrade also significantly enhances STAR’s physics capability at RHIC top energy. The improved dE/dx resolution allows better separation of charged kaons and protons at high momentum.

    BES II

    Project Schedule, Cost and Management

    This page have been repurposed to be the main page for management for the iTPC that was approved as a BNL Capital 
    project (< 5M%$). The subpages will contain the main point for iTPC manegement. The old pages have been deleted at this point.

    Cost and Schedule

    Following the DOE review the project files are being updated.

    November 20, 2016
    Draft milestone table from current WBS  excel file 
    The greyed out lines are poposed not to be in the Project Management Plan

    Older files:
    Management Forms from BNL; Project and cost files
    The cost spreadsheet is from March 21, 2016. The numbers are used in the project management plan

    Management plan and other documents

    Project Management Plan: 
    Version 12: updated version for September review.
    Verdion 20: updated with KPP and clarification- changes since December marker in red.
    Version 21: updated org chart  (Feb 2018)


     Reports quarterly.


     Reports quarterly.

    ES&H reviews

     The material here is from several ES&H reviews and their follow ups.

    compiled by Robert Pak 8/15/17

    Attached is a folder of documents regarding safety reviews with C-AD you requested for distribution to DOE.  There were the following meetings (additional internal meetings and discussions with vendors occurred that are not included here):
    i) ASSRC meeting on March 8th (Robert presented for Rahul).
    ii) Engineering review of the installation platform on March 29th (Rahul presented remotely).
    iii) ESRC meeting on May 8th (Flemming and Tonko presented).
    iv) ASSRC meeting for enclosure with fire safety engineer on August 4th (Robert presented).
    v) Installation platform inspection by C-AD on August 15th (no formal presentation).

    Upcoming meetings include:
    i) Meeting on tests in the clean area.
    ii) ESRC meeting once power requirements for the new detector are finalized.
    iii) ESRC walk through before turn on.

    October 2018 DOE NP review

     Review was held at BNL

    Here are the final reports

    September 2016 iTPC NP review

    The review was held on September 13 & 14 in Washington DC
    All the talks and background material is available at the BNL indico page 

    The closeout report will be posted once finalized.
    I already extracted the recommendation and the comments that needs some action. Note it is preliminary since we do
    not have the final report, but it should still beuseful. See attachment. (9/20/16)

    The final close-out report was received on 12/14/2016 nd attached to this page. See list below

    • cover letter
    • excert from reviewers (personal comments)
    • final report

    The talks from the Jan 2016 Directors review are on the BNL indico page

    Response to recommendations

    1. Update on KPP -- we asked for more time on this which was granted
      We are suggesting a path forward for adding a KPP that reflects that the UPP dE/dx is achievable. At the review it was suggested, for example, to use the width from using signal from an 55Fe source. 

      The connection between observed resolution of an 55Fe source and final dE/dx is not trivial. The resolution of the source does e.g. depend on how the signal is read out e.g. via the pads or the wires. 

      We are pursuing this by simulations of MWPC response to 5.9 KeV electrons, by reviewing historical records since part of the original acceptance criteria was a scan of all sectors with sources, and investigating the just started tests with 55Fe source and X-ray gun at SDU, all to understand what the ideal response to stand alone measurements would be.

      We hope you will agree to such a path forward and the plan is to aim for having a quantified proposal by January 30 2017 for this KPP. Enclosed are the suggested table, and text.  

    2. Workforce for installation etc  main document
      1. workforce spreadsheet
    3. Lessons learned from previousconstruction
      1. Document (word) the double click does not work on mac OS
    4. Updated Project Management Plan with new milestones and resource loaded WBS
      1. The pdf of the updated WBS is here
      2. My comments to request and recommendation
    5. iTPC testing and commisioning plan September 2017

    Background Material for Review

     The requested material will be collected here. For now it's the list that can be updated

    • TDR (November 2015)  SN0644 
    • Review report for Directors review (Jan 2016)
    • Response to review (Feb 15 2016)
    • Risk assesment Plan (November 2015)
    • Q&A Plan and procedures
    • Project Management Plan (pdf)

    iTPC review responses

     The first response was by Oct 15 to provide an updated KPP. The repsonse that was send in is attached here

    By November 1 we have to provide a workforce plans

    The iTPC group should work with RHIC management to anticipate and identify workforce needs for construction, installation, and commissioning and develop a plan to mitigate any schedule risk due to a lack of technical and mechanical support personnel.  Submit the workforce plan to DOE by November 1, 2016.

    I have worked with a few members of iTPC and STSG to come up with the first estimates. These are contained in two documanents
    one describing the activities, and a second with a summary of resources. Its not yet complete.
    See the attached documents.

    The second items is

     Generate a Lessons Learned document from the construction and commissioning of the original STAR TPC and submit to DOE by November 1, 2016.

    This has been discussed  and Jim proposes to generated a document with the many-many presenteation that we have assembled, and write an introductionary 
    document.  This may actually serve us well to assemble all this material in a coherent fashion.
    Document was submitted on time

    The testing plan was submitted to DOE in mid September 2017 ahead of the  yearly review.

    September 2017 DOE NP yearly progress review

     Meeting will be a BNL in room 2-160.

    The call for review is the content of an e-mail send to me by Cassie Dukes of the NP office.

    The talks for the review is on the BNL indico pages.

    The final report was received in December 2017, and is included here

    iTC Risk assesment

    Nov 30, 2015

    A draft version of the risk assesment has been assembled and is available for
    comments  draft  

    This page will also have some of the background of the iTPC risk assesment.

    1. Letter from Berndt Mueller  (word file)
    2. Draft Charge from Zhangbu (pdf)
    3. Risk Analysis Plan - Draft template from the Late Ralph Brown (word)

    Background material

    iTPC Directors Review Jan 2016

    January 2016 Presentations on BNL Indico site


    This page will be used to keep track of note, documentation need for preparation of the review.

    1. Jim Thomas comments to the Schedule as on Dec 11. 
    2. Further comments from Jim, and action from Flemming (word file)
    3. Comments from Blair on cleanness, HV and water systems.
    4. The most recent pdf print of the project file is here
    5. Unfortunately I cannot attach the MS project file- drupal does not allow that

    QA page and documents

     This page contains the sector assembly QA schedule

    1. Pdf version of project file
    2. Project file (cannot be uploaded to drupal!)
    3. Sector assembly (and QA steps from Qinghua word file

    iTPC QA

    This page and the child page will contain information on the QA of sectors, organized by sector number
    SN1001 is the prototype  SN00xx the production ones.

    7/19/18 Added the daily test activity summary file. The daily updates are written by Qian, an has all entries in the file with the most recent first.

    Latest version  8/26/2018

    Hanseul made a nice webpage that  shares all update on the iTPC testing.

    The traveller that is used for pre installation checks is attached to the page.

    Summary of sector status  9/20/2018. A summary of problem sectors that should be considered as spare,
    and not installed. Powerpoint File.

    10/15/2018 screenshot of testing status at BNL

    The material in the child pages are copies of the LBNL google pages, and additional analysis results that may have ben performed.

    The LBL assembly instructions including check points is attached
    The work at LBNL is completed as per 5/16/2018 and last sectors send to SDU

    6/6/2018 : A pdf version of the final filled out smartsheet is saved here

    6/6/2018: Jim  and Howard have analyzed all the survey measurements. The spreadsheet that summarizes the results is attached here.

    The Chinese travellers are updated to Quinghua's blog page

    The travellers for testing at BNL are posted on

    Travellers from the pre-installation check saved under each SNXXXX folder.
    ITPC status  10/15/2018 . All sectors at BNL checked

    The two failed sectors SN0027 and SN0020 had separated in wide corners. Look fo repairs at LBL.
    SN0024 failed the very sensitive He-leak test at LBL vacuum was 10-4 above the limits. It can be shipped to SDU
    and see if it passes the Ar sniffer test.
    SN0028 had failed complete along long edge. May be difficult to repair should be set aside.

    The article 31-36 are the additional strongbacks to be bonded. Padplanes on, sidemount done. Waiting for final machiung, CMM and cleaning.
    It is believed that SN0012, SN0027 and SN0021 are repairable, planned to be done during feb-March until the strongbacks arrive from IMT

    Washing procedure changes ; double check vacuum, refill with glyptal.

    The padplane connectivity and checkout QA is in the summary attached, and provide a list of all pad planes (34) inspected and the summary from the
    QA sheets used during inspection

    Reports on various issue, found and resolved. This is work in progress

    January 3, 2018
      Report on shipping temperature for SN 1001

    December 15, 2017
      Report on 2 FEE slots in SN0025 blocked by epoxy    

    February 2, 2018

    De-bonding of PCB to Al  (GG wire) SN0015    

    March 21, 2018
     Report on pad plane drilling survey at LBL for last 7

    March 4, 2018
     Report of shifted GG board on SN0012

    April 3, 2018
    Report of grounded pins on ABDB board on SN0008

    Shipping of sectors

    August 2018  SN0014,1715 and 10
    The temperature from the USB file.
    The box was opened on August 2.
    The pdf of the graph is here.

    September 18 SN0001, 17, 31
    Temperature from sensor for shipment

    Article 7 SN0020


    Article 16 SN0012

     This sector had a serious oversight during bonding resulting in a grounding wire caught below the pad plane.
    As the wire is 600 microns think there is no way the flatness and bonding with expoxy which is only ~100 microns can be good.
    Project have rejected this sector.

    Article 17 SN0019


    Article 18 SN0025


    Article 19 SN0015


    Article 20 SN0014


    Article 20 SN0014

     Docs from LBL assembly

    Article 21 SN0010


    Article 21 SN0010


    Article 22 SN0017


    SN0018 (Article 24)


    SN0031 article 31


    article 6 SN0026

     QA from SDU


    article 1 prototype SN1001

     QA files for article 1.

    article 10 SN0028


    article 11 SN0024


    article 12 SN0029

    This sector was found at SDU to have the right GG side mount out of spec, just at limit where the
    wire would touch the side mount surface
    The figure shows the measurements from SDU and LBL CMM for righthand GG sidemount
    The difference is understood due to way measurements are done 30-50 microns 

    A copy of the SDU traveler is at this location 

    article 13 SN0030


    article 14 SN0021


    article 15 SN0011


    article 2 SN0009

     QA infor from LBL and analysis

    QA from SDU

    LBL spreadsheets etc as attachments

    article 3 SN0006

    Traveller from SDU production link to Qinghua's blog

    article 4 SN0022

     LBL survey info
    SDU scanned production traveller (upkoad 10/8/2017)

    article 5 SN0027

    The sector was rejected due to separated plane 8/16/1017 -- returned to LBL

    The QA travellers from SDU

    article 8 SN0023

     QA from SDU


    Sn0023_test results.pdf

    article 9 SN0016

     QA from SDU


    1. Right side of anode wire mount apart from strongback about 5cm -- repaired at SDU
    2. two tapered pins extruded ~2mm beyond the side wire mount
    3. 5 pins of LOAB missing/broken repaired at SDU
    4. leakage found on 8 feed-through boards - re-epoxied
    5. Two fat wires used  75um BeCu wire used instead of 125 by mistake no effect from simulation by Irakli

    iTPC Quarterly Reports

    In this page I will also keep the slides for the monthly phone conferences with DOE, as well as brief minutes

     It is organized according to WBS. The lead people for each section is given here.

    • Project Management  --  Flemming
    • Padplane -- Flemming 
    • Mechanics-Strongback -- Flemmig
    • Mechanics -MWPC -- Qinghua
    • Integrations & installation R-- Robert
    • Electronics -- Tonko
    • Software - Irakli
    • Other activities -- Flemming

    Flemming is responsible for the reports as such.

    In general the report should be completed by mid-July, mid-October ,etc...

    Quarterly reports

    Monthly phone conferences

    iTPC brief reports and presentations

     Page to keep track of various brief notes, documents for iTPC


    May 24, 2017   Gain measurements on prototype MWPC at SDU - pdf
    May 18, 2017   Notes on assembly issues for article 2, 3 side mounts - word document
    April 28, 2017  Notes on broken pins - article 2  word document

    Aug 22, 2017 Brif update on status at SDU (FV) presentation

    iTPC closeout review May 2, 2019

    Final report and experts from the review were received on August 1, 2019
    The three documents have been attached 
    cover letter
    Review report  
    Excerpts from reviewers


    The material for the closeout review including talks are all on

    On this page I added the 3 final documents: close-out report, lessons learned, and the transitions to ops.
     The close out review for STAR has been scheduled for May 2. The notice from DOE is enclosed here
    This page will be used for the preliminary material, Final talks and material will be put on a BNL indico page
    as we did for the previous reviews.

    As the iTPC project is neither an MIE no a project for the CD process, I believe the requested closeout and transition to ops documents
    can be fairly brief.

    -- notes from DOE NP

    As you know, the dates for the STAR iTPC Project Closeout/Transition to Operations Review has been confirmed for May 2, 2019. Attached, please find a list of the reviewer panel and anticipated DOE participants. For your information, the web-conference info is included below for distribution to the panel via the review website.


    Join from PC, Mac, Linux, iOS or Android:


    And/or join by phone:


        +1 646 876 9923 (US Toll) or +1 669 900 6833 (US Toll)

        Meeting ID: 737 668 005


    Note: with the ZOOM web-conference, if the equipment you are using is not equipped with a microphone, you will need to use the link to log into the meeting to share/view presentations, as well as call-in via phone for voice participation.


    Please draft an agenda and a list of proposed documents to be sent to the review panel prior to the review  (for example, previous review report, response to DOE Review Recommendations, etc.). Please note: background documents should also include a draft Project Closeout Report, draft Transition to Operations Report, as well as a draft lessons learned document.  Once the draft agenda and the list of proposed documents have been prepared please send this input to me for comments – I will collect comments from all applicable individuals within the NP office and will iterate with you on the agendas to ensure all topics are covered. Once the materials have been finalized, please make the background materials, as well as presentations, available to review participants in electronic form as soon as possible but no later than two weeks prior to the review (presentations can be made available at a later date, however, we request no later than 5 days prior to the review).

    The panel members are in the attached document

    -- as previous e-mail the charge for review content is

    Please hold May 2, 2019 for the Project Closeout/Transition to Operations Review of the STAR iTPC. We are happy to schedule the meeting as early as possible, however, this is likely to be one-day starting no earlier than 9:00 am ET with an executive session, 9:30 am ET for presentations to start. For your information, suggested topics for talks and the schedule for the one day close out meeting would be as follows:


    -              Project status and deliverables

    -              Project commissioning results 

    -              Cost and Schedule

    -              Management and Safety issues

    -              Transition to operations

    -              Working lunch and executive session to write a few page report

    -              Close out   (early afternoon, between 2-3 pm)

    I should point out all t6he charge bullets is what any project from 5M$ and up is subject to.

    iTPC meetings

    A child page maintains a list of all tpc meetings and the technical meetings held
    for integration , installation. Some presentation are listed on that page

    The meeting summary up to October 2015  
    was kept in Quingha's blog page here

    For meeting related to safety see

    Electronics Production Readiness Review

     An iTPC production readiness review was held on January 22, 2018

    The agenda was:
    the review will take place tomorrow at 1 pm EDT at 1-224 in the physics department.
    Introduction 10 min  F.Videbaek
    Electronics   40 minutes  Tonko Lubicic
    Discussions; questions and answers 20 min
    Commitee discussions 40 min

    The committee will write a report to be send following the meeting to the iTPC group.
    Report was received on January 23, 2018

    iTPC minutes

     The following regular meetings are being organized for the project
    • Weekly iTPC meeting for all interested. Wednesday's at 10.30 am;  9.30 when standard time
      • The agenda is usually mgt updates, report on electronics, SDU, mechnics
      • The integration , installation is usually discussed primarely at the Monday meetings
    • Meeting info updated onMay 15; We are havig continuous problems with eZuse and go to BlueJeans
    • Phone Dial-in
      +1.408.740.7256 (United States)
      +1.888.240.2560 (US Toll Free)
      +1.408.317.9253 (Alternate number)
      (Global Numbers)

      Meeting ID: 832 810 289
      Moderator Passcode: 6253 

      Room System or

      Meeting ID: 263 878 370
      Moderator Passcode: 6253

      weekly iTPC for status updates

    • The mechanical meeting series is complete with the final installation of all sectors on October 2018
    • Bi (or weekly)  weekly meetings of internal iTPC working group to define, and follow up on mechanics, and installation. Currently on Mondays at 1.00 pm.Meet in 1006 using the STAR ops standing eZuce reservation. Minutes attached (latest update 7/7/2016) from earlier meeting. The individual meetings will show up in list below here from. Meeting is led by Robert Pak, with engineers, techs,  physicist and from BNL and LBL, and minutes written by him.
      • August 30, 2018 minutes
      • April 19, 2018 minutes
      • April 12, 2018 minutes
      • March 15, 2018 minutes
      • March 8, 2018 minutes
      • February 22, 2018 minutes
      • February 12, 2018 minutes
      • December 18,2017  minutes
      • December 11, 2017  minutes
      • December   6, 2017 minutes
      • November 20, 2017 minutes
      • November 13, 2017 minutes
      • November 6, 2017 minutes
      • October 30, 2017 minutes
      • October 23, 2017 minutes
      • September 25, 2017 minutes 
      • September 11, 2017 minutes
      • August 28, 2017 minutes
      • August 21, 2017 minutes
      • August 14, 2017 minutes
      • August 7, 2017 minutes
      • July 31, 2017 minutes 
      • July 24, 2017 minutes (installation plan, clean room, spreader bar)
      • July 17, 2017, minutes (insertion tool, platform, clean enclosure, clean room)
      • July 10, 2017, minutes (Clean enclosure, AOB)
      • June 26, 2017 minutes
      • June 19, 2017 minutes
      • June 5, 2017 minutes
      • May 22, 2017 minutes
      • May  8, 2017 minutes
      • April 24, 2017 minutes
      • April 10, 2017 minutes
      • March 27, 2017 minutes (sideboards,LBNL activity, Mark update, Rahul installation)
      • March 13, 2017 meeting (LBL progress, items to ship,  testchambers)
      • February 27, 2017 meeting (QA pad planes,anode wire mounts, Update from Mark,Canary Chamber, Shipping containers)
      • February 13, 2017 meeting 
      • January 23, 2017 meeting (QA padplanes, wiremount cleaning, update LBNL)
      • Janunary 9, 2017 meeting (QA padplanes, wiremount cleaning, tooling LBNL, canary tests)
      • December 12, 2016 meeting (padplanes sidemounts canary tests insertion tooling)
      • November 28, 2016 meeting
      • November 14, 2016 meeting
      • October 31, 2016 meeting
      • October 17, 2016 meeting
      • October 3, 2016 meeting (padplane, combs, wiremounts, inventory, shipping containers canary chamber, installation platform kickoff)
      • September 19, 2016 meeting
      • August 29, 2016 meeting (padplane, report central shop, insertion tooling)
      • August 1, 2016 meeting (strongback inspection, combs, assembly inventory)
      • July 18, 2016 meeting    (strongback production, wire mounts, wire combs, insertion tooling)
      • July  5, 2016   meeting  (strongback QA, canary chamber, insertion tool, padplane)

    iTPC run18 progress

     The page will contain material presented at the itpc software meetings,
    or circulated with the group. Material will be in reverse order
    The meeting will be on Mo and Th 11 in general.
    The bluejeans information is

    Phone Dial-in
    +1.408.740.7256 (United States)
    +1.888.240.2560 (US Toll Free)
    +1.408.317.9253 (Alternate number)
    (Global Numbers)

    Meeting ID: 634 285 245
    Moderator Passcode: 6253 

    Room System or

    Meeting ID: 634 285 245

    April 23, 2018 A few pictures comparing iTPC and TPC by Yuri

    April 18, 2018 Update on Gain on iTPC  (Tonko)

    April 16, 2018 Further analysis of clusters and distribution (Flemming)
    File on Monday meeting

    March 29, 2018
    Analysis of 86040  . Charge distribution plots

    Entry April 2, 2018/ update by 4/8/18

    Adc vs pad for different rows (FV)

    Yuri' update after gating grid leak fix 

    Entry March 29,2018 

    Charge distribution per row for inner sector The profile has been fitted with a landau distribution

    Similar plot for the outer sector

    March 2018  Tonko analysis of iTPC pulser run



    Archived Endcap web pages for years 1998 -2008 at MIT 'locker'


    New place for Endcap 'unprotected' analysis

    2007 run, hardware changes



     April 4, 5 pm, no beam: 

    We would like ETOW tcd phase set from 12->19 and EMSD from 55->65 , Jeff implemented it

     Will's new table (to be implemented)

                     TCD      box dec     box hex
               1.     19        18          0x12
               2.     19         8          0x8
               3.     19        86          0x56
               4.     19        80          0x50
               5.     19        43          0x2B
               6.     19        31          0x1f

    For EEMC MAPMT -- rather than change all 48 box configs we could
    start out by just adding 10 ns to the phase: 55 -> 65.

    new Tower config files in /home/online/mini/tcl/ you'll have to change symbolic links
           tower-1-current_beam_config.dat ->
     Jim: after 8094053 should have the new tcd phase and box configuration
    The night shift took a 300k calibration run with the ETOW and ESMD Run 8095061
    There is a shift log entry as to the run numbers and conditions.
    I shifted only the tcd phase and used the new FEE configs installed
    yesterday. This should show fall off by ~10-20% on each side in towers
    and flat in MAPMTs.

    run ETOW tcd ESMD tcd
    8095096 19 65 30k std config, for 1st daq file ETWO head=off
    8095097 1 55 30k
    8095098 7 60 30k
    8095099 13 60 30k
    8095100 25 70 30k
    8095101 31 75 30k
    8095102 19 65 100k std config
    8095103 19 65 0k std config died

    8095104 19 65 28k std config

    ------ April 12----
    I've made these changes in 2007Production2, 2006ProductionMinBias &

    a. UPC ps --> 3
    b. bht1 thresh --> 16
    c. raised all triggers to production
    d. changed all triggers based on zdc to different production ids


    2008 run preparation

    Timinng curves for ETOW & ESMD

    Timing Scan 11/23/2007

    Timing Scan 11/23/2007

    EEMC timing scan was taken on11/23/2007.

    To generate the curves, log into your favorite rcas node and

    $ cvs co -D 11/27/2007 StRoot/StEEmcPool/StEEmcTimingMaker

    and follow the instructions in the HOWTO

    $ cat StRoot/StEEmcPool/StEEmcTimingMaker/HOWTO.l2ped

    (tried to post code, but drupal wouldn't accept it...)

    Will's notes on crate configuration:

    FYI here are some (old) notes on how I set up config files
    for EEMC tower timing scans that were taken a few days back (BTW,
    these configs are still loaded).

    1) Old running settings -- config files are on eemc-sc in directory
    /home/online/mini/tcl with symbolic links:
    tower-"n"-current_beam_config.dat ->
    We had (I believe) been using directory 04.04.07 for the run with
    ETOW TCD phase of 19; crate fifo (RHIC tic) 0x13. Those crate delay
    settings are:
    1 -> 0x12; 2 -> 0x8; 3 -> 0x56; 4 -> 0x50; 5 -> 0x2b; 6 -> 0x1f

    2) new scan settings ... for time scans using only TCD phase
    we usually create special config files with approprieate box delay and
    TCD values.

    nominal (ns) for (eff RHIC tic
    run 7 scan ns)

    1 -> 0x12 (18) 0x5a (-17) fifo 0x14 (e.g., 107-90)
    2 -> 0x8 ( 8) 0x50 (-27) fifo 0x14 (e.g., 107-80)
    3 -> 0x56 (86) 0x42 ( 66) fifo 0x13
    4 -> 0x50 (80) 0x3c ( 60) fifo 0x13
    5 -> 0x2b (43) 0x17 ( 23) fifo 0x13
    6 -> 0x1f (31) 0xb ( 11) fifo 0x13

    Here we have shifted crates "earlier" in time: 1&2 by 35 ns and
    rest by 20 ns.Starting TCD scan at 5 then should start things
    ~ 34 (49) ns earlier than nominal with ~ 70 ns for scan to run
    (suggested TCD: 5,10,15,25,35,45,55,65,75,70,60,50,40,30,20,10)

    ETOW tcd phase delay
    N events
    8327013 5 136k
    8327014 15 20k
    8327015 25 20k
    8327016 35 20k
    8327017 45 20k
    8327018 55 20k
    8327019 65 20k
    8327020 75 20k
    8327021 70 20k
    8327022 60 20k
    8327023 50 20k
    8327024 40 20k
    8327025 30 20k
    8327026 20 20k
    8327027 10 20k

    Figure 1 --Integral from ped+25 to ped+75, normalized to total number of events, versus TCD phase delay.

    Channel-by-channel plots are attached below.

    Timing Scan 11/27/2007 (MuDst)


                Posted results are from MuDst data of 17 runs with 50K events in each run.


                  1,     ShiftLog Entry   

                  2,    Run Summary

                          Run                    ETOW & ESMD phase (ns)                # of Events (K)  

                          8331091                               5                                             200

                                 1092                            15                                              200

                                 1094                            25                                              200

                                 1097                            35                                              200

                                 1098                            45                                              200

                                 1102                            65                                              200

                                1103                             75                                              200

                                1104                             70                                              200

                                1105                             60                                              200

                                1106                             50                                              200

                                1107                             40                                              200

                                1108                             35                                              200

                                1109                             30                                              200

                                1110                             25                                              200

                                1111                             20                                              200

                                2001                             10                                              109 


                   3,   Crate Timing Curves  


    Fig. 1 Tower Crate. It agrees with results from L2 Data

    Fig. 2 Crate 64-67

    Fig. 3 Crate 68-71

    Fig. 4 Crate 72_75

    Fig. 5 Crate 76-79

    Fig. 6 Crate 80_83

    Fig. 7 Crate 84-87

    Fig. 8 Crate 88-91

    Fig. 9 Crate 92-95

    Fig. 10 Crate 96-99

    Fig. 11 Crate 100-103

    Fig. 12 Crate 104-107

    Fig. 13 Crate 108-111

                  4, PDF Files of MAPMT Channel Timing Curve

       tower-crate-1.pdf  tower-crate-2.pdf  tower-crate-3.pdf  tower-crate-4.pdf  tower-crate-5.pdf  tower-crate-6.pdf

       mapmt-crate-64.pdf  mapmt-crate-65.pdf  mapmt-crate-66.pdf  mapmt-crate-67.pdf  mapmt-crate-68.pdf  mapmt-crate-69.pdf
       mapmt-crate-70.pdf  mapmt-crate-71.pdf  mapmt-crate-72.pdf  mapmt-crate-73.pdf  mapmt-crate-74.pdf  mapmt-crate-75.pdf
       mapmt-crate-76.pdf  mapmt-crate-77.pdf  mapmt-crate-78.pdf  mapmt-crate-79.pdf  mapmt-crate-80.pdf  mapmt-crate-81.pdf
       mapmt-crate-82.pdf  mapmt-crate-83.pdf  mapmt-crate-84.pdf  mapmt-crate-85.pdf  mapmt-crate-86.pdf  mapmt-crate-87.pdf
       mapmt-crate-88.pdf  mapmt-crate-89.pdf  mapmt-crate-90.pdf  mapmt-crate-91.pdf  mapmt-crate-92.pdf  mapmt-crate-93.pdf
       mapmt-crate-94.pdf  mapmt-crate-95.pdf  mapmt-crate-96.pdf  mapmt-crate-97.pdf  mapmt-crate-98.pdf  mapmt-crate-99.pdf
       mapmt-crate-100.pdf  mapmt-crate-101.pdf  mapmt-crate-102.pdf  mapmt-crate-103.pdf  mapmt-crate-104.pdf  mapmt-crate-105.pdf
       mapmt-crate-106.pdf  mapmt-crate-107.pdf  mapmt-crate-108.pdf  mapmt-crate-109.pdf  mapmt-crate-110.pdf  mapmt-crate-111.pdf


    Timing Scan 11/29/2007

    Timing Scan 11/29/2007

    posted 11/30/2007 Shiftlog entry
          run     btow   etow
    8333113 12 5
    115 17 15
    116 22 25
    117 27 35
    118 32 45
    120 37 55
    121 42 65
    123 52 70
    124 57 60
    125 62 50
    126 36 40
    127 36 30
    128 36 20
    129 36 10

    Figure 1 -- Tower crates

    Email from Will setting tower timing for this year
         Below in the forwarded message you will see a link to the 
    analysis (thanks Jason) of the more recent (much better statistics) 
    EEMC tower timing scan. Based on these I set the timing for this year
    as follows (from my shift log entry)
    > 11/30/07
    > 19:49
    > General
    > new timing configuration files loaded for EEMC towers
    > crate 1 delay 0x12 (no change from last year nominal)
    > crate 2 delay 0x8 (no change)
    > crate 3 delay 0x57 ( + 1 ns)
    > crate 4 delay 0x52 (+ 2 ns)
    > crate 5 delay 0x2b (no change)
    > crate 6 delay 0x1f (no change)
    > change ETOW phase to 21 (saved in all configs)
    > above phase represents overall shift of + 2 ns


    TFile *file = 0;
    TChain *chain = 0;

    #include <vector>

    #include "/afs/"

    // summary TTree branches created by StEEmcTimingMaker
    Int_t mRunNumber;
    Float_t mTowerDelay;
    Float_t mMapmtDelay;
    Int_t mTotalYield;
    Int_t mTowerCrateYield[MaxTwCrates];
    Int_t mMapmtCrateYield[MaxMapmtCrates];
    Int_t mTowerChanYield[MaxTwCrates][MaxTwCrateCh];
    Int_t mMapmtChanYield[MaxMapmtCrates][MaxMapmtCrateCh];
    Int_t mTowerMin;
    Int_t mTowerMax;
    Int_t mMapmtMin;
    Int_t mMapmtMax;

    // vectors to hold TGraphs for tower and mapmt crates
    Int_t npoints = 0;

    TGraphErrors *towerCrateCurves[MaxTwCrates];
    TGraphErrors *mapmtCrateCurves[MaxMapmtCrates];

    TGraphErrors *towerChanCurves[MaxTwCrates][MaxTwCrateCh];
    TGraphErrors *mapmtChanCurves[MaxMapmtCrates][MaxMapmtCrateCh];

    // enables printing of output files (gif) for documentation
    // figures will appear in same subdirector as input files,
    // specified below.
    //Bool_t doprint = true;
    Bool_t doprint = false;

    void plotEEmcL2Timing( const Char_t *input_dir="timing_files/")

    // chain files

    // setup branches

    // get total number of points
    Long64_t nruns = chain -> GetEntries();

    // setup the graphs for each crate and each channel

    // loop over all runs
    for ( Long64_t i = 0; i < nruns; i++ )



    // draw timing scan curves for tower crates
    // for ( Int_t ii=0;ii<MaxTwCrates;ii++ ) towerChannels(ii);
    // for ( Int_t ii=0;ii<MaxMapmtCrates;ii++ ) mapmtChannels(ii);

    std::cout << "--------------------------------------------------------" << std::endl;
    std::cout << "to view timing curves for any crate" << std::endl;
    std::cout << std::endl;
    std::cout << "towerChannels(icrate) -- icrate = 0-5 for tower crates 1-6"<<std::endl;
    // std::cout << "mapmtChannels(icrate) -- icrate = 0-47 for mapmt crates 1-48"<<std::endl;
    std::cout << "print() -- make gif/pdf files for all crates and channels"<<std::endl;

    // ----------------------------------------------------------------------------
    void print()
    for ( Int_t ii=0;ii<MaxTwCrates;ii++ ) towerChannels(ii);
    //for ( Int_t ii=0;ii<MaxMapmtCrates;ii++ ) drawMapmt(ii);

    // ----------------------------------------------------------------------------
    void drawCrates()

    // tower crates first
    TCanvas *towers=new TCanvas("towers","towers",500,400);
    const Char_t *opt[]={"ALP","LP","LP","LP","LP","LP"};

    TLegend *legend=new TLegend(0.125,0.6,0.325,0.85);

    Float_t ymax=0.;
    for ( Int_t icr=0;icr<MaxTwCrates;icr++ )
    TString crname="tw crate ";crname+=icr+1;
    legend->AddEntry( towerCrateCurves[icr], crname, "lp" );
    if ( towerCrateCurves[icr]->GetYaxis()->GetXmax() > ymax )
    towerCrateCurves[0]->SetTitle("EEMC Tower Crate Timing Curves");
    towerCrateCurves[0]->GetXaxis()->SetTitle("TCD phase[ns]");
    TString ytitle=Form("Integral [ped+%i,ped+%i] / N_{events}",mTowerMin,mTowerMax);


    // ----------------------------------------------------------------------------
    void mapmtChannels( Int_t crate )

    static const Int_t stride=16;
    Int_t crateid = MinMapmtCrateID+crate;

    TString fname="mapmt-crate-";fname+=crate+MinMapmtCrateID;fname+=".ps";
    TCanvas *canvas=new TCanvas("canvas","canvas",850/2,1100/2);
    Int_t icanvas=0;

    for ( Int_t ich=0;ich<192;ich+=stride )


    TString pname="crate";

    const Char_t *opts[]={"ALP","LP","LP","LP","LP","LP","LP","LP","LP","LP","LP","LP","LP","LP","LP","LP","LP","LP","LP","LP","LP"};

    // normalize
    Float_t ymax=0.0;
    Double_t sum[stride];for ( Int_t jj=0;jj<stride;jj++ )sum[jj]=0.;
    Double_t max=0.;
    for ( Int_t jch=0;jch<stride;jch++ ) // loop over channels in this one graph
    Int_t index=ich+jch;
    Double_t *Y=mapmtChanCurves[crate][index]->GetY();
    for ( Int_t ipoint=0;ipoint<npoints;ipoint++ ) {
    if ( Y[ipoint]>ymax ) ymax=Y[ipoint];
    if ( sum[jch]>max ) max=sum[jch];
    if ( max <= 0. ) continue; // meh?

    TLegend *legend=new TLegend(0.55,0.11,0.85,0.525);
    for ( Int_t jch=0;jch<stride;jch++ )
    Int_t index=ich+jch;
    // offset X axis of each of these
    Double_t *X=mapmtChanCurves[crate][index]->GetX();
    Double_t *Y=mapmtChanCurves[crate][index]->GetY();
    Double_t *EY=mapmtChanCurves[crate][index]->GetEY();
    if ( sum[jch]<= 0. ) continue;
    // std::cout<<"before"<<std::endl;
    for ( Int_t ip=0;ip<npoints;ip++ ){
    Float_t shift = 0.5+ ((float)jch) - ((float)stride)/2.0;
    Double_t yy=Y[ip];
    X[ip]-= 0.1*shift;
    // std::cout << "ip="<<ip<<" y="<<yy<<" y'="<<Y[ip]<<std::endl;
    if ( !jch )

    TString label="crate ";label+=crate+1;label+=" chan ";label+=index;


    // if(doprint)c->Print(pname+".gif");
    if ( !(icanvas%2) ){
    // if(doprint)c->Print(pname+".gif");

    gSystem->Exec(TString("ps2pdf ")+fname);

    // ----------------------------------------------------------------------------
    void towerChannels( Int_t crate )

    static const Int_t stride=12;

    TString fname="tower-crate-";fname+=crate+1;fname+=".ps";
    TCanvas *canvas=0;
    canvas = new TCanvas("canvas","canvas",850/2,1100/2);

    Int_t icanvas=0;

    for ( Int_t ich=0;ich<120;ich+=stride )


    // TString aname="crate";aname+=crate;aname+=" channels ";aname+=ich;aname+=" to ";aname+=ich+stride-1;
    // TCanvas *c = new TCanvas(aname,aname,400,300);

    TString pname="crate";

    const Char_t *opts[]={"ALP","LP","LP","LP","LP","LP","LP","LP","LP","LP","LP","LP","LP","LP","LP","LP"};

    // normalize
    Double_t sum[stride];for ( Int_t jj=0;jj<stride;jj++ )sum[jj]=0.;
    Double_t max=0.;
    for ( Int_t jch=0;jch<stride;jch++ ) // loop over channels in this one graph

    Int_t index=ich+jch;
    Double_t *Y=towerChanCurves[crate][index]->GetY();
    for ( Int_t ipoint=0;ipoint<npoints;ipoint++ ) sum[jch]+=Y[ipoint];
    if ( sum[jch]>max ) max=sum[jch];
    if ( max <= 0. ) continue; // meh?

    TLegend *legend=new TLegend(0.125,0.15,0.325,0.45);
    for ( Int_t jch=0;jch<stride;jch++ )

    Int_t index=ich+jch;
    // offset X axis of each of these
    Double_t *X=towerChanCurves[crate][index]->GetX();
    Double_t *Y=towerChanCurves[crate][index]->GetY();
    Double_t *EY=towerChanCurves[crate][index]->GetEY();
    if ( sum[jch]<= 0. ) continue;
    // std::cout<<"before"<<std::endl;
    for ( Int_t ip=0;ip<npoints;ip++ ){
    Float_t shift = 0.5+ ((float)jch) - ((float)stride)/2.0;
    Double_t yy=Y[ip];
    X[ip]-= 0.1*shift;
    // std::cout << "ip="<<ip<<" y="<<yy<<" y'="<<Y[ip]<<std::endl;


    TString label="crate ";label+=crate+1;label+=" chan ";label+=index;


    // if(doprint)c->Print(pname+".gif");
    if ( !(icanvas%2) ){
    if ( doprint ) canvas->Print(fname+"(");

    if ( doprint ) {
    gSystem->Exec(TString("ps2pdf ")+fname);


    // ----------------------------------------------------------------------------
    void fillCrates(Int_t ipoint)
    #if 1
    // loop over tower crates
    for ( Int_t icr=0;icr<MaxTwCrates;icr++ )
    Float_t yield = (Float_t)mTowerCrateYield[icr];
    Float_t total = (Float_t)mTotalYield;
    if ( total > 10.0 ) {
    Float_t eyield = TMath::Sqrt(yield);
    Float_t etotal = TMath::Sqrt(total);
    Float_t r = yield / total;
    Float_t e1 = (yield>0)? eyield/yield : 0.0;
    Float_t e2 = etotal/total;
    Float_t er = r * TMath::Sqrt( e1*e1 + e2*e2 );
    towerCrateCurves[icr]->SetPoint(ipoint, mTowerDelay, r );
    towerCrateCurves[icr]->SetPointError( ipoint, 0., er );
    else {
    towerCrateCurves[icr]->SetPoint(ipoint, mTowerDelay, -1.0 );
    towerCrateCurves[icr]->SetPointError( ipoint, 0., 0. );
    // loop over mapmt crates
    for ( Int_t icr=0;icr<MaxMapmtCrates;icr++ )
    Float_t yield = (Float_t)mMapmtCrateYield[icr];
    Float_t total = (Float_t)mTotalYield;
    if ( total > 10.0 ) {
    Float_t eyield = TMath::Sqrt(yield);
    Float_t etotal = TMath::Sqrt(total);
    Float_t r = yield / total;
    Float_t e1 = (yield>0)? eyield/yield : 0.0;
    Float_t e2 = etotal/total;
    Float_t er = r * TMath::Sqrt( e1*e1 + e2*e2 );
    mapmtCrateCurves[icr]->SetPoint(ipoint, mMapmtDelay, r );
    mapmtCrateCurves[icr]->SetPointError( ipoint, 0., er );
    else {
    mapmtCrateCurves[icr]->SetPoint(ipoint, mMapmtDelay, -1. );
    mapmtCrateCurves[icr]->SetPointError( ipoint, 0., 0. );
    // ----------------------------------------------------------------------------
    void fillChannels(Int_t ipoint)

    #if 1
    // loop over tower crates
    for ( Int_t icr=0;icr<MaxTwCrates;icr++ )
    for ( Int_t ich=0;ich<MaxTwCrateCh;ich++ )

    Float_t yield = (Float_t)mTowerChanYield[icr][ich];
    Float_t total = (Float_t)mTotalYield;
    if ( total > 10.0 ) {
    Float_t eyield = TMath::Sqrt(yield);
    Float_t etotal = TMath::Sqrt(total);
    Float_t r = yield / total;
    Float_t e1 = (yield>0)? eyield/yield : 0.0;
    Float_t e2 = etotal/total;
    Float_t er = r * TMath::Sqrt( e1*e1 + e2*e2 );
    towerChanCurves[icr][ich]->SetPoint(ipoint, mTowerDelay, r );
    towerChanCurves[icr][ich]->SetPointError( ipoint, 0., er );
    else {
    towerChanCurves[icr][ich]->SetPoint(ipoint, mTowerDelay, -1.0 );
    towerChanCurves[icr][ich]->SetPointError( ipoint, 0., 0. );
    #if 1
    // loop over mapmt crates
    for ( Int_t icr=0;icr<MaxMapmtCrates;icr++ )
    for ( Int_t ich=0;ich<MaxMapmtCrateCh;ich++ )

    Float_t yield = (Float_t)mMapmtChanYield[icr][ich];
    Float_t total = (Float_t)mTotalYield;
    if ( total > 10.0 ) {
    Float_t eyield = TMath::Sqrt(yield);
    Float_t etotal = TMath::Sqrt(total);
    Float_t r = yield / total;
    Float_t e1 = (yield>0)? eyield/yield : 0.0;
    Float_t e2 = etotal/total;
    Float_t er = r * TMath::Sqrt( e1*e1 + e2*e2 );
    mapmtChanCurves[icr][ich]->SetPoint(ipoint, mMapmtDelay, r );
    mapmtChanCurves[icr][ich]->SetPointError( ipoint, 0., er );
    else {
    mapmtChanCurves[icr][ich]->SetPoint(ipoint, mMapmtDelay, -1.0 );
    mapmtChanCurves[icr][ich]->SetPointError( ipoint, 0., 0. );
    // ----------------------------------------------------------------------------
    void initGraphs()

    for ( Int_t i=0;i<MaxTwCrates;i++ ){
    towerCrateCurves[i] = new TGraphErrors(npoints);

    for ( Int_t j=0;j<MaxTwCrateCh;j++ )

    for ( Int_t i=0;i<MaxMapmtCrates;i++ ){
    mapmtCrateCurves[i]= new TGraphErrors(npoints);

    for ( Int_t j=0;j<MaxMapmtCrateCh;j++ )


    // ----------------------------------------------------------------------------
    void chainFiles(const Char_t *path)
    chain=new TChain("timing","Timing summary");

    TFile *tfile = 0;
    std::cout << "chaining files in " << path << std::endl;
    TSystemDirectory *dir = new TSystemDirectory("dir",path);

    TIter next( dir->GetListOfFiles() );
    TObject *file = 0;
    while ( file = (TObject*)next() )
    TString name=file->GetName();

    // sum the event counter histogram
    if ( name.Contains(".root") ) {
    // open the TFile and
    std::cout << " + " << name << std::endl;
    // tfile = TFile::Open(name);

    // ----------------------------------------------------------------------------
    void setBranches(const Char_t *dir)

    chain->SetBranchAddress("mRunNumber", &mRunNumber );
    chain->SetBranchAddress("mTowerDelay", &mTowerDelay );
    chain->SetBranchAddress("mMapmtDelay", &mMapmtDelay );

    chain->SetBranchAddress("mTotalYield", &mTotalYield );
    chain->SetBranchAddress("mTowerCrateYield", &mTowerCrateYield );
    chain->SetBranchAddress("mMapmtCrateYield", &mMapmtCrateYield );
    chain->SetBranchAddress("mTowerChanYield", &mTowerChanYield );
    chain->SetBranchAddress("mMapmtChanYield", &mMapmtChanYield );





    New EEMC Calibrations Page

    2007 EEMC Tower Gains

    Run 7 EEMC Tower Gains - Using Slopes

    Goals: Use "inclusive slopes" from fast-detector only, min-bias runs to determine relative (eta-dependent) gains for all EEMC towers for the 2007 run.  More specifically, analyze ~30k events from run 8095104 (thanks to Jan [production] and Jason [fitting] !), fit slopes to all ungated tower spectra, in order to:

    1. check if new / replaced PMT's (only 2 for this year) need significant HV adjustment
    2. make sure tubes with new / replaced bases are working properly
    3. search for towers with unusual spectra, anomalous count rates, or slopes that are far from the norm for that eta bin
    4. compare individual slopes to 2006 absolute gains (from mips) for each eta bin, to test robustness and stability of gain determinations
    5. for tower gains far from ideal (as determined with slopes and/or mips) consider adjusting HV
    6. look for anything else that seems out of whack!


    For the gain calibration of towers, we will use

    • x = channel number = ADC - ped
    • E = full e.m. energy (GeV) = (deposited energy / sampling fraction) for e.m. particles
    • G = absolute gain (channels / GeV) including sampling fraction

    So:   E = x / G

    For slopes, raw spectra (y vs. x) are fit to:   y = A e-bx

    Thus, one expects that for a given eta bin:   G  ~  1 / b


    1.  Two new tubes are fine!   Slopes of recently replaced PMT's 04TB12 and 12TE06 are very close to those of neighboring towers at same eta, or those of same subsector in the neighboring sector:

    towerID integral slope error
    03TB12 2003 -0.04144 0.00181
    04TA12 2081 -0.04527 0.00177
    04TB12 2022 -0.04400 0.00173
    04TC12 2195 -0.03825 0.00170
    05TB12 2056 -0.04465 0.00177

    towerID integral slope error
    11TE06 2595 -0.04157 0.00162
    12TD06 1965 -0.05977 0.00185
    12TE06 2535 -0.04516 0.00165
    01TA06 2124 -0.05230 0.00179
    01TE06 2070 -0.05342 0.00190

    More global comparisons to all the tower slopes in the same eta bin are given below.   For both tubes, the gain is 5-10% lower than average, but well within useful range.

    2.  Change of base (same PMT) has little effect on tower gains.  This has been confirmed for the six bases that were changed (03TA09, 06TB04, 10TE01, 12TA01, 12TC11, 12TE06), using the same comparisons to neighboring towers used in step 1 above.

    3.  For all 720 towers, comparison of 2007 slopes to 2006 mip-based absolute gains indicates about 6 problem towers (most "well known")

    • 06TA03 - no useful mip results, fitted slope was positive!  Spectra never make much sense.
    • 08TC05 - didn't work last year, still not working!  Spectra shows only a pedestal.
    • 07TC05 - no gain determined in 2005 or 2006.  Has largest slope of all towers, probably useless.
    • 06TD11 - each year, everything gets replaced; each year it continues to be 'flakey,' sometimes working, sometimes not.
    • 12TD01 - seemed okay last year, now has a very small slope.  Maybe PMT is dying fast?
    • 10TA11 - worked fine last year, recently died.  HV off, only a pedestal.

    In addition, 09TE01 seems to be working now, though it failed the mip gain analysis last year, and hasn't been 'fixed.'

    All of these cases are easily seen in the following correlation plot:

    4.  See clear correlations, within each eta bin, between new (2007) slope analysis, last year's mip analysis    ->   gains are stable, methods are robust!   On vertical scale, solid magenta line = ideal gain for that bin, dashed = +/- 15%

    eta bin

    correlation plot comments
    1 .gif one high gain tube (10TA01), reasonable correlation, no obvious problems
    2 .gif looks okay, all within +/- 20% of ideal gains
    3 .gif pretty ratty - several towers ~15% off 'correlation' curve
    4 .gif one very low gain tube (01TA04), one with very small slope (02TD04), otherwise all okay
    5 .gif a couple of high-gain towers, correlation is very good
    6 .gif one low gain, a few high-gain, but good correlation.  New PMT 12TE06 looks reasonable
    7 .gif overall gains a bit high compare to ideal, no real problems
    8 .gif no problems
    9 .gif no problems
    10 .gif strong correlations, tight clustering in both gain sets
    11 .gif odd shape, but okay.  Only problem (lower left corner) is 06TD11
    12 .gif everything a bit noisier, gains ~7% high overall.  New PMT 04TB12 fits right in!

    5.  Number of 'gain outliers' is quite small, deviation of average from ideal always < 10%.  Because the endcap towers are not used for trigger decisions, no obvious advantage in making HV adjustments to large number of towers.

    Conclusion:  Endcap towers are in good shape!  A very small number (~6 / 720) are not working well, but for these few, HV adjustment would not solve the problem.  No strong argument for changing HV on any particular tube at this point.

    N.B.   For each eta bin, one can calculate the ratio   R = G / (1/b)   as a 'conversion' of slope data to absolute gains.   Using the 2006 mip calibration and the 2007 slopes, one gets a fairly smooth curve, though something seems to be happening around eta bin 8.

    Calculating EEMC pedestal and status tables

    These instructions are for generating EEMC pedestals and status tables from raw ADC distributions extracted from raw DAQ files.  A useful overview of the "philosophy" behind the code described below can be found here.  The instructions producing histograms from the raw DAQ files is given here.  

    The instructions below are based entirely on code which exists in CVS and not any private directories.
    1) Check out the relevant code from the cvs repository to your working directory:
    % cvs co StRoot/StEEmcPool/StEEmcDAQ2Ped
    % cvs co StRoot/StEEmcPool/StEEmcPedFit
    % cvs co StRoot/StEEmcPool/StEEmcStatus
    and compile
    % cons
    2) Copy the necessary macros and scripts to your working directory:
    % cp StRoot/StEEmcPool/StEEmcDAQ2Ped/macros/plDAQ2Ped.C ./
    % cp StRoot/StEEmcPool/StEEmcPedFit/macros/fitAdc4Ped.C ./
    % cp StRoot/StEEmcPool/StEEmcPedFit/macros/ ./
    % cp StRoot/StEEmcPool/StEEmcStatus/macros/pedStat.C ./
    % cp StRoot/StEEmcPool/StEEmcStatus/macros/ ./
    3) Produce 1D ADC histograms for every EEMC channel from the output of the daq reader (described elsewhere) using StEEmcDAQ2Ped and fit these distributions to produce pedestal tables using StEEmcPedFit.  The script will run over histogram files for many runs stored in a single directory:
    % ./
    4) Analyze the ADC distributions for every EEMC channel and determine its status and fail bits (ie. status table info) using StEEmcStatus and write to StatFiles/ directory.  The script will loop over all runs which are given in an ascii file (runList) with content like
    Then just execute
    % ./
    5) Produce status tables for DB upload (one for each sector) :
    % cd StatFiles/
    % ./
    Pedestal and status table files for each sector should now be located in each run's directory in StatFiles/.  These are what will be uploaded to the DB.

    Calculating EEMC tower ideal gains and expected MIP response

    This is a quick summary of how one goes from a measured MIP peak to a final tower gain.

    In the attached spreadsheet, I use the EEMC tower boundaries in eta (lower table) to determine the average eta per bin and the ideal gain in each bin, assuming our goal ("ideal") is to have an e.m. shower of transverse energy ET = 60 GeV saturate the 12-bit ADC, that is, land in channel 4096.  This calculation is independent of assumed sampling fraction.  The result appears in column H in the lower table, and is highlighted in yellow.

    For a calibration based on MIP's, we also need to know the actual energy deposited by the MIP as it traverses all of the scintillator layers, so we need to know the total thickness of scintillator (for normal incidence) and the dE/dx of a MIP.  These values appear in cells L5 and M5, respectively.  All calculations are keyed to these cells, so changing these cells will propagate to all other columns.

    Finally, to connect ideal gains with MIP energy depositions (so we can arrive at the quantity of direct interest for a MIP-based calculation: in which ADC channel (above pedestal) should the MIP peak appear?), we also need to know the calorimeter sampling fraction.  I have used 5%, which is in cell G5.  Again, changing this one cell value will fill the rest of the tables accordingly. 

    With these assumed values (60 GeV, 4096 channels, 99 mm, 0.20 MeV/mm, 5% - all in row 5) one can now determine the ADC channel (above pedestal) in which the MIP peak will appear, if the gain is "ideal".  These are given in column N of the upper table and highlighted.  For each tower, the ratio of the actual (measured / fit) MIP peak channel to this ideal channel is the factor by which the ideal gain needs to be multiplied to arrive at the "true gain" per tower, which is what is loaded into the database.

    N.B.  I just cut and pasted these two tables together, so there is some overlap between them.  Several columns relate to estimating number of photo-electrons (pe) and high voltage (HV) and can be ignored.

    EEMC Calibration Docs

    This page is meant for centralizing all EEMC calibration documents.

    Calibrations through 2007(MIT locker):

    Alice B.'s calibration code blog:

    Ting Lin's updated MIP calibration instructions:  eemc_code_instruction_by_Ting_2.pdf

    EEMC Tower Swaps

    During the EEMC MIP calibration, we find that some of the EEMC cables are swaped.

    Swaps in database:(This has been implemented during the production, you do not need to worried about these.)
    1. mapping=S1 rot, P1 as in sect=5, swap TA4-5, QA11-B2, JB;
    2. mapping=swap V209:216, V216-280, V265:272, Bob
    3. mapping=swap 10TD04 with 10TD06, Ting and Mike(Not valid before 2015-08-13)

    Swap towers found From MIP calibration: 
     2009 pp200: 
     10TD06 <=> 10TD04 
     11TE10 <=> 11TE12

     2012 & 2013:
     10TD04  <=> 10TD06  
     11TC05  <=> 11TC07
     11TB04  <=> 11TB06
     04TB01  <=> 04TB12
     04TB02  <=> 04TB11
     04TB03  <=> 04TB10
     04TB04  <=> 04TB09
     04TB05  <=> 04TB08
     04TB06  <=> 04TB07

    You can remap the towers in your own analysis.
    For example, in Jet analysis, add a small piece of code before you record the tower Id in StRoot/StJetMaker/mudst/StjEEMCMuDst.cxx at line 84.
    /////////////////////////////////////////// Sample Code ////////////////////////////////////////////////////////

    void tileReMap(int &sec , int &sub , int &etabin){
      if(sec==11) {
        if(sub==5 && etabin==10 ) {  // 11TE10<==>11TE12;By Ting 10-27-2014
        } else if(sub==5 && etabin==12 ) {

    Overview for generating EEMC pedestals and status tables

    This is an informal overview of the 'philosophy' used to generate pedestals and status tables for the STAR endcap EMC, and in particular the ESMD.

    For the EEMC offline database, the default protocol is to store one set of pedestals and status tables per fill for the pp runs. In general, this information is updated less frequently for heavy-ion running, depending on user demand.  For the endcap, other database information, such as detector mapping and gains, will apply for much longer timescales (like years, or at least a whole run), and so there may be a single database entry for an entire running period.

    Focusing on the smd strips, our guiding assumptions are pretty simplistic: First, strips that have constant problems (i.e., those that stay bad after their crate is reconfigured or power-cycled, for example) are easy to catch, and will be flagged as bad no matter what data are used for QA. These aren't the concern. The messier case is when channels suddenly go bad, but can be recovered later (by power-cycling, etc.).  We assume that these sorts of problems, which tend to affect an entire FEE card and not individual channels, can occur at any time while running, but especially at the very start of a fill during tuning and collimation of the beams. These problems don't often fix themselves, and so will remain until action is taken - which usually occurs only between fills.

    For the smd strip pedestals and status tables, we analyze one min-bias run per fill, preferably one taken near the end of the fill. Guided by the above ideas, we assume that by this time we have 'accumulated' all the problems that will arise during the fill, and we will mark them as bad for the entire fill. This means that any strip that died or developed some problem _during_ the fill is marked as bad even for the runs early in the fill when it was still working. So it is a conservative approach: If a strip was malfunctioning near the end of the fill, we assume it was bad for the entire fill.  It is clear that if such problems are only cured in-between fills, this all makes sense.  If a problem is truly intermittent, however, and comes and goes from run to run, then in this approach we might catch it, or we could easily miss it.

    Updating the status information in the database on shorter timescales, or basing each entry on more than one run per fill (e.g., take an OR of problems found at the start and at the end of each fill), is certainly possible - it just requires more time and effort.  At this point, we don't plan to change our protocol unless new and unexpected time dependences are observed for problems that don't fit into our model of channels breaking and being 'fixed.'   I don't think our current assumptions are totally screwy.  Just from watching the P-plots, one can see that the endcap smd spectra start to get 'ratty' after a few fills, as more and more groups of four strips (which are consecutive in DAQ and P-plots, but not in the physical detector) start to drift around in their pedestal, or go south in some other manner.  After a thorough re-cycling, most of these problems can be fixed, so things look pretty good again at the start of the next fill.

    Nevertheless, at the end of the day, the most relevant question for the endcap status tables is "are we doing well enough?" and the best feedback comes from doing real analysis.  So the more that people stare at spectra and find new problems, especially those with unexpected time dependences, the better we can design our QA algorithms and protocol to identify and keep track of them.  No matter what sorts of problems we have found in the past or might have anticipated, nature always finds new ones, and we rely on users to point these out.

    Producing ADC distributions for the EMCs from raw DAQ files

    For calibrations of the EMCs (eg. pedestals, status, relative gains) it is often useful to look at raw ADC distributions from a sample of minimum bias events.  This can be done simply by analyzing the MuDsts once production has occured, but if one wants to proceed with calibrations before production occurs it often faster to use the raw DAQ files to produce these simple ADC distributions summed over many events.  The instructions below describe an adaptation of the general daq reader (provided by Tonko et. al.) used specifically to produce these distributions. 

    The general daq reader for all STAR subsystems can be found in StRoot/RTS/src/RTS_EXAMPLE/rts_example.C, however for EMC purposes not all of the functionality provided there are necessary.  The macro used here, emchist.C, uses the relevant pieces of the general daq reader to retrieve raw ADC information on a crate/channel level from the daq files and store them in ROOT histograms.  These histograms are useful for many QA and other tasks including timing scans, pedstals, status tables, relative gains (from slopes), etc.
    If one is interested in only events from a specific trigger to increment the raw ADC histograms, then this can be specified in the emchist.C macro by using
    int trigID[2]={A,B};
    where A is the "DAQ trigger ID" for events to be incremented in the histograms and B is another trigger which is only implemented as a counter.  These trigger IDs can be found in the RunLog browser, but then they need to be converted to get the numbers A and B in trigID[].  The mapping pattern is
    1 2 4 8 16 32 64 128 256 512 1024 2048...
    1 2 4 8 10 20 40 80  100 200 400  800...

    So for example, for the emc-check runs in Run 13,

    the line should be trigID[2]={1024,0};


    1) Check out the macro from cvs:
    % cvs co StRoot/StEEmcPool/macros/DaqReader

    2) Copy the relevant macros and scripts to your working directory:

    % cp StRoot/StEEmcPool/macros/DaqReader/ ./
    % cp StRoot/StEEmcPool/macros/DaqReader/emchist.C  ./
    % cp StRoot/StEEmcPool/macros/DaqReader/  ./
    % cp StRoot/StEEmcPool/macros/DaqReader/  ./

    3) Compile the macro by using the script:
    % ./ emchist.C
    which produces an executable emchist* which reads the daq file by executing
    ./emchist /star/data03/daq/2012/100/13100049w_js/st_W_13100049_raw_1340001.daq
    for the daq file of interest.
    To process all the daq files for a given run which are stored on some NFS disk space there is a script provided ( which loops over a given runList to do this.  Finally, you can add all the histograms for a given run using the script.

    Run 10 EEMC Calibrations

    Run 11 EEMC Calibrations

    This is the main page for all EEMC calibration information for Run 11

    EEMC HV adjustments for "outliers"

    EEMC HV adjustments for "outliers"

    Using the sums method (similar to Run 9 analysis) Scott Identified some outliers who's gains were either too high or too low compared to other towers in the same eta ring.  The list of towers is below in two different groups 1) known bad channels and 2) channels to adjust HV.

    1) Known bad channels:

    06TA03, 02TC06, 07TC05 -> all reported to still be bad and masked at L0

    04TB05 -> spectra shows this channel is dead at startup

    2) Channels to adjust HV

        gain too high:  11TB08, 03TA06, 08TC03, 07TC07, 02TE02, 01TA04

        gain too low:  12TD01, 10TA09



    Minbias runs (12030069-73) were used to determine the slope of each channel using "Scott's method".  Below is a summary of the channels slope and the median slope for towers in that eta bin as well as the current HV (HVset_ix) for each tower, all of which is used to calculate the new HV (HVset_xi) to be used to match the other towers in that eta bin.

    Table 1:

    The equation used to determine the new HV values is HV_1 = HV_2 * (slope_2 / slope_1) ^ (1/kappa), where the value of kappa is taken to be 8.8 from previous HV adjustments.    This is equation is different than the similar equation used by the barrel becuase in the endcap gain ~ 1/slope and in the barrel gain ~ slope.


    1) 11TB08 appears to be unstable (HV status is 5 or 7 instead of 4="good") running at 517 V, so it was decided to set this tower to its original value of 699.9 V where it runs stably.  Thus, this tower will continue to be masked out of L0 and L2 trigger and will need to be calibrated carefully to be used in offline analysis.

    2) 12TD01 is a bit of a special case as it was "hot" in Run 8 and had its voltage lowered (946.2 -> 830.8) before Run 9, but then the gain was way too low.  So it was decided to put its voltage at 880.0 to try and increase the gain without getting hot.


    Runs taken to test new HV

    Once new HV values were determined 2 emc-check runs were taken to check the new files.  12037043 was taken with HVset_ix and 12037046 was taken with HVset_xi.  Below is a summary of the slopes for the 2 runs for the channels of interest.  Unfortunately. some channels didn't get a new HV loaded because of communications problems with HVsys branch "C" (these are shown in blue). 

    Table 2:

    For the towers where the new HV was loaded correctly (red) the slopes now match much better to the median slope in it's etabin, so the new HV values look reasonable and will be used for the remainder of Run 11.  HVset_xi is used for all runs after R12038072.

    Note:  10TA09 appeared to be hot after its HV was raised to 827.0 so it was set back to its HVset_ix voltage value.  There was probably beam background when the original slopes were measured causing this to incorrectly be labeled an outlier.

    5P1 adjustments

    During the same test runs (12037043 and 12037046) a test was done increasing tube #2 of 5P1 from 750 -> 840 V, as the spectra for channels 176-191 was way down in some early runs (eg. 12034091).  This increased the gain by ~2.6, but comparisons of the slopes for channels from tube #2 to other preshower channels in 5P1 showed that the gain should be increased by another factor of ~2 (see txt file with slopes for tubes of interest and median slope of other channels in run 12037046). 

    So the final HV used for 5P1 will be 913 V, which was determined with a similar formula as for the towers, but with kappa_mapmpt=8.3.

    Run 12 EEMC Calibrations

    pp500 EEMC Gain Calibration with MIPs

    Note four sets of tower gains were uploaded to the database to account for gain decrease over the course of the run.

    See attachments for calibration summary and masks lists.

    Plots can be found here:

    Run 13 EEMC Calibrations

    EEMC Gain Calibration with MIPs

    Note four sets of tower gains were uploaded to the database to account for gain decrease over the course of the run.

    See attachments for calibration summary and masks lists.

    Plots can be found here:

    EEMC Status and Pedestal Tables

    Run List

    General Procedure:

    1)  Produce ADC distributions from raw daq files as outlined here.

    2)  Make ADC distributions for each EEMC channel and fit the histograms to get pedestal and rms values as shown here.

    3)  Use StEEmcStatus to get status table information.  See the last two steps here.

    Typical ADC Distribution of one EEMC channel:

    Status codes appearing in Run 13:
    ONLPED    0x0001 // only pedestal visible
    STKBT        0x0002 // sticky lower bits
    HIGPED      0x0010 // high chan, seems to work
    WIDPED      0x0080 // wide ped sigma

    "failed" status: 
    fit fails, all entries in 1 channel, too many ADC = 0 bins, dead channel, stuck in another mode, HV was off, signal fiber broken, etc.

    Lower bit(s) failed ("sticky bits"):

    Entire run 13: 

    • a04TB07, a06TA07, a08TB07

    Most of run 13:

    • a05TA12

    One to several runs:

    • a01TD12, a04TD05, a05TA10, a06TB11, a06TE10, a08TE08, a09TA09, a11TA07

    High pedestal:  a05TB01 for 6 runs

    Wide ADC distribution:

    Most of run 13
    • a03TB09
    One to several runs
    • a12TC09, a03TB01, a03TB02, a03TB10, a06TD04, a09TD09, a11TA12, a12TD09, a02TD04, a02TD05, a03TB11, a03TD09

    Status tables inserted where large time-gaps occur between emc-check runs:
    Fill 17237  -->  use table from fill 17250
    Fill 17263  -->  use table from fill 17268
    Fill 17311  -->  use table from fill 17312
    Fill 17328  -->  use table from fill 17329
    Fill 17399  -->  use table from fill 17402
    Fill 17426  -->  use table from fill 17427

    Status tables inserted mid-fill due to major problems and fixes:
    Fill 17333, Run 14096099  -->  use table from fill 17335
    Fill 17484, Run 14130003  -->  use table from fill 17486
    Fill 17573, Run 14152029  -->  use table from fill 17579
    Fill 17586, Run 14152029  -->  use table from fill 17587

    See this for MAPMT status info.
    See this for MAPMT "diagnostic" details.

    Run 15 EEMC Calibrations

    Status and Pedestal Tables

    We used one good emc-check run with 100k events each for each fill.  Some fills did not have a good emc-check run.  Below are the runs we used.
    Run List

    Produced ADC distributions from raw DAQ files following the instrucitons here.

    Determined the status and pedestals for each tower and mapmt channel with the instructions here.

    Summary of tower issues:
    On average, about 2.5% of all towers are masked-out per fill.
    Tower Status by Fill

    02TA01:  dead entire run
    02TC04:  bad entire run
    02TC06:  fail for part of the run
    04TB07:  stuck bit entire run
    04TC01:  fail for part of the run
    05TA12:  stuck bit entire run
    06TA03:  failed entire run
    06TA07:  stuck bit entire run
    06TC08:  dead for one run
    06TD04:  failed for one run
    07TC05:  failed entire run
    08TB07:  stuck bit entire run
    10TA09:  dead for two runs
    10TC02:  failed entire run
    10TC03:  failed entire run
    10TC09:  failed entire run
    10TC11:  good for only two runs
    11TA08:  dead entire run
    11TA12:  mark as stuck bit entire run
    11TB08:  failed entire run
    11TC04:  dead for part of the run
    12TB02:  dead part of the run
    12TC05:  bad entire run
    12TD01:  bad for part of the run

    **See attached file for MAPMT pedestal widths**

    Run 17 EEMC Calibrations


    Status and Pedestal Tables

    RunList Selection:
    Use one good emc-check run with at least 50k events for each fill from pp510. Some fills did not have good emc-check run.

    For pp510, total emc_check run list has 227 runs, some problematic (?) runs:
    18065063, only has 1 event; 
    18066002, second emc_check run in same fill, Shift Leader comment: 18065001 rate too high?
    18087034, only has 1 event;
    18092096, emc_check run pp energy < 500GeV
    18108002, second emc_check run in same fill.
    18108043, emc_check run pp energy < 500GeV
    18109051, emc_check run pp energy < 500GeV
    18111048, emc_check run pp energy < 500GeV
    18111052, emc_check run pp energy < 500GeV
    18112046, emc_check run pp energy < 500GeV
    18113047, emc_check run pp energy < 500GeV
    18115037, emc_check run pp energy < 500GeV
    18115043, emc_check run pp energy < 500GeV
    18115047, emc_check run pp energy < 500GeV
    18115051, emc_check run pp energy, Blue 253.798GeV, Yellow 253.797GeV, smaller than normal value 254.867GeV.
    18115055, emc_check run pp energy < 500GeV
    18119001, Shift Leader Marked as Junk
    18143047, second emc_check run in same fill.
    The final list has 210 runs and is available: runList_2017_emc_check_final

    Summary of tower:
    tower status by fill
    a01TA05: masked out on April 26th by Will
    a01TC05: failed for part of the run
    a02TA01: dead entire run
    a02TC04: bad entire run
    a02TC06: failed for part of the run
    a03TE03: dead for one run
    a03TE11: failed for two runs
    a04TB07: stuck bit entire run
    a04TC01: dead entire run
    a05TA12: stuck bit entire run
    a05TC12: dead entire run
    a06TA03: failed entire run
    a06TA07: stuck bit entire run
    a07TB12: failed for one run
    a07TC05: failed entire run
    a08TB07: stuck bit entire run
    a09TC04: dead for part of the run
    a11TA08: dead entire run
    a11TB07: failed for part of the run
    a11TD01 dead for part of the run

    a12TC05: bad entire run
    a12TD01: failed for part of the run
    a12TD09: failed for part of the run

    Summary of MAPMT:
    MAPMT status by fill

    MAPMT Pedestal Width

    Run 8 EEMC calibrations

    This is the main page for all EEMC calibration information for Run 8

    Comparison of old (Run 7) to new (Run 8) EEMC tower HV's

    At the end of run 7, we compared slopes for all EEMC towers with two sets of HV values in a series of consecutive runs.  The goal was to see if the new HV set would change the slopes in the 'expected' way, to bring the tower hardware gains into closer agreement with their ideal values.

    Here is a summary of what we planned to do:  

    What was actually done was send in a private email to a few people.  The email is attached below, along with two plots.  "2006TowerGains" shows the absolute gain determined for each tower, compared to its ideal value.  "2006Gains_x_SlopeRatio" is the same data, but each point has simply been scaled by the ratio of the slopes determined for the two data sets (old HV vs new HV).  Note that the correction is not just a calculation, but based only the slope measured for each tower before and after the new HV set was loaded.


    EEMC Pedestals and Status Tables for Run 8

    Generating Pedestal and Status Table Information

    Requesting Emc Check Runs

    In order to produce pedestal and status table information for the EEMC, Min Bias runs must be analyzed to determine the pedestal and status for each channel (tower, preshower, or SMD strip).  Thus during the running, usually once per fill an EmcCheck run is produced with approximately 200,000 of these Min Bias events.  This run must include EEMC and ESMD, and it is preferable for this run to be the first run in the fill, but not absolutely necessary.  A list of these runs we wish to have produced via Fast-Offline is sent to Lidia Didenko through the starprod hypernews list.  These runs are usually produced to /star/data09/reco/EmcCheck/ReversedFullField/dev/ or sometimes data10.  For each run there might be 20 MuDst files, that will be deleted in a week or so, so they must be processed to hist.root files quickly.  A list of the runs that were requested and produced for 2008 is given here:

    Creating hist.root files and fit.hist.root files

    In order to analyze these runs, the raw MuDst needs to be transfered hist.root fromat.   This is  done with the macro rdMu2Ped.C  which is executed by procPeds (all of the following code can be found in my directory at /star/u/stevens4/ped08 at rcf).   procPeds requires an input file Rnum.lis which has a list of the locations of all the files for a given run, this can be created via the executible filefind (Rnum is a string of Rydddnnn where y is the year, xxx is the day of the run, and nnn is the number of the run on that day).  Once rdMu2Ped.C has written the .hist.root file for the given run, procPeds then executes fitAdc4Ped.C which fits each channels histogram using the code in pedFitCode/.   The macro fitAdc4Ped.C also creates ped.sectorXX files which contain the pedestal information for each sector which will be loaded to the database, as well as other log files.  Finally procPeds moves all these files to a directory for that particular run. 

    Status Tables

    The code used to create these status and fail words for each channel are in the directory /star/u/stevens4/ped08/pedStatus.  The source code for the program is in oflPedStat.cxx, and it is executed using oflPed.  It requires and input file, runList, which contains the list of runs to be analyzed, and it requires the hist.root and fit.hist.root files to be stored in /star/u/stevens4/ped08/dayxxx/outPedRyxxxnnn.   This code outputs two files, Ryxxxnnn.errs, which contains the status and fail words in hex format for each problematic channel, and Ryxxxnnn.log, which gives explanation (ie which test it failed) for why each channel was problematic.  Both of these output files are written in /star/u/stevens4/ped08/pedStatus/StatFiles/.  Once these files are written the script procErrs can be executed in the same directory.   procErrs reads in the .errs files and writes (with DistrStat2Sectors.C) the stat-XX files containing the status and fail words that will be uploaded to the database, as well as copy  each stat-XX and ped.sectorXX to the run number directory in /StatFiles/.  

    The current set of status bits for EEMC (usage:  #define EEMCSTAT_* )
    ONLPED    0x0001 // only pedestal visible
    STKBT        0x0002 // sticky lower bits
    HOTHT       0x0004 // masked for HT trigger
    HOTJP        0x0008 // masked for JP trigger
    HIGPED      0x0010 // high chan, seems to work
    HOTSTR     0x0020 // hot esmd strip
    JUMPED     0x0040 // jumpy ped over few chan
    WIDPED      0x0080 // wide ped sigma

    More information about the database usage is given by Jan at:


    Uploading Tables to Database

    General information for uploading tables to the database is given by Jan at:

    More specific information on uploading pedestals and status tables to the database refer to /star/u/stevens4/database/uploadinfo.txt




    Run 9 EEMC calibrations

    This is the main page for all EEMC calibration information for Run 9

    EEMC Gain Calibration Using MIP Run9

    Dead channels:
              SMD strips:        
                       03V112, 03V258, 05U212, 05U234, 05V057, 06U069, 06U091, 08U124, 09V029, 09V047, 09V113.
                       03U, 04V, 09U, 10V strips numbered 284-287. All the strips labeled 288.
                       02TC04, 02TC06, 06TA03, 06TE04, 07TC05, 11TD05

    Bad channels:
                       05PA01, 05PA02, 05PA03, 05PB10, 05PB11, 05PB12, 05PC10, 05PC11, 05PC12, 05PD10, 05PD11, 05PD12, 05PE01,     
                       05PE02, 05PE03

                       11PE10, 11PE12, 11QE10, 11QE12, 11RE10, 11RE12
                       11TE12, 11TE10, 10TD04, 10TD06

    Note: Fifteen 05Pre1 channels have PMT problem; Swaps 11TE10<->11TE12; 10TD04<->10TD06

    The procedures and results can be found here:

    All the plots are in this directory:

              Pre1, Pre2 and tower's gain decreased by 10% compared to run6;
              Post shower's gain remain stable.

    EEMC Gains - corrected for mis-set TCD phase

    EEMC TCD Phase and Effective Gains

    During Run 9 the TCD phase was set incorrectly for ETOW (run < 10114054) and ESMD (run < 10140030).  A study (shown here) found the slope ratio for the 2 TCD phases which was used to calculate new gain tables for ETOW and ESMD.   These "mis-set" TCD phase timing settings are not optimal for the vast majority of channels, thus the data taken during these periods are more suspect to issues such as timing jitter, vertex position dependencies, etc.  To account for these issues, we have set gain=-1 for these time periods for the standard "ofl" flavor of the DB.  The new gains (calculated with the slope ratios) have been uploaded to the DB for the same timestamps but with a flavor of "missetTCD", so that this data is permanently flagged as having issues that data taken with optimal timing (hopefully) do not. 

    As a reminder, here are a few lines of code for how to read these "missetTCD" flavor tables from the DB instead of the default "ofl" tables:

    stDb = new St_db_Maker("StarDb", "MySQL:StarDb");
    stDb->SetFlavor("missetTCD","eemcPMTcal");  //sets flavor for ETOW gains
    stDb->SetFlavor("missetTCD","eemcPIXcal");  //sets flavor for ESMD (mampt) gains

    Note: the "missetTCD" flavor is valid only for Run 9 during the time periods given above, so it will return gain<0 for any other times.

    EEMC Pedestals and Status Tables for Run 9

    Run 9 EEMC Pedestals and Status Tables

    Abstract:  To produce pedestals and status tables for ETOW, ESMD, and EPRS based on zdc_polarimeter (EmcCheck) runs taken at the beginning of each fill with calorimeters only.  This year the raw adc spectra were retrieved from the .daq files on HPSS using the DAQ_READER instead of waiting for these runs to be produced.

    Runlist:  200 GeV


    1) Retrieve .daq files from HPSS and use Matt Walker's version of the DAQ_READER to make 2D spectra of all EEMC components (code located at /star/u/stevens4/daqReader/ ).  Output is hist.root file with 6 ETOW histograms and 48 ESMD/EPRS histograms, one for each crate.

    2) Using mapping from DB create 1D histograms for each EEMC channel softID from the 2D histograms generated by the DAQ_READER (macro: /star/u/stevens4/ped09/fromDAQ/plDAQ2Ped.C).  Ouput is hist.root file with 720 ETOW and 9072 ESMD/EPRS  histograms.

    3) Fit 1D histograms produced by plDAQ2Ped.C to get pedestal value for each channel (macro: /star/u/stevens4/ped09/offline/fitAdc4Ped.C) .  Output is fit.hist.root file with fitted 1D histograms for every channel and a ped.sectorXX with pedestal values for each channel in that sector which can be uploaded to the DB.

    4) Compute status for each channel and generate status table for each sector (macro: /star/u/stevens4/ped09/offline/pedStat.C).

    The current set of status bits for EEMC (usage:  #define EEMCSTAT_* )
    ONLPED    0x0001 // only pedestal visible
    STKBT        0x0002 // sticky lower bits
    HOTHT       0x0004 // masked for HT trigger
    HOTJP        0x0008 // masked for JP trigger
    HIGPED      0x0010 // high chan, seems to work
    HOTSTR     0x0020 // hot esmd strip
    JUMPED     0x0040 // jumpy ped over few chan
    WIDPED      0x0080 // wide ped sigma


    Known problems put in status tables "by hand":

    Problem Fills effected (based on zdc run at beginning of fill)
    Crate 6 problem configuring 10157048-10169028 (not all of crate 6 for all fills)
    SMD Sectors 12 and 1 bad spectra 10139100, 10142078-10146010

     Note:  We also had problems with counts below pedestal in the ESMD/EPRS due to "extra accepts" in the triggering.  These problems are not included in the status tables because it is thought that these problems won't show up in the produced data, but we will have to wait and see.

    ESMD (MAPMT FEE) Timing for Run 9

    The timing scans for ESMD/MAPMT FEE for Run 9 were taken by
    raising the box delay settings as far as feasible, staying
    within the present RHIC tic "c" delay setting and then varying
    the TCD phase delay in order to see as much as possible of the
    right-hand-side timing cutoff in the scans (Note: due to present
    nature of the various delays there is a timing "hole" which
    cannot be accessed ... we will try to fix in future years e.g.,
    by extending the delay range of the new TCD).

    The new MAPMT configuration files for the scans were put on the
    EEMC slow controls machine (eemc-sc) in directory:
    /home/online/mapmtConfig/03-01-09_scan. The initial conditions
    are outlined in cols 1-7 of the spreadsheet "MAPMT_DELAYS_v7"
    (among the last attachments below). The nominal TDC phase setting
    from previous years is = 65. Within allowable additions to
    the box delay, we chose to divide things into 4 classes:

    a) add 22 ns box delay as per cols 8-12 of spreadsheet:
    (should clearly see edge as in previous years):
    12S1-12P1, 2S3, 4S1-4S3, 7S1-7P1, 8S2-10P1

    b) add 17 ns box delay as per cols 15-19 of spreadsheet:
    (will see less but better than previous):
    1S1, 1S3, 2S1, 4P1, 8S1, 11S1, 11S3

    c) add 7 ns box delay as per cols 22-26 of spreadsheet:
    (will see even less, etc.):
    1P1, 2S2, 2P1-3S3, 5S1, 5S3, 6S1, 8S2, 6P1, 11S2, 11P1

    d) delay w/ truncation @ 400 HEX as per cols 22-26 of
    (mistake: see notes below ... max is really 3FF)
    1S2 (439), 3P1 (44E), 5P1 (40C), 6s3 (423)

    Data for the scans was taken on Friday 6 March 2009:

    Phase Phase
    10065031 80 80
    10065032 10 10
    10065033 20 20
    10065034 30 30
    10065035 40 40
    10065036 50 50
    10065037 60 60
    10065038 70 70
    10065039 75 75
    10065040 65 65
    10065041 55 55
    10065042 45 45
    10065043 35 35
    10065044 25 25
    10065045 15 15
    10065046 5 5
    10065047 0 0
    (in last entry at "0" peds seem to indicate this didn't work
    for ETOW ... too many counts in spectra)

    These data were analyzed by Alice Bridgeman at link:

    Attached below are the same plots from her analysis, but
    annotated to show the run 8 effective timing setting (long
    vertical line at 43, 48, 58 depending on box ("crate"), for
    added delays of 22, 17 and 7, respectively) as well as
    indication of the location of the "right edge" of the timing
    scan and length of flat top region. (The files for the good
    timing scans are appended first and in order below for crates
    64 [e.g., mapmt-crate-64_set.pdf], 66-68, 70-78, 80-84, 86,
    88-89, 91-94, and 96-111.) The associated values from this
    somewhat subjective procedure (regions selected by eye and
    computer drawing "straight edge"), are given in cols 29-33
    (again on spreadsheet "MAPMT_DELAYS_v7) for the distance to the
    edge, range of distances, flattop range and time difference to
    near edge, respectively.

    In the past we have tried to set the delays so that that we
    sit (operating point) about 12 ns into the plateau region from
    the right side timing edge ... this allows for several ns of
    "time jitter" as well as possible error in determining the edge
    while still maintaining a safe (estimate > 5 ns) distance of
    the effective operation point from the fall off edge. The
    projected adjustments are given in col 36 of "MAPMT_DELAYS_v7"
    and converted to final box delay in HEX in col 39.

    These scans are more definitive that those of previous years
    (due to mixture of issues) and hence the new values bounce
    around a bit, but in general the shifts are only ~ few ns with
    a few outliers.

    There are several special cases!

    For boxes 65 (12S2), 69 (1S2), 79 (3P1), 85 (5S2), 87 (5P1),
    90 (6S3), the box delay was set to "400" instead of the max
    allowed of "3FF" (a mistake as noted above) which effectively
    zeroed out the box delay causing just the left hand timing edge
    to be visible in the scans (for box 95 7P1 plots there is something
    else is wrong and very little is plotted).

    For these special cases one can estimate the timing by looking at the
    LHS edge and applying the 50-55ns flat top to guess where the leading
    edge is (e.g., see the plots). But in general for these case the timing
    was set by looking at neighboring boxes in the clock chain and deducing
    a value to use (see spread sheet).

    The final Hex delay values are indicated in one of the last columns of
    the spreadsheet (MAPMT_DELAYS_v7)


    ETOW Gains - using "sums" to identify outliers

    Run 9 EEMC Tower Gains - Using "sums" to check for outliers

    Goal:  Use Alice B's analysis of endcap tower spectra, calculating sums of counts over a fixed range in (adc - ped), to search for "outliers," and in particular to check that any tower that was 'touched' during the shutdown is still giving results consistent with the average from similar towers.


    1. Sums were extracted over the adc range 20-100 (above pedestal) for all 720 endcap towers, for a series of runs used in timing scans.  Details of the runs selected, and the timing delays used for each, can be found at Alice's blog
    2. Based on the above analysis, Will decided on the optimal TCD delay settings.  A summary of these can be found in Will's blog
    3. To test for problematic channels, I used Alice's results for the scan with 60 ns delay (run 10065037) to examine all towers in crates 1 and 2, and used the scan with 40 ns delay (run 10065035) for all towers in crates 3-6.  An ascii file giving the crate #, channel #, adc sum, and sum error for each tower, for each of these two delay settings, is available here
    4. Because these times are not exactly at their optimal values (60 is ~4 ns too late, while 40 is ~2-3 ns too early), the "averages" and "sigmas" I compare to are over all towers in the same eta ring, but only those in crates from the same timing scan, e.g., for a tower like 02TC10, which is in crate 2, I would compare its adc sum to the average of the 20 towers found in crates 1 and 2 at etabin = 10.
    5. Anything listed as "not analyzed" means that Alice found too few counts in the adc range to learn anything useful - usually indicates a dead or low gain channel.

    Results:  These fall into four main categories

      Known bad channels
      1. 06TA03 (cr 4 ch 18):   reported to be still bad and masked in fee cr4 bd1 JP4
        =>  not analyzed
      2. 07TC05 (cr 4 ch 117):   reported to be still bad and masked in fee cr4 bd4 JP3
        =>  still bad:  sum = 26 ± 6    avg = 155, sig = 30
      3. 12TC05 (cr 1 ch 97):   reported to be still bad and masked in fee cr1 bd4 JP1
        => known to have very high ped, not analyzed

      Needed to be checked
      1. 02TC06 (cr 2 ch 98):   seems ok right now, but still marked in Pplots as bad
        =>  looks fine:  sum = 187 ± 16    avg = 192, sig = 42
      2. 04TD10 (cr 3 ch 45):   seems ok now, not masked
        =>  looks fine:  sum = 223 ± 18    avg = 187, sig = 35

      Fixed before run
      1. 09TA05 (cr 5 ch 105):   base replaced, looks ok
        =>  looks fine now:  sum = 177 ± 16    avg = 155, sig = 30
      2. 11TA01 (cr 6 ch 56):   base replaced, looks ok
        =>  looks fine now:  sum = 128 ± 13    avg = 120, sig = 26
      3. 12TD01 (cr 1 ch 40):   HV recently lowered by 125 V, current gain now looks too low
        => PROBLEM!    gain very low now:  not analyzed, average of peers = 140
      4. 03TC09 (cr 2 ch 76):   cable replaced, now looks ok
        => PROBLEM!    gain too low now:  sum = 42 ± 8    avg = 173, sig = 40
      5. 05TA03 (cr 3 ch 58):   cable replaced, now looks ok
        =>  looks fine:  sum = 144 ± 14    avg = 161, sig = 40
      6. 08TC05 (cr 5 ch 101):   cable replaced, now looks ok
        =>  looks fine:  sum = 150 ± 14    avg = 155, sig = 30

      Extreme outliers
      • 07TD10 (cr 5 ch 5) and 11TB08 (cr 6 ch 67) had sums that were very high
        =>  need to monitor these to see if they are flagged as "hot".


    Endcap Tower Timing Settings Run 9

    For now see link to blog page:

    and go to Section IV

    Uploading EEMC Pedestal, Status and Gain Calibrations to the DB

    This page is intended to document the process of uploading EEMC calibrations to the DB using the "eemcDb" utility script originally written by Jan Balewski.  Some old notes from Jan are here.  Before we begin, a quick reminder that this is not a task many people should need to do but should be limited to one or two "experts", who will be given special DB writing priviledges by Dmitry Arkhipkin (  The code is all in CVS though for documentation purposes.

    Building the eemcDb utility:

    All the uploads to the EEMC DB are handled by the eemcDb utility which Jan called the "swiss army knife" of DB uploads.  The source code to build the eemcDb executible can be found in CVS.  To compile the script follow these quick instructions

    mkdir yourDirectory
    cd yourDirectory
    cvs co StRoot/StDbLib/
    cd StRoot/StDbLib/
    cd ../../
    cvs co StRoot/StEEmcUtil/database/macros/upload/src/
    cd StRoot/StEEmcUtil/database/macros/upload/src/

    Then the eemcDb executible is ready to use.  It can be tested with a simple read command:

    eemcDb -r -p Ver2004d/ -T

    Uploading tables to the DB:

    Thre are several scripts for uploading pedestal, status and gain tables to the DB located in CVS at StRoot/StEEmcUtil/database/macros/upload/.  The names are fairly obvious, but just in case, here is the breakdown:

    writeIdealGains.C :  writes ideal gain tables in ascii files to be uploaded
    writeIdealPed.C : write ideal ped tables (pedestal = 0) in ascii files to be uploaded
    writeIdealStatus.C : write ideal status tables (status = 0) in ascii files to be uploaded

    In the following scripts you need to specify the location of the eemcDb executible (compile instructions above) as its currently listed as "yourDirectory."  Also there are various exit lines in the scripts which you'll need to comment out once you're ready to upload (they kept me from accidental uploads in the past so I kept them in place). :
    • script which executes eemcDb to write MAPMT gain files to the DB
    • requires user input of timestamp, table "flavor", gain file location, and comment to go in DB :
    • script which executes eemcDb to write tower gain files to the DB
    • requires user input of timestamp, table "flavor", gain file location, and comment to go in DB
    loadPed+Status.tcl :
    • script which executes (below) for many runs from the input file which specifies the fillNumber, runNumber, and unix timestamp
    • requires user input of list of runs and comments to go in the DB :
    • script which executes eemcDb to write pedestal and status files (for both towers and MAPMT) to the DB
    • loadPed+Status.tcl should provide user input of timestamp, table "flavor", gain file location, and comment to go in DB

    One last note that in order to upload to the DB you need write priviledges from Dmitry and to execute the following command which allows you to write to the DB.  Once you're done with the upload remove this to prevent "accidental" uploads.
    setenv DB_ACCESS_MODE write

    EEMC Detector Operator Manual

    Link to current EEMC Detector Operations manual

    This should also come up as the homepage on eemc-spin in the STAR control room.


    EEMC Maintenance/Operations Documents

    Detailed operations manual

    Over the years I have maintained a text based operations manual for the EEMC.  It has a lot of expert information and detail in it.

    The version in the control room has all the passwords filled in.  Of course the pw should not appear on the web so are blank here.   Consult the shift leader for any pw needs.

    The run 10 version is attached below.


    ESMD (Shower Max and Pre- & Post-Shower Detectors)

    ETOW (Towers)

    Endcap Geometry

    Geometry definition

    1. Detailed description of the geometry (ver 5.1) as implemented by
      Oleg Rogachevski are listed in the depth.txt file
    2. Distribution of material as fuction of eta and phi
    3. Mapping of SMD strips to towers (11/20/03 jwebb)

    Geant pictures of calorimeter are generated with plot_geom.kumac

    1. View of EndCap caloremeter (variant C) in STAR detector

    2. cross section of calorimeter towers variant C

    3. cross section of lower half of calorimeter plane ZY at X=0

    4. cross section of calorimeter (var.C) plane ZY at X=30cm

    5. cross section at eta=2.0front part with SMD

      line eta = 2.0 intersects megatile (blue) at its center
      and radiators (black) at forward edge.
      Hub is seen at upper edge. Each megatile extends from eta=2 to hub
      as nonactive plastic and radiator extends as stainless steel.

    6. cross section at eta=1.086 front part with SMD

      line eta = 1.086 intersects megatile at its center
      and radiators at the back edge of radiator
      Projective (20x25 mm) bar is seen at the lower edge of calorimeter
      XXX page 9 - megatile cell structure in local coordinates, particles go along Y axis on this plot.

    7. regular SMD sector, V plane, blue line depicts +-15 deg. between sectors

    8. edge SMD sector with cutted strips, V plane

    9. cross section of 1st SMD plane

    10. cross section of 2st SMD plane

    11. cross section of 3st SMD plane

    12. cross section of 1st SMD plane labeled with "SUV" ordering

    13. cross section of the gap between SMD sectors

    14. cross section of the gap between tower at the sector boundary

    15. cross section of the backplate

    Three variants of EEMC geometry are available:
    A --- lower half with only 5-8 sectors filled with scintillators
    B --- fully filled lower half
    C --- both halves filled with scintillators

    Endcap Geometry update (2009)

    EEMC geometry v6.0

    Proposed name for the geometry file: pams/geometry/ecalgeo/ecalgeo1.g

    List of changes

    • CAir bug fixed
    • Increased size of mother volume containing SMD strips
    • Added material to front and back of SMD planes (material wrapping SMD planes)
    • Added SMD spacer layers
    • Introduced sector overlaps closer to the "as build" geometry
    • Birk's law constants for SMD strips corrected
    • Some dimention paramaters tuned to that in real geometry
    • Code reorganized and commented

    Lead alloy mixtures are not implemented
    due to the problem with mixture in GSTAR/Geant (see below)

    Resulting improvements in the simulated EEMC response

    • Geometry configuration is closer to the "as build" geometry
    • Correct simulation of the transverse shower shape profile
    • Realistic (close to 5%) sampling fraction
    • More realistic simulation of the tower energy profile (with LOW_EM option)

    Supporting materials

    EEMC sampling fraction nonlinearities and CAir bug

    EEMC geometry reshape

    Issue with mixture in GSTAR/Geant

    Jason's tests and studies

    1. Validation of EEMC MC Geometry
    2. SMD Problems at the sector boundary
    3. EEmc MC Geometry version 5.21
    4. Rough cut of EEMC SMD spacer geometry
    5. Check of material in corrected EEMC geometry
    6. Linearity Check in fixed ecalgeo.g, take II
    7. Linearity Check in fixed ecalgeo.g
    8. List of small, almost trivial, problems with the Monte Carlo
    9. EEMC simulation study: mockup of CDF testbeam experiment
    10. Verify that the fast simulator sees all of the energy deposited in geant
    11. Energy dependence of the sampling fraction in the EEMC
    12. EEMC simulation studies (spin-pwg-simulations-report-07-30-2009.pdf)

    Ilya's tests and studies

    1. new EEMC geometry: Pure lead and new SMD layers
    2. Jason EEMC geometry: Effect of ELED block change
    3. Jason EEMC geometry: results with and without LOW_EM options
    4. Jason EEMC geometry: Jason with ELED block from CVS file
    5. Jason EEMC geometry: comparison without LOW_EM option
    6. Jason EEMC geometry: effect of removing new SMD layers
    7. Jason vs. CVS EEMC: removed SMD layers
    8. Sampling fraction problem: full STAR vs. EEMC stand alone geometry
    9. Jason geometry file: Full STAR simulations (sampling fraction, shower shapes)
    10. Jason geometry tests: SMD energy, number of strip vs. thrown photon position
    11. Effect of added layers in Jason geometry file
    12. Volume id fix in Jason geometry file
    13. Jason vs. CVS EEMC geometry: sampling fraction and shower shapes
    14. Test of corrected EEMC geometry: LOW_EM cuts
    15. EEMC geometry tests: on-off SVT detector and EEMC slow-simulator
    16. Single particle MC with corrected geometry vs. eta-meson from data
    17. Corrected EEMC geometry: shower shapes
    18. Corrected EEMC geometry (bug 1618)

    Alice's tests and studies

    1. Summary of Lead Problems
    2. Further tests with lead
    3. Testing changes to cvs geometry file
    4. Some geometry tests

    Log of tower base and fee issues

    Attached is a text file of tower base and other issues.  I went back through the electronic shift log and recorded all the bases that had been replaced and recording of other fixes and problems.  The status as of the begin of the run 10 is also stated.


    eemc as-built info and proto tests

    Here starts 8/09 a collection of misc. information re: as-built eemc from construction documentation and prototype testing of various sorts.

    ... to be detailed

    emc2-hn minutes (by Jan)

    • xx xx, 200x
      • next,
    • xx xx, 200x
      • next,
    • xx xx, 200x
      • next, I forgot to edit this


    how-to by Jan


    offline DB upload (write)

     Loose notes helping Justin in uploading of the offline DB tables for Endcap


    1) Monitoring current content of DB,


    use web interface: 

    The following query selects pedestal tables for sector 1 (element ID) for year 2007+ 

    results with just 2 tables:

    • the official (just one) table for 2007 run (flavor 'ofl') valid since April 5, 4:40 pm  GMT   (note it is not EST)
    • test table ( flavor=online  ) for 2008 run, valid since February 22

    If you click on 'Control' you will see the content of this table, but I rarely do that


    2) Upload  new tables to DB

    • need special DB write privileges, only Jan Y Justin have such.
    •  setenv DB_ACCESS_MODE write
    • execute _working_ version of eemcDb with proper params
    • you do NOT need any more the dbServer.xml file pointing to robinson.db, so do NOT have it in your main directory

    Note, the last successfully compiled and working eemcDb is located at:

    /star/u/balewski/dbaseIO-2008-sc.starp/eemcDb - use it as long as it works.

    The source code is at sc.starp , user=sysuser, directory: junk2/


    Good luck,



    offline DB usage (read)

    DB usage : ped, gains, fail/stat flags for EEMC towers/pre/post/SMD

    Wed Oct 27 13:09:10 EDT 2004
    Key features:




  • EEMC DB consist of 4 basic components: map of hardware channels to logical elements, peds, gains and fail/stat bits. The content of all DB tables for all time stamps is described in eLog entry 605 .


  • An independent set of tables with the 'sim' flavor is stored with beginTime of Jan 1 1999. If selected, allows to run ~exactly the same code on the M-C or real events.
    Content of 'ideal' simulation tables:
    * channel map as of October 2004
    * tower gains : 4096 ADC=60 GeV transverse electromagnetic energy in the tower
    * pre/post/smd gains : 23,000 ADC = 1 GeV of energy deposit by a MIP in scint
    * all pedestals set at 0 ADC, but sigPed of 1.0 ADC for Towers and of 0.7 ADC for MAPMT
    * masks: fail=stat=0 , meaning all elements are good

    The above content of sim-tables is consistent with the actual fast EEMC simulator code and hits stored in StEvent & muDst.
    Note, in the M-C a sampling fraction of 5% is assumed while converting GEANT energy deposit in tower scint layers to tower ADC. In order to get ~right pi0 or gamma energy a fudge factor of ~4/5 is still needed.


  • Example of geometrical manipulations:
  • The definition of all possible stat/fail bits values is at $STAR/StRoot/StEEmcDbMaker/cstructs/eemcConstDB.hh.
    For 2004 data the following 'stat' bits are in use:
    #define EEMCSTAT_ONLPED   0x0001 // only pedestal visible
    #define EEMCSTAT_STKBT    0x0002 // sticky lower bits
    #define EEMCSTAT_HOTHT    0x0004 // masked for HT trigger
    #define EEMCSTAT_HOTJP    0x0008 // masked for JP trigger
    #define EEMCSTAT_HIGPED   0x0010 // ped is very high but channel seems to work
    #define EEMCSTAT_HOTSTR   0x0020 // hot esmd strip
    #define EEMCSTAT_JUMPED   0x0040 // jumpy  ped over several chan over days
    #define EEMCSTAT_WIDPED   0x0080 // wide ped over:2.5 ch  towers, 1.5 ch MAPMT's
    It is up to a user what 'stat' condition is fatal for his/her analysis.
    Potentaily good elements may have set the 'STKBT', meaning the lowest bit(s) did not worked and only the energy reolution is worse.
    'JUMPED' bit means ped jumped by 20-40 ADC counts during one run. It is fatal for calibration with MIP's but ~OK for reco of 20 GeV gammas.

    For the record the following 'fatal' bits are set and all users should reject all elements marked that way.

    #define EEMCFAIL_GARBG  0x0001  // exclude from any analysis
    #define EEMCFAIL_HVOFF  0x0002  // HV was off
    #define EEMCFAIL_NOFIB  0x0004  // signal fiber is broken
    #define EEMCFAIL_CPYCT  0x0008  // stuck in copyCat mode
  • To see all stat/fail tables for sector 5 type:
    ~/ezGames/dbase/src/eemcDb -p Ver2004d/sector05/eemcPMTstat -H -t 2001
    To see content of stat/fail table for a given time stamp type:
    ~/ezGames/dbase/src/eemcDb -p Ver2004d/sector05/eemcPMTstat -g -t 1080832032


    Use constants defined in


    Access to EEMC DB-maker within the chain
    In .h add
    class  StEEmcDbMaker;
    class StYourAnalysistMaker : public StMaker {
      StEEmcDbMaker *eeDb;
    In .cxx add
    #include "StEEmcDbMaker/StEEmcDbMaker.h"
    #include "StEEmcDbMaker/EEmcDbItem.h"
    #include "StEEmcDbMaker/cstructs/eemcConstDB.hh"
    #include "StEEmcUtil/EEfeeRaw/EEname2Index.h"
    StYourAnalysistMaker::Init() {
     // connect to eemcDB
      eeDb = (StEEmcDbMaker*)GetMaker("eemcDb"); // or "eeDb" in BFC
      assert(eeDb); // eemcDB must be in the chain, fix it


    Details of DB usage for muDst events , loop over hist for one event:
     // choose which 'stat' bits are fatal for you, e.g.
     uint killStat=EEMCSTAT_ONLPED  | ......... ;
       StMuEmcCollection* emc = mMuDstMaker- >muDst()- >muEmcCollection();
      //.........................  T O W E R S .....................
      for (i=0; i < emc->getNEndcapTowerADC(); i++) {
        int sec,eta,sub,rawAdc; //muDst  ranges:sec:1-12, sub:1-5, eta:1-12
        assert(sec>0 && sec< =MaxSectors);// total corruption of muDst
        //Db ranges: sec=1-12,sub=A-E,eta=1-12,type=T,P-R ; slow method
        const EEmcDbItem *x=eeDb->getTile(sec,'A'+sub-1,eta,'T');
        ...... this is the same also for pre/post/smd (except ene fudge factor!)................
        assert(x); // it should never happened for muDst
        if(x->fail ) continue;  // drop broken channels
        if(x->stat &  killStat) continue; // drop not working channels
        if(x->gain < =0) continue; // drop it, unless you work with ADC spectra
        if(rawAdc < x-> thr) continue; // drop raw ADC < ped+N*sigPed
        float adc=rawAdc-x->ped; // ped subtracted ADC
        float ene=adc/x->gain;   // energy in GeV
        if(MCflag) ene/=0.8; //fudge factor for TOWER sampling fraction,  to get pi0, gamma energy right
        .... do your stuff ..........
     } // end of towers
     //.........................  P R E - P O S T .....................  
      int pNh= emc->getNEndcapPrsHits();
      for (i=0; i < pNh; i++) {
        int pre, sec,eta,sub;
        //muDst  ranges: sec:1-12, sub:1-5, eta:1-12 ,pre:1-3==>pre1/pre2/post
        StMuEmcHit *hit=emc->getEndcapPrsHit(i,sec,sub,eta,pre);
        float rawAdc=hit->getAdc();
        //Db ranges: sec=1-12,sub=A-E,eta=1-12,type=T,P-R ; slow method
        const EEmcDbItem *x=eeDb-> getTile(sec,sub-1+'A', eta, pre-1+'P');
        if(x==0) continue;
        ..... etc, as for towers ....
       //.......................  S M D ................................
      char uv='U';
      for(uv='U'; uv < ='V'; uv++) {
        int sec,strip;
        int nh= emc->getNEndcapSmdHits(uv);
         for (i=0; i < nh; i++) {
          StMuEmcHit *hit=emc->getEndcapSmdHit(uv,i,sec,strip);
          float rawAdc=hit->getAdc();
          const EEmcDbItem *x=eeDb->getByStrip(sec,uv,strip);
          assert(x); // it should never happened for muDst
          ... etc, as for towers ....


    Details of DB usage for StEvent , loop over hist for one event - posted for the record.
    Remember, NEVER EVER access EEMC data from StEvent. It is so slow and clumsy. It is asking for a trouble. All EEMC analysis SHOULD work on muDst ONLY - Jan
     T O W E R S 
     // choose which 'stat' bits are fatal for you, e.g.
     uint killStat=EEMCSTAT_ONLPED  | .......;
     StEvent*  mEvent = (StEvent*) StMaker::GetChain()->GetInputDS("StEvent");  assert(mEvent);
     StEmcCollection* emcC =(StEmcCollection*)mEvent->emcCollection(); assert(emcC);
     StEmcDetector* etow = emcC->detector(kEndcapEmcTowerId);  assert(etow);
     for(uint mod=1;mod < =det->numberOfModules();mod++) {
        StEmcModule*     module=det->module(mod);
        StSPtrVecEmcRawHit&     hit=  module->hits();
        int  sec=mod ; // range 1-12
        for(uint ih=0;ih < hit.size();ih++){
          StEmcRawHit *h=hit[ih];
          char sub='A'+h- >sub()-1; // range 'A' - 'E'
          int  eta=h->eta(); // range 1-12
          int  rawAdc=h->adc(); // raw ADC
          //Db ranges: sec=1-12,sub=A-E,eta=1-12,type=T,P-R; slow method
          const EEmcDbItem *x=eeDb->getTile(sec,sub,eta,'T');
          if(x==0) continue;
          ....  now follow muDst example for towers ....
        } // end of sector

    PRE1,PRE2, and POST -all mixed together preL='P','Q','R' for pres1,pres2,post, respectively StEmcDetector* det=emcC- > detector(kEndcapEmcPreShowerId)//==(14) for(int imod=1;imod < =det- > numberOfModules();imod++) { StEmcModule* module=det- > module(imod); printf("EPRE sect=%d nHit=%d\n",imod, module- > numberOfHits()); StSPtrVecEmcRawHit& hit= module- > hits(); int ih; for(ih=0;ih < hit.size();ih++){ StEmcRawHit *x=hit[ih]; int sec=x- > module(); int ss=x- > sub()-1; char sub='A'+ss%5; char preL='P'+ss/5; int eta=x- > eta(); int adc=x- > adc(); printf("ih=%d %02d%c%c%02d ss=%d -->adc=%d ener=%f ss=%d\n",ih,sec,preL,sub,eta,ss,adc, x- > energy(),ss); }

    SMD U & V are stored in SEPARATE collections StEmcDetector* det=emcC- > detector(kEndcapSmdUStripId)// U=15, V=16 for(int imod=1;imod < =det->numberOfModules();imod++) { StEmcModule* module=det- > module(imod); printf("ESMD sector=%d nHit=%d\n",imod, module- > numberOfHits()); StSPtrVecEmcRawHit& hit= module- > hits(); int ih; for(ih=0;ih < hit.size();ih++){ StEmcRawHit *x=hit[ih]; int sec=x- > module(); int strip=x- > eta(); int adc=x- > adc(); printf("ih=%d %02dU%03d -->adc=%d ener=%f\n",ih,sec,strip,adc, x- > energy()); }

    Details of the DB- Maker(s) setup in the muSort.C script:


  • By default ADC threshold (x->thr) is set at 3*sigPed. You may change 3.0 to any other (float) factor :
    myDb=new StEEmcDbMaker("eemcDb");
  • To switch to (ideal) simulation DB tables you need to change DB flavor for the St_db_Maker (different from StEEmcDbMaker ):
      St_db_Maker *dbMk=new St_db_Maker("db", "MySQL:StarDb", "$STAR/StarDb");
        ? dbMk->SetDateTime(20031120,0);  (you may need to specify the DB time stamp)
    To verify the ideal DB tables were loaded you should find in the log-file the following message for every sector:
      EEDB  conf ADC map for sector=6
    StInfo:       EEDB chanMap=Ideal EEMC mapping, (October 2004), RF
    StInfo:       EEDB calTw=Ideal EEMC tower gains, E_T 60GeV=4096ch, RF
    StInfo:       EEDB tubeTw=Ideal EEMC P-names, (October 2004), RF
    StInfo:       EEDB calMAPMT=Ideal EEMC P,Q,R,U,V gains, 23000ch/GeV, RF
    StInfo:       EEDB ped=Ideal EEMC peds/ADC at 0.0, sig: Tow=1.0, Mapmt=0.7; RF
    StInfo:       EEDB stat=Ideal EEMC stat=fail=0 (all good), RF
    To use Barrel ideal DB do
      starDb->SetFlavor("sim", "bemcPed");
      starDb->SetFlavor("sim", "bemcStatus");
      starDb->SetFlavor("sim", "bemcCalib");
      starDb->SetFlavor("sim", "bemcGain");



    slow controls archive viewer

    There is a viewer for slow controls quantities documented at

    There is an interface through a web browser or a java script.  Both must run from the starp internal network.  I used the java script run from sc.  Two plots of voltage tracking are attached.  These were made via screen capture of the display.




    Trash pages for testing

    chain tricks


    > do I remember it correct the current implementation of StMaker() does
    > not prevent execution of subsequent makers in the chain even if the
    > earlier one returns:
    > return kStErr;
    It depends. If maker is "privileged" then loop is ended.
    Normal user makers are not priviliged, to avoid skipping of other users
    The priviliged ones are all I/O makers and StGeantMaker (which is also I/O
    User could define his maker as a priviliged:
    instead of:
    user should:
    chain->SetAttr(".Privilege",1,"UserMakerName" );




    Endcap Sofware  2006++


    test entry

    test child page control


    Fig. 1 Tower Crate

    Fig. 2 Crate 64-67

    Fig. 3 Crate 68-71

    Fig. 4 Crate 72_75

    Fig. 5 Crate 76-79

    Fig. 6 Crate 80_83

    Fig. 7 Crate 84-87

    Fig. 8 Crate 88-91

    Fig. 9 Crate 92-95

    Fig. 10 Crate 96-99

    Fig. 11 Crate 100-103

    Fig. 12 Crate 104-107

    Fig. 13 Crate 108-111

       Plots of channels  


    Welcome to the area for the STAR Event Plane Detector (EPD)

    Placeholder for the Event Plane Detector information.

    2017 cosmic ray tests at OSU and BNL

    Scans of the logbook for supersector tests may be downloaded here:

    Excel file with data:

    Test configuration 1







    Cosmic Tests at BNL - Diagonal issue

    While running at BNL, it was noticed that there was a diagonal line when looking at the correlation between two tiles.  Essentially, they would both fire, and with ADCs that are strongly correlated.

    Figure 1: Example correlation between two tiles on the left, example correlation between a tile and the empty tile at tile "zero".

    In Figure 1, we can see an example of this.  As expected, one can see that pedestal and mip peak for each tile, completely uncorrelated with the signal in the other, except for the points along the diagonal.  In fact, this was even seen in the first channel when running on evens (which we have called tile 0).  Since there is no tile, or fiber, there is no way for there to be a signal.

    The entire set of correlations can be seen at:
    It should be noted here that the last 4 tiles of the bottom SS were removed from the ADC in slot 7 to the empty ADC (given the labels blank0, etc).  In fact, if we select events in which tile 0 in the top supersector had a significantly higher than pedestal value (adc > 250), we see that we can pull this diagonal correlation from all channels, other than those from the "empty" ADC:

    What was noticed is that the last ADC, which had been empty, did not show this characteristic diagonal correlation.  This is true even with the data being added to it.  (We noted that the empty channels in the previously full ADC do show it, but none of the channels on the empty one showed it either before or after putting the data into the system).  One difference was the timing, the first 4 ADCs were 28 ns behind.  Another was that the logic feeding these ADCs, it looked sort of like the 4-fold coincidence was a 3-fold (at least it was firing more often than the other, and we could not put the level any higher in coincidence), so we moved this cables into a more stable one and verified that both sets now fired precisely the same.  We also removed the 28 ns of extra cable, so everything was a the same timing.

    After doing this, the diagonal correlation seems to go away:

    Figure 2: Two correlations after our fix which do not seem to show the diagonal line.

    In Figure 2, we do not see any evidence of this correlation.  On the left is the correlation between tile 14 on the top and in the middle, so the correlation in the middle is from true cosmic rays.  On the right is the correlation between tile 14 on the top and tile 6 in the middle.  One can see the pedestal and MIP peaks for both, which are mostly uncorrelated as expected.  (The few points in the middle could be from diagonal cosmics.)

    The full range of correlations from these channels can be seen at: 

    First Autumn 2017 cosmic tests at STAR

    After Thanksgiving, we have placed a stack of three supersectors on the top platform ("roof") of STAR.  Above and below the stack are position-sensitive scintillator strips provided by Les Bland; these generated the trigger.  The clear fiber bundles were dangled down to the new EPD FEE box on the SE side, which have six FEE cards (the same ones used in the 2017 run).  These are powered by a new power supply and the signals brought to the EPD rack C1 on the first level of the south side platform.

    Phase 1 - Nov-Dec 2017

    For "phase 1" of these tests, we are reading out with a CAMAC-based DAQ system which was developed largely by Wanbing He and Xinyue Ju.
    Here are some photos of the first day of "phase 1".

    The set-up on the SE side of the upper platform of STAR.  Three SS are sandwiched between the trigger scintillator strips.

    The SS stack is seen in the upper left of this photo. The fiber bundles (black, so difficult to distinguish) are dangled down to the shiny FEE box which sits by itself in the otherwise-brown region.

    The populated FEE box with 6 FEEs.  We managed to make it look relatively neat, but assembling a full box will require a couple of hours of very careful work.  We have put advice in the log book for the future.

    Not a great photo of our set-up in the 1C1 and 1C2 racks on the platform.  Left rack (1C1) from top down: simple trigger electronics in NIM bin; TUFF box; DAQ (mac) computer; DAQ PS; CAMAC crate carrying Rx cards.  (The CAMAC crate with the Rx cards has voltages set to 6.5 V rather than 6 V.)  Right rack (1C2) has a CAMAC crate (set to 6 V) with 5 LRS ADCs, a LRS TDC and the crate controller.

    The new TUFF PS is much nicer on the back, and on the front panel, voltage and current for the positive and negative supplies are indicated.

    First MIP peaks from one hour of running.  Top, middle and bottom Supersector signals are shown, for odd-numbered tiles.  Small tiles in top SS don't show good peaks, probably due to trigger timing issues which we are looking into.

    Update 2 Dec 2017

    First production data using the trigger PMTs has been taken and is being analyzed by Te-Chuan and Joey.  Their first study is inspired by the Prashanth's analysis of the pre-2017 run tests done by Prashanth and Les.  See his study at

    Joey/Te-Chuan, please update with your stuff here. 
    First results of ADCs from vertical cosmic rays:
     - Landau fits:
     - presentation by Te-Chuan:

    Update 5 Dec 2017

    It was noted by Te-Chuan that the ADC distribution for TOP Tile 15 goes all the way to 1024 (hence saturates at the high end).  The pedestal was close to 500 counts, which is quite high.  (One sees this also in the photos of the spectra above.)  It turns out that our high pedestals are due to the overly wide gate I had set.  As seen in the photo below, we see that we sit very nicely in the gate, but the gate itself is about 275 ns (compare to ~80 ns that we use in STAR).  The pedestal one expects is

    pedestal = (baseline voltage) * (gate width) / [(input impedance) *(ADC conversion factor)
    = (baseline voltage) * (275 ns) / [(50 ohm)*(0.25 pC/count)
    = (baseline voltage) * (22 count/mV)

    This should be added to the "typical residual pedestal" of the 2249A (see here) quoted as
    1 + [(0.03 pC)/(0.25 pC/ct)*(t in ns) = 34 counts for our gate

    The baseline voltages coming out of the Rx cards are of order 10 mV, so we expect pedestals of about 250 counts.  I know these "typical residual pedestals" can vary significantly, so 350 counts is not crazy.  500 counts is still a bit high, but I am not shocked, since baseline voltage will vary, too.

    Output of the Rx cards for the same tile-number from the three stacked supersectors fall well within the gate.  They have baseline offsets of about 10 mV.  The gate is overly wide, about 275 ns.


     This will be a page that aggregates information for calibrating the EPD.

    Welcome to the EPD calibration page. From here, you can:

    • Find a calibration status for any year and run
    • Learn how to calibrate the EPD
    • Get current software to calibrate the EPD and display EPD issues

    Sections generally provide links to more detailed information.


    Calibration Status

    This is the current and past calibration status for the various runs in STAR. All runs will also show whether they are complete, in progress, or not yet started.

    Run 20 calibrations:

    • Status: in progress
    • 7.7 GeV FXT and 9.2 GeV COL complete
    • No other energies in progress at this time (focus is on Run 19)

    Run 19 calibrations:

    Run 18 calibrations:

    Calibration Process

    The basics of calibration can be found here:

    There will be some updates to this based on more recent code, but this will get you started. Up to date code can be found here:

    EPD Meetings

    EPD Meetings
    Thursdays 08:30 (BNL time)

    Meeting Zoom

    Meeting 12 August 2021 (830 am EST)
    1. EPD Small Systems - Jordan Cory -
    2. Calibrations
    3. AOB

    Meeting 1 July 2021 (830 am EST)

    1. EPD Removal Plan
    2. Calibrations
    3. AOB

    Meeting 3 June 2021 (830 am EST)

    1. EPD Current Status
    2. Calibrations
    3. AOB

    Meeting 13 May 2021 (830 am EST)

    1. EPD EQ3 Issues and OO Running -
    2. EPD EP Resolution
    3. Calibrations
    4. AOB

    Meeting 6 May 2021 (830 am EST)
    1. dN/dphi - Xiaoyu -
    2. Run 21 Calibrations
    3. Run 21 OO Running
    4. AOB

    Meeting 11 March 2021 (830 am EST)

    1. Beamline Offset - Xiaoyu
    2. Run 21 -
    3. AOB