Dear BRAHMS Software People,
There was what I call a BRAHMS software Micro-Workshop which essentially
means that I went to BNL for 2 1/2 days and discussed software with
softies (mainly Flemming and J. H.) at BNL.  The following attachment is
a summary of what we discussed and did.  As indicated somewhat in the
summary, there will be a number of other documents about BRAHMS software
released in the very near future.  

If you have any comments about any of this, please let me know.  If you
see something we missed please let us know.  Let me also take this
opportunity to emphasize that there is a huge amount of work ahead in
regards to software.  It is quickly becoming time for more individuals
to become involved in the software effort.  This is becomming much
easier due to recent work we have done in setting up software, some of
which is enumerated in the attached summary.

The software representatives at each institution can probabally expect a
call in the next few days asking for progress reports on BRAHMS
software.  So please report any software progress in the last month to
your software representative so that it can be forwarded through the
BRAHMS management chain to RHIC management.

Kris


Summary of Software micro-workshop at BNL 23-25 February, 1998.
F. Videbaek, J. H. Lee, K. Hagel

1.  Performed final preparations of Sonata++ to be handed to RCF personnel 
    for use in benchmarking computers being considered for integration into 
    RCF.

2.  Discussed BRAHMS Software in context of ROOT.

3.  Discussed memo which contains recommendation of ROOT as Analysis Framework
    to the software working group.

4.  Installed AFS on the BRAHMS NT machine, pii0.  Installation was 
    straightforward with only minor problems.

5. Discussed BRAHMS software coding conventions.  Formal 
    recommentations will be  printed a forthcoming document on 
    the BRAHMS event model.  Recommendations include:
    a) Include files have #ifndef protection at beginning with convention that
       defined name is UPPERCASE name of module, with _H attached at end.
    b) Include files that include another file will check for definitions.  
       This will speed up compilation since not so many files need to be read
       in as well as provide a double protection against redefining things.
    c) Begin local variables in classes with f followed by something 
       descriptive
    d) Pointers end with _p
    e) Static variables begin with s followed by something descriptive.
    f) As in ROOT, static variables begin with g followed by something 
       descriptive.
    g) Variables in classes are in private.  They are set and accessed by
       inline functions.  The function to set is Set and the
       function to get is Get
    h) BRAHMS classes begin with Br followed by something descriptive

6.  Discussed plans for near future.
    a) Define base classes and put into CVS (next few days)
    b) Make final conversion of prototype tracking software from Sonata++ to
       BRAT (next few weeks)
    c) Generate some instructions and tutorial to get started using the BRAT
       software. (next few weeks)
    d) Generate a consistent scheme of  Makefiles for the BRAT system.

7.  Implemented several new methods in Base Analysis Module class.
    a) A method to allow the class to specify in it's constructor the tables 
       it will need.  This will allow from the outside to list what tables 
       are needed for checking.
    b) A method that is called before the Event method is called and one that
       is called after the Event method is called.  The primary purpose of
       this method is to gather system statistics on the Event method, but
       could be overridden to gather any other statistics one might desire.

8.  Changed slightly the philosophy of the BrEvent class.  There is now a
    BrEventNode class which has a list of the various tables used in the 
    analysis.  This class now inherits from BrDataObject class.  There is a 
    event class BrEvent which inherits from BrEventNode.

9.  Discussed possibilities for directory structure for BRAT.  The current
    thought is to have the BRAT system in one directory tree and all of the
    analysis subsystems in another tree.  For early stage analysis, this is 
    likely to be for the most part the detector subsystems.  In later analysis
    there could also be track and pid analysis subsystems to name a few.
    So a possible directory structure would be the following:

    /bin/

    /lib/

    /test
    /tutorials
    /html

    base/		(for BRAT system)
	/src
	/inc

    tpc/
	/src
	/inc

    dc/
	/src
	/inc

    tof/
	/src
	/inc

    global/
	/src
	/inc

    pid/
	/src
	/inc


    Each of the higher level directories would be an entry in CVS.  A user
    wishing to modify a particular part would checkout the part to modify,
    would link that part with the "official" version to generate the executable
    or shared library.  Once satisfied all is in order, it would be checked
    back in and implemented as the "official" version.

10. Discussed issues of parameters and databases.  Parameters in the current
    version are very simple minded and work for simulations, but need to be 
    much more organized and logically separated for real data where things
    are very likely to be much more complex.  There will also need to be an
    interface between ROOT and Obj-y as some parts of the parameters are likely
    to be stored in the object oriented database.

11. Discussed issues of geometrical transformations.  BRAHMS detectors have 
    several different coordinate systems and a scheme needs to be agreed upon
    to make transformations between the different systems with no confusion.