From gwatts@phys.washington.edu Fri Apr 30 16:45:41 2004
Date: Thu, 22 Apr 2004 15:06:47 -0700
From: Gordon Watts <gwatts@phys.washington.edu>
To: Reiner Hauser <rhauser@fnal.gov>
Cc: d0dfwg@fnal.gov
Subject: RE: Comments on analysis with tmb_trees

Hi,
  The BID algorithms give their answers in d0root. I think the easiest
way to think of d0root is as a collection of C++ objects that derive
from TLorentzVector. So they look a lot like a TMBTree physics object,
but they are different (!).
  One could write the results back into the TMBTree (with a new branch
or a friend branch). As long as you handle memory management correctly,
this technique works fairly simply.
  The bug in root... that is the one bug I actually have fixed in root.
:-) Turns out when running on windows you can step into the root code
directly... I'm pretty proud of finding that... Ahh, the small things in
life. And, btw, never again!

	Cheers,
		Gordon.

-----Original Message-----
From: Reiner Hauser [mailto:rhauser@fnal.gov] 
Sent: Thursday, April 22, 2004 3:57 AM
To: Gordon Watts
Cc: d0dfwg@fnal.gov
Subject: RE: Comments on analysis with tmb_trees

Hi Gordon,

On Thu, 22 Apr 2004, Gordon Watts wrote:

> - the 10-15 seconds to compile and link as compared to the 5 mins on a
> good machine. You are _not_ talking about the same program. The 10-15
> seconds is building your analysis framework with a custom makefile.
The
> 5 mins is building a framework executable. Is this correct?

That's correct. There is the dependency hell of all those *_evt packages
that you need when using the framework. I guess that could be
solved with enough effort, so that you don't have to link 200 libraries.
That the build system is overall slower than a Makefile is something
one could live with.

> - The ADM remark ("slow") has come from several people that have
> complained they are slow. I'm actually bench marking them now and
> comparing them to other root-tuples. BTW, if you are doing a multi-jet
> analysis, which requires millions of events, TMBTrees probably are to
> slow used the way you use them. An ultra small (and efficient) root
> tuple may have to be designed for that.

Ok, that I believe. As it was presented it could have been interpreted
as being slow compared to unpacking and reading chunks.

> - Vertexing and btagging you could have rerun -- it is in d0root, and
a
> tmb tree -> d0root converter exists.

Then the output is in d0root format (I don't even know what that is) ?
Or
can I go back to tmb_trees ? We would have probably done part of the
analysis in another framework if necessary, but to avoid that in the
future is the task you guys...

> - Your TMBEvent sounds interesting. Several of us have written similar
> things. BTW, it is possible to decide what branches to read in on the
> fly if you want to be sophisticated about it.
yes, I know, but I think we only left out bc jets in the end. With some
version of root in the past there was actually a bug where reading
everything was faster than reading only some branches ;)

> - In the single top analysis we also found a name-value pair thing
> lacking. We ended up using TEnv, a root class, and that actually
worked
> out quite well.
>
> - As Serban mentioned, examples and documentation are never good
enough,
> and perhaps we should think about providing some sort of framework
once
> we get past the data format issue.

  Reiner