Re: Friend trees of "filtered Trees"

On Sun, Jun 21, 2009 at 4:52 PM, Tim Head <betatim_at_gmail.com> 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?

This I'm not sure of. I'm hoping to get this functionality to work.

>
>
> 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?

We'll be providing two sets of files... one that is always opened, and one that is sometimes opened if the user specifies. All of the details of the event that are within those files will be retrieved.

Cheers,
Sal

>
>
> Tim
>
> >
> > Thanks for the suggestion, though! I appreciate it.
> >
> > Sal
> >
> >>
> >> > Thanks for the advice anyway, though!
> >> >
> >> > Sal
> >> >
> >>
> >>
> >>
> >> --
> >> http://tim.jottit.com/
> >
> >
>
>
>
> --
> http://tim.jottit.com/
>
>
Received on Mon Jun 22 2009 - 14:46:26 CEST