Hi John,
Just my two cents.
As you correctly say, people means different things by "framework".
A framework may be seen as an experiment-specific environment defining
some rules for the communication between modules and a standardisation
process to create and call these modules dynamically.
My definition of a framework is more general. It is my experience
that people do not like experiment-specific frameworks. They
prefer a "framework" that has a chance to show some similarities
with other experiment frameworks, using the same basic ideas.
The reason is very simple: Most physicists nowadays work in several
experiments or move between experiments.
Some important ingredients of a general experiment independent
framework are:
A- a common object dictionary allowing:
-a common I/O sub-system
-object inspection and browsing
-calling compiled class functions from interpreters
B- a common distributed data set/file/run catalog well connected
to the I/O system, including support for queries and supporting
the GRID concept
C- rules and tools to store/search object collections in memory
D common tools to query the data sets and visualize them.
E rules and tools to create tasks/algorithms, organize these tasks
dynamically. tasks support recursivity. They are browsable and
can be executed in a debugger style mode.
F a coherent graphical user interface
The ROOT system is an attempt to assemble classes to implement
such a framework.
"A" is fully supported via the CINT dictionary, the I/O sub-system
and the C++ interpreter. Other interpreters can be put on top,
eg JavaRoot, PythonRoot.
"B" is an area in constant development. Root is interfaced with
GRID systems such as Alien or/and Condor. It would be too long
to summarize this activity in this mail.
"C" is an important point. We have always emphasized the importance
of a "white board" system to minimize the coupling between classes
and facilitate the communication between modules. The Root folders
(class TFolder) is a nice way to organize collections. TFolders
facilitate the understanding of complex data structures because
they can easily be browsed and queried.
"D" The Tree/Chain query mechanism is an important element.
PROOF supports parallelism in queries on distributed data sets.
This area will become increasingly important with the growing
size of experiment data bases.
"E" Like with TFolders, the Root class TTask is a simple and
natural way to organize algorithms in a hierarchy. TTasks can be
browsed and debugged. Algorithms deriving from TTask have a
common behaviour. TTask and TFolder are symmetric classes.
I also want to stress the importance of having a good plug-in
manager.
"F" GUI classes are fundamental for good interactive systems.
The Root GUI classes are an attempt to provide a portable state
of the art UI. We are investing a lot of manpower in this area.
There are certainly more desirable features that could be included.
many experiments have developed their own framework on top of Root.
We have many examples. However, I see a general tendency to converge
towards the criteria defined above with the gradual elimination
of experiment-specific features that are in fact experiment independent.
The Root framework has been built gradually in the fast 8 years
by including interesting features and ideas in experiments using the
system. More ideas are welcome ::)
Rene Brun
John Pretz wrote:
>
> Hello fellow ROOTers,
>
> The experiment I am working on (Icecube) is considering different
> possibilties for an offline simulation/reconstruction/analysis framework.
>
> Of course there is the immediate problem that people mean different things
> by framework. The thing that I think people want is some sort of Analysis
> Module which are largly indpendent and can operates on the event stream.
> The example that crops up alot is Gaudi, where users overload an Algorithm
> class, and the framework is responsible for calling the right methods of
> the Algorithm at the right times.
>
> My first reaction is to just write some experiment-specific extensions to
> ROOT and provide whatever people want. (Indeed I have done so in draft
> form. With the ROOT tools it was easy. Less than 700 lines.) Nevertheless,
> I have been commissioned to find out what already exists, so I pose the
> question to you all:
>
> Do you know of any (free) experiment-independent extensions to ROOT that
> have something like Gaudi's Algorithm? The 'experiment-independent' is
> important because I have no shortage of experiment-dependent examples.
>
> Thank you for any help you can give.
>
> John Pretz
>
> --
This archive was generated by hypermail 2b29 : Thu Jan 01 2004 - 17:50:13 MET