Hi Eugene,
You can create a TChain of 400 event files with 'init.C' and then
loop through them with the standard TSelector methods. See, for
example 'blast/exp/analysis/macros/tmt_offsets.C'. It is fast
because it correctly handles chains and only actually opens one file
at a time. I just started with the root standard example, and it
does support SetBranchStatus (although I just manually read the
branches I am interested in).
If your 'Int_t list' is an event list, I recommend using the
TEventList support in ROOT. They can also be save in TFile's.
--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 May 22, 2006, at 11:26:19, Eugene J. Geis wrote:
> the files aren't broken. I can load them individually from the
> command line in ROOT using the exact same commands that kill
> ROOT from the inside of my program (This is what I mean when I
> contend that I have a ridiculous amount of bad luck when I try and
> do simple things). The problem with lr.C is
> that I'll have to call it 400 times in this program. I don't
> think it is wise to chain 400 lr files due to their size. If I am
> mistaken in this assumption, please let me know as this task
> would become very easy to accomplish. I was also thinking about
> filling a 2-D array of 2.6 million integers but I haven't tried
> this either because I'm afraid of more memory problems. I don't
> know much about the limitations of the innards of computing. If
> an array this large, e.g. Int_t list[2][1300000], is ok, then I
> could cut the possibility that it is a problem with having two
> input files open (the ifstream eventlist file and the lr-# ntuple).
>
> Also,since I'm building an ntuple of 12 entries and using the memory
> addresses of the branches in the lr-# file. I am calling
> SetBranchStatus, and SetBranchAddress functions and I don't know if
> these are accessible through any other method outside of calling an
> instance of TNtuple.
>
> -e
>
>
>
> Quoting Christopher Crawford <chris2@lns.mit.edu>:
>
>> Hi Eugene,
>> Have you tried 'lr.C'? Perhaps those files are broken, but still
>> it shouldn't break ROOT.
>> --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 May 22, 2006, at 01:51:35, Eugene J. Geis wrote:
>>
>>> Hello,
>>> Another insignificant email of the ridiculous bad luck
>>> I have with every simple thing I try:
>>>
>>> I'm opening an event list that spans about 400+ run
>>> numbers. I need to open the 7 data files that contain
>>> my event list sequentially, and open single lr-# files
>>> one at a time to retrieve and fill a 12 member branch
>>> in a TTree. When I open particular run numbers, e.g.
>>> 8412, 8413, 8414, 8416, 8482... my program simply breaks.
>>> I declare the TFile, and when I file->Get("lr"); the program
>>> breaks and root quits. Works for all files in my runlist from
>>> ~7800 through 8211, then breaks for the run numbers mentioned
>>> earlier.
>>>
>>> This is how I call the lr files.
>>>
>>> TFile* file = new TFile("/net/Data/9/Analysis/data/lr-#.root");
>>> TNtuple* block = (TNtuple*)file->Get("lr");
>>>
>>> I open these files one at a time while I keep an ifstream
>>> instance of a file open. Maybe memory errors? In which case
>>> I still need to do this differently.
>>>
>>> Does anyone use some alternate ways of calling lr events from
>>> an Ntuple file?
>>>
>>> -e
>>>
>>> --------------------------------------------------------------------
>>> --
>>
>>> ----
>>> Eugene Geis
>>> PhD Student, Physics Department, ASU
>>> Research Affiliate, MIT-Bates Laboratory of Nuclear Science
>>> eugene.geis@asu.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