[d2n-analysis-talk] DB discrepancies

[Brad Sawatzky]

On Tue, 06 Apr 2010, Diana Parno wrote:

> Where does one go to figure out the right crate/slot/channel mapping
> for the detector maps in DB files?

The names of the db_* files are tied to the name of the class that reads
them.

If you instantiate a THaRasteredBeam class with the name BBrb:
  gHaApps->Add(new THaRasteredBeam("BBrb","Rastered Beam"));
then it will look for its DB information in the file(s):
  db_BBrb.*.dat

I can make a second instance with a different name (in the same replay):
  gHaApps->Add(new THaRasteredBeam("foobar","Rastered Beam"));
and that class will use db files named like:
  db_foobar.*.dat

> I'm trying to understand the DB files for rastered vs unrastered beam. In, 
> say, the DB/20090310 folder, I count eleven files whose names suggest they 
> are associated with the beam characteristics (db_BBrb.Raster.dat, 
> db_BBurb.BPMA.dat, db_BBurb.BPMB.dat, db_beam.dat, db_beam.Raster.dat, 
> db_rb.dat, db_rb.Raster.dat, db_urb.BPMA.dat, db_urb.BPMB.dat, db_urb.dat, 
> db_urb.Raster.dat). My understanding from the Hall A documentation is that 

I assume the symlinks got replaced by full copies due to an ancient and
really annoying limitation of CVS...  You can see what files are
identical/different with this trick:
  brads at d2n 2013% md5sum db_*rb.* db_*beam*.* | sort
  037111ed32d52662594424f2f5418cd6  db_beam.dat
  037111ed32d52662594424f2f5418cd6  db_beam.Raster.dat
  1fd0f03f7ba4430b4b7f8d831d8c1895  db_BBrb.Raster.dat
  1fd0f03f7ba4430b4b7f8d831d8c1895  db_BBurb.BPMA.dat
  1fd0f03f7ba4430b4b7f8d831d8c1895  db_BBurb.BPMB.dat
  4a79b1f49cb8e19e3e20ae046901702b  db_urb.dat
  5d3a2b24d37c44ccdc7e518663470ba4  db_rb.Raster.dat
  5d3a2b24d37c44ccdc7e518663470ba4  db_urb.BPMA.dat
  5d3a2b24d37c44ccdc7e518663470ba4  db_urb.BPMB.dat
  90c7b6badc304febd71a9ad3e020dae3  db_rb.dat
  934e419d3616e2c142e2fbbc3e9a01c7  db_urb.Raster.dat
Those with the same hash are identical.  (Note that this is quick but
not perfect, since a single space will change the hash but not the
informational content of a file.)

You can find out what files are actually in use by grep'ing on the
replay*.C files.  For example 
  brads at d2n 2016% grep '"beam"' *.C
shows nothing, therefore nothing is using those DB files.  The urb, rb,
BBrb, etc, names are all in use.

> the idea is to copy or symlink a master database file (beam_db.dat) to 
> three different data files (db_rb.Raster.dat, db_urb.BPMA.dat, 
> db_urb.BPMA.dat) so that the analyzer can have the data file for each 
> detector that it expects. We get additional copies (e.g. BBurb, urb) to 
> account for our two detector arms.

Correct.

I don't think we need a million copies of the files we do have (one in
each sub-directory.  When this gets cleaned up, use as few files as you
possibly can.  The only reason we need to use the StartType.pl hack is
when we have multiple detector configuration changes in a single day.
That is not the case with the raster/beam stuff.

> But the detector mappings don't all agree where I would expect them to. 
> For example, here's the diff for the detector mappings in db_rb.dat 
> and db_rb.Raster.dat. Line 7 is the BPMA, line 10 is the BPMB, and line 13 
> is the raster:

The correct answer is to use the ones you have calibrated and know to be
correct.  Each arm will need a different detector map since BB looks at
different scalers than the LHRS.  I would expect most (all?) of the
calibration constants to be identical though.

Hope this helps.  Drop me a line if you have more questions, or if I
didn't answer your first ones.

-- Brad

-- 
Brad Sawatzky, PhD <brads at jlab.org>  -<>-  Jefferson Lab / Hall C / C111
Ph: 757-269-5947  -<>-  Fax: 757-269-5235  -<>- Pager: brads-page at jlab.org
The most exciting phrase to hear in science, the one that heralds new
  discoveries, is not "Eureka!" but "That's funny..."   -- Isaac Asimov