[G8b_run] g8 meeting
Ken Livingston
Kenneth.Livingston at glasgow.ac.uk
Mon Mar 25 11:50:55 EDT 2013
Hi All,
I though it was already a done deal.
Let's make it 11.00 Jlab time. Will you kick it off Eugene.
Please add to the agenda at
https://clasweb.jlab.org/rungroups/g8/wiki/index.php/Mar_26,_2013
Instructions for offsite participants:
https://clasweb.jlab.org/rungroups/g8/wiki/index.php/Instructions_for_off-site_participants
Regards,
Ken
-------- Original Message --------
Subject: Re: [G8b_run] Fwd: g8b TOF paddle issue
Date: Mon, 25 Mar 2013 15:27:54 +0000
From: Eugene Pasyuk <pasyuk at jlab.org>
To: Kenneth Livingston <Kenneth.Livingston at glasgow.ac.uk>
Hi Ken,
It looks like the best time is tomorrow, Tuesday March 26 between 11:00 and 12:30 of JLab time http://doodle.com/ycqshd8fpnda66mx
You pick the time.
-Eugene
----- Original Message -----
> From: "Eugene Pasyuk" <pasyuk at jlab.org>
> To: "Kenneth Livingston" <Kenneth.Livingston at glasgow.ac.uk>
> Cc: "g8b run" <g8b_run at jlab.org>
> Sent: Wednesday, March 20, 2013 12:22:57 PM
> Subject: Re: [G8b_run] Fwd: g8b TOF paddle issue
>
> Call-in instructions:
>
> ------------------------------------------------------------------------
> Dial Toll-Free Number: 866-740-1260 (U.S. & Canada)
> International Toll-Free Numbers: http://www.readytalk.com/intl
> Enter 7-digit access code, 7440953 followed by #
>
> -Eugene
>
> ----- Original Message -----
> > From: "Ken Livingston" <Kenneth.Livingston at glasgow.ac.uk>
> > To: "g8b run" <g8b_run at jlab.org>
> > Sent: Wednesday, March 20, 2013 12:18:13 PM
> > Subject: Re: [G8b_run] Fwd: g8b TOF paddle issue
> >
> > Hi All,
> > I've made a very brief meeting page at
> > https://clasweb.jlab.org/rungroups/g8/wiki/index.php/Mar_26,_2013
> >
> > Can you please upload any relevant files (eg Brian's plots).
> >
> > Cheers,
> > Ken
> >
> >
> > On 20/03/13 16:01, Eugene Pasyuk wrote:
> > > So far 7 people responded to doodle poll. The earliest best time
> > > slot at the moment is Tuesday 12:30 JLab time.
> > >
> > > -Eugene
> > >
> > > ----- Original Message -----
> > >> From: "Eugene Pasyuk" <pasyuk at jlab.org>
> > >> To: "g8b run" <g8b_run at jlab.org>
> > >> Sent: Tuesday, March 19, 2013 4:36:38 PM
> > >> Subject: [G8b_run] Fwd: g8b TOF paddle issue
> > >>
> > >>
> > >>
> > >>
> > >> ----- Forwarded Message -----
> > >> From: "Eugene Pasyuk" <pasyuk at jlab.org>
> > >> To: "Michael Dugger" <dugger at jlab.org>
> > >> Cc: "Ken Livingston" <Kenneth.Livingston at glasgow.ac.uk>, "Franz
> > >> Klein" <fklein at jlab.org>, "Brian Vernarsky" <soulish at gmail.com>,
> > >> "Volker Crede" <crede at fsu.edu>, "Patrick Collins"
> > >> <pcollins at jlab.org>, "Charles Hanretty" <hanretty at jlab.org>
> > >> Sent: Tuesday, March 19, 2013 4:21:10 PM
> > >> Subject: Re: g8b TOF paddle issue
> > >>
> > >> Let's have a meeting. I set up doodle:
> > >> http://doodle.com/ycqshd8fpnda66mx
> > >>
> > >> -Eugene
> > >>
> > >> ----- Original Message -----
> > >>> From: "Michael Dugger" <dugger at jlab.org>
> > >>> To: "Volker Crede" <crede at fsu.edu>
> > >>> Cc: "Ken Livingston" <Kenneth.Livingston at glasgow.ac.uk>, "Franz
> > >>> Klein" <fklein at jlab.org>, "Brian Vernarsky"
> > >>> <soulish at gmail.com>, "Eugene Pasyuk" <pasyuk at jlab.org>
> > >>> Sent: Tuesday, March 19, 2013 3:36:51 PM
> > >>> Subject: Re: g8b TOF paddle issue
> > >>>
> > >>>
> > >>> Hi,
> > >>>
> > >>> This could be scary.
> > >>>
> > >>> From what I understand, this problem will create phi dependent
> > >>> inefficiencies. This will especially true for single track
> > >>> events.
> > >>> However,
> > >>> if an analysis uses the data to self analyze the phi dependent
> > >>> efficiencies (e.g. forming quantities like (Y_PARA -
> > >>> Y_PERP)/(Y_PARA
> > >>> +
> > >>> Y_PERP)), then the recooking of data will only help add
> > >>> statistics
> > >>> for
> > >>> those type of analyses.
> > >>>
> > >>> Since I have two channels of g8b that have gone through
> > >>> analysis
> > >>> review,
> > >>> and Volker is either finished with analysis review, or nearly
> > >>> so,
> > >>> it
> > >>> is
> > >>> important that we determine if those analysis can remain as is.
> > >>>
> > >>> If it is determined that all of the analyses must use recooked
> > >>> data,
> > >>> we
> > >>> need to do the recooking as soon as possible.
> > >>>
> > >>> Take care,
> > >>> Michael
> > >>>
> > >>> On Tue, 19 Mar 2013, Volker Crede wrote:
> > >>>
> > >>>> Hi all,
> > >>>>
> > >>>> It sounds really scary. Yes, we should meet and discuss this.
> > >>>>
> > >>>> Volker
> > >>>>
> > >>>>
> > >>>> On Mar 19, 2013, at 12:34 PM, Michael Dugger <dugger at jlab.org>
> > >>>> wrote:
> > >>>>
> > >>>>> Hi,
> > >>>>>
> > >>>>> Having a meeting makes sense.
> > >>>>>
> > >>>>> Take care,
> > >>>>> Michael
> > >>>>>
> > >>>>> On Tue, 19 Mar 2013, Ken Livingston wrote:
> > >>>>>
> > >>>>>> Hi All,
> > >>>>>> It does indeed look like we cooked with the version that was
> > >>>>>> in
> > >>>>>> /home/clasg8/g8/packages/
> > >>>>>> where, as Brian says, we had
> > >>>>>> #define SC_TDC_MAX 4096
> > >>>>>>
> > >>>>>> if I look at set_env_g8b.sh see
> > >>>>>> export CLAS_PACK=/u/home/${RUN_USER}/g8/packages
> > >>>>>>
> > >>>>>> I think we do need to consider recalibrating the TOF and
> > >>>>>> recooking the data. At least starting with one coherent peak
> > >>>>>> setting.
> > >>>>>>
> > >>>>>> What do you all think?
> > >>>>>> We should at least have a meeting to discuss this.
> > >>>>>>
> > >>>>>> Cheers,
> > >>>>>> Ken
> > >>>>>>
> > >>>>>>
> > >>>>>>
> > >>>>>>
> > >>>>>>
> > >>>>>> On 19/03/13 13:43, Franz Klein wrote:
> > >>>>>>> sorry, replied only to Eugene ...
> > >>>>>>> ----- Forwarded Message -----
> > >>>>>>> From: "Franz Klein" <fklein at jlab.org>
> > >>>>>>> To: "Eugene Pasyuk" <pasyuk at jlab.org>
> > >>>>>>> Sent: Tuesday, March 19, 2013 9:38:42 AM
> > >>>>>>> Subject: Re: g8b TOF paddle issue
> > >>>>>>> Yes, Eugene, I worked on the copy_pipeline.cc routine in
> > >>>>>>> the
> > >>>>>>> beginning of g9a ... mostly because the SC, EC banks took
> > >>>>>>> the
> > >>>>>>> first TDC entry from SCT, ECT instead of the one which is
> > >>>>>>> in
> > >>>>>>> the 'right' (expected) range.
> > >>>>>>> So maybe I'll take a look first into the g8b version of
> > >>>>>>> this
> > >>>>>>> routine as well as SCT, ECT, REF.
> > >>>>>>> ----- Original Message -----
> > >>>>>>> From: "Eugene Pasyuk" <pasyuk at jlab.org>
> > >>>>>>> To: "Franz Klein" <fklein at jlab.org>
> > >>>>>>> Cc: "Michael Dugger" <dugger at jlab.org>, crede at fsu.edu,
> > >>>>>>> "Brian
> > >>>>>>> Vernarsky" <soulish at gmail.com>, "Kenneth Livingston"
> > >>>>>>> <Kenneth.Livingston at glasgow.ac.uk>
> > >>>>>>> Sent: Tuesday, March 19, 2013 9:29:45 AM
> > >>>>>>> Subject: Re: g8b TOF paddle issue
> > >>>>>>> One thing which comes to mind is that at some point after
> > >>>>>>> pipeline TDC were installed we discovered that there is
> > >>>>>>> some
> > >>>>>>> issue in on-line procedure of matching TDC and ADC from SC
> > >>>>>>> and
> > >>>>>>> SCT banks and remaking of raw SC bank. The procedure was
> > >>>>>>> revisited and as I recall we used new matching procedure in
> > >>>>>>> user_ana for g9a data. May be this is the reason for g8b
> > >>>>>>> problem?
> > >>>>>>> -Eugene
> > >>>>>>> ----- Original Message -----
> > >>>>>>>> From: "Franz Klein" <fklein at jlab.org>
> > >>>>>>>> To: "Kenneth Livingston"
> > >>>>>>>> <Kenneth.Livingston at glasgow.ac.uk>
> > >>>>>>>> Cc: "Michael Dugger" <dugger at jlab.org>, "Eugene Pasyuk"
> > >>>>>>>> <pasyuk at jlab.org>, crede at fsu.edu, "Brian Vernarsky"
> > >>>>>>>> <soulish at gmail.com>
> > >>>>>>>> Sent: Tuesday, March 19, 2013 9:23:00 AM
> > >>>>>>>> Subject: Re: g8b TOF paddle issue
> > >>>>>>>> Ken,
> > >>>>>>>> unfortunately I don't remember whether we checked or
> > >>>>>>>> changed
> > >>>>>>>> the cut
> > >>>>>>>> on overflows. We took the code from eg3 (Joern) which
> > >>>>>>>> assumes
> > >>>>>>>> TDC
> > >>>>>>>> entries in the range ~1000 to ~6000 (depending on particle
> > >>>>>>>> and
> > >>>>>>>> REF
> > >>>>>>>> signal).
> > >>>>>>>> However, Brian found out quite some time ago that often in
> > >>>>>>>> multi-track events many track candidates weren't getting
> > >>>>>>>> into
> > >>>>>>>> time-based tracking due to missing timing information from
> > >>>>>>>> ST
> > >>>>>>>> and/or
> > >>>>>>>> SC.
> > >>>>>>>> For sure we made the mistake to cut out all SC paddles in
> > >>>>>>>> the
> > >>>>>>>> reconstruction for which the calibration didn't work out
> > >>>>>>>> (instead of
> > >>>>>>>> letting students worry about SC paddle cuts later in their
> > >>>>>>>> analysis). In that sense it might be a good idea to
> > >>>>>>>> recheck
> > >>>>>>>> ST
> > >>>>>>>> and
> > >>>>>>>> SC calibrations and maybe rerun user_ana for some coh.edge
> > >>>>>>>> setting
> > >>>>>>>> on the farm.
> > >>>>>>>> Maybe as a first step, Brian should tar his source code he
> > >>>>>>>> copied
> > >>>>>>>> from the clasg8 account and we verify whether it is the
> > >>>>>>>> code
> > >>>>>>>> which
> > >>>>>>>> was used for g8b reconstruction.
> > >>>>>>>> Cheers,
> > >>>>>>>> Franz
> > >>>>>>>> ----- Original Message -----
> > >>>>>>>> From: "Ken Livingston" <Kenneth.Livingston at glasgow.ac.uk>
> > >>>>>>>> To: "Brian Vernarsky" <soulish at gmail.com>
> > >>>>>>>> Cc: "Michael Dugger" <dugger at jlab.org>, "Eugene Pasyuk"
> > >>>>>>>> <pasyuk at jlab.org>, crede at fsu.edu, "Franz Klein"
> > >>>>>>>> <fklein at jlab.org>
> > >>>>>>>> Sent: Tuesday, March 19, 2013 8:18:45 AM
> > >>>>>>>> Subject: Re: g8b TOF paddle issue
> > >>>>>>>> Hi Brian,
> > >>>>>>>> There's certainly something funny going on there which we
> > >>>>>>>> need
> > >>>>>>>> to get
> > >>>>>>>> to
> > >>>>>>>> the bottom of.
> > >>>>>>>> However, I'm not sure your diagnosis is correct.
> > >>>>>>>> As far as I can see, when I log on to the clasg8 account
> > >>>>>>>> cd
> > >>>>>>>> $CLAS_PACK
> > >>>>>>>> directory is set to
> > >>>>>>>> /home/clasg8/packages, not /home/clasg8/g8/packages/
> > >>>>>>>> where
> > >>>>>>>> you
> > >>>>>>>> mention
> > >>>>>>>> finding the header file with the old version of sc.h.
> > >>>>>>>> In the clasg8 account version of $CLAS_PACK/include/sc.h
> > >>>>>>>> the
> > >>>>>>>> relevant
> > >>>>>>>> line is
> > >>>>>>>> #define SC_TDC_MAX 8192 /* pipeline */
> > >>>>>>>> Do any of the rest of you have any opinion or memory on
> > >>>>>>>> that?
> > >>>>>>>> Regards,
> > >>>>>>>> Ken
> > >>>>>>>> On 18/03/13 22:03, Brian Vernarsky wrote:
> > >>>>>>>>> Hello all,
> > >>>>>>>>> In trying to finalize my results for the spin density
> > >>>>>>>>> matrix
> > >>>>>>>>> elements
> > >>>>>>>>> for the omega I have run into a serious issue with the
> > >>>>>>>>> g8b
> > >>>>>>>>> dataset.
> > >>>>>>>>> When I project out my spin density matrix elements I
> > >>>>>>>>> found
> > >>>>>>>>> that the
> > >>>>>>>>> unpolarized elements, which can be compared to previous
> > >>>>>>>>> experiments
> > >>>>>>>>> (g11a most notably), were slightly offset with respect to
> > >>>>>>>>> those
> > >>>>>>>>> previous measurements. I have shown these elements at
> > >>>>>>>>> previous
> > >>>>>>>>> CLAS
> > >>>>>>>>> Hadron meetings so some of you may be aware of this.
> > >>>>>>>>> I traced the source of my problem back to the fact that
> > >>>>>>>>> the
> > >>>>>>>>> phi
> > >>>>>>>>> distributions of the particles were skewed and this was
> > >>>>>>>>> not
> > >>>>>>>>> properly
> > >>>>>>>>> reflected in the monte carlo. Looking further into the
> > >>>>>>>>> issue
> > >>>>>>>>> I
> > >>>>>>>>> discovered that the start counters have a serious issue
> > >>>>>>>>> with
> > >>>>>>>>> detecting
> > >>>>>>>>> individual pions; the efficiency varies wildly from
> > >>>>>>>>> paddle
> > >>>>>>>>> to
> > >>>>>>>>> paddle.
> > >>>>>>>>> However, since we had a one-track trigger and I am
> > >>>>>>>>> looking
> > >>>>>>>>> for
> > >>>>>>>>> three-track events with a proton, this was not the source
> > >>>>>>>>> of
> > >>>>>>>>> my
> > >>>>>>>>> issue,
> > >>>>>>>>> however it could be a serious issue for anyone looking
> > >>>>>>>>> into
> > >>>>>>>>> single
> > >>>>>>>>> pion reactions. The source of my issue is particles that
> > >>>>>>>>> have
> > >>>>>>>>> a
> > >>>>>>>>> TOF
> > >>>>>>>>> paddle set to 0, indicating there is a problem with them.
> > >>>>>>>>> As
> > >>>>>>>>> you
> > >>>>>>>>> can
> > >>>>>>>>> see in the enclosed file phi_distributions_g8b.pdf the
> > >>>>>>>>> actual
> > >>>>>>>>> phi
> > >>>>>>>>> distribution for each particle (in black) looks to be ok,
> > >>>>>>>>> however
> > >>>>>>>>> when
> > >>>>>>>>> we remove the particles with TOF paddle = 0 (in red) and
> > >>>>>>>>> are
> > >>>>>>>>> left
> > >>>>>>>>> with
> > >>>>>>>>> just the particles with a "good" TOF paddle (in blue)
> > >>>>>>>>> there
> > >>>>>>>>> is
> > >>>>>>>>> a
> > >>>>>>>>> pretty severe problem, mostly for the pions.
> > >>>>>>>>> In looking at the TOF paddle = 0 events for the two pions
> > >>>>>>>>> you
> > >>>>>>>>> can
> > >>>>>>>>> notice that they are almost the exact same, whereas the
> > >>>>>>>>> proton
> > >>>>>>>>> has
> > >>>>>>>>> significantly less events with a "bad" TOF paddle. And
> > >>>>>>>>> there
> > >>>>>>>>> is a
> > >>>>>>>>> definite phi dependence to the bad events. Certainly we
> > >>>>>>>>> should
> > >>>>>>>>> expect
> > >>>>>>>>> some events with bad TOF paddles in every channel,
> > >>>>>>>>> however
> > >>>>>>>>> this is
> > >>>>>>>>> accounting for almost half of the total events in sector
> > >>>>>>>>> 5
> > >>>>>>>>> for
> > >>>>>>>>> the
> > >>>>>>>>> pions. There is no physical reason for this to be so.
> > >>>>>>>>> I have found the source of the problem to be in the TDCs
> > >>>>>>>>> of
> > >>>>>>>>> the TOF
> > >>>>>>>>> paddles. In the file tdcs_and_adcs_g8b.pdf I have shown
> > >>>>>>>>> the
> > >>>>>>>>> values
> > >>>>>>>>> from the TDCs and ADCs for the TOF paddles, in the order
> > >>>>>>>>> TDCL,
> > >>>>>>>>> ADCL,
> > >>>>>>>>> TDCR, ADCR, for the proton (top), pi+ (middle) and pi-
> > >>>>>>>>> (bottom),
> > >>>>>>>>> integrated over all paddles and sectors for one amorphous
> > >>>>>>>>> run
> > >>>>>>>>> (48133).
> > >>>>>>>>> The blue on each plot are "good" events and the red
> > >>>>>>>>> are
> > >>>>>>>>> "bad", or
> > >>>>>>>>> TOF
> > >>>>>>>>> = 0, events. It is very evident from the TDC plots for
> > >>>>>>>>> all
> > >>>>>>>>> particles
> > >>>>>>>>> that something turns on at channel 4096. I have tried to
> > >>>>>>>>> illustrate
> > >>>>>>>>> that by drawing a vertical line at 4096 on the TDC plots.
> > >>>>>>>>> The
> > >>>>>>>>> ADC
> > >>>>>>>>> plots show nothing out of the ordinary.
> > >>>>>>>>> What happened is that before the g8b run the TDCs were
> > >>>>>>>>> changed
> > >>>>>>>>> from
> > >>>>>>>>> a
> > >>>>>>>>> 12-bit system to a 16-bit system, changing the maximum
> > >>>>>>>>> channel
> > >>>>>>>>> from
> > >>>>>>>>> 4096 to 65536. However, this change was not made in the
> > >>>>>>>>> code
> > >>>>>>>>> as in
> > >>>>>>>>> the g8b cooking code (found at /home/clasg8/g8/packages/)
> > >>>>>>>>> the
> > >>>>>>>>> file
> > >>>>>>>>> include/sc.h we find
> > >>>>>>>>> #define SC_TDC_MAX 4096
> > >>>>>>>>> instead of 8192 like we find in other experiments after
> > >>>>>>>>> the
> > >>>>>>>>> TDCs
> > >>>>>>>>> were
> > >>>>>>>>> changed. (It seems that while we effectively have 65,536
> > >>>>>>>>> channels
> > >>>>>>>>> in
> > >>>>>>>>> practice we only use 8192.) Any particle that registered
> > >>>>>>>>> above
> > >>>>>>>>> 4096
> > >>>>>>>>> on a TDC was deemed a "bad" event in that TDC. If the
> > >>>>>>>>> particle had
> > >>>>>>>>> a
> > >>>>>>>>> "bad" TDCL but a "good" TDCR then it is still possible to
> > >>>>>>>>> recover
> > >>>>>>>>> the
> > >>>>>>>>> events, and vice versa, though not all particles could be
> > >>>>>>>>> recovered
> > >>>>>>>>> in
> > >>>>>>>>> this way. However, if both TDCs measured a value above
> > >>>>>>>>> 4096
> > >>>>>>>>> then
> > >>>>>>>>> the
> > >>>>>>>>> particle was deemed "bad" and assigned TOF paddle = 0.
> > >>>>>>>>> For a signifcant number of TOF paddles the range of TDC
> > >>>>>>>>> channels
> > >>>>>>>>> was
> > >>>>>>>>> from 3800-4200, though some skewed higher or lower than
> > >>>>>>>>> others.
> > >>>>>>>>> For
> > >>>>>>>>> paddles where the distribution was quite high as many as
> > >>>>>>>>> half
> > >>>>>>>>> of
> > >>>>>>>>> the
> > >>>>>>>>> pions were cut and a signficant number of protons were
> > >>>>>>>>> also
> > >>>>>>>>> cut.
> > >>>>>>>>> This
> > >>>>>>>>> led to difficulty in calibrating the paddle and so the
> > >>>>>>>>> entire
> > >>>>>>>>> paddle
> > >>>>>>>>> was cut. There were 31 paddles cut in g8b, more than 10%
> > >>>>>>>>> of
> > >>>>>>>>> the
> > >>>>>>>>> total
> > >>>>>>>>> number of paddles.
> > >>>>>>>>> For the pions the cut is pretty evenly distributed across
> > >>>>>>>>> the
> > >>>>>>>>> momentum
> > >>>>>>>>> spectrum, but for protons it cuts only events above ~550
> > >>>>>>>>> MeV
> > >>>>>>>>> as can
> > >>>>>>>>> be
> > >>>>>>>>> seen in the file p_dist_bad_paddles.pdf, which shows the
> > >>>>>>>>> momentum
> > >>>>>>>>> distribution for protons that have been ascribed TOF
> > >>>>>>>>> paddle
> > >>>>>>>>> =
> > >>>>>>>>> 0.
> > >>>>>>>>> Now,
> > >>>>>>>>> this is a small fraction of the total number of proton
> > >>>>>>>>> events,
> > >>>>>>>>> but
> > >>>>>>>>> it
> > >>>>>>>>> is still significant.
> > >>>>>>>>> Based on all of this I think that it is imperative that
> > >>>>>>>>> we
> > >>>>>>>>> recook
> > >>>>>>>>> the
> > >>>>>>>>> g8b dataset. We will need to change the value of
> > >>>>>>>>> SC_TDC_MAX
> > >>>>>>>>> and
> > >>>>>>>>> then
> > >>>>>>>>> recalibrate the TOF paddles; hopefully the ones that were
> > >>>>>>>>> considered
> > >>>>>>>>> "good" before will not need much work, but of the ones
> > >>>>>>>>> considered
> > >>>>>>>>> "bad" before most of them can almost certainly be
> > >>>>>>>>> salvaged.
> > >>>>>>>>> This
> > >>>>>>>>> recook is necessary because it is clear that this is
> > >>>>>>>>> significantly
> > >>>>>>>>> affecting the phi and momentum distributions of all
> > >>>>>>>>> particles
> > >>>>>>>>> and
> > >>>>>>>>> thus
> > >>>>>>>>> will affect all measurements that depend on phi,
> > >>>>>>>>> momentum,
> > >>>>>>>>> TOF
> > >>>>>>>>> or
> > >>>>>>>>> particle ID. The plus side is that we can recover a
> > >>>>>>>>> large
> > >>>>>>>>> number
> > >>>>>>>>> of
> > >>>>>>>>> paddles and thus increase our statistics significantly,
> > >>>>>>>>> especially
> > >>>>>>>>> with multi-particle events. Any other minor issues that
> > >>>>>>>>> wouldn't
> > >>>>>>>>> necessitate a recook on their own can also be addressed
> > >>>>>>>>> before
> > >>>>>>>>> we
> > >>>>>>>>> start. And lastly I think that it would be a very good
> > >>>>>>>>> idea
> > >>>>>>>>> to
> > >>>>>>>>> include some more banks in the cooked files this time
> > >>>>>>>>> than
> > >>>>>>>>> we
> > >>>>>>>>> did
> > >>>>>>>>> before; to find the TDC and ADC values I had to go to the
> > >>>>>>>>> raw
> > >>>>>>>>> files
> > >>>>>>>>> without any PID info and then cross check between that
> > >>>>>>>>> and
> > >>>>>>>>> the
> > >>>>>>>>> cooked
> > >>>>>>>>> file to make sure I had the right particle, certainly the
> > >>>>>>>>> SC
> > >>>>>>>>> banks
> > >>>>>>>>> should be included in the newly cooked files.
> > >>>>>>>>> Let me know what you think, if you would like any
> > >>>>>>>>> additional
> > >>>>>>>>> information or plots just ask.
> > >>>>>>>>> Brian
> > >>>>>>>> --
> > >>>>>>>> =======================================================
> > >>>>>>>> Ken Livingston
> > >>>>>>>> Dept. of Physics & Astronomy, Tel: +44 141 330 6428
> > >>>>>>>> University of Glasgow, Fax: +44 141 330 5889
> > >>>>>>>> Glasgow G12 8QQ.
> > >>>>>>>> Scotland. UK.
> > >>>>>>>> =======================================================
> > >>>>>>>> --
> > >>>>>>>> ===============================================================
> > >>>>>>>> Franz J. Klein, Associate Professor
> > >>>>>>>> CUA, Department of Physics
> > >>>>>>>> Washington, DC 20064
> > >>>>>>>> office: Hannan Hall 206 phone: 202-319-6190
> > >>>>>>>> or: Jefferson Lab,CC F-243 phone: 757-269-6672
> > >>>>>>>> ---------------------------------------------------------------
> > >>>>>>
> > >>>>>> --
> > >>>>>> =======================================================
> > >>>>>> Ken Livingston
> > >>>>>>
> > >>>>>> Dept. of Physics & Astronomy, Tel: +44 141 330 6428
> > >>>>>> University of Glasgow, Fax: +44 141 330 5889
> > >>>>>> Glasgow G12 8QQ.
> > >>>>>> Scotland. UK.
> > >>>>>> =======================================================
> > >>>>
> > >> _______________________________________________
> > >> G8b_run mailing list
> > >> G8b_run at jlab.org
> > >> https://mailman.jlab.org/mailman/listinfo/g8b_run
> > >>
> > > _______________________________________________
> > > G8b_run mailing list
> > > G8b_run at jlab.org
> > > https://mailman.jlab.org/mailman/listinfo/g8b_run
> >
> >
> > --
> > =======================================================
> > Ken Livingston
> >
> > Dept. of Physics & Astronomy, Tel: +44 141 330 6428
> > University of Glasgow, Fax: +44 141 330 5889
> > Glasgow G12 8QQ.
> > Scotland. UK.
> > =======================================================
> >
> > _______________________________________________
> > G8b_run mailing list
> > G8b_run at jlab.org
> > https://mailman.jlab.org/mailman/listinfo/g8b_run
> >
> _______________________________________________
> G8b_run mailing list
> G8b_run at jlab.org
> https://mailman.jlab.org/mailman/listinfo/g8b_run
>
More information about the G8b_run
mailing list