Re: Friend trees of "filtered Trees"

> Can you play some tricks to make tree.Draw() work
> again for the TreeIndex approach? Maybe via the TEntryList/EventLists?

No need for trick :) Tree::Draw natively understand and use any index build on the friend
tree to connect the event/entry in the main tree with the event in the friend tree.
(And if you are plotting data from both trees, only events that are in both will be used).

Cheers,
Philippe.

Tim Head wrote:
> Hello
>
> 2009/6/21 Salvatore Rappoccio <rappocc_at_fnal.gov>:
>
>> On Sun, Jun 21, 2009 at 1:18 PM, Tim Head <betatim_at_gmail.com> wrote:
>>
>>> Hello all (for real this time),
>>>
>>> 2009/6/19 Salvatore Rappoccio <rappocc_at_fnal.gov>:
>>>
>>>> On Fri, Jun 19, 2009 at 5:30 PM, Tim Head <betatim_at_gmail.com> wrote:
>>>>
>>>> Hi, Tim,
>>>>
>>>> Thanks for the suggestion, but unfortunately in our case this solution
>>>> doesn't scale sufficiently to help us.
>>>>
>>>>
>>> What kind of benchmarks did you do to find this out? My trees
>>> currently seem to be acceptable (hundreds of MB) but I would be
>>> interested to know when to expect this falling over.
>>>
>>> Tim
>>>
>> The issue for us would be that we will have the following situation:
>>
>> - A huge dataset (many hundreds of GB, in principle) that is skimmed down to
>> very few events, and most branches dropped. This is expected to be on the
>> tens of GB level or less.
>> - The user does work with the smaller dataset locally.
>> - If they don't understand something, they access the "full" dataset if
>> necessary via the grid (or on some mass storage, in the case of FNAL it
>> would be DCACHE).
>> - At CMS there are two ways to do an analysis, with our "full framework"
>> (which has read/write capability, access to DB and geometry, etc) and our
>> "light framework" which is basically object libraries on top of root, plus
>> some added capability. Typically the user will do selection with the "full
>> framework" via the grid, and then do their analysis with the "light
>> framework". Oftentimes the user doesn't have the exact configuration to do
>> the skim in the "light framework", and simply wants to access the
>> information via "run,event" mapping.
>>
>> The example from Philippe will be much more extensible in our use case
>> (creating a "run,event" mapping between the trees).
>>
>
> Ok, so I misunderstood what you were after :-) I was thinking you
> wanted to combine the two trees in order to do things like tree.Draw()
> and such, which I find very useful in cases where there is something I
> don't understand because it is so quick to get a rough idea of what
> things look like. Can you play some tricks to make tree.Draw() work
> again for the TreeIndex approach? Maybe via the TEntryList/EventLists?
>
> Obviously your trees are _very_ large, so making copies will be a not
> so smart idea.
>
> So you are going to provide a function getFullEvent(run, eventnumber)
> which grabs me the full details of an event?
>
> Tim
>
>
>> Thanks for the suggestion, though! I appreciate it.
>>
>> Sal
>>
>>
>>>> Thanks for the advice anyway, though!
>>>>
>>>> Sal
>>>>
>>>>
>>>
>>> --
>>> http://tim.jottit.com/
>>>
>>
>
>
>
>
Received on Tue Jun 23 2009 - 05:08:40 CEST