On Mon, 5 Jan 2004, Tancredi Botto wrote:
>
> Happy new year Chi, how are things ?
happy new year chief.
> I've *not* read in detail all of your communications yet, but thank you
> for it. I assumed the holiday crunch went well. Would you please report
> results/performances achieved with the new lib to an analysis meeting ?
sure, but really not much. I am going to send an email briefly report
about the crunch so let this one be it.
The crunch finally started on Jan 1st, 4pm after a few attempts with
wrong emap and so on. jobs were put onto all spuds and dblast11, dblast14.
dblast08 and 13 are spared. by noon Jan 5th, all runs in RUNLIST.new are
finished. it took a little less than 4 days. it is not any slower than
the old one if not any faster. runs 3889, 3895, 3930, 3937, 3948, 4046,
4102, 4112, 4146, 4150, 4207, 4211, 4212, 4213, 4218 were not closed
properly indicating problems in the crunching. 15 out of the 328
runs crunched. forgot to give -bm -1 to run 3966.
I ran show_ep_asym.C on the same runs Jason did in elog post 18370.
count out the runs not closed, elog and RUNLIST both say 3809-3811 were
unpol runs. I then get:
Charge in (beam-target) polarization states:
( h, P) charge
-------- -----------
( +1, +1) 2767.0254
( -1, +1) 2803.3462
( +1, -1) 0.0000
( -1, -1) 0.0000
Using absolute helicity values = 1 (+ state) and 1 (- state)
h_L[ 0] : total counts = 55685 = 47.667
h_L[ 1] : total counts = 61081 = 52.286
h_R[ 0] : total counts = 61880 = 47.647
h_R[ 1] : total counts = 67934 = 52.308
compare to old lib:
Charge in (beam-target) polarization states:
( h, P) charge
-------- -----------
( +1, +1) 3245.5579
( -1, +1) 3211.0488
( +1, -1) 0.0000
( -1, -1) 0.0000
Using absolute helicity values = 1 (+ state) and 1 (- state)
h_L[ 0] : total counts = 43212 = 48.415
h_L[ 1] : total counts = 46000 = 51.539
h_R[ 0] : total counts = 32910 = 48.159
h_R[ 1] : total counts = 35392 = 51.791
note that number of events available is much much more than before, almost
doubled for electrons in the right. note also the total charge used is
less than what Jason used because the exclusion of unpol runs and the
unclosed runs. this indicates that our efficiency is much improved.
Unfortunately we never quantified efficiency of 2.96 with reversed field.
I atatched the show_ep_asym figure.
> (even if it is before new calibrations, it will make a nice point about
> it)
>
> Two things come to mind:
>
> - Lead removal: is it the last 2 tof's or the last 4 ? I'll assume the
> last two but please confirm this.
we have deuteron starting from TOF 13 and below. it is probably safe to
remove at least 3 tof's lead if we are going to do it. in that case, we
are not exposed to acceptance dependant stuff in PAD 13.
>
> _ We usually do ADC_hit = ADC_bot + ADC_top. (left,right). It should
> actually be ADC_hit = sqrt(ADC_bot * ADC_top) since this is
> position/attenuation independent. I am really sorry for this if I did
> not tell you before. We have been spending too much energy before
> Xmas on other things (including coll meeting). Thanks to michael who
> reminded us.
Hah, I knew you finally are going to ask this. :) though not in lrn, this
geometric average ADC is implemented in DetRecon and recorded in dst. I
realized we may need this when reading the thesis of ZhenWei Chai, one of
the students graduated from our group last year.
see TBLDetRecon.h:
float GetSCgenergy(int sec, int nhit) const { return
tof[sec][nhit].genergy; }
float GetSBgenergy(int sec, int nhit) const { return sb[sec][nhit].
genergy; }
float GetNCgenergy(int sec, int nhit) const { return nc[sec][nhit].
genergy; }
float GetL20genergy(int sec, int nhit) const { return
l20[sec][nhit].genergy; }
float GetL15genergy(int sec, int nhit) const { return
l15[sec][nhit].genergy; }
TBLEvent.h:
Float_t GetSCGEnergy(int n) const {
return ((TBLEvTof*)fSC->UncheckedAt(n))->GetGEnergy(); }
Float_t GetNCGEnergy(int n) const {
return ((TBLEvNC*)fNC->UncheckedAt(n))->GetGEnergy(); }
they are defined as: sqrt(e1*e2) where e1 = (adc1-pedestal1)*scale1
scale for ADC are 50 (fC/channel?) as listed in blast.sc_cal. which is
only an uncalibrated dummy. currently, pedestals in blast.sc_cal are all
0, so the ADC we have been looking at are all RAW.
Note the G in the function names indicates GEOMETRIC.
it only takes a few lines to add these to the ntuples. But we probably
could only append to the ntuple, not putting them together with others.
Chi
This archive was generated by hypermail 2.1.2 : Mon Feb 24 2014 - 14:07:30 EST