Just a thought: In 'lrd', some of the information is taken from the
DST, and the rest from the LR-ntuple. So the problem may be that
'lrd' could not find the LR-ntuple, and therefore some of the
information is missing.
--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 13:23:42, Christopher Crawford wrote:
> 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 | |
>> +-------------------------------------+--------------------------+
>>
>>
>>
>>
>>
>>
>>
>>
>>
>>
>>
>>
>>
This archive was generated by hypermail 2.1.2 : Mon Feb 24 2014 - 14:07:33 EST