Several points were agreed to at the CLHEP workshop at Fermilab held June 29-30, 2000. Although these were presented at the end of the workshop as a sequence of 29 individual items, here some overlapping items have been combined, and the agreements are grouped into several categories:
The following items of agreement were reached at the CLHEP workshop:
If a specific platform has a deficiency (with respect to the C++ standard) that will not permit some CLHEP package to work, the editors will choose among the following actions:
If the package fundamentally requires the deficient construct, and the deficiency cannot be resolved in one of the above desirable ways, then one of two less pleasant choices will be selected:
This does not imply that ZOOM is dropping its
LinearAlgebra package. However:
Organization of CLHEP and its Packages
CHLEP will maintain a package dependency tree, will keep it accurate,
and will strictly adhere to the implications of this dependency tree.
The RandomObjects class would contain the multivariate
(vector) distributions, and would also replace the fucntionallity
of the random-filled-Matrix that is excised from Matrix.
This represents a cleaning up of the test directory:
CLHEP will have the central test directory it currently has, but in addition, each package will have a test subdirectory.
Test2, and so forth.
(The tests in the central test directory must compile and run on all CLHEP platforms.)
Each package area will have a doc subdirectory, to contain html and/or tex
sources for documentation (also possibly flat-text technical maintenance notes).
The central doc area will have a ps or pdf version of key documentation for each package, which may be supplied or built in an automated manner.
Except for classes which already have adequate methods to capture and restore
the state of a given instance, each class will have the collowing lines of
code in its public area:
friend class xxxOpen;
Bob Jacobsen will write up a paragraph explaining the workings
and benefits of this arrangement.
The following CLHEP packages, which in the past have been deprecated,
will not be present
in the next CLHEP release and will be removed from the
cvs repository (other than in the attic):
(Has been in complete dis-use for some time already.)
See agreement about documentation.
Combinations, which uses Alist, had not been working anyway, and
would have to be seriously revamped if it were retained. If there
is need for a Combinations package, it may be re-constituted in the
The Utilites package will become empty, and assumedly will then be
eliminated (though we did not state that it would
definitely be removed by the next release). Instead of having a catch-all
Utilities packages, CLHEP will be amenable to including several fairly small
Although Tools was not listed in the "packages to be removed"
discussion, an implication of the way we are doing dependencies is that
this package, as a catchall for classes with awkward dependencies,
will go away.
In some cases, instead of adding classes to Tools, small new packages will be introduced.
Issues Concerning Current Packages
Bob Jacobsen will draft a first approximation at explaining the relationships
among the vector-like classes in CLHEP's Geometry and Vector packages.
This understanding needs to converge before we can consider a new
package introducing another form of vector (e.g., template-specialized
vectors of two and three dimensions using floats and doubles).
We will not introduce a new package involving yet another form of vector
at this time
(that is, at least till after the next CLHEP release.
Somebody will be added to the editor list with co-responsibility for support
of the Matrix package.
The GenericFunctions package (Joe Boudreau as editor) is accepted.
First version should start with single-variable
functions, so as to be able to consider user comments
when developing the potentially trickier mulit-variable features.
Evegeni has code in the following areas:
That is, reading lines in the format
and plaing the values in the right variables.
Evegeni has an expression evaluator, which will be accepted as a new package
(with E.T. as editor).
He will incorporate any improvements
found by exploring the similar class used in Babar.
Although CLHEP is looking for an automated documentation tool for
internal use, it is not intended (at this time)
that this become available to the users as a CLHEP package.
The ZOOM exceptions package is accepted into CLHEP as Exceptions
(M. Fischler as editor).
However, other CLHEP packages (coming in from ZOOM or elsewhere) are
not at this time permitted to depend on Exceptions.
ZOOM's ISOcxx Portability package wil be included in CLHEP
(W. Brown as editor).
This implies that the package build will put a file into the
package area itself. This has implications concerning distribution by
read-only CD. CLHEP can accept these implications.
include is present when evaluating for
defects." This, and perhaps other accomodations, should reduce the chances of
clashes among attempts to remedy defects.
Coordination with ZOOM Packages
inherit from the corresponding CLHEP Vectors class
we will augment the CLHEP Vectors class interfaces
to provide the additional ZOOM PhysicsVectors functionallity.
If a specific funtionallity belongs with a concept,
we should put it in the header of the class that embodies
even though that causes the header to be larger.
We should not use inheritance in this situation.
Of course, when doing the merge judgement will be used to excise
any feature whose "bloat" exceeds its likely value.
PlaneVector) will be
added, with names following the pattern used in CLHEP Vector.
Work by ZOOM in the Matrix area, on enhancements and optimizations driven
by the needs of FNAL users, will go into the CLHEP Matrix package.
Particle and Event Classes
The StdHepC++ package,
when moving toward a better-organized structure for
events, will make use of the particle and "intrusive container" classes
in use in HepMC.
There will be a class representing the Particle Data Table entries for a
particle. (The name PDTentry was suggested but not necessarily agreed.)
This class will be developed and maintained by the StdHepC++ editor
(L. Garren). It will include ways to map from various id's (e.g., Lund ID)
into a pointer to an entry in the table.
This does not imply that ZOOM is dropping its LinearAlgebra package. However: