While studying scalers for SpaceCharge calibration of Run 8 data last summer, I found that the BBC beam background scalers were clearly You do not have access to view this node (regarding which one was for the yellow beam and which one was for the blue beam) between two places they were stored: an ntuple I made from an online database, and MuDsts. The databases store RICH scalers which have been sampled every 30 seconds (even though they are ~60 second averages over data), while the MuDsts get data from DAQ file streams which store RICH scalers sampled about once per second (1 second averages).

Here I show what are labeled as the BBC Blue & Yello Beam background scalers (top & bottom respectively) from the 1-second and 30-second readings (left & right respectively):

One of the databases which stores these scalers is accessible via a web interface. This is from the database stored online (onldb:3502 Conditions_rich/richScalar). This morning, Jamie Dunlop verified the labeling presented on that interface versus the hardware. Jamie writes:

 Ok, I went in and checked. Documentation is correct:

Rs4 has west delayed
Rs5 has east delayed

Blue goes from East to West at STAR.
Yellow goes from West to East at STAR.

E and (W delayed) means that the west was hit first, i.e. particle going from West to East, i.e. Yellow Background
W and (E delayed) means that the east was hit first, i.e. particle going from East to West., i.e. Blue background

So Rs4 == Yellow background
     Rs5 == Blue background

this is as is in the RICH scaler page, not as labeled in the documentation.
http://online.star.bnl.gov/cgi-bin/db_scripts/cgi/database_scaler.pl

So the documentation at
http://hepwww.physics.yale.edu/star/tpc-study/scaler-mar-25.ppt

is right in the connections, but incorrect in the interpretation of Blue and Yellow.

--J

I looked at the configuration file which sends data into that online DB table, and it does not appear to have anything backwards. So there is good reason to believe that what is in the online DB table is correct.

The online DB table gets migration to an offline DB table (dbx:3316 Calibrations_rich/trigDetSums) which was historically used by the offline reconstruction code (and still is if scalers are not found in the DAQ stream, something which happened frequently during Run 5, but not so often (at all?) anymore). From what I can tell from a Jan 31, 2003 version of the migration script (FillTD.C), the online DB was queried for:

select UNIX_TIMESTAMP(beginTime),rs1,rs2,rs3,rs4,rs5,rs6,rs7,rs8,rs9,rs10 from richScalar ...

which was then assigned in the incorrect order to:

     bbcBlueBkg[i] = atod(row->GetField(4));
     bbcYellowBkg[i] = atod(row->GetField(5));

So this migration script had the values backwards for many years back. In the spring and summer of 2007, I wrote the code which reads the DAQ stream. At the time, I believe I noticed that in order for the offline DB results and the DAQ stream to match, I had to swap the yellow and blue beam background assignments and did so intentionally. From StRoot/StDaqLib/SC/SC_Reader.cxx which I committed in August 2007:

int SC_Reader::BBCBlueBkg() {
  return sc.rich_scalers[3];
} 

int SC_Reader::BBCYellowBkg() {
  return sc.rich_scalers[4];
} 

In November 2007, before Run 8, I see that FillTD.C was modified, but with no real effect, as the order of assignment was corrected but the order of querying was reveresed. Here is the diff 2007 2003:

123c121
<     "select UNIX_TIMESTAMP(beginTime),rs1,rs2,rs3,rs5,rs4,rs6,rs7,rs8,rs9,rs10,rs16 from richScalar
 where beginTime > from_unixtime(%u) and beginTime < from_unixtime(%u) order by 1 asc",startRunTime,endRunTime);
---
>     "select UNIX_TIMESTAMP(beginTime),rs1,rs2,rs3,rs4,rs5,rs6,rs7,rs8,rs9,rs10 from richScalar
 where beginTime > from_unixtime(%u) and beginTime < from_unixtime(%u) order by 1 asc",startRunTime,endRunTime);
165,166c163,164
< 	  bbcYellowBkg[i] = atod(row->GetField(4));
< 	  bbcBlueBkg[i] = atod(row->GetField(5));
---
> 	  bbcBlueBkg[i] = atod(row->GetField(4));
> 	  bbcYellowBkg[i] = atod(row->GetField(5));

So the offline DB remained reversed through Run 8, as did the reading of the DAQ stream so that the two matched (i.e. wrong in the 2 (out of 3) places which matter for offline reconstruction, but right in the one place I was using for my ntuple of 30 second scalers).

Now I believe it is time to get these right. Fixing the migration script is easy, requiring merely swapping rs4 and rs5 in the query. Fixing the reading of the DAQ stream in SC_Reader.cxx is more complicated. Naively, one would think a mere re-labeling of the two functions would suffice. However, the Run 8 data dAu200 (2008) used what was called the blue beam background from the DAQ stream (even though I understand now that the label was wrong). So swapping function names would cause the reconstruction code to use the other scaler. The scalers used for SpaceCharge corrections are determined by parameters in the DB, so one could potentially set the DB parameters to use the other scaler as it really should. However, this switch would correspond to an entryTime in the DB, and not to a version of the code run. In order to tie the two pieces together, it should all be done in the code. So perhaps something like the following:

int SC_Reader::BBCBlueBkg() {
  return sc.rich_scalers[(RunYear<9 ? 3 : 4)];
} 

int SC_Reader::BBCYellowBkg() {
  return sc.rich_scalers[(RunYear<9 ? 4 : 3)];
} 

It turns out this is doable without changing any dependencies. The constructor of SC_Reader uses a pointer to the class StDaqLib/GENERIC/EventReader, and from that is available a timestamp for the data from which the year can be easily determined. It turns out that timestamp is not filled using the new DAQ reader, so it returns a unixtime of 0, which equates to the year 1970. But the new DAQ reader only works on data from RunYear>=9 anyhow. So I implemented logic to use the old (wrong) indices for years 1996-2008, and correct indices for anything else. This should do the job and I committed it on March 5, 2009.

Implications

• Viewing of RICH scalers at the experiment has always been via the online DB as far as I can tell. This is the one place where everything has always been correct. This is very good news because it means we have always been able to use the appropriate measure as feedback to the collider operators when RHIC is running.
• I know of no users who are affected by the reversed offline BBC beam background scalers. If there are any such users, they should be aware of their reversal:
  • From Run 9 on, the offline DB, StEvent files, and the MuDsts will have correct labels for these scalers.
  • For all Runs before Run 9, the offline DB, StEvent files, and the MuDst have these scalers reversed.
• That the offline scalers were reversed is not an issue for the Run 8 TPC distortion corrections which used them.
  • In Run 8 dAu data, the improperly labeled BBC Blue Beam Background scaler (properly: Yellow Beam) was used in corrections of luminosity dependent TPC distortions (the SpaceCharge & GridLeak corrections).
  • This scaler was read from the DAQ files, and if not present the fallback was the offline DB: in both cases it was consistent.
  • The label of the scalers was unimportant as long as the one which was used in the calibration was also used in the processing, and this was indeed the case.

If this is the whole story, then the conclusions are indeed positive and we can turn the page and move on without fears.

G. Van Buren