Re: Couple of questions/comments regarding TRefs in a array (5.18.00a)

Hi Constantin,

Constantin Loizides wrote:
> Hi Rene,
> thanks for the fast response.
>
> Would option a) the TRefArray also work if
> I'd start to mix events where the contents of the event
> come from two different files/processes?
Yes, this should work.
>
> Not clear to me how to "associate" the TRef to the
> TRefArray, what do you mean by that?

In order to get the autoloading, for each collection that you want to see autoloaded
define a TRef pointing to any element of this collection. Then when reading, before using the TRefArray
make sure that the collection is read from the Tree by reading the TRef branch and dereferencing the TRef object.   TClonesArray* mycollection; //collection of say Tracks   TRef* junkref;
  TRefArray muons; //collections of muons (references to elements in mycollection)

When reading, get a pointer to the branch corresponding to junkref (say b_junkref)
 -b_junkref->GetEntry(entry);

• junkref->GetObject(); //this will force the autoreading of the TClonesArray branch -Get a pointer (say b_muons) to the TRefArray branch -b_muons->GetEntry(entry); -Now you can use muons array.

Rene

>
> (Would I still call TTree::BranchRef())
>
> Thanks,
> Constantin
>
>
> Rene Brun wrote:
>> Hi Constantin,
>>
>> Constantin Loizides wrote:
>>> Dear all,
>>>
>>> I'd like to store an array of TRefs in a class that
>>> itself is stored in a TClonesArray. The TRefs can point
>>> to objects in different branches of the same tree.
>>> The following are my findings/questions for 5.18.00a.
>>>
>>> a) Using a TRefArray:
>>> TRefs stored in TRefArray seem not to support
>>> autoloading via TTree::BranchRef()?
>> correct. We will implement this possibility in a medium term version.
>> For the time being you must associate a TRef object to the TRefArray
>> to force the autoloading of another branch.
>>>
>>> Also not sure if TRefArray would be split?
>> This does not make sense. The TRefArray elements are streamed to the
>> same buffer.
>>>
>>> Assuming the above two points could be
>>> made to work. What happens if I merge two trees created
>>> in different processes? From the description of the
>>> TRefArray I would rather guess that this is not
>>> supported?
>> You can perfectly merge two trees containing TRef and TRefArray. The
>> corresponding TProcessID objects from all the files are copied to the
>> result file.
>>>
>>> b) Using a TClonesArray of TRef
>>> Autoloading worked but the TClonesArray was not split.
>>> Is this a restriction when having a TClonesArray inside
>>> a TClonesArray?
>> This a violation of the good old principles of a TClonesArray, ie
>> having variable length collections
>> in a variable length collection.
>>>
>>> c) Using a std::vector of TRef
>>> Autoloading and splitting works, so this is what I am
>>> using for now.
>> Yes, this should be OK, although far much less efficient (memory,
>> time and file space wise)
>> than a TRefArray.
>>> My experience with ROOT and std::vector
>>> is limited however. In particular I'd like to know if
>>> I have to "trim" the std::vector to its minimal size
>>> before storing it? In other words assuming its capacity
>>> is bigger than its size, on read time would I recreate
>>> the std::vector as it was before with the larger
>>> capacity or would ROOT create the std::vector just with
>>> the needed size?
>> std::vector are automatically trimmed to the exact size and rebuilt
>> at the correct length
>> when reading. This is done automatically.
>>
>> Rene Brun
>>>
>>> Thanks,
>>> Constantin
>>>
>>
>
Received on Mon Jul 14 2008 - 13:11:33 CEST