Classes for use in Offline Code
Recent Changes
- 28 Sep, 1998 -- MatEnv added (Bob)
- 21 Jun, 1998 -- ErrLogger (Bob)
- 13 Apr, 1998 -- PackageList (Bob)
- 18 Jan, 1998 -- Added items about Parameters (Bob)
- 28 Oct, 1997 -- Pointer to CLHEP docs at CERN (Bob)
- 19 Feb, 1997 -- Added warning about HepTuple vs CLHEP (Bob)
- 29 Jan, 1997 -- Added Tools.h++ text (Bob)
Using a standard class has several advantages:
- Your code can interchange data with that of others, which also makes it much easier for people to use your code directly.
- Because these classes have been around for a while, they are usually pretty well debugged.
If you find that an existing class doesn't meet your needs, consider improving or extending a standard class instead of writing a new one. This can be done either by adding methods to the existing class, or by subclassing to a new one. Either way, you
should get the function you need with less effort, and others will be able to profit from your work.
For more information on any of these, follow the links, consult the package README file, or do a Hypernews search.
Existing Classes
In this category are classes which are in CVS and/or recent SRT releases. They should be used when possible.
Collections
For many uses, straightforward C++ arrays are fine. You should consider them when you know the number of elements at compile time. Its usually not a good idea to pass these through function arguments, etc, as then you have to worry
about also passing the length. In cases like that, you should use a real collection object.
We have standardized on container and collection classes from the Rogue Wave Tools.h++ library. A recommendation document exists (also available as a
text file). More details are available in the common meeting discussions, particularly item
116 and its followups.
As yet, we are not using STL collections. Please do not use these, regardless of how glamourous they seem.
The valarray class(es) from the C++ standard libraries will be very useful for handling arrays of numbers in a parallel fashion. These classes have certain minor restrictions on the use of pointers and references which allows the
compiler to heavily optimize the code that refers to them. If you're interested in this, contact Bob; we need a recommendation on how to handle these on all our platforms.
The HepAList container classes are now formally obsolete, and should not be used in new code. We are trying to replace them with the newer forms above. In the meantime, some documentation is available from CERN in the CLHEP reference guide and the CLHEP user guide.
Time, Date, Duration
We have adopted standard formats for printing and reading calendar dates, wall clock time, and durations of various sizes. The BbrTime and BbrDuration
classes implement those standards. These are being replaced by the similar BdbTime and BdbDuration classes for use with the event store and conditions databases.
Histograms and nTuples
The HepTuple package contains classes for representing histograms (1D or 2D) and ntuples. Support for output files, etc, is being built into the reconstruction framework. See also the HistModule example in the FrameExample package.
Note that the similar classes in the CLHEP package should not currently be used. There will later be a migration to these, but for now please #include the header files from the HepTuple package.
Simple geometry
Note: "geometry" means many things to many people. In this case, it means the ability to represent various small primitives (points, lines, vectors, etc.). These can then be used to represent more complex items like the "detector geometry".
Classes that exist right now
- CLHEP's HepPoint
- Represents a space point.
- CLHEP's HepThreeVector
- A three-vector used to represent a direction, analogous to the vectors that you learned about in introductory mechanics.
Unfortunately, representing "points", "directions" and "displacements" all as 3-vectors forces the programmer to keep track of which is which so that the correct transformation rules can be applied. (Point, direction and displacement all can be
represented as three components, but they behave differently under translations and scalings of the coordinate system). To reduce the confusion and chance for error, the above classes have been written to work together with transforms to do the right
thing.
- CLHEP's HepLorentzVector
- A four-vector for use with special relativity.
CLHEP also contains classes to represent rotations, translations, etc.
Future direction
THe CLHEP maintainers, in company with the developers of GEANT4, CMS and RD45, have agreed to standardize the CLHEP 3 and 4 vectors. This may result in small changes to the interface, but the classes should survive. In the meantime, some documentation is
available from CERN in the CLHEP reference guide and the CLHEP user guide.
Character information
The usual C++ character support is fine for single characters. As constants, for example messages for output, C++ strings are fine. They are problematic in more complicated cases where you want to manipulate and/or pass variable length strings. Although
in the past the HepString class has been used for minimal operations (concatenate, take substrings), please don't use this class for new code. New classes should be designed to use the Tools.h++ RWCString classes. We will eventually move to the C++
standard "string" class, but we currently don't have an acceptable implementation of it.
Random Numbers
The reconstruction code (as opposed to simulation or analysis code) does not need, and will not use, any 'random numbers' in the usual sense. There will be no 'random choices' in the reconstruction of BaBar data. ( More information on this statement and the requirements that drive it is available in the discussion system). Note that this does not mean that reconstruction will not need long
sequences of 'uncorrelated numbers', such as you get by running a generator off of a known, repeated seed.
To ensure compatibility with the simulation, please use the random number classes from the CLHEP package. Consult the simulation pages for recommendations on how to initialize them, etc.
Particle Data Table
The PDT and package by Luca Lista et al is now the standard particle data table for offline code. Please do not write explicit translations into your code, but use the PDT instead.
AbsParm classes
The AbsParm group of classes from the Framework package provide mechanisms for attaching parameters to offline modules, which can then be changed and examined from the Framework command line. They provide bool, int, double and filename inputs, as well as
limited support for creating menus.
PackageList and SoftRelTools
PackageList and SoftRelTools are the standard for creating makefiles. PackageList controls linking via small files in your package. Please use them.
ErrLogger
The ErrLogger package provides a simple interface for logging messages emitted by offline programs. Its important that it be used so that your messages can be captured and looked at during batch running.
Almost existing classes
In this category are classes which need a little work to be completely useful.
MatEnv The simulation group is working on "MatEnv", a package to maintain information on material types for simulation and reconstruction. Please contact them if you need to find out the density, radiation length, etc of a material.
Planned classes In this category are classes we want, but nobody is yet implementing.
Statistics
A Consistency class for encapsulating statistical information seems useful. A first version would provide an easy way to return chisq and nDOF from a test, fitter, etc, with later versions adding poisson statistics, binomial statistics,
etc. A sketch of such a class is in the BaBar package.
Return to BABAR reconstruction software page, BABAR Computing Home Page, or BABAR
Home Page.
Maintained by Bob Jacobsen,
Bob_Jacobsen@lbl.gov 510-486-7355
|
