Roman Pot Phase II*
.png)
| Technical information |
Data analysis Elastic proton-proton scattering Central Exclusive Production Single Diffractive Dissociation pAu/pAl Ultra Peripheral Collisions |
| Software Geant4 simulation Reconstruction |
Pictures DX-D0 chamber Roman Pot Setup in the tunnel Other useful figures |
| Meetings history |
2009 setup (Phase I) Technical notes Paper reviews: A_NN and A_SS 2009 drupal website (PP2PP) |
Technical information
| Run 15 preparation Photographs of crates Roman Pot naming convention |
Trigger
|
| Alignment |
DAQ-expert materials Packages tests (Si + trig.count.) Trigger counters tests |
DAQ-expert materials
DAQ-expert materials
Test of Si detector packages:
A-6 A : STAR/system/files/userfiles/2729/file/Assembly_test/Assembly_A6_detAcorrect.pdf
A-6 B : STAR/system/files/userfiles/2729/file/Assembly_test/Assembly_A6_detBcorrect.pdf
A-6 C : STAR/system/files/userfiles/2729/file/Assembly_test/Assembly_A6_detCcorrect.pdf
A-6 D: STAR/system/files/userfiles/2729/file/Assembly_test/Assembly_A6_detDcorrect.pdf
A-6 Trigger system: STAR/system/files/userfiles/2729/file/Assembly_test/A_6_cosmic.pdf
A-1 A: STAR/system/files/userfiles/2729/file/Assembly_test/AssemblyA1_detA(1).pdf
A-1 B: STAR/system/files/userfiles/2729/file/Assembly_test/Assembly_A1_detB(1).pdf
A-1 C: STAR/system/files/userfiles/2729/file/Assembly_test/Assembl_A1_detC.pdf
A-1 D: STAR/system/files/userfiles/2729/file/Assembly_test/Assembl_A1_detD.pdf
Trigger system for A-1 assembly: STAR/system/files/userfiles/2729/file/Assembly_test/PMT_A1.pdf
A-4 A: STAR/system/files/userfiles/2729/file/Assembly_test/Assembly_A_4_detA.pdf
A-4 B: STAR/system/files/userfiles/2729/file/Assembly_test/Assembly_A_4_detB.pdf
A-4 C: STAR/system/files/userfiles/2729/file/Assembly_test/Assembly_A4_detC.pdf
A-4 D: STAR/system/files/userfiles/2729/file/Assembly_test/Assembly_A4_detD.pdf
Trigger system for A-4 assembly: STAR/system/files/userfiles/2729/file/Assembly_test/PMT_A_4.pdf
B-1 A: STAR/system/files/userfiles/2729/file/Assembly_test/Assembly_B1_detA.pdf
B-1 B: STAR/system/files/userfiles/2729/file/Assembly_test/Assembly_B_1_detB.pdf
B-1 C: STAR/system/files/userfiles/2729/file/Assembly_test/Assembly_B_1_detC(1).pdf
B-1 D: STAR/system/files/userfiles/2729/file/Assembly_test/Assembly_B_1_detD.pdf
Trigger system for B-1 assembly: STAR/system/files/userfiles/2729/file/Assembly_test/B_1_cosmic.pdf
B-2 A: STAR/system/files/userfiles/2729/file/Assembly_test/Assembly_B2_detA.pdf
B-2 B: STAR/system/files/userfiles/2729/file/Assembly_test/Assembly_B_2_B.pdf
B-2 C: STAR/system/files/userfiles/2729/file/Assembly_test/Assembly_B_2_C.pdf
B-2 D: STAR/system/files/userfiles/2729/file/Assembly_test/Assembly_B_2_D.pdf
Trigger system for B-2 assembly: STAR/system/files/userfiles/2729/file/Assembly_test/PMTB2.pdf
B-4 A: STAR/system/files/userfiles/2729/file/Assembly_test/Assembly_B4_detA.pdf
B-4 B: STAR/system/files/userfiles/2729/file/Assembly_test/Assembly_B4_detB.pdf
B-4 C: STAR/system/files/userfiles/2729/file/Assembly_test/Assembly_B4_C.pdf
B-4 D: STAR/system/files/userfiles/2729/file/Assembly_test/Assembly_B4_detD.pdf
Trigger system for B-4 assembly: STAR/system/files/userfiles/2729/file/Assembly_test/B_4_cosmic.pdf
B(A)-5 A: STAR/system/files/userfiles/2729/file/Assembly_test/Assembly_BA5_detA.pdf
B(A)-5 B: STAR/system/files/userfiles/2729/file/Assembly_test/Assembly%20_BA5_detB.pdf
B(A)-5 C: STAR/system/files/userfiles/2729/file/Assembly_test/Assembly_BA5_detC.pdf
B(A)-5 D: STAR/system/files/userfiles/2729/file/Assembly_test/Assembly_BA5_detD.pdf
Trigger system for B(A)-5 assembly: STAR/system/files/userfiles/2729/file/Assembly_test/PMT_BA5.pdf
A-3 A: STAR/system/files/userfiles/2729/file/Assembly_test/Assembly_A3_detA.pdf
A-3 B: STAR/system/files/userfiles/2729/file/Assembly_test/Assembly_A3_detB.pdf
A-3 C: STAR/system/files/userfiles/2729/file/Assembly_test/Assembly_A_3_detC.pdf
A-3 D: STAR/system/files/userfiles/2729/file/Assembly_test/Assembly_A3_detD.pdf
A-3 Trigger system: STAR/system/files/userfiles/2729/file/Assembly_test/A_3_cosmic.pdf
------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------
Test of trigger counters:
Setup
Test of the trigger counters was performed using (see first photo):
- high voltage power supply,
- Tektronix MSO 3034 Mixed Signal Oscilloscope,
- beta radiation source 90Sr.
Trigger counters were left in the storage boxes to avoid possible damages. Both PMTs in the counter were supplied with the same voltage, which was changed in a range 800-1200 V. Beta source was always sitting on the surface of the scintillator, pointing to it (like on the second photo). Measurements were done with the source in a few different points on the surface of the scintillator, in order to determine position dependencies. As shown in the third photograph, storage boxes with trigger counters were additionally placed inside the folder with zipper to fully avoid influence of the external light.
In order to enable offline analysis, some number of waveforms from both channels (PMTs) was stored on a USB flash memory in *.isf format (internal save format of the scope). Then, isf files were converted into ROOT histograms and processed (contact me to get the converting program).
Dark noise measurement
This measurement was done without use of the 90Sr source. Signals were triggered with very low threshold value (order of mV, depends on supplying voltage). The lack of signal in the PMT other than the triggering one (like on the figure below; red = channel 1, blue = channel 2) was a confirmation for non-cosmic-ray origin of the pulse.
For such events the dark-noise peak amplitudes were histogramed. Links to plots of these histograms are contained below.
A-3 A-6 B(A)-5 B-1
As an output the dark noise levels as a function of the supplying voltage were prepared for each channel separately: DARK NOISE vs. VOLTAGE.
Detailed tests with 90Sr source - part 1
The main part of the test was done with the beta source placed in three points on the scintillator, as shown in red on the right-hand side sketch. For each position of the source and each PMT voltage, about 150 triggers were collected. The triggering threshold was set to ~2sigma above the noise level, based on the dark noise measurement (see above). Only one of the channels was set to trigger. An exemplary output from oscilloscope is presented in the left-hand side figure (below), together with description of quantities whose distributions are available in the table below.
| quantity \ counter | A-3 | A-6 | B(A)-5 | B-1 |
|---|---|---|---|---|
| Signal amplitudes (correlation between channels and 1-D amplitude distributions) |
||||
| Signal integrals (correlation between channels and 1-D integral distributions) |
||||
| Time difference between moments of reaching the threshold by signals in two channels |
||||
| Rise time (correlation between channels and 1-D rise time distributions) |
||||
| Fall time (correlation between channels and 1-D fall time distributions) |
Explanation of quantities from the table:
Signal amplitude is nothing but the maximum absolute value of the pulse (at peak).
Signal integral is simply an integral of the pulse over time.
Time difference (\delta t, difference in time of discrimination) is the time interval between the moment of reaching the threshold level by the pulses in two channels (see the left figure above).
Rise time is defined as the time interval for the pulse to reach 10% and 90% of its peak value (see the left figure above).
Fall time is defined as the time interval for the pulse to fall from 90% to 10% of its peak value (see the left figure above).
One should note, that the time difference contains a component which depends e.g. on the lenght of wires connecting PMTs with the oscilloscope, so only the relative time difference ("difference between time differences") should be studied.
Detailed tests with 90Sr source - part 2
The second part of the tests was also done with the use of beta source, this time however a more detailed position dependence (11 different points) of the pulse properties was checked. For each position of the source and supplying voltage only one waveform (for each channel) was saved (instead of ~150 as in part 1), however, a waveform itself was an average of 512 triggered pulses (the same trigger thresholds were set for corresponding voltages as in part 1). Examples of the average pulses from two channels are presented in figure below. Results of the 2nd part of tests are contained in the table below.
| quantity \ counter | A-3 | A-6 | B(A)-5 | B-1 |
|---|---|---|---|---|
Average-signal amplitudes |
||||
Time difference (for average signals) |
The black contour in the plots in the table above marks the area of the scintillator (8 cm x 5 cm). Colours of markers correspond to the value of presented quantity (see description of z-axis).
Detector package information
Detector package information
Here you can find all the information about performance of compononets of the Roman Pot detector packages.
Each cell in the table below corresponds to single package (as it was assembled in 2009), whose label is given at the top of the cell.
Two tables at the bottom of the page indicate the Roman Pot in which components
of each particular package (silicon planes - A, B, C and D, and trigger counter - TC)
were installed during run 2009 and 2015.
Each cell in the table below corresponds to single package (as it was assembled in 2009), whose label is given at the top of the cell.
Two tables at the bottom of the page indicate the Roman Pot in which components
of each particular package (silicon planes - A, B, C and D, and trigger counter - TC)
were installed during run 2009 and 2015.
|
A-3
Run 2009 performance: SVX pedestals:
Cluster properties (silicon data):
Trigger counter:
Pre-2015 tests:
SVX ped. and cluster properties:
Trigger counter:
|
B-4
Run 2009 performance: SVX pedestals:
Cluster properties (silicon data):
Trigger counter:
Pre-2015 tests:
SVX ped. and cluster properties:
Trigger counter:
|
A-1
Run 2009 performance: SVX pedestals:
Cluster properties (silicon data):
Trigger counter:
Pre-2015 tests:
SVX ped. and cluster properties:
Trigger counter:
|
B-1
Run 2009 performance: SVX pedestals:
Cluster properties (silicon data):
Trigger counter:
Pre-2015 tests:
SVX ped. and cluster properties:
Trigger counter:
|
|
B(A)-5
Run 2009 performance: SVX pedestals:
Cluster properties (silicon data):
Trigger counter:
Pre-2015 tests: SVX ped. and cluster properties:
Trigger counter:
|
A-6
Run 2009 performance: SVX pedestals:
Cluster properties (silicon data):
Trigger counter:
Pre-2015 tests:
SVX ped. and cluster properties:
Trigger counter:
|
B-2
Run 2009 performance: SVX pedestals:
Cluster properties (silicon data):
Trigger counter:
Pre-2015 tests:
SVX ped. and cluster properties:
Trigger counter:
|
A-4
Run 2009 performance: SVX pedestals:
Cluster properties (silicon data):
Trigger counter:
Pre-2015 tests:
SVX ped. and cluster properties:
Trigger counter:
|
| E1U | E1D | E2U | E2D | W1U | W1D | W2U | W2D | |
| A | B-4 | A-3 | B-1 | Spare | A-4 | B(A)-5 | A-1 |
B-2
|
| B | B-4 | A-3 | B-1 | A-6 | A-4 | B(A)-5 | A-1 | B-2 |
| C | B-4 | A-3 | B-1 | A-6 | A-4 | B(A)-5 | A-1 | B-2 |
| D | B-4 | A-3 | B-1 | A-6 | A-4 | B(A)-5 | A-1 | B-2 |
| TC | B-4 | B-1 | A-4 | A-6 | A-3 | B(A)-5 | A-1 | B-2 |
Run 2009
| EHI | EHO | EVU | EVD | WHI | WHO | WVU | WVD | |
| A | A-3 | B-4 | A-1 | B-1 | B(A)-5 | A-6 | B-2 |
A-4
|
| B | A-3 | B-4 | A-1 | B-1 | B(A)-5 | A-6 | B-2 | A-4 |
| C | A-3 | B-4 | A-1 | B-1 | B(A)-5 | A-6 | B-2 | A-4 |
| D | A-3 | B-4 | A-1 | B-1 | B(A)-5 | A-6 | B-2 | A-4 |
| TC | A-3 | B-4 | A-1 | B-1 | B(A)-5 | A-6 | B-2 | A-4 |
Operation instructions
Power to most of the STAR Roman Pot systems can be controlled remotely with two APC Switched Rack Power Distribution Units. Individual outlets on each rack can be turned on or off using a browser pointing to the following IP a11ddress (inside the BNL firewall):
East Roman Pots: 130.199.90.26
West Roman Pots: 130.199.90.38
A browser running on ppdaq1.phy.bnl.gov (in STAR Control room) is the prefered link to the APC, if there is a need for remote access, a connection to a NX server will give you access to a window whwre you can launch FireFox and access the URLs listed above.
Only one connection is possible to the APC, but the connections time-out after 1 minute without action
Once a connection to the APCs is established you will be asked for user name and password.
A LabView based monitor system called lv-pp2pp-slow runs a server in the ppdaq1.phy.bnl.gov computer. Clients communicate with the server to display the status of the bias and low voltage power supplies and the relevant values of voltages, currents and temperatures. One can run a client remotely by first connecting to a BNL gateway (rssh.rhic.bnl.gov) and from there login into ppdaq1.phy.bnl.gov from the daq account. (All necessary passwords need to be requested from relevant people). The client program is then launched by ~/bin/lv-ppslow &. The following window will open on you computer:
When a board fails (blown fuse or other problem we need to change the pp2pp-slow.conf and use the variable SiIgnore at the end of the file. That variable uses 32 bits which correspond to all planes as listed in the file (Plane00 correspond to the least significant bit SiIgnore = 0x00000001 and so on. This only masks out the alarm on the OneButton GUI below and the alarms (one on LV channel in question and another one on the "Global Alarm" section) would still appear in the the above GUI (lv-ppslow).
Shift crew Detector operators will interact with Roman Pots thru the "Single button" client:
Which appears above in the off position.
This window is activated with the icon:
what to do if the icon has dissapeared from the Desktop?
Possible faults as seen in the "single button" client.
Persistent Blue field:
Red Alarm:
There is also a "command line" monitor which has funcionality to peform many actions, it is called pp2pp_cmd. A snippet of the code gives you a list of all its functionality:
If there is a need to modify the pp2pp daq configuration files one needs to login as evpops (not "operator" since early 2017) on daqman.starp.bnl.gov. To reach that computer you have to be inside BNL firewall and login into the STAR gateway with your certificates (ssh -Y -A username@stargw.starp.bnl.gov). Or, you may "ssh -i ~pp2pp/.ssh/skm-key-yipkin-daqman.starp.bnl.gov evpops@daqman" from our workstation blanchett in the STAR Control Room (and ask Kin Yip for the ssh passphrase). The configuration files are in:
/RTS/conf/pp2pp/pp01.ini for the East Roman Pots,
as a reminder of which RP plane is connected to a particular sequencer use this figure:
As is shown in the figure below, each sequencer uses 4 bits to indicate which detector (plane, chain) is active and will be read. Example all planes are active 0xF
if chain D failed in E1D one should have 0x7 in ppSEQ02
/RTS/conf/pp2pp/pp02.ini for the West Roman Pots
as a reminder of which RP plane is connected to a particular sequencer use this figure:
with the corresponding variables in pp02.ini:
The cameras are at 130.199.90.6 East (air flow) 130.199.90.7 (electronics rack)
130.199.90.9 (air flow) 130.199.90.22 ElectronicsWest
East air flow: 130.199.90.6/home/homeS.html
East electronics rack 130.199.90.7/home/homeS.html
West air flow: 130.199.90.9/home/homeS.html
West electronics rack: 130.199.90.22/home/homeS.html
Igor/Dima's trick in checking the LV quickly from the command line (which is the same set commands that the pp2pp-slow-server.c uses):
In ppdaq1, we need two terminals.
- In one terminal (like "xterm"), do
"stty -F /dev/vttyAP1 time 1 min 1" and then "cat /dev/vttyAP1" (for the East), OR
"stty -F /dev/vttyAP3 time 1 min 1" and then "cat /dev/vttyAP3" (for the West),
and wait;
- In another terminal, do:
echo -ne '$00A\r' >> /dev/vttyAP1 (for the East) OR
echo -ne '$00A\r' >> /dev/vttyAP3 (for the West) ;
- Watch the first terminal for any output. If that power board/card exists, we should see a reading (output); otherwise, this may indicate that there is no such power board, when all the cables (including the relevant serial link !) have been connected.
- 'A' : AVDD1 volt reading
- 'B' : AVDD2 volt reading
- 'C' : DVDD volt reading
- 'D' : DPECL volt reading
Igor's quick initialization check:
After logging to operator@pp01-l or operator@pp02-l (from daqman.starp.bnl.gov for example),
- cd /RTS/IGOR
- Edit ppSEQ.ini to set the sequencer(s)/chain(s) that you want to initialize (just like pp01.ini/pp02.ini in /RTS/conf/pp2pp).
- ./pprun
- When working, you should see the least significant number after "read" to fluctuate between 0 and 1 when the number after "expect" changes between 2 and 3.
Running pedestal:
- Get an account for blanchett.starp.bnl.gov (by asking Wayne Betts or Michael Poat and also requesting your account be put under the "pp2pp" group).
- cd /home/pp2pp
- ./pedestal.csh run_no
- Hit return to see all the pedestals and rms' for all chains. The figures, 8 for pedestals and 8 for rms', are stored as seq_1.gif ... seq_8.gif and rms_seq_1.gif ... rms_seq_8.gif.
Looking for hints in DAQ Monitoring log files (/log/esb.log in daqman) :
- When you found errors when using the RunControl of STAR to take data, you may go to daqman.starp.bnl.gov (one can login with the operator account) to find more detailed error messages.
For example, one can do the following to find out problems related to pp02 :
grep pp02 /log/esb.log
and one might see:
[pp02-l 17:35:36 016] (pp2ppMain): ERROR: ppSEQ.C [line 98]: FAILURE: ppSEQ07: Switching to EXT clocks failed
This means that something was wrong with the clock connection to the sequencer #7.
-
A hint for which VME to reboot in /log/esb.log or /log/daq.log in daqman or in STAR Run Control Panel:
The first example may be seen in the STAR Run Control panel (used by the STAR Shifters) or in /log/esb.log
esb.log:[pp01-l 08:32:39 060] (pp2ppMain): CRITICAL: det.C [line 140]: PP2PP: RDO 1 -- too many auto-recoveries. Stopping!
esb.log:[pp01-l 08:32:49 060] (pp2ppMain): CRITICAL: esbTask.C [line 2458]: Recovery failed for RDO(s): 1 -- stopping run!
If one sees the above the "CRITICAL" message for pp01-l, one knows that it's the pp01-l (VME) in the East that's at fault and so we should reboot that VME crate. { From Tonko, this one was due to crashes in one of the sequencers and we got a message of failed recovery as there is NO recovery possible ! }
Another example, either in the Run Control panel or /log/daq.log, one might see:
daq.log:[daqman 14:14:39 065] (scDeamon): CRITICAL: scDeamon.C [line 1218]: PP2PP[1] [0x6111] Rebooted
In this case, from Tonko, "PP2PP[1]" also pointed out thtat pp01-l (VME) should be rebooted. Also from Tonko, we got this message that said "CPU rebooted" because either the CPU or the Ethernet had crashed.
-
Also, we don't need to worry about the the "ERROR" messages about "External clock" such as :
esb.log:[pp02-l 11:06:51 060] (pp2ppMain): ERROR: ppSEQ.C [line 97]: ppSEQ05: External clock reqired, but lost, status 0x80520C0F, trying to fix
esb.log:[pp01-l 11:06:51 060] (pp2ppMain): ERROR: ppSEQ.C [line 97]: ppSEQ03: External clock reqired, but lost, status 0x80520C0F, trying to fix
Tonko said: "Yes, the loss of clock seems to happen fairly often. It happens to both sides (crates) at the same time so it must be somehow related to the driver module at the TCD end. But it doesn't seem to cause any issues.Also, you will see this message at EVERY run-stop because of the way clock switch-over is sequenced. But this is completely innocuous because the run has already stopped."
Chanaka's slow-control panel to control the bias HV's for our 16 trigger PMT's:
In the Control Room, one usually just goes over to the terminal for the sc5 node. But if one wants to remotely change the HV's, one may login from any starp gateway/node (such as our "blanchett"),
In the Control Room, one usually just goes over to the terminal for the sc5 node. But if one wants to remotely change the HV's, one may login from any starp gateway/node (such as our "blanchett"),
- ssh sysuser@sc5 and find the password (for sysuser) from the folder in the STAR Control Room ;
- enter the alias command "pp2pphv" on the command prompt ;
[ From a home computer or whatever, pp2pphv may abort. So, instead of doing
"medm -displayFont scalable -x /home/sysuser/GUI/trg/pp2pp.adl" (which is what "pp2pphv" does), you may do:
medm -displayFont alias -x /home/sysuser/GUI/trg/pp2pp.adl ]
- a "PP2PP HV Controls" panel would pop up ;
- by putting the cursor on top of the "demand voltage" field of the relevant channel , one can type in to raise the voltages (such as 1100 V).
Moving Roman-Pots using the "pet" page:
One should communicate with the MCR first and gain their approval before you can move the roman-pot; otherwise, illegal roman-pot movement may result in complete beam loss.
If it's not already opened for you, you may go to any of the following "pet" page to try to move roman-pots.
- "pet" → "RHIC" → "Interaction_Regions" → "PP2PP" → "RomanCtrl" → "Sector 5" (East) or "Sector 6" (West)
OR
- "pet" → "RHIC" → "Drives" → "romanPots" → "Sector 5" (East) or "Sector 6" (West)
The two pet pages are mostly the same and we probably use the first one mostly, as the first one provides plots of the NMC radiation levels. [ But the second one allows one to re-enable the motor drive permit (by clicking "disable" and then "enable", at the bottom of each page) that the first one doesn't. This may be needed after one moves the roman-pot back to retracted position after finishing some work during an access or maintenance etc. ]
There are 4 stations on each page and we should just pay attention to the familiar names of ours such as E1U, E1D etc. For each plot, one should see "LVDT Top" or "LVDT Bottom" (under "Position Measurements"), and at the fully retracted positions, that number should about ±89 mm.
For each pot, in order to move a pot, go to the space below the word "step cmd" and type in the "absolute" (not incremental) no. of steps to move the pot. 1 mm needs about 8000 steps. ( It's "0" if the pot is fully retracted. ) After typing in the no. of steps, you should see the absolute number of 87 mm decrease. Eg. if 87 mm changes to 85 mm, it indicates that the pot has moved 2 mm towards the center of the beam pipe. To move more, you need to type in a bigger "number of steps".
The hard stop is 15 mm from the center (0 mm) but the limiting switch would limit the pot movement to around 16.5 mm or so.
To go back to the fully retracted position, just hit "home" for that pot.
ACresets :
In the unlikely event that you want to AC-reset APC or network equipment inside the tunnel, you may go to the following pet page area:
In the unlikely event that you want to AC-reset APC or network equipment inside the tunnel, you may go to the following pet page area:
- "pet" → "RHIC" → "Interaction_Regions" → "PP2PP" → "RomanCtrl" → "ACresets"
On each side (East/yo5 or West/bo6), you may "AC reset" the power of the APC (apc.acpwr) or Network Switch (nw.acpwr) or Magnum Converter (mc.acpwr). Magnum Converter converts between Ethernet signals and optical signals.
Cronjob in ppdaq1.phy.bnl.gov
There is a cronjob in /etc/cron.d/pp2pp-slow:
# Check pp2pp slow server every 2 minutes
*/2 * * * * daq /home/daq/pp2pp-slow/check-server.sh >> /dev/null
which checks whether the server is running or not and restarts it if not.
During shutdown, it may be kept as a hidden file /etc/cron.d/.pp2pp-slow (noticing the "." before "pp2pp-slow").
One can use the serial/DIGI link to look at the reboot of the VME in the tunnel, the instructions have been written in:
https://romanpot-logbook.phy.bnl.gov/Romanpot/25
East: 130.199.90.81
West: 130.199.90.120
West: 130.199.90.120
Restarting network daemon in ppdaq1.phy.bnl.gov:
One should do :
service NetworkManager restart
NOT
!!
Check lists for Installation and Repair of Roman Pot assemblies STAR/system/files/userfiles/2729/file/Assembly_test/installRP(2).pdf
Running TCD manually:
http://online.star.bnl.gov/daq/export/TCD_WWW/index.html?client=tcd-pp2pp
Goto "Scheduler" and select "Start". User name: star_tcd.
Run 15 preparation
Run 15 preparation
| Documents Roman Pot naming convention |
|
| Drawings / Schemes / Pictures Photographs of crates on EAST and WEST |
Photographs of crates
|
East
    |
West
    |
Map of connections
Click on a chosen scheme to enlarge. Similar schemes for 2009 setup can be found here.
East   |
West
   |
Trigger
Trigger
Data analysis
.png)
Central Exclusive Production analysis
The following webpage will be filled with information about the analysis of central exclusive production (CEP) process
p+p -> p+X+p,
X = pi+pi-, K+K-, pi+pi-pi+pi-, pi+pi-K+K-, K+K-K+K-
p+p -> p+X+p,
X = pi+pi-, K+K-, pi+pi-pi+pi-, pi+pi-K+K-, K+K-K+K-
Talks:
Quick analysis of Central Exclusive Production (RP_CPT2 trigger) (8 April 2015, UPC weekly meeting)
Central Exclusive Production: quick summary of fast-offline MuDST analysis (20 May 2015, UPC weekly meeting)
Central Exclusive Production with forward protons tagging in Run 15 (3 June 2015, STAR Collaboration Meeting)
Quick analysis of Central Exclusive Production (RP_CPT2 trigger) (8 April 2015, UPC weekly meeting)
Central Exclusive Production: quick summary of fast-offline MuDST analysis (20 May 2015, UPC weekly meeting)
Central Exclusive Production with forward protons tagging in Run 15 (3 June 2015, STAR Collaboration Meeting)
Central Exclusive Production of pi+pi-, K+K- and pi+pi-pi+pi- - analysis update (5 August 2015, UPC weekly meeting)
Preliminary mass plots in PDF and EPS formats are attached at the bottom of webpage.
Elastic proton-proton scattering
Elastic proton-proton scattering
analysis webpage
Single Diffractive Dissociation
Single Diffractive Dissociation
analysis webpage
pAu/pAl Ultra Peripheral Collisions
pAu/pAl Ultra Peripheral Collisions
analysis webpage
Software
Software
StMuRpsUtil - Roman Pot data analysis utilities (afterburner)
StMuRpsUtil (under development, for testing purposes only!!!)
Should you have any questions/comments/remarks regarding this module please contact rafal.sikora@fis.agh.edu.pl.
1. What is StMuRpsUtil
2. Structure
3. Utilities
4. How to use
5. Useful links
What is StMuRpsUtil
StMuRpsUtil is user-friendly utility class which provides a set of post-processing corrections (afterburner) to Roman Pot data stored in StMuRpsCollection class. It has built-in functionalities which expand standard Roman Pot data collection.
Structure
StMuRpsUtil is a ROOT-based class intended to work in the STAR computation environment, as well as local environments e.g. standalone machines. A typical STAR "Maker" format (inheritance from StMaker class) was abandoned in order to gain possibility to run the same code on MuDST files and other storage formats e.g. private picoDST files. The only limitation/requirement is, that Roman Pot data has to be stored in the StMuRpsCollection class.
Usage of StMuRpsUtil invloves creation of single instance of the class at the beginning of analysis, and invocation of StMuRpsUtil::process() and StMuRpsUtil::clear() methods at the beginning and ending of event analysis, respectively. StMuRpsUtil::process() returns pointer to StMuRpsCollection2 class, a mirror class of standard StMuRpsCollection, which contains RP data post-processed using final calibartions. All elements of StMuRpsCollection2 can be accessed in the very same way as of StMuRpsCollection class.
Utlities
StMuRpsUtil provides the following corrections to data:
- run-based alignment calibration
- (to be implemented) run-based time slewing corrections
- (to be implemented) hot strips removal
The following functionalities are available to user:
- user can set position of the vertex that is used in reconstruction of proton kinematics
StMuRpsUtil::updateVertex(double x, double y, double z)This method should be invoked before StMuRpsUtil::process(). The unit of arguments is meter.
-
(to be implemented) user can select type of selection criteria (loose, medium, tight): only proton tracks passing cuts at selected level are present in the tracks collection
- Setup environment to SL16c or newer.
starver SL16c
Make sure you have the latest definitions of Roman Pot data classes in your StRoot. -
Download StMuRpsUtil package from repository.
cvs co offline/users/rafal_s/StMuRpsUtil -
Put downloaded StMuRpsUtil catalogue under StRoot path in your analysis directory.
mv offline/users/rafal_s/StMuRpsUtil myAnalysisDir/StRoot/. -
Edit setup.h file (myAnalysisDir/StRoot/StMuRpsUtil/setup.h) so that only the following line is uncommented.
#define RUN_ON_MUDST // set if afterburner is used on MuDST -
Edit the header file of your analysis maker class.
Add declaration of StMuRpsUtil class before definition of your analysis maker class, and add pointer to StMuRpsUtil object as the element of your analysis maker class./*...*/
class StMuRpsUtil;
/*...*/
class MyAnalysisMakerClass: public StMaker{
/*...*/
StMuRpsUtil* mAfterburner;
/*...*/
} -
Edit the implementation file of your analysis maker class.
Include StMuRpsUtil and StMuRpsCollection2 headers at the beginning./*...*/
In the analysis maker constructor, create StMuRpsUtil object passing as an argument pointer to StMuDstMaker.
#include "StMuRpsUtil/StMuRpsUtil.h"
#include "StMuRpsUtil/StMuRpsCollection2.h"
/*...*/MyAnalysisMakerClass::MyAnalysisMakerClass(StMuDstMaker* maker): StMaker("MyAnalysisMakerClass"){ /*...*/ mAfterburner = new StMuRpsUtil(maker); }At the beginning of MyAnalysisMaker::Make() method in your analysis maker class, invoke StMuRpsUtil::process() which will provide you post-processed RP data collection. Don't forger to call StMuRpsUtil::clear() at the end of MyAnalysisMaker::Make().Int_t MyAnalysisMaker::Make( ){ /*...*/ StMuRpsCollection2* muRpsColl = mAfterburner->process(); // <-- muRpsColl can be used to get corrected proton tracks etc.
/* here analysis of an event */
mAfterburner->clear(); // <-- critical!!! return kStOK; } -
Download RP data calibration files from http://www.star.bnl.gov/~rafal_s/protected/rpsCalibrations2015.tar.gz, unpack it and put exatracted catalogues under myAnalysisDir (you should then have myAnalysisDir/Alignment etc.).
-
Add the following line:
gSystem->Load("StMuRpsUtil.so");to the macro which starts the analysis chain. It ensures that afterburner libraries are accessible.
-
Edit you job submission XML file so that directories with calibration files extracted from rpsCalibrations2015.tar.gz are included into sandbox.
<SandBox installer="ZIP"> <Package> <!-- Any other files.... --> <File>file:./Alignment</File> <File>file:./HotStrips</File> <!-- etc. --> </Package> </SandBox>
After the above steps your code should be compilable and should make use of StMuRpsUtil afterburner in MuDST analysis.
If you find any problems using StMuRpsUtil (code does not compile or crashes at execution) you are kindly requested to report it to developers. We kindly ask to not edit the StMuRpsUtil code on your own.
► picoDST analysis (Krakow format) (description to be added)
Useful links
StMuRpsUtil repository in STAR CVS: http://www.star.bnl.gov/cgi-bin/protected/cvsweb.cgi/offline/users/rafal_s/StMuRpsUtil/
Working example of analysis using StMuRpsUtil: /star/u/rafal_s/StMuRpsUtil_tutorial/
Roman Pot data calibration files (run 2015): http://www.star.bnl.gov/~rafal_s/protected/rpsCalibrations2015.tar.gz
StMuRpsCollection documentation (write-up): https://drupal.star.bnl.gov/STAR/system/files/RomanPotsInStEvent_0.pdf
StMuRpsCollection documentation (doxygen): http://www.star.bnl.gov/webdata/dox/html/classStMuRpsCollection.html
Roman Pot alignment description: to be added
If you find any problems using StMuRpsUtil (code does not compile or crashes at execution) you are kindly requested to report it to developers. We kindly ask to not edit the StMuRpsUtil code on your own.
► picoDST analysis (Krakow format) (description to be added)
Useful links
StMuRpsUtil repository in STAR CVS: http://www.star.bnl.gov/cgi-bin/protected/cvsweb.cgi/offline/users/rafal_s/StMuRpsUtil/
Working example of analysis using StMuRpsUtil: /star/u/rafal_s/StMuRpsUtil_tutorial/
Roman Pot data calibration files (run 2015): http://www.star.bnl.gov/~rafal_s/protected/rpsCalibrations2015.tar.gz
StMuRpsCollection documentation (write-up): https://drupal.star.bnl.gov/STAR/system/files/RomanPotsInStEvent_0.pdf
StMuRpsCollection documentation (doxygen): http://www.star.bnl.gov/webdata/dox/html/classStMuRpsCollection.html
Roman Pot alignment description: to be added
Analysis code for UPC picoDST (Krakow format)
Analysis code for UPC picoDST (Krakow format)
Should you have any questions/comments/remarks please contact rafal.sikora@fis.agh.edu.pl or leszek.adamczyk@agh.edu.pl.
1. Introduction
2. Code structure
3. How to run
4. Configuration file (options)
5. Useful links
Introduction
In this page you can find a set of instructions that will enable you to develop, run, and share ROOT-based C++ code for the picoDST analysis created and maintained by the Krakow group of the UPC PWG. The code is shared beetween all data analyzers via CVS repository http://www.star.bnl.gov/cgi-bin/protected/cvsweb.cgi/offline/UPC/.
Code structure
► Shared files - can be editted by all users:
rpAnalysis.cpp - analysis class (definitions)
► Shared files - can be editted by all users:
rpAnalysis.cpp - analysis class (definitions)
rpAnalysis.hh - analysis class (header)
config.txt - configuration file
► Core files - do not edit those files and directories:
runRpAnalysis - launching script (recommended to use)
runRpAnalysis - launching script (recommended to use)
rpAnalysisLauncher.C - launching script
clearSchedulerFiles.sh - utility macro which removes files created by STAR scheduler
picoDstDescriptionFiles - folder with a core code describing picoDST content etc.
The skeleton of the analysis class rpAnalysis (inherits from TSelector) was created with ROOT built-in method MakeSelector() (some more information about MakeSelector() can found here).
When the analysis starts, methods rpAnalysis::Begin() and rpAnalysis::SlaveBegin() are invoked (right place to create histograms etc.). Next, the rpAnalysis::Process() is called for each event in picoDST tree - you can put here your selection algorithms, filling histograms, and so on. After all events in picoDST are processed, methods rpAnalysis::SlaveTerminate() and rpAnalysis::Terminate() are invoked, where e.g. output file can be written.
Data of single event accessible in rpAnalysis::Process() is stored by particle_event object. Click here to see all elements of this class.
Running an analysis code should be launched by runRpAnalysis script (executable). The script can be run with one argument which is the name of the configuration file with a definition of the trigger that you would like to analyze and some analysis options (they can be used to control which part of a code should be executed). If script is run without any arguments, a configuration file config.txt is used to launch the analysis.
How to run
► Preparation of the analysis environment (first run)
- Setup environment to stardev.
stardev
- Create and enter a directory where you want to work with the UPC analysis code. Let's denote it MY_PATH.
mkdir MY_PATH cd MY_PATH
- Download analysis code from repository. Enter the code directory.
cvs co offline/UPC cd offline/UPC
-
Edit the configuration file config.txt. Especially important is to provide valid paths under options CODE_DIRECTORY and OUTPUT_DIRECTORY (absolute paths). You are encouraged to set the path for analys output outside the offline/UPC.
CODE_DIRECTORY=/absolute/path/to/MY_PATH/offline/UPC OUTPUT_DIRECTORY=/absolute/path/to/MY_PATH/output
OUTPUT_DIRECTORY does not have to exist, in such case it will be automatically created by the analysis launching script. -
Now you are prepared to run the analysis. For the first execution do not edit SINGLE_RUN option in the configuration (leave it set to "yes"). To start analysis simply type
runRpAnalysisIf there are any problems with the configuration file, e.g. wrong data directory etc., you will receive appropriate message(s) in the terminal.
If no problems are found by the launching script, you should see a ROOT being started and displaying messages about compilation progress (please, do not bother about the warnings related to picoDST description files). When the compilation is done, analysis code is finally executed. You can verify the successfull execution by checking the content of OUTPUT_DIRECTORY - you should find there a ROOT file with analysis output.
► Regular code development/running
If you find any problems (code does not compile or crashes at execution) and you suspect it is an issue of the code core you are kindly requested to report it to developers.
Configuration file (options)
Find below a list of options available in the configuration file. Obligatory options are TRIGGER, SINGLE_RUN, RUN_NUMBER (only if SINGLE_RUN=yes), DATA_DIRECTORY, CODE_DIRECTORY and OUTPUT_DIRECTORY.
If you think more options/utilities are needed in the configuration file, contact developers.
Useful links
UPC analysis code repository in STAR CVS: http://www.star.bnl.gov/cgi-bin/protected/cvsweb.cgi/offline/UPC/
CVS tutorial @ drupal: https://drupal.star.bnl.gov/STAR/comp/sofi/tutorials/cvs
Presentation on the Krakow picoDST: https://drupal.star.bnl.gov/STAR/system/files/talk_42.pdf
StMuRpsCollection documentation (write-up): https://drupal.star.bnl.gov/STAR/system/files/RomanPotsInStEvent_0.pdf
StMuRpsCollection documentation (doxygen): http://www.star.bnl.gov/webdata/dox/html/classStMuRpsCollection.html
Roman Pot alignment description: to be added
- Setup environment to stardev.
stardev
- Enter the directory with UPC analysis code (MY_PATH is where you have offline/UPC directory).
cd MY_PATH/offline/UPC
-
Update the content of shared repository - this will ensure you are working with the latest version of all files in offline/UPC.
cvs update
- Now you are free to work on analysis. You can change the analysis code (rpAnalysis.cpp, rpAnalysis.hh), edit the configuration file to run analysis code over various triggers, with different options etc., and launch analysis using runRpAnalysis script. NOTE: Use comments // or /* */ to describe part of the code you add, so that everybode can understand it.
- When you finish working with the code you should commit the changes you have made, so that all users are always working with same version of the software. It is important to always do a commit if change in the code has been made. Simply type
cvs commit rpAnalysis.cpp rpAnalysis.hh
NOTE: Before 'commit' always make sure that the code compiles and executes without errors! If the code doesn't work, but you would like to save all your work, you can easily comment lines in the code you have added, commit and work out the problem later.
NOTE 2: Do not commit files other that rpAnalysis.cpp or rpAnalysis.hh. Especially important is to avoid committing configuration file, which is analyzer-specific.
NOTE 3: CVS is "smart", so if somebody does a commit before you do, it can merge (typically with success) the changes in latest commited and your version of the file. If after doing 'cvs commit' you receive a message similiar tocvs commit: Up-to-date check failed for `rpAnalysis.cpp'it means that described conflict has occured. In such case simply do
cvs [commit aborted]: correct above errors first!cvs updateIf you don't get any warnings, you can re-commit (first command in bullet #5). However, if you find a warnig likercsmerge: warning: conflicts during merge cvs update: conflicts found in rpAnalysis.cpp
you need to manually edit the file you want to commit. Click here to learn about the details.
If you find any problems (code does not compile or crashes at execution) and you suspect it is an issue of the code core you are kindly requested to report it to developers.
Configuration file (options)
Find below a list of options available in the configuration file. Obligatory options are TRIGGER, SINGLE_RUN, RUN_NUMBER (only if SINGLE_RUN=yes), DATA_DIRECTORY, CODE_DIRECTORY and OUTPUT_DIRECTORY.
If you think more options/utilities are needed in the configuration file, contact developers.
- TRIGGER
This option is the name of the trigger that you want to analyze. It should have the same form as at http://online.star.bnl.gov/rp/pp200/. - SINGLE_RUN
• If set to "yes" forces analysis of a single run (run number is defined by RUN_NUMBER option). In this case analysis is launched without STAR scheduler, using node you are currently logged on. Name of the output ROOT file in the OUTPUT_DIRECTORY has the following form: analysisOutput.RUN_NUMBER.TRIGGER.root.
• If set to "no", full available dataset for a TRIGGER is analyzed using STAR Scheduler with job-splitting to multiple RACF nodes.
NOTE: It is recommended to check validity of the code (compilation and execution with no errors) using SINGLE_RUN=yes before you run analysis over full dataset using STAR Scheduler with SINGLE_RUN set to "no".
The submission XML file is automatically created by the launching script. Number of files for a single job is defined to 20 (can make it changeable if needed), so typically there are a few dozens of jobs submitted. This results in plenty of scheduler files showing up in CODE_DIRECTORY, as well as log/error files in OUTPUT_DIRECTORY. If you want to clean up CODE_DIRECTORY from the scheduler files, use clearSchedulerFiles.sh script. You can check progress of jobs execution with command
condor_q -submitter $USERor, if you do not have any other jobs submitted, use
condor_q -submitter $USER | tail -n1If the output is:
0 jobs; 0 completed, 0 removed, 0 idle, 0 running, 0 held, 0 suspended
it means that all jobs are finished. If all jobs were successfull, in your OUTPUT_SIRECTORY you should see a number of ROOT files called analysisOutput.SOME_LONG_NAME_WITH_VARIOUS_CHARACTERS.TRIGGER.root. Those are output files from each single job (SOME_LONG_NAME_WITH_VARIOUS_CHARACTERS is the ID of submission and ID of the job, separated by underscore "_"). To merge them into single file type
hadd allRunsMerged.root analysisOutput.*This will create a single file called allRunsMerged.root. Remember to merge files only from one submission! If you suspect something went wrong during job execution you can check log and error files of each single job that are placed in OUTPUT_DIRECTORY and have extensions .log and .err, respectively. - RUN_NUMBER
is the ID number of analyzed run (this option is omitted if SINGLE_RUN=no). - DATA_DIRECTORY
Should contain full path to a directory where lists of available picoDST files are stored (same place as picoDSTs themselves). Currently it is /gpfs01/star/pwg/UPCdst. - CODE_DIRECTORY
Should contain full path to a directory where your private copy of offline/UPC/ directory is placed. - OUTPUT_DIRECTORY
Should contain full path to a directory where you want an analysis output (ROOT files, log files) to be saved. In case OUTPUT_DIRECTORY does not exist, it is created. - ANALYSIS_OPTIONS
This option is intended to contain set of options separated by "|" character, that are send to analysis program and can be used, for example, to control which part of code should be executed etc..
Useful links
UPC analysis code repository in STAR CVS: http://www.star.bnl.gov/cgi-bin/protected/cvsweb.cgi/offline/UPC/
CVS tutorial @ drupal: https://drupal.star.bnl.gov/STAR/comp/sofi/tutorials/cvs
Presentation on the Krakow picoDST: https://drupal.star.bnl.gov/STAR/system/files/talk_42.pdf
StMuRpsCollection documentation (write-up): https://drupal.star.bnl.gov/STAR/system/files/RomanPotsInStEvent_0.pdf
StMuRpsCollection documentation (doxygen): http://www.star.bnl.gov/webdata/dox/html/classStMuRpsCollection.html
Roman Pot alignment description: to be added
Other databases created for the 2015 reconstructions
1. Calibrations/pp2pp/pp2ppPMTSkewConstants
There are 64 Skew constants, as there are 4 constants for each PMT's and there are 2 PMT's for each of the 8 RP's.
Rafal's prescription:
Constants in set1.* contain parameters for runs
16085056, 16085057 and >=16090042
Constants in set0.* contain parameters for all other runs.Implementations:
1st set:
set0.* entered at "2015-01-01 00:00:01 GMT"
2nd set:
"RTS Stop Time" for 16085055 was "2015-03-26 23:05:04 GMT"
"RTS Start Time" for 16085056 was "2015-03-26 23:06:39 GMT"
set1.* entered at "2015-03-26 23:05:05 GMT"
3rd set:
"RTS Stop Time" for 16085057 was "2015-03-27 00:07:59 GMT"
"RTS Start Time" for 16085058 was " 2015-03-27 00:14:32 GMT"
set0.* entered at "2015-03-27 00:08:00 GMT"
4th set:
"RTS Stop Time" for 16090041 was "2015-03-31 22:38:57 GMT"
"RTS Start Time" for 16090042 was "2015-03-31 22:39:59 GMT"
set1.* entered at "2015-03-31 22:38:58 GMT"
2. Geometry/pp2pp/pp2ppAcceleratorParameters
The order of entries in each set is:
x_IP y_IP z_IP theta_x_tilt theta_y_tilt distancefromDX_east distancefromDX_west LDX_east LDX_west bendingAngle_east bendingAngle_west conversion_TAC_time
Entries entered :
"2015-04-28 00:00:01 GMT" : 0 0 0 -0.003640421 0 9.8 9.8 3.7 3.7 0.011238936 0.026444185 1.8e-11
( The pp run stopped on Apr. 27 and there were a few days before C-AD could switch from pp to pAu operationally. I picked the beginning of Apr. 28 for this pAu entry.)
"2015-06-08 15:00:00 GMT" : 0 0 0 -0.002945545 0 9.8 9.8 3.7 3.7 0.012693812 0.025021968 1.8e-11
( The last *pAu* run was 16159025 on June 8 and the first *pAl* run was 16159030 which was a bad run and started at "2015-06-08 15:44:13 GMT". The previous run --- a pedestal run, 16159029, ended at "2015-06-08 14:24:54 GMT". So I arbitrarily selected the above time kind of in the middle. )
pp2ppRPpositions (STAR offline database) corrections
Originally, this is mainly to correct for the malfunctioning LVDT readings of the E1D between Mar. 18 and Apr. 6, 2015. I have come across 7 blocks/sub-periods where the E1D LVDT readings need to be corrected. Since the steps are the same 505004 (with one exception below), I have used an average of the LVDT readings closest to the period of malfunctioning (usually the good ones before but if the last good readings was too long before, I have taken the averages of those good ones shortly after the period in question). These are in the files ToCorrect1.txt, ToCorrect2.txt, .... ToCorrect7.txt. The average position of each of this period that I have used is listed at the end of the file. [ ToCorrect1.txt has one entry which I have "bracketed" as it has to be corrected with the positions of ~-32 cm, instead of ~-25 cm, and this is explained in the 1st below. ]In all cases, in the table of "Calibrations/pp2ppRPpositions", I have just inserted a set of 8 entries 1 second later in the "beginTime" than the original "beginTime" (the latter of which appears in all the .txt files listed here) as Dmitry Arkhipkin has instructed, even though there might be only one entry (E1D) that was changed.
However, I have come across the following and so I have also corrected them:
- For the run 16077055, it's ~32 cm or 449748 and so I have used the average of the last good LVDT readings corresponding to the same no. of steps (449748). The file is "ToCorrect1.exception_32cm.txt".
- On Apr. 7, there was a period that the LVDT's of E1D and E2D were swapped by mistake. I've corrected this as well. The file for this is "E2D.txt". I have needed to correct both E1D and E2D; and at the end of the file, the 1st position is for E1D and the 2nd one is for E2D.
- Accidentally, I've also come across a period (~6 pm on Apr. 3 to 10 am on Apr. 4) which had wrong entries because the online database was not updated (due to inaccessibility of CDEV/STAR portal server). Dmitry Arkhipkin has scanned the entire online database and found 5 periods which has such gap of a period > 5 minutes, including the above-mentioned one. I've checked that we only need to correct for 2, 4 runs in the above period (Apr. 4) and 6 runs on May 8 --- which was in the heavy-ion period where only the West side roman pots were actually inserted. For the other 3, they are either not in the pp2pp (roman-pot) data-taking period or the positions (the steps) remained the same before and after the gap (so that the offline database just used the previous LVDT positions available in the online database). The file for this is "NotUpdated.Apr4_.txt" and "NotUpdated.May8_.txt" respectively for Apr. 4 and May 8.
Pictures
| DX-D0 chamber | Roman Pot |
| Setup in the tunnel Roman Pot vertical station (old) |
Other useful figures |
2009 setup (Phase I)
|
|
Analysis notes |
| Drawings / Schemes / Pictures |
Other ADC and TAC distributions Silicon performance (cluster data) |
Paper review - A_NN and A_SS
A_NN, A_SS GPC paper review link (PP2PP subsystem webpage):
Photomultipliers data
ADC and TAC distributions
Sets of plots below contain ADC and TAC spectra from the Roman Pot trigger counters, as they were in the sample of reconstructed elastic proton-proton scattering events (sqrt{s} = 200 GeV). Five datasets were used to prepare histograms: 0, 1, 4, 6, 9 (see numeration here).
One should take into account, that TAC spectra are sensitive to the time-space structure of colliding bunches (that's the reason why many "bumps" are presents in the distributions). Also, TAC spectra from Roman Pots were biased due to "TAC cut-off" (sharp right edge - loss of early events). Sets of points around TAC ~ 100 also results from the cut-off.
The PDF versions of the plots are listed at the bottom of the page.
Racks schemes
East   |
West
   |
Silicon performance (cluster data)
Silicon performance
SVX chips pedestals: average and RMS (from here)
EHI (average): EHI (RMS): EHO (average): EHO (RMS):
EVU (average): EVU (RMS): EVD (average): EVD (RMS):
WHI (average): WHI (RMS): WHO (average): WHO (RMS):
WVD (average): WVD (RMS): WVU (average): WVU (RMS):
--------------------------------------------------------------
The part of page below contains sets of graphics with the data from Silicon Strip Detectors mounted in Roman Pots in 2009 run at sqrt{s} = 200 GeV. Five datasets were used to prepare histograms presented below: 0, 1, 4, 6, 9 (see numeration here). All histograms can be downloaded in the PDF format (see list of files at the very bottom).
Number and length of clusters
Sets of plots below contain distributions of the number of clusters(left) and number of strips (length) in clusters (right) in each silicon plane. Each row represents different Roman Pot, each column - a silicon plane.
Cluster energy:
Below an energy distribution of clusters is shown for each detector(file)/plane(row)/cluster length(column). Upper limit of cluster length used in reconstruction is 5.EHI: EHO: EVU: EVD:
WHI: WHO: WVD: WVU:
Cluster energy vs. strip
For clusters consisting of one strip (length=1) it was possible to draw the distribution of energy collected by the strip as a function of the strip number.EHI:
EHO:
EVU:
EVD:
WHI:
WHO:
WVD:
WVU:
Below the piece of code used to fill the histograms presented above is attached:
for(Int_t j=0; j<nOfPlanesInRpPerCoordinate; ++j){
Int_t nClusters = rps->numberOfClusters(i,Planes[coordinate][j]);
nOfClusters[i][Planes[coordinate][j]]->Fill(nClusters);
if(nClusters < maxNumberOfClusterPerPlane)
for(Int_t k=0; k < nClusters; ++k){
Int_t lenCluster = rps->lengthCluster(i,Planes[coordinate][j],k);
clusterLength[i][Planes[coordinate][j]]->Fill(lenCluster);
if(lenCluster <= maxClusterLength && lenCluster>0){
Int_t enCluster = rps->energyCluster(i,Planes[coordinate][j],k);
clusterEnergy[i][Planes[coordinate][j]][lenCluster-1]->Fill(enCluster);
if(lenCluster==1)
clusterEnergy_vs_strip[i][Planes[coordinate][j]]->Fill(1e3*rps->positionCluster(i,Planes[coordinate][j],k)/Pitch[coordinate], enCluster);
}
}
}