[d2n-analysis-talk] THaScaler and THaScalerGroup

[Diana Parno]

> I'm actually looking at this now, going through runs event-by-event  
> and printing to the screen whenever I have the condition u3c < 400  
> (an arbitrary choice of a value, just something that is near zero)  
> -- and (at least for my first run that is processing) I have all the  
> u3c = 0 events in the first 54 events... I'm not quite sure why that  
> happens just yet, just thought you'd be interested to know.


Hey, that's really interesting! If the scalers take a little while to  
start up right after the run begins, then that's actually sort of a  
reasonable failure mode. It also explains why the BeamTrip Finder code  
was often erroneously finding a beam trip at the beginning of my  
BigBite runs. It may even help explain the lower percentage of  
affected BigBite events; if the scalers are non-functional for a  
certain fixed length of time at the beginning of data-taking, and if  
BigBite has a lower readout rate during startup, then the huge number  
of BigBite readouts later in the run would outweigh the startup  
readouts much more thoroughly than in the LHRS.

I was just reading Seamus's thesis last night and he was talking about  
discarding the first 1000 events of every run, because the helicity  
wouldn't be working right. This may be worth some more investigation  
for both of us, if other things besides these scalers are having  
trouble. I've put this back on the list due to the potential for  
general interest.

Best,
Diana

On Jan 31, 2011, at 12:01 PM, David Flay wrote:

>
>
> On Mon, Jan 31, 2011 at 2:38 PM, Diana Parno <dparno at cmu.edu> wrote:
> At last week's meeting, we discussed whether the scaler decoding code
> is the same for BigBite and the LHRS.
>
> I believe it is. There are no *C or *h files in bigbitelib for
> THaScaler or THaScalerGroup (the latter is the class called in the
> replay scripts to handle scaler information). A grep command in the
> bigbitelib folder yields no mention of scalers, except for a single
> line in the Makefile where the Analyzer source directories (including
> hana_scaler, which is different) are included. The BigBite
> documentation doesn't mention scalers either.
>
> In short, I don't see how the BigBite replays could be using scaler
> data at all, unless they're pulling the THaScaler* classes from the
> analyzer environment. Unfortunately, this makes it much harder for the
> LHRS/BB differences in bcm misbehavior to be due to a coding problem.
>
>
> I'm actually looking at this now, going through runs event-by-event  
> and printing to the screen whenever I have the condition u3c < 400  
> (an arbitrary choice of a value, just something that is near zero)  
> -- and (at least for my first run that is processing) I have all the  
> u3c = 0 events in the first 54 events... I'm not quite sure why that  
> happens just yet, just thought you'd be interested to know.
>
>
> -- 
> -----------------------------------------------------------
> David Flay
> Physics Department
> Temple University
> Philadelphia, PA 19122
>
> office: Barton Hall, BA319
> phone: (215) 204-1331
>
> e-mail: flay at jlab.org
>            flay at temple.edu
>
> website: http://www.jlab.org/~flay
>              http://quarks.temple.edu
> -----------------------------------------------------------
>
>