[d2n-analysis-talk] BB cer TDCs

[MATTHEW R POSIK]

I took Brads advice and added my TDC cuts one by one to the BB.cer.asum_c
variable (BB cerenkov adc sum) and seen how many events were left after
applying cuts. For the TDC cuts I used DBB.BBcerT%02d[0]<400.0, where %02d
is the TDC corresponding to the mirror that I want so %02d runs from 1 to 20
and chan 400 was selected so that I could quickly make the cuts and not
worry about seperate TDC ranges all in time peaks are near chan 200, so
timing peak is included in chan 400 cut. Here is a list of the results,
where the arrow (T1->T3 say) means T1 | | T2 | | T3  and T1,T5 meand T1 | |
T5 and no arrow or comma is just the individual TDC cut:

'OR' ed TDCs (DBB.BBcerT)          evnets

No TDC cut                                 21376
T1                                              5208
T1,T2                                         6971
T1->T3                                       8298
T1->T4                                       8672
T1->T5                                       7968
T1->T6                                       5001
T1->T7                                       4577
T1->T8                                       3871
T1->T9                                       3333
T1->T10                                     2730
T1->T11                                     584
T1->T12                                     35
T11                                           1014
T11->T12                                   107
T12                                           323
T13                                           910
T11,T13                                    284
T11->T14                                  51
T15                                          1344
T14,T15                                    367


So it seems that there is a big event fall off when the RHRS side of the
TDCs is applied. I know that there is more background on the beamline side
because of the higher rates, but I don't think the events should fall that
much.

I Also made TDC cuts on BB.cer.asum_c using the BB.cer.t[ ] TDC variables
from the THaCherenkov class, here are the results:

TDC Cut              events

none                     21376
T1                         11810
T1->T2                  16273
T1->T3                  18782
T1->T4                  20022
T1->T5                  20688
T1->T6                  21102
T1->T7                  21243
T1->T8                 21304
T1->T9                 21339
T1->T10               21355
T1->T11               21371
T1->T12               21376
T1->T20               21376

This is what I was expecting. I am not too sure what the problem is. I think
that I am going to form the DBB TDC cut by looping over Ndata hits as Brad
commented below.


-Matt
On Sun, Jan 31, 2010 at 11:22 AM, Brad Sawatzky <brads at jlab.org> wrote:

> On Fri, 29 Jan 2010, MATTHEW R POSIK wrote:
>
> > Ok, so I just tried using the cut
> >
> >
> DBB.BBcerT11[0]<400.0||DBB.BBcerT12[0]<400.0||||DBB.BBcerT13[0]<400.0||DBB.BBcerT14[0]<400.0||DBB.BBcerT15[0]<400.0
> >
> > and applied it to BB.cer.asum_c[0]
>
> Only index array variables.  BB.cer.asum_c is a scalar.  It would be far
> better if ROOT just threw an error and crashed on bugs like that rather
> than attempting to guess "what you mean".  If anyone can find an option
> that would make ROOT behave that way, PLEASE tell me!  Usually ROOT
> guesses correctly, but it encourages sloppy code practice.  When errors
> do crop up they're hard to debug...
>
> Bottom line is this:
>  - always use an explicit index on array variables
>  - never index a scalar variable
>  - if you don't know if a variable is an array or scaler, then find out
>    using T->Print(<var_name>), or equivalent
>
> > The result was out of ~500000 only 18 were left. I checked all the
> > TDCs and all have there in time peaks around 200-300, so having just
> > 18 events left doesn't make sense.
>
> That is very strange.  I recommend copying your generated cut string
> into a text file.  Then, _by_hand_ at the root prompt, call
> T->Draw("..", ...) and add pieces of your cut step by step until you
> discover what part is throwing away your data.
>
> -- 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
>



-- 
Matthew Posik
Email: posik at temple.edu
Temple University Physics Dept.
Office: BA-319
Office #:  215-204-1331
-------------- next part --------------
An HTML attachment was scrubbed...
URL: https://mailman.jlab.org/pipermail/d2n-analysis-talk/attachments/20100201/8192c43e/attachment.html