[d2n-analysis-talk] replay_det_BB.C: error messages and scalers

[Diana Parno]

Thanks for looking into this, Brad, but I'm still having trouble, I'm 
afraid ...

On Mon, 1 Mar 2010, Brad Sawatzky wrote:

> FWIW, run 1521 replayed cleanly for me using the central DB and a fresh
> copy of the 'stock' replay scripts.  Histos and the root Tree look good.

I've changed my .bashrc file to have the correct environment variables -- 
I was still looking at Dave's copy of the analyzer, for example. For 
purposes of debugging, I'm also using a replay_det_BB.C and 
replay_det_BB.cdef that are symlinked to yours. However, I am still seeing 
a problem.

I'm using my own replay_det_BB.odef file with the idea of having a couple 
of trees just for the scaler data. The definition of said trees is at the 
bottom of /home/dseymour/d2n-replay/replay/replay_det_BB.odef -- it starts 
out, for example,

  #start scaler stuff..
  # "bbite" = event type 140
  # 1024 Hz clock
  begin scalers bbite
    clkcount 4 7 counts
    u1cnt 4 16 counts
    u3cnt 4 17 counts
    u10cnt 4 18 counts
    d1cnt 4 19 counts
    d3cnt 4 20 counts
    d10cnt 4 21 counts
  .
  .
  .
  end scalers

When I replay the run, a BBITE tree shows up in the file, with all the 
branches defined as in the .odef file -- but it hasn't been filled. There 
are 0 entries, i.e. no data, in the tree. Meanwhile, if I run 
replay_scalar.C on the same run, with the bbite tree defined pretty much 
the same way (except for some extra branches), the tree has 301 entries, 
which all look like real data (that is, there's some variation).

The main tree T has some branches that sound like they're what I'm 
interested in (this is a BCM calibration run, so "bbite_u1cnt" for example 
-- I've got the bbite_* branch turned on in my .odef file), but in 19177 
entries they all seem to be identically zero, which does not exactly make 
them look like real data. Are these the wrong variables? How can I find 
the right ones?

So the replay is not throwing a lot of errors, and the trees seem to be 
constructed properly, but something seems to have gone very wrong with 
what's going into them.

Any ideas why the bbite tree wouldn't be filled? (evbbite isn't, either, 
for my data.) Or where this null bbite_u1cnt data is coming from?

> I did get a crash when I tried to run two replay_BB_det.C() calls with
> out quiting the analyzer in between...  Could be one of the modules
> isn't cleaning up after itself correctly.

At this point I've been fairly well trained to quit the analyzer in 
between replays. I think we figured out a few months ago that the modules 
aren't cleaning up after themselves very well -- this is why we wound up 
commenting out the lines

/*  gHaApps->Delete();
     gHaPhysics->Delete();
     gHaScalers->Delete();
     analyzer->Close();
*/

in our standard version of ReplayCore.C, right?

>
> I haven't looked at the code, but I wouldn't be surprised if the
> THaADCHe3Spin class pulled information from one of the raster classes.
> Unadvertized inter-module dependencies do exist in the code.  Yes, that
> does violate the object-oriented coding model.  Rather than use
> conventional coding techniques like sanity checks on return values, and
> proper error handling with informative error messages, enforcement is
> imposed by exposing the student to bizarre crashes and "misleading"
> error messages until s/he becomes an expert on the twisted internals of
> the code.  Then you get to hack in your own unholy fixes to confound the
> next generation of students.

Heh. That is both deeply depressing and somewhat reassuring (inasmuch as 
it is apparently not breaking only for me.

Does anyone have/know of any documentation where I can just get a list of 
what variables exist and what they mean, for LHRS and/or for BBITE?? 
Suppose I just *think* I'm looking at the right variables ... is there any 
way to pick the right ones apart from (1) trial and error or (2) pestering 
other people for their code? Some variables obviously follow conventions, 
e.g. for particular shower blocks, but what if you don't know the 
convention for the particular X you're looking for?

Thanks,
Diana

> My environment is set here:
>  /home/brads/.bash_root-setup
>
> The replay directory I used is here:
>  /home/brads/d2n-replay/replay/
>
> -- Brad
>
> -- 
> Brad Sawatzky, PhD <brads at jlab.org>  -<>-  Jefferson Lab / Hall C / C111
>  Ph: 757-269-5947 -<>- Pager: 757-584-5947 -<>- Fax: 757-269-7848
> The most exciting phrase to hear in science, the one that heralds new
>  discoveries, is not "Eureka!" but "That's funny..."   -- Isaac Asimov
> _______________________________________________
> d2n-analysis-talk mailing list
> d2n-analysis-talk at jlab.org
> https://mailman.jlab.org/mailman/listinfo/d2n-analysis-talk
>
>