Re: Why I am forced to abandon Root

Hello

I don't quite understand Tom's issue. Here's my personal experience. I wrote a Data Model and a small analysis framework for some detector data. Whenever I don't need to use the X-windows capabilities I manage to run not making any calls to any method/library doing so. You just need to implement that 'capability'. In this way I am able to run my software, using ROOT, in batch mode (for example), within computer clusters, or even computers not supporting X-windows (like a few machines in point1, say for example SBCs). I recently wrote an online machine based on ROOT, not using X capabilities, running successfully.

I know a bunch of other small experiments doing something very similar and this problem you describe doesn't seem to me quite real. If I may do the remark. May be you are implementing your software in such a way that this problem shows up and it should really ?

I really think your implementation can be tweaked, may be you need a new design. In the previous message, Philippe offered taking some time to explain to you what's the issue with your software. I would strongly recommend to drop by and give it a new look before fully considering dropping ROOT.

cheers,

John Idarraga

On Thu, 2009-09-03 at 11:59 -0700, Tom Roberts wrote:
> 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:
> A) re-factoring TFile, TDirectory, TNtuple, etc. so they each have
> an "IO-Only" base class that has an empty Draw(); the
> current class derives from this new base class and implements
> Draw(). There might be other functions from TObject that need
> such treatment, and there might be other classes that would
> benefit from such re-factoring (e.g. TH*, ...); the idea is to
> avoid bringing in functionality unrelated to I/O, and most
> especially other libraries -- IMHO success would be if the
> IO-Only build of Root requires no external libraries other
> than system libs.
> A') Instead of that re-factoring, just use a "#ifdef IOOnly"
> to implement a dummy Draw() (etc.) in appropriate classes;
> use the build system to omit all non-I/O stuff.
> B) extending the build system so an "IO-Only" version could be
> built on a system without image libraries or X-Windows.
> C) Documenting and testing the above.
>
> 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 - 23:23:53 CEST