Classes for use in Offline Code
Recent Changes
- 23 Mar, 2000 -- ComTimeStamp added (Bob)
- 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 BdbTime and BdbDuration
classes implement those standards.
These replace the obsolete BbrTime and BbrDuration classes
which should no longer be used.
The ComTimeStamp function in the CommonUtils package
provides a standard-format timestamp for use in logfiles
and messages. Please use this when you need
a timestamp so that we only need to have parsing routine in
log scanners, etc.
Histograms and nTuples
The HepTuple package contains classes for representing histograms (1D or 2D) and ntuples. Support for output files, etc, is built into the BaBar application framework.
See also the HistModule example in the FrameExample package.
Note that the similar classes in the CLHEP package should not currently be used.
The CLHEP maintainers have deprecated this package.
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.
Complex detector geometry
The
DetectorModel package
provides geometry classes for reconstruction and graphics applications.
The simulation group is using the GEANT4 package for similar uses. They have
also developed various utilities for creating DetectorModel and GEANT4
objects from common information. See the simulation pages for
more information.
MatEnv - Material information
The simulation group has created "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.
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.
Due to storage-ownership issues, they should not be used for the
return values of functions. Use a class instead.
For more complex operations, or when you want to pass a string as an object,
use the Tools.h++ RWCString classes.
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.
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.
Parameters for controlling code - 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.
Build support - PackageList and SoftRelTools
PackageList and SoftRelTools are the standard for creating makefiles.
PackageList controls linking via small files in your package. Please use them.
See
the SoftRelTools HOWTO,
PackageList/README, the
PackageList user guide, and the
header of PackageList/link_all_reco.mk for more information.
Output message logging - 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 production batch running.
Statistics
The Consistency classes encapsulate statistical information.
The existing classes provide an easy way to return chisq and nDOF
from a test, fitter, etc, with specific implementations
for Poisson statistics, binomial statistics,
etc.
Almost existing classes
In this category are classes which need a little work to be completely useful.
Planned classes
In this category are classes we want, but nobody is yet implementing.
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
|
