Impressions of ROOT - G. Watts

First my background. I've attempted two projects with ROOT:

• Converting large LeptoQuark mass fit ntuples to ROOT object files. Do mass fits inside root using a shared library that had the mass fitting code (in FORTRAN, fairly CPU intensive).
• Simpler H->b b-bar mass study for Run II

In feb I gave a talk about doing this sort of thing -- includes some sample screen shots. See http://www-d0.fnal.gov/~gwatts/talks and search for the string "Root" and you should find a pointer to a ps file. I think (but I'm not positive) this was the talk I gave while Rene was here at Fermi (I'm pretty sure he was one of the audience).

The first project was a mess because the i/o level was full enough of bugs, and I was trying to use it in new enough ways (I guess) that I had to give up. Summary of what happened:

• The biggest pain was that you couldn't write out an object the interpreter knew about: you have to compile in the object.
• The code to read back in a tree that had been written out as optimized (setting the branch thing to 1 so that buffers were written out instead of whole events -- like column wise ntuples vs rowwise) wasn't the same.
• You had to explicitly tell ROOT what leaves in a split tree you wanted to read back in, instead of it automatically figure it out, as it did in PAW. I consider this a major step backwards. (There were no error messages!).
• When I made a mistake it was often much later in the run experience that ROOT would bomb. As often as not, it was a acvio which was rather hard to track down.

The second project I gave up on trying to write object i/o and instead just used the h2root converter to make an ntuple and then tried to use it as I did paw.

• The resulting ntuple/tree had only limited use in the browser-- the gui wasn't powerful enough to deal with an array, for example.
• If you wanted to do anything besides just plot a single variable you were reduced to writing code -- the ntuple/plot. Paw++, while ugly, was more functional that this guy. I understand with 2.0 out now (I was using 1. something) that a new GUI has been implemented, so this comment may now be out of date.
• The CINT interp was so full of bugs as to make life really tough. Besides not having templates (which isn't such a big deal in ROOT when you are using it for basic ROOT stuff), it seemed to have a lot of problems in general parsing regular syntax. The devil was in the details: complex operations often produced acvios that by moving a line or two of source code would go away.
• Upside: it is now an option to move your "kumac" code to compiled code, something that was never true in PAW. However, still not trivial.
• The graphics stuff was nice -- a plot in ROOT looked a lot better than in PAW, for example.

My summary is good idea, poor programming practices. The middle layer is missing -- the upper (graphics/hist, etc.) looks sharp, the lower (object i/o) looks good but is full of bugs + cint good idea but more work -- the middle (auto plotting/reading in of column wise like objects, etc.) is not there yet.

I note the VR committee's recommendation on how Fermi should participate in the development of whatever product we choose as encouraging.

Cheers, Gordon.