Summary of CLHEP workshop, May 13-15 96, CERN

LHC++ issues

Although the workshop was on CLHEP and not LHC++, there were a number of issues related to LHC++ that were raised:

Random number classes from GEANT-4

The new random classes were accepted for CLHEP with some small modifications (basically, the changes are to permit the "distribution-objects", e.g. gaussian etc. to be instantiated. This will be done as follows:
  1. Make the distribution-classes inherit from HepRandom, thus making HepRandom the base-class for each distribution;
  2. Add constructors to each distribution class and a pointer to HepRandomEngine as private data-member with a set of shoot methods (not static) for shooting values using that engine.

Feedback from GEANT-4

In addition to the new random number classes, which have been developed and tested within the context of GEANT-4, the following issues were raised:

Physics units and constants

The GEANT-4 strategy for handling physics units and constants will be adopted. Basically, these are defined by the following header files:

Rotations

CLHEP consistently rotates objects and vectors in a reference frame (applying matrices from the left).

For all cases where there is a natural physical meaning for a transformation of coordinates, we can provide methods following a naming convention.

Adopting the naming convention of a prefix like FRAME to the CLHEP methods is sufficient to resolve the problems.

Users are then free to rotate objects, the reference system or both, but a consistent naming scheme will make clear what is happening.

e.g.

Support for float in CLHEP classes

It was agreed that all code in CLHEP should be double-precision (i.e. 64-bit, defined as d_Double) and that support for float should be dropped. (Done for float, for HEP/ODMG types, see below).

3-vector issues

It was agreed that public set methods for the individual components should be added.

CLHEP and the STL

By adopting the STL, the following CLHEP classes become redundant: HepAList is unfortunately not made redundant by the STL. However, by adopting RogueWave's Tools.h++ (agreed), HepAlist is also redundant.

HistOOgrams

The prototype histograms from the LHC++/hist++ working group were accepted for CLHEP with the following additions:

Issues related to an ODBMS

The HepODBMS.h package is a set of header files which The components of HepODBMS.h are as follows: It was agreed that the ODMG definitions for fixed-length types would be adopted. These are defined as follows:

Type Name Range Description
d_Short 16 bit signed integer
d_Long 32 bit signed integer
d_UShort 16 bit unsigned integer
d_ULong 32 bit unsigned integer
d_Float 32 bit IEEE Std 754-1985 single-precision floating point
d_Double 64 bit IEEE Std 754-1985 double-precision floating point
d_Char 8 bit ASCII
d_Octet 8 bit no interpretation
d_Boolean 0 or 1 defines false(0) or true(1)

The full set of ODMG types will be adopted on the timescale of the summer, and HEP types will exist for a subset of them (i.e. Hep_Double but no Hep_Float).

The other header files would also be adopted, with the understanding that they are by no means finalised and subject to change.

CLHEP: next steps

Following Bob Jacobsen's presentation on some proposals for the next steps for CLHEP, the following agreement was reached: In this respect, one might question whether heap management and/or garbage collection would not be better solved by adopting an existing "standard" solution, e.g. Heap.h++ for heap management. This would also be consistant with the LHC++ policy of concentrating on HEP-specific issues.

CLHEP repository

The CLHEP repository is stored on a CERN machine in AFS. The repository itself is managed by CVS in 
/afs/cern.ch/project/lhc++

The repository has been restructured so that each component is stored in a seperate subdirectory.

The include files for a given component will be stored with the code, e.g. 

#include "CLHEP/Component/x.h"
The filenames have been changed to be consistant with the class names (excluding the Hep prefix, which will be dropped when namespaces become available). The directory structure (below CLHEP) is as follows: 
Alist           PersistentIO    Vector          configure-orig
Combination     Random          aclocal.m4      configure.in
Hist            String          classdoc        configure.in~
Matrix          Utilities       configure       test

CLHEP editors

(*) editor in chief

Contributing to CLHEP

It was agreed that there should be a few loose requirements that code should meet:

Generally speaking, new code would not become part of the default CLHEP installation until it had been reviewed, e.g. at a CLHEP workshop. To submit something to CLHEP, one is invited to send mail to the editor in chief, Nobu Katayama

Timescale for CLHEP evolution

It was agreed that the next version of CLHEP would be V0.20. The goal is to reach V1.0 by spring 1997 (before CHEP'97?). Obsolescent features will be dropped in V1.0. For comparison, we can expect to see other elements of LHC++ being built up as follows:

CLHEP requirements on compilers

The C++ compiler must at least support the following:

Future workshops

It was agreed that this workshop was successful, as can be seen from this summary, and that future workshops should be held roughly two times a year. The proposed dates for the next workshops are: In addition, a workshop concentrating on "Minuit++" is planned for the latter part of the year, where appropriate experts would be invited.

Attendees