We believe we now have the manpower and tools at hand to address our lack of an Event-level analysis gui with coupling to an event display. By Event-level is meant a tool to facilitate processing of individual events.
Analysis spans the ability to browse existing histograms, manipulate ntuples and analyze the full structured Root trees directly.
The desired high level features needed include flexibility and speed. Most likely the tools should be able to operate from histogram, ntuple and full Root tree files. They should be able to select events and pass them to an event display for viewing.
Known options are to
couple the gui to Gaudi, via a userAlg-like mechanism whereby the Root files are ingested by the persistency service and analysis is performed in compiled code
create a gui on top of Root which will facilitate the opening and browsing of Root files, as well as coupling in detail to a customizable helper Root macro like RootTreeAnalysis. This macro could be compiled with ACLiC. This option uses Root entirely - for I/O and analysis of the Root files. A mechanism would have to be created to transmit HepRep data to an external event display like FRED or WIRED.
use an alternative analysis package, like JAS, which can read Root files and copy them to Java classes. WIRED is a plugin to JAS, but a filler mechanism would still have to be created for HepRep. Users would code their analyses in Java. One would have to evaluate whether JAS has the desired features for "line mode" ntuple analysis
use PyRoot to access the Root files from python. Analysis scripts would be in python. It is not clear how one would do histogramming and the like, but this would be a similar situation for the ScienceTools scripting environment.
Minimum functionality includes
dialogues for opening files (and chains) and loading analysis scripts
aids for analyzing specific events; looping over all events; rewind
ability to edit and reload analysis without exiting the gui
easy histogram manipulation and fitting from histogram files
the ability to combine ntuple columns and apply boolean cuts to ntuple files
supply a framework for analysis of our standard Root trees
be able to show selected events from the Root trees in an event display
It would be useful if this gui could provide experience for development of the Science Tools gui. In this case, it would be worth considering whether the solution adopted for Events would or could be aligned with that for the ScienceTools.
As things stand, the gui would have to be able to run C++ executables, perhaps as well as loading and running shared libraries.
In this option, there is limited direct access to histogramming options as currently in use. We would need to provide more examples of Root (presumably) analysis tools in the Gaudi environment. It would result in a CLG-environment. Any change in the analysis code would require a new compile, link and go iteration. It would allow one the method of generating an ntuple for later analysis with a different tool.
Advantages
Access to the full TDS
Disadvantages
limited interactivity
Historically there has been a split between the widget set for windows and linux. The claim is there are now two choices to get around this. The win32 equivalent is said to be ready; and Qt is an option. It may be that the supported version of Qt on windows costs money (Riccardo was told $1500); only the developer licences are needed, not user.
In this option, an internally consistent set of tools is used which are native to the Root files. For good or bad, Root macros are used on Root classes. It is known that the Root gui tools are adequate to build what we need, while the Qt widget set is better yet.
We were advised by the Root team to investigate the GO4 project use of Qt (CHEP03 update), and that the BNL Qt-Root (http://root.bnl.gov) is not ready to be depended on yet. These are the HADES folks, upon which we based our original Root prototype gui.
A bit of history here: Dan Flath wrote a linux gui based on the then HADES gui which added a tab to handle our (then) RootTreeAnalysis macro. It was pretty successful, and I showed (see slides 9-10 for screen shots) it at the 2000 Root Users Meeting at CERN. But the windows side was still too rudimentary, so we shelved it. In the past year, Dan has switched to using Java and JNI to create a similar looking interface, though only to Root histograms so far. The project is now on a far back burner.
Advantages
native access to Root files
lots of examples of building gui's available from Root web
Disadvantages
CINT is not the most wonderful environment
This is a self-contained analysis studio, with integrated histogram and event display; event loop framework and Java editor. The gui is already built. It can read Root files, copying them into Java classes. Analysis code is in Java. It is unknown to me what special ntuple analysis features there are, if any. JAS support by SLAC appears to be secured now, with it being adopted by G4 (at least), and we are most likely adopting it (as has I&T) for web display of System Tests.
Ref: http://jas.freehep.org
Advantages
environment is already built, including the connection to WIRED
Disadvantages
must copy data from Root to Java classes
a new language (Java) for GLAST analysis
I believe the credible options are Root and JAS.
On one Root hand, we have an example for gui building (GO4) and native access to Root files. On the other, CINT is not ANSI C++, and C++ is not a trivial language to work in for the trees (not much of an issue for ntuple analysis). Using Root would tend to enhance general understanding of the Root I/O.
For JAS, there is already a very nice interface. Access to Root is not native, and one pays a penalty for copying the data. And then one deals in a different structure (assuming all Root classes are readily translatable into Java versions) and language.
My preference at the moment would be for the Root option.
R.Dubois Last Modified: 2010-06-01 15:45:30 -0700