This is the main page for all EEMC calibration information for Run 9
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.
Pre&Post:
02PA11
Tower:
02TC04, 02TC06, 06TA03, 06TE04, 07TC05, 11TD05
Bad channels:
Pre&Post:
05PA01, 05PA02, 05PA03, 05PB10, 05PB11, 05PB12, 05PC10, 05PC11, 05PC12, 05PD10, 05PD11, 05PD12, 05PE01,
05PE02, 05PE03
11PE10, 11PE12, 11QE10, 11QE12, 11RE10, 11RE12
Tower:
11TE12, 11TE10, 10TD04, 10TD06
Note: Fifteen 05Pre1 channels have PMT problem; Swaps 11TE10<->11TE12; 10TD04<->10TD06
The procedures and results can be found here:
https://drupal.star.bnl.gov/STAR/system/files/EEMC-cal-run6%2526run9forpresentation11172014_1.pdf
All the plots are in this directory:
http://www.star.bnl.gov/protected/spin/tinglin/summber2014/run9final/
Conclusion:
Pre1, Pre2 and tower's gain decreased by 10% compared to run6;
Post shower's gain remain stable.
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.
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
Procedure:
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.
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
spreadsheet
(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:
Run ETOW TCD ESMD TCD
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:
http://drupal.star.bnl.gov/STAR/blog-entry/aliceb/2009/mar/11/preliminary-eemc-timing-curves-crate
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)
For now see link to blog page:
http://drupal.star.bnl.gov/STAR/blog-entry/wwjacobs/2009/mar/06/run-9-calibr-qa
and go to Section IV