makeL2TimingFiles.pl

plotEEmcL2Timing.C


TFile *file = 0;
TChain *chain = 0;

}


runEEmcL2Timing.C

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

 

Procedure:

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.

Notes:

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.

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:
http://www.star.bnl.gov/protected/spin/jhkwas/calibrations/run12plots/

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:
http://www.star.bnl.gov/protected/spin/jhkwas/calibrations/run13plots/

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:

• a03TB09

• 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.

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

Status and Pedestal Tables

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:

 www.star.bnl.gov/HyperNews-star/get/starops/2520/1.html  

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: www.star.bnl.gov/protected/spin/stevens4/ped2008/runList.html

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: http://drupal.star.bnl.gov/STAR/subsys/eemc/endcap-calorimeter/db-usage

Uploading Tables to Database

General information for uploading tables to the database is given by Jan at: drupal.star.bnl.gov/STAR/subsys/eemc/endcap-calorimeter/offline-db-upload-write

More specific information on uploading pedestals and status tables to the database refer to /star/u/stevens4/database/uploadinfo.txt

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

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

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

ETOW Gains - using "sums" to identify 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.

Method:

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:

http://drupal.star.bnl.gov/STAR/blog-entry/wwjacobs/2009/mar/06/run-9-calibr-qa

and go to Section IV

test child page control