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

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

      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

     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

2007 EEMC Tower Gains

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!

Definitions:

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

Results:

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:

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%

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

% cvs co StRoot/StEEmcPool/StEEmcDAQ2Ped

% cvs co StRoot/StEEmcPool/StEEmcPedFit

% cvs co StRoot/StEEmcPool/StEEmcStatus

% cons

% cp StRoot/StEEmcPool/StEEmcDAQ2Ped/macros/plDAQ2Ped.C ./

% cp StRoot/StEEmcPool/StEEmcPedFit/macros/fitAdc4Ped.C ./

% cp StRoot/StEEmcPool/StEEmcPedFit/macros/procDAQ2Ped.sh ./

% cp StRoot/StEEmcPool/StEEmcStatus/macros/pedStat.C ./

% cp StRoot/StEEmcPool/StEEmcStatus/macros/procPedStat.sh ./

% ./procDAQ2Ped.sh

% ./procPedStat.sh

% cd StatFiles/

% ./procErrs.sh

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 E_T = 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):  web.mit.edu/rhic-spin/public/eemc-bnl/calibration/

Alice B.'s calibration code blog:  https://drupal.star.bnl.gov/STAR/blog/aliceb/2010/oct/08/updated-eemc-calibration-code

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

Suggestion:
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 ////////////////////////////////////////////////////////

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

int trigID[2]={A,B};

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};

% cvs co StRoot/StEEmcPool/macros/DaqReader

% cp StRoot/StEEmcPool/macros/DaqReader/compile.sh ./

% cp StRoot/StEEmcPool/macros/DaqReader/emchist.C  ./

% cp StRoot/StEEmcPool/macros/DaqReader/submitAll.sh  ./

% cp StRoot/StEEmcPool/macros/DaqReader/addFiles.sh  ./

% ./compile.sh emchist.C

./emchist /star/data03/daq/2012/100/13100049w_js/st_W_13100049_raw_1340001.daq

Run 10 EEMC Calibrations

Run 11 EEMC Calibrations

This is the main page for all EEMC calibration information for Run 11

Run 12 EEMC Calibrations

Run 13 EEMC Calibrations

Run 15 EEMC Calibrations

Run 17 EEMC Calibrations

Run 8 EEMC calibrations

This is the main page for all EEMC calibration information for Run 8

Run 9 EEMC calibrations

This is the main page for all EEMC calibration information for Run 9

Uploading EEMC Pedestal, Status and Gain Calibrations to the DB

Building the eemcDb utility:

mkdir yourDirectory
cd yourDirectory

cvs co StRoot/StDbLib/
cd StRoot/StDbLib/
make

cd ../../
cvs co StRoot/StEEmcUtil/database/macros/upload/src/
cd StRoot/StEEmcUtil/database/macros/upload/src/
make

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:

• 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

• script which executes writePed+Status.sh (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

setenv DB_ACCESS_MODE write

ESMD (Shower Max and Pre- & Post-Shower Detectors)

ETOW (Towers)

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: http://orion.star.bnl.gov/Browser/EEMC/ 

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,

Jan

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:

#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

#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

~/ezGames/dbase/src/eemcDb -p Ver2004d/sector05/eemcPMTstat -H -t 2001

~/ezGames/dbase/src/eemcDb -p Ver2004d/sector05/eemcPMTstat -g -t 1080832032

......
class  StEEmcDbMaker;
class StYourAnalysistMaker : public StMaker {
 private:
  StEEmcDbMaker *eeDb;
  ....
}

 
#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
} 

.....
 // 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
    emc->getEndcapTowerADC(i,rawAdc,sec,sub,eta);
    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 ....
      ..............
  }
}

 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());  }

myDb=new StEEmcDbMaker("eemcDb");
....
myDb->setThreshold(2.5);
....
chain->Init();
....

  St_db_Maker *dbMk=new St_db_Maker("db", "MySQL:StarDb", "$STAR/StarDb");
     dbMk->SetFlavor("sim","eemcPMTcal");
     dbMk->SetFlavor("sim","eemcPIXcal");
     dbMk->SetFlavor("sim","eemcPMTped");
     dbMk->SetFlavor("sim","eemcPMTstat");
     dbMk->SetFlavor("sim","eemcADCconf");
     dbMk->SetFlavor("sim","eemcPMTname");
    ? dbMk->SetDateTime(20031120,0);  (you may need to specify the DB time stamp)

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

  starDb->SetFlavor("sim", "bemcPed");
  starDb->SetFlavor("sim", "bemcStatus");
  starDb->SetFlavor("sim", "bemcCalib");
  starDb->SetFlavor("sim", "bemcGain");

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
makers.
The priviliged ones are all I/O makers and StGeantMaker (which is also I/O
maker)
User could define his maker as a priviliged:
instead of:
bfc(999,...)
user should:
bfc(0,...);
chain->SetAttr(".Privilege",1,"UserMakerName" );
chain->EventLoop(1,999);

Victor

software

Endcap Sofware  2006++

test entry

timing_WMZ

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  
   mapmt-crate-64.pdf