User name R. Michaels
Log entry time 11:22:51 on April10,2008
Entry number 231173
keyword=Scaler checkout, scaler.map updateThere was a small bug in the scaler.map file, that for the
bigbite detectors the number of channels was always zero,
when it should have been one. This causes spurious output (which
reminds me I probably should print a warning). So I've updated
scaler.map in the scaler directory and subdirectories.
You should probably update this in the Podd directory, although
the scaler.map bug only affects commands like this:
sprintf(device,"E%dL",i+1);
rate = scaler->GetScalerRate(device,0);
(where device is a char* and scaler is a THaScaler*)
The scaler.map bug does not affect GetScalerRate(slot,chan)
which Podd mainly uses.
The code "tscalbbite" (source in /dev/tscalbbite_main.C) analyzes
bigbite scalers. Type "goxscaler" on adaq, then
./tscalbbite /adaql2/data3/e04007_2726.dat.0
(for example)
At the end you get a printout like this:
-------------- Summary of Bigbite Scalers --------------
Time of run (sec) 648.22
Triggers :
T1 = 252615087 T2 = 459740248 T3 = 16543050 T4 = 3345681
T5 = 677070 T6 = 1107681 T7 = 4322897 T8 = 663777
Charge (arb units): 19084026
Events (L1A) : 1005565
The results differ slightly from the halog because the bigbite
scalers are not gated by the trigger supervisor while the L-HRS
scalers are gated.
You also get a root file scaler.root
You can analyze the ntuple there with a script like "showbb.C"
and change "which1", "which2" there. Examples are in the
attached screens.
I've checked several recent runs. Conclusion is that the bigbite
scalers in datastream are fine. I also checked the L-HRS scalers
and they are ok too. Boring ... but that's a good thing.
FIGURE 1
FIGURE 2
