To: BRAHMS software group
From: Kris Hagel, and F.Videbaek
Subject: Recommendation for BRAHMS Analysis framework

One of the open issues left at the collaboration meeting at BNL in
August was the choice of Analysis Framework. Since then much work has
gone into investigating the options. This issue should be settled soon
such that a detailed plan for software can be presented and discussed at
the collaboration meeting in Krakow in April. We do solicit your
comments and opinions to the recommendations presented below.

Base on the investigations, outlined below, we recommend that BRAHMS
adapt a software strategy that is based on using the ROOT system.

We believe that this will give us an immediate advantage in the
development of object oriented software over an adaptation of STAF. In
the long term it may be that STAF will give more advantages e.g. in
terms of support at RCF and development from the two large RHIC
experiments. It is also important to keep in mind other project e.g.
those of LHC++, the use of Objectivity Database at RCF for data storage
during the development of the BRAHMS code. One way of maximizing the
opportunities is to develop base classes and code that may not utilize
all features of ROOT but can, in time, be replaced by other generic
classes (lists, iterators, RTI features, templates).

In this document we discuss results of the investigation with STAF and
ROOT, both positive and negative. The codes for the examples developed
are not included but can be found at the RCF cluster. Finally is given a
work plan for software development.

We do solicit your comments and opinions to the recommendations
presented here. As the next step is to continue and start new
developments based on this scheme we will like to have an
acknowledgement, concerns, and other questions needed to be discussed by
end of next week (March 6).20

Prototype analysis modules implemented using STAF.

A small analysis chain was written as an example and actual testing of
its concepts. The module consisted of the following sequence

1. Read GBRAHMS c-stream file and convert to tables of hits and tracks. The hits and tracks were defined with idl files gtrack.idl and ghits.idl. Input parameters to the reading module were done though additional tables i.e. a simple struct since there is no need for more than one entry.
2. A Time of flight digitization module reading the ghits information and creating raw Tof data.
3. A time of flight module reading the raw tof data and calibrating these into normalized data.

The Simulated data were written to a data set SIM/=85 the raw data to
another data set RAW. The data sets can have many different tables
associated with them and can be written to external flat files in xdf
format. It was simple to direct output to specific files and read it
back in another Staf module.

The STAF code does at present only know about table which are really
only C or Fortran structures and not C++ class objects. To bypass some
of these aspects the STIC compiler was modified to generate a C++
wrapper class such that the user module would deal with C++ objects and
not deal directly with the Staf tables. This would allow for a nicer
upgrade when Staf becomes capable of maintaining objects and passing
these to and from user analysis modules.

Commands to STAF are presently implemented with Kuip commands but can
relatively simply be upgraded to tcl commands.

STAR and PHENIX are committed to STAF. It is a bit unclear who will be
the main driving people behind further work. The two big experiments
clear have a long-term commitment, and in the long run STAF could be a
worthwhile package to use.

At present it though seem to have disadvantages in the following area
- Staf presently only knows about simple tables.
- The number of supported platforms is limited, and we will
have to add lots of work ourselves for non-supported RCF
platforms.
- As documented before the xdf data format though very
general and transportable has a large overhead thus creating
large files.
- The underlying code has lots of legacy c-code, and relies
presently on CERNLIB (PAW, and KUIP).
- It is not possible to create multiple instances of the
same user modules if these have private/local data.
 
The code developed for the STAF examples have been stored on the RCF
machines under the brahmlib account. At this point there is not a
working executable. 
The examples for staf was developed for the September 97A release made
public for PHENIX (Thanks to Dave Morrison). It can be found in
/brahms/u/brahmlib/staf/
/brahms/u/videbaek/staf/ana


Prototype implementation using Root.

The prototype tracking program Sonata++ was re-written into ROOT object
model based on the Phobos implementation by KH. Partially work was done
by FV (modules, data objects) and checkout of simple user modules which
can digitize GBRAHMS TPC and TOF data.

The base classes were used to define a TPC and TOF digitization module.
A simple analysis chain with two instances of the TPC module and one of
the TOF module was created. Data was read from the GBRAHMS c-stream
files and two root files were generated. The tasks investigated were
similar to the ones set forth for the STAF investigations.

The availability of the CINT command line interpreter makes development
of code, which uses developed classes as well as the basic ROOT classes
very easy. It should be noted that you can not develop classes derived
from ROOT or other loaded classes with CINT. The build in graphics tools
for class, element inspection, and for analysis are very good.

Some concerns

  ROOT uses pointers almost everywhere. This is potentially a problem
with many users. To the degree that a framework can be made using
call by value or by reference the chance for memory leaks are highly
reduced.
  The CINT interpreter and rootcint can be quirky.


 
 

Conclusion

The analysis frame as well as the data model could well be based on
STAF. It would tie in to the overall strategy of STAR and PHENIX and
might have very useful fallout from software development to manipulate,
access data in the RCF. It is though clear at this time that the object
oriented approach of ROOT offers more advantages. This in some of the
area's listed below
  Basing the event model on tables only will limit the use of object
oriented methods, and will hinder developments in this area. Also the
present STAF implementation with static PAMs (in the sense of only
one instance) is a severe restriction on our code. The module
(object) can be used for multiple instances e.g. time-of-flight code
for different detectors.
  Availability on many more platforms.
  Though documentation is not complete it is many times better that
that of STAF. It also presently has nice public support though the
ROOT list server.
  Object oriented approach.
  Readily available graphics interfaces and analysis tools.
  No use of commercial software for analysis and display purposes. It
is planned to use Objectivity for the Online database, and likely
also for calibration databases assuming RCF solves the licensing
issues for Pentiums running Linux and/or Solaris.
  Giving up the use of STAF means less overlap on software issues with
the two large experiments, but Brahms could possibly benefit from
collaboration with PHOBOS.

Some concerns were also listed.
  Long terms support of ROOT may be questionable. It is not a CERN
supported product, but a NA49 product. It is also at least to us not
clear what support there would be for CINT (via HP). This is crucial.
Without this, much of the easy interactive use of ROOT will
disappear. It would be fairly simple to replace the base classes used
for modules, parameters and event structures with pure C++ classes.
This would be used in purely compiled programs, but would loose the
interactive flexibility's from CINT.
  The ROOT classes may not be the ideal ones. Templates are not
supported. It therefor relies heavily on casting operators, or many
data types are derived from the same base classes making coding
mistakes more likely. The compiler will not catch mistakes
  Though very compact it is not clear one will want the ROOT data file
format as the persistent storage for raw and intermediate event data.
This has to do with long term storage and access.


Work plan

The overall Classes must be defined. This relates to the areas of
  Data and event objects.
  External( Persistent) data storage
  Modules (Control classes)
  Parameter, geometry, database access classes
  Magnet classes, tracking, matching and swimming.
  Display of detectors, hits, tracks for event display, debugging etc.
This will take some time. Delegation of tasks should be determined.

The organization of the source code, libraries and make-files has to be
setup.