Excerpt from the Blueprint RTAG Report
Interactivity and visualization
Command line environments for interactive and batch (script) access to
the functionality of the system. Good candidate for common
projects. We propose that Python and ROOTCINT both be available, with
the possibility to easily move between them. The architecture is to
make it possible to access application-defined objects from both these
environments. The capabilities provided by the Python and ROOT
environments, which should be largely complementary, will then both be
trivially available in the architecture. How they are used by a given
experiment will be a matter of experiment policy. This implies work
principally on the ROOT side, in particular the capability to work
with 'foreign' classes now being introduced.
GUI toolkits, used to build experiment-specific interfaces but not
themselves experiment specific, are a good common project
candidate. We propose the adoption of Qt as a common GUI library that
fulfils the criteria of Section 6.8.7.
Event, detector displays in 2D and 3D. Here again, general tools
underlying experiment-specific graphics could be a good common project
candidate.
Analysis tools
Histogramming, n-tuples, fitting, statistical analysis, data
presentation tools. Will be addressed in a common project.
Should be well integrated with the experiment framework: access to
experiment data objects; integrated with event display;
allow configurable interactive simulation and reconstruction.
Concurrent availability of 'event' oriented capability and
'distribution' oriented capability.
AIDA
We propose the adoption of AIDA to provide interfaces to data analysis
components. With that, we expect to facilitate the integration of
existing implementations or adaptations and to provide continuity in
their current use in the experiment frameworks. New implementations of
the AIDA interfaces, or some subset of them, are also expected in the
future. In particular, a ROOT implementation would be desirable to
facilitate interoperability of analysis objects (histograms, n-tuples,
etc.) between different frameworks.
LCG should follow and participate in the evolution of these
interfaces. It is very likely that new interfaces to analysis
components not currently covered by AIDA will be added and that the
existing ones will most probably evolve based on user's and
implementer's feedback. This will be an opportunity to evolve them in
a direction that conforms better to the guidelines described in this
document and thus providing a more coherent set of interfaces in the
longer term.
Python
We have proposed Python for adoption as an interactive/scripting
environment and component bus. It should be implemented so as to
permit the swapping in of another scripting tool if desired later. It
should be an optional element of the architecture, and should coexist
with ROOTCINT as an interactive/scripting option available in the
architecture. We recommend that a project working group be set up to
determine how such an environment should be interfaced to the
architecture, evaluating available approaches such as Swig and Boost.
Use of ROOT
The ROOT data analysis framework is widely used in HENP and beyond, and
is being heavily used by the LHC experiments and the LCG. We see the
LCG software as a user of ROOT; a user with a very close relationship
with the ROOT team. While the ROOT team is highly attuned and
responsive to the needs of the LHC experiments, it also supports a
large and diverse non-LHC community (including many major HENP
experiments) with its own requirements, not least the stability of
ROOT itself. It is impractical for LCG software architecture and
development to be tightly coupled to ROOT and vice versa. We expect
the user-provider relationship to work much better. The ROOT team has
an excellent record of responsiveness to users. So while ROOT will be
used at the core of much LCG software for the foreseeable future,
there will always be a 'line' with ROOT proper on one side and LCG
software on the other.
For the purposes of the user-provider relationship described, we must
define what we mean by 'ROOT proper'. We mean the ROOT software that
has been either developed or accepted by the ROOT team for inclusion
in ROOT releases and is supported on the same basis as the rest of
ROOT code. We do not mean any application or tool which makes use of
ROOT. Nor do we mean solely those components of ROOT which exist
today: ROOT itself will grow and change over time. Decisions on making
use of ROOT in the implementation of LCG software components should be
made on a case by case basis, driven by the circumstances.
Despite the user-provider relationship, LCG software may nonetheless
place architectural, organizational or other demands on ROOT. For
example, the library organization and factorization of ROOT will
impact component interdependencies in LCG software employing ROOT
implementations and may drive changes in the organization and/or
factorization. A consideration in assessing the pros and cons of a
ROOT-based implementation of a component or service in a particular
domain will be the imposition of a bulky library.
Analysis RTAG
In this RTAG we have not addressed in any detail the specifics of
physics analysis software (but the blueprint documented here is as
applicable to physics analysis software as it is to other areas). We
recommend the prompt initiation of a new RTAG on physics analysis
software to specifically address requirements and potential common
project activity in this area, with particular attention to the
distributed aspects of physics analysis. There is substantial and
rapidly increasing activity in the design and development of
distributed analysis software and tools - grid
portals, for example. We feel an RTAG is warranted at this time to
understand better the distributed analysis environment we anticipate,
the common requirements in this area, and the common project
activities that will address experiment needs in a coherent way.
Vincenzo Innocente
Last modified: Sun Sep 28 16:13:20 W. Europe Daylight Time 2003