I have been using Root for 3-4 years, and have been reasonably happy
with it. But I have long been frustrated with build issues, that have
now culminated in my complete inability to build Root on a supercomputer
at NERSC. The underlying problem is:
LACK OF MODULARITY Note that the only Root classes that my code uses are: TNtuple, TFile, TDirectory, and the only Root functionality is to read and write TNtuple-s to and from TFile-s.
Performing such basic Root I/O brings in an INCREDIBLE amount of Root code. I understand that the desire to read arbitrary objects from Root files beings in Cint and related dictionary code; I could live with that. But this also brings in the image libraries and X-Windows -- I CANNOT live with that, for the simple reason that the supercomputer does not support shared objects or X-windows on its compute nodes.
At base, this is caused by the fact that TObject::Draw() exists, and is implemented for TFile, TDirectory, and TNtuple. I understand the reasons for that, but this design is preventing me from compiling Root because it inherently brings in the image and X-Windows code.
So I am forced to use a file format other than Root. I could use ASCII files, but for large problems that is inefficient. I am considering both SDDS and HDF5. Suggestions?
Another possibility would be to make Root usable for such applications. I believe this could be done with only modest effort:
In closing, I'll point out that in casual conversations at Fermilab I have been told by several people "don't use Root" (in a computationally intensive context), for just this reason. Perhaps it is in the interest of the general Root community to solve this problem. A complete re-organization is clearly neither possible nor desirable, but the ability to build and link root for JUST I/O would be most welcome. The existence of the non-Root "RIO" package indicates I am not alone in this.
Tom Roberts Received on Thu Sep 03 2009 - 20:59:54 CEST
This archive was generated by hypermail 2.2.0 : Fri Sep 04 2009 - 05:50:08 CEST