Advanced Analysis Environments - Summary

Suzanne Panacek

Fermi National Laboratory, PO Box 500, Batavia Illinois 60510, USA

**Abstract.** This is a summary of the panel discussion on Advanced
Analysis Environments. René Brun, Tony Johnson, and Lassi Tuura shared
their insights about the trends and challenges in analysis environments.
This paper contains the initial questions, a summary of the speakers\'
presentation, and the questions asked by the audience.

# 

# Introduction {#introduction .INTRODUCTION}

The panel was started with a set of questions to start the discussion.

1.  What is the role of Java in physics analysis?

2.  Will programming languages be relevant?\
    We all thought that the answer to this question was \"yes, the
    programming languages will be relevant.

3.  Can commercial products help meet our needs in this area?

4.  What is the role of modularity and abstract interfaces?\
    Modularity is very important however not well defined.

5.  Do we want an all encompassing framework or a collection of
    configurable tools?

# The Speakers 

The three speakers were: René Brun from CERN. Tony Johnson from SLAC,
and Lassi Tuura from Northeastern University in Boston.

René is a leading architect of ROOT the large HEP Analysis Framework
written in C++. René is also an architect of PAW and many other large
analysis software packages.

Tony Johnson is a leading architect of JAS which is a HEP Analysis
Framework written in Java and geared towards the Java user.

Lassi Tuura is part of the Iguana team that is currently evaluating
analysis tools for the Atlas collaboration.

## René Brun: Future of Analysis Environments: Personal Views 

René observed two trends in data storage for physics analysis. The first
is to store everything in an object data base such as Objectivity. He
noted that many experiments following this path have abandoned it, and
he would not recommend it for a PAW like analysis.

The second trend is to put the write-once data into an object store as
is done by the ROOT streamers. In addition, the run catalogs, and
calibration data is stored in a relational data base. For example ROOT
and Oracle or ROOT and Objectivity.

René summarized the basic requirements for a framework. One being that
the interpreted code can call the compiled code and vice versa. He also
addressed Automatic Code generation, noting that in ROOT 40% of the code
is automatically generated. He listed several options on how to
integrate ROOT and Java.

Languages for data analysis need to be powerful in interpreted and
compiled mode. A scripting language is not the solution. He showed a
graph to illustrate the time to execute a task vs. the number of tasks.
This shows the different situation for using interpreted vs. using
compiled scripts.

He sees Oracle as a likely commercial product to be of use. He does not
see commercial GUI components, or special fitting algorithms as playing
a strong role. He believes in open source and strong discussion groups.

René, described the trend in ROOT to go towards a GRID like architecture
with it\'s parallel processing capability PROOF.

Modularity is not well defined. René asked many interesting questions
concerning modularity. He explained how ROOT addressed modularity, and
showed a historical graph on how the physics analysis tools evolved from
libraries to a framework.

## Tony Johnson: The Role of JAVA 

Tony\'s presentation focused on two startup questions. \'What is the
role of Java in physics analysis?\' and \'What is the role of modularity
and abstract interfaces?\'

He explained that Java is a great language for analysis because it is
clean, modern, Object Oriented, relatively simple, and platform
independent. It also is a mainstream language with a set of standards.
In addition, large research teams are working on development and
performance. Java is simple and lets the physicist spend time solving
physics problems rather than working around language problems.

Java solves three problems we see in data storage, it has the ability to
represent complex data structures, provides persistence, and access to
named data at run time (RTTI). C++ is lacking built-in persistence and
RTTI.

Tony showed a graph illustrating the large advances made in the
performance of Java. It is now at 60% of C++ performance. No performance
improvement for C++ is expected, but Java performance continues to
improve.

Tony showed a list of Java applications. They are: WIRED, JAS, LCD --
reconstruction/analysis, and FreeHEP -- a library of components.

Tony showed how Java has built-in support for the GRID. He also thinks
that computer languages will be relevant.

Tony made several points about modularity. He sees it as fundamental to
Object Oriented design. As an example he showed us how JAS is divided
into modules. He also showed a slide on AIDA, the Abstract interface for
Data Analysis.

Tony saw no paradox in having both a framework and a collection of
tools.

## Lassi Tuura: Analysis Environment Challenges

Lassi started by noting we can do better than just ntuples. For example
ROOT trees, and CMS\'s full object model. He noted that many experiments
are making big jumps by using objects rather than just data. The user
interfaces still need to catch up. He sees a need for several ways a
user will interface with an analysis tool: Batch, interactively, data
store operations, browsing, 2D and 3D visualization, and moving code
across final analysis.

Lassi showed a slide on the challenge of distributing your data store.
He noted the need for uniform integrated interface to the whole task
range. He mentioned MS Outlook as a user interface that could be
mimicked for patching together system analysis tools.

Lassi showed a slide on his recommendation for implementation. Divide
and conquer the problem into categories, share existing modules,
integrate the tools into a user friendly environment, and make
applications by choosing from a module pool.

He showed us a couple of slides on modularity. His opinion was to use
modularity where it matters, but not everything needs to be modular.

In his summary he reminded us that as complexity grows we need to be
able to interact with the data in many new ways. Building all from
scratch is not feasible and we need to help people co-operate and not
disturb each other too much.

Lassi talked about the three-tier architecture and the use of wizards.

He showed us a list of pros and cons on modularity and interfaces. He
stated that modularity is good, but has a cost associated with it. Bad
interfaces can make it very awkward. A good interface clearly defines a
mission.

Lassi stated that in spite of what language is used great concepts will
survive in almost any language. However, the realities are that a PAW
analysis will not run on a C++ object, and finding someone to port the
FORTRAN code is difficult.

Lassi also showed us illustrations of the modularity in CMS and IGUANA.

## Questions From The Audience

### Question: Why can we now bring code to the data when it has failed in the past?

The panelists thought that new technology (Java) is key to making it
happen now. However, it will not happen until there is a user demand for
it. Also, the solution may include a combination of moving data and code
rather than just moving code to data.

### Questions: Memory leaks, Modularity

Is Java really memory leak free? The answer is yes, due to multi-level
garbage collection.

Can software be modular if user classes must inherit from a base class?
Yes, one can provide a standard behavior in other ways.

### Questions: What is the vision for \"your\" tool in 5 years from now?

For ROOT the emphasis is on PROOF and Schema evolution. In JAS the
emphasis is to integrate JAS components with FreeHEP, leveraging reuse
and open source. In CMS/IGUANA we beg, borrow, and steal tools that meet
CMS\'s requirements.

### Questions: What about the Open Source model? 

### 

Many people contribute to ROOT (three contributions last week). RTTI and
a working product are essential to enable and inspire contributors. JAS
is moving to integrate with FreeHEP and both projects are now open
source.

#