I have a workaround... It isn't a "true" nwl/r entry, but I can retrieve those
and the hwl/r entries from the flr files. Small pain in ass but manageable.
And vitaly swears that a shift in acceptance is impossible... Don't know
what to say...
-eugene
Quoting Christopher Crawford <chris2@lns.mit.edu>:
> In this case, I would strongly recommend using the TChain::Friend
> functionality. This is, in fact what I used for my thesis analysis
> when I wanted to include information from an auxiliary ntuple
> containing the variables "ltwl,r" and "xtwl,r". It is also
> extremely to use within the context of 'init.C'.
> All you have to do is invoke your script with two data sets, for
> example:
>
> root -l myscript.C $ANALDIR/flr 12144-13266 -d $OLDANALDIR/flr
> 12144-13266
>
> Then, in your script add the following line after invoking 'init()'
> or '.x init.C':
>
> chain[0]->AddFriend(chain[1],"old");
>
> Finally, you can access "nwl" and cousins from the old flr by
> appending 'old.', for example:
>
> chain[0]->Draw("twl:twr","old.hwl>18");
>
> This may be an easy and attractive alternative to a week of Chi's
> frustration! BTW, the 'lr' or even 'flr' structures are not subsets
> of the 'dst'.
>
> --Chris
> _______________________________________
>
> TA-53/MPF-1/D111 P-23 MS H803
> LANL, Los Alamos, NM 87545
> 505-665-9804(o) 665-4121(f) 662-0639(h)
> _______________________________________
>
>
> On Apr 10, 2006, at 11:58:45, Michael Kohl wrote:
>
> > Hi Chi,
> >
> > don't call these entries non-essential. In fact, they are needed
> > e.g. by Eugene to make the proton veto by the wch effective.
> > Also Yuan had asked for these variables.
> >
> > Can't we just copy the old flr tree and have lrd update only those
> > fields that are subject to change? You did it similarly with the
> > charge tree which is an identical copy.
> > I think flr from lrd should have the same entries like flr generate
>
> > by lrn.
> >
> > Is it really a week of developing time??
> >
> > And, asking on the DST: Does it not contain the flr-tree?
> >
> > Best regards,
> >
> > Michael
> >
> >
> >
> > On Mon, 10 Apr 2006, Chi Zhang wrote:
> >
> >>
> >> Hi,
> >>
> >> I forgot what nwl/r mean, but hwl/r mean the total number of WC
> >> hits in each sector. So it is not surprising that when recrunched
> >> from DST, this piece of info is not recoverable, since DST
> >> contains only the "linked" hits, not all hits. These variables
> >> were introduced quite a while ago for WC debugging purpose anyway.
>
> >> At that time, we were very concerned and interested about the
> >> X'mas tree and/or inefficient events in the chamber. The running
> >> condition was largely improved by the introduction of 2nd level
> >> trigger.
> >>
> >> One could presumably open the old lr/flr files and copy the
> >> fields, but that requires a whole bunch of new codes to handle the
>
> >> ntuple root files and synch of events in multiple old root files.
> >> I saw the reward of preserving a few non-essential entries too
> >> little to justify another week of devel time. :)
> >>
> >> Chi
> >>
> >> On Mon, 10 Apr 2006, Michael Kohl wrote:
> >>
> >>> Hi,
> >>> I've just checked and found that flr files produced by lrd have
> >>> never had nwl,r and hwl,r filled in any version.
> >>> So, this seems not be a bug but a missing piece of software in
> lrd.
> >>> Regards,
> >>>
> >>> Michael
> >>> On Mon, 10 Apr 2006, Yuan Xiao wrote:
> >>>> Hi Chris and Michael,
> >>>> Just a reminder, from v16 and including v16, nwl/r and hwl/r
> >>>> were all zeros.
> >>>> Yuan
> >>>> Quoting Christopher Crawford <chris2@lns.mit.edu>:
> >>>>> Hi Michael,
> >>>>> I'll take a look at them as soon as I can. You can do 'cvs
> >>>>> diff - r v3_4_17 -r v3_4_18', to see what has changed, but I
> >>>>> can't think of anything I would have don't to omit them.
> >>>>> You are right, I haven't looked at Lwl,r yet. I did
> >>>>> introduce an independent (albeit slow) track fitter
> >>>>> TBLMinuitTrack as a check of TBLNewt. The only thing left to
> >>>>> check in reconstruction is TBLSimTrack, the RK4 integrator
> >>>>> itself. It has undergone various modifications, and the fact
> >>>>> that it doesn't calculate the track length properly leads me
> >>>>> to suspect the rest of the integration also! So I believe the
>
> >>>>> proper way to check the path length is to rewrite a new track
> >>>>> integration, which integrates along arc-lengths instead of
> >>>>> straight lines (for higher accuracy). When I get time!
> >>>>> --Chris
> >>>>> _______________________________________
> >>>>> TA-53/MPF-1/D111 P-23 MS H803
> >>>>> LANL, Los Alamos, NM 87545
> >>>>> 505-665-9804(o) 665-4121(f) 662-0639(h)
> >>>>> _______________________________________
> >>>>> On Apr 10, 2006, at 09:03:04, Michael Kohl wrote:
> >>>>>> Hi Chris,
> >>>>>> can you find out the reason for the missing entries? I think
> >>>>>> it only occurred after you checked in your new variables.
> >>>>>> On pathlength: In v3_4_18 there are still double peaks in
> >>>>>> Lwl,r. Am I right that this method hasn't been touched and
> >>>>>> that the only fix compared to v3_4_17 was regarding ltwl,r?
> >>>>>> Is ltwl,r correct? Are we going to live with ltwl,r for the
> >>>>>> time being?
> >>>>>> Best regards,
> >>>>>>
> >>>>>> Michael
> >>>>>> ---------- Forwarded message ----------
> >>>>>> Date: Sun, 09 Apr 2006 17:59:29 -0700 (MST)
> >>>>>> From: Eugene J. Geis <Eugene.Geis@asu.edu>
> >>>>>> To: Michael Kohl <kohlm@mit.edu>
> >>>>>> Cc: Yuan Xiao <yxiao@mit.edu>,
> >>>>>> "[BLAST_ANAWARE]" <Blast_anaware@rocko.lns.mit.edu>
> >>>>>> Subject: Re: unfilled nwl/r and hwl/r
> >>>>>> Hi Mike and All,
> >>>>>> This needs to be fixed ASAP... I can't trust any lrd
> >>>>>> recrunches if this is always going to be the case that
> >>>>>> nwl/r or hwl/r is not included. As it turns out, v17
> >>>>>> 2005 data is missing these as well and means that my
> >>>>>> recrunched 2005 GEN analysis is completely untrustworthy.
> >>>>>> Thanks Yuan for noticing this... I took it for granted
> >>>>>> that this was an old issue. If the whole reconstruction
> >>>>>> is re-done, what is so hard about accessing these values?
> >>>>>> I wish I was part of the collaboration earlier so I'd
> >>>>>> have a better understanding of our software, and I'd fix
> >>>>>> these problems...
> >>>>>> -e
> >>>>>> Quoting Michael Kohl <kohlm@mit.edu>:
> >>>>>>> Hi Yuan,
> >>>>>>> I'm doubting that this happens on purpose. Chris, can you
> >>>>>>> comment?
> >>>>>>> The used crunch command was
> >>>>>>> "lrd -ff +nw +pid +epsk +SQL Geometry.File=blast.geom.2004"
> >>>>>>> On your access of blast_anaware mailing list, please contact
> >>>>>>> Barbara
> >>>>>>> Santorella <bsantore@MIT.EDU>.
> >>>>>>> Regards,
> >>>>>>>
> >>>>>>> Michael
> >>>>>>> On Tue, 4 Apr 2006, Yuan Xiao wrote:
> >>>>>>>> Hi, Michael,
> >>>>>>>> From recrunch version 16, nwl/r and hwl/r have not been
> filled.
> >>>>>>>> Is this on purpose? or is there something wrong?
> >>>>>>>> BTW, I'm not authorized to send emails to "[BLAST_ANAWARE]"
> >>>>>>>> <Blast_anaware@rocko.lns.mit.edu>. Can u help me with this?
> >>>>>>>> Thanks and regards,
> >>>>>>>> Yuan
> >>>>>>> +-------------------------------------
> >>>>>>> +--------------------------+
> >>>>>>> | Office: |
> >>>>>>> Home: |
> >>>>>>> |-------------------------------------|-------------------------
>
> >>>>>>> -|
> >>>>>>> | Dr. Michael Kohl | Michael
> >>>>>>> Kohl |
> >>>>>>> | Laboratory for Nuclear Science | 5 Ibbetson
> >>>>>>> Street |
> >>>>>>> | MIT-Bates Linear Accelerator Center | Somerville, MA
> >>>>>>> 02143 |
> >>>>>>> | Middleton, MA 01949 |
> >>>>>>> U.S.A. |
> >>>>>>> | U.S.A.
> >>>>>>> | |
> >>>>>>> | - - - - - - - - - - - - | - - - - - - -
> >>>>>>> - -|
> >>>>>>> | Email: kohlm@mit.edu |
> >>>>>>> K.Michael.Kohl@gmx.de |
> >>>>>>> | Work: +1-617-253-9207 | Home:
> >>>>>>> +1-617-629-3147 |
> >>>>>>> | Fax: +1-617-253-9599 | Mobile:
> >>>>>>> +1-978-580-4190 |
> >>>>>>> | http://blast.lns.mit.edu
> >>>>>>> | |
> >>>>>>> +-------------------------------------
> >>>>>>> +--------------------------+
> >>>>>> -----------------------------------------------------------------
>
> >>>>>> ----- ----
> >>>>>> Eugene Geis
> >>>>>> PhD Student, Physics Department, ASU
> >>>>>> Research Affiliate, MIT-Bates Laboratory of Nuclear Science
> >>>>>> eugene.geis@asu.edu
> >>>>>> -----------------------------------------------------------------
>
> >>>>>> ----- ----
> >>>>>> http://quickreaction.blogspot.com
> >>> +-------------------------------------+--------------------------+
> >>> | Office: | Home: |
> >>> |-------------------------------------|--------------------------|
> >>> | Dr. Michael Kohl | Michael Kohl |
> >>> | Laboratory for Nuclear Science | 5 Ibbetson Street |
> >>> | MIT-Bates Linear Accelerator Center | Somerville, MA 02143 |
> >>> | Middleton, MA 01949 | U.S.A. |
> >>> | U.S.A. | |
> >>> | - - - - - - - - - - - - | - - - - - - - - -|
> >>> | Email: kohlm@mit.edu | K.Michael.Kohl@gmx.de |
> >>> | Work: +1-617-253-9207 | Home: +1-617-629-3147 |
> >>> | Fax: +1-617-253-9599 | Mobile: +1-978-580-4190 |
> >>> | http://blast.lns.mit.edu | |
> >>> +-------------------------------------+--------------------------+
> >>
> >
> >
> > +-------------------------------------+--------------------------+
> > | Office: | Home: |
> > |-------------------------------------|--------------------------|
> > | Dr. Michael Kohl | Michael Kohl |
> > | Laboratory for Nuclear Science | 5 Ibbetson Street |
> > | MIT-Bates Linear Accelerator Center | Somerville, MA 02143 |
> > | Middleton, MA 01949 | U.S.A. |
> > | U.S.A. | |
> > | - - - - - - - - - - - - | - - - - - - - - -|
> > | Email: kohlm@mit.edu | K.Michael.Kohl@gmx.de |
> > | Work: +1-617-253-9207 | Home: +1-617-629-3147 |
> > | Fax: +1-617-253-9599 | Mobile: +1-978-580-4190 |
> > | http://blast.lns.mit.edu | |
> > +-------------------------------------+--------------------------+
> >
> >
> >
> >
> >
> >
> >
> >
> >
> >
> >
> >
> >
>
>
--------------------------------------------------------------------------
Eugene Geis
PhD Student, Physics Department, ASU
Research Affiliate, MIT-Bates Laboratory of Nuclear Science
eugene.geis@asu.edu
--------------------------------------------------------------------------
http://quickreaction.blogspot.com
This archive was generated by hypermail 2.1.2 : Mon Feb 24 2014 - 14:07:33 EST