The source code for the jet algorithms is in the src/ directory. To make
the JetAlgs library, just type 'make' in that directory. If you want to
learn how to use the code under C++ and how to build an executable, you
should look, respectively, at the main.cc and run.csh files in the
example.c++/ directory. For use under Fortran there is code in the
example.f77/ directory and, in case you want to link the JetAlgs library
with a Monte Carlo generator, in the example.herwig6504/ directory.

In all these examples the jet algorithms are fed with 4-vectors. For
MidPoint this is perfectly okay, even though we use 'PhysicsTowers' in the
CDF software framework. But since these PhysicsTowers are computed by
adding up the two 4-vectors which have been determined from the energy
depositions and the locations of the EM and the HAD sections of the tower
(assuming that each part is massless), and since the 4-vector of a cluster
of PhysicsTowers is the sum of the 4-vectors of the PhysicsTowers (both
inside the algorithm and in the calculation of the properties of the final
jets), there would be no point to provide the possibility to feed MidPoint
with any other kind of input quantities; the results would be the same.

In the case of the JetClu algorithm, however, the jet configurations can,
in principle, be different if we use 4-vectors computed from PhysicsTowers
or the CDF (AC++) PhysicsTowers themselves. This is because here we use
the Snowmass scheme both to add up the EM and HAD sections and to
calculate the centroid of a cluster of PhysicsTowers, and the 4-vector
scheme only for the calculation of the final jet properties. If a tower
acquires a mass (because z_vtx != 0 or because the phi segmentation of the
EM and the HAD sections are different, which is true in the transition
region between the central, wall and plug calorimeter), the results of the
Snowmass and the 4-vector schemes are slightly different, and so the final
jet configurations can depend on what type of input quantites is used
(4-vectors, which are then transformed into PhysicsTowers, or the real
PhysicsTowers). Also, the tower indices are important in JetClu, and if
they are available, they should be given to the JetClu algorithm;
otherwise they are calculated from the 4-vector eta and phi values
(assuming z_vtx = 0) and may be different by 1 unit due to rounding errors
if z_vtx = 0, or even more if z_vtx != 0.

In the example.CDF.c++/ directory there is a piece of code which shows how
to feed the JetClu algorithm with alternative input quantities (full
PhysicsTowers: Et, eta, phi, iEta, iPhi, px, py, pz, E; PhysicsTowers
without 4-vector: Et, eta, phi, iEta, iPhi; PhysicsTowers without 4-vector
and without tower indices: Et, eta, phi; 4-vectors: px, py, pz, E). I
don't provide a corresponding example for Fortran because if the user has
the AC++ PhysicsTower information, then he must have been able to use the
CDF software, which is written in C++; but it would certainly be possible
to extend the Fortran example accordingly.

One important thing: Since the JetClu algorithm starts off by making
preclusters from seed towers, since the tower indices of these seed towers
must either be given to the algorithm or calculated from 4-vectors, and
since the tower indices are defined by the CDF calorimeter geometry, there
is a limit in abs(eta) beyond which no jets can be reconstructed. Seed
towers only go out to about |eta| = 3.6, so jets can't be much more
forward. (This is also true if you use the JetClu algorithm for HEPG
particles (to reconstruct hadron or parton level jets) within the CDF
software framework.)

I tested the code and found the resulting jet configurations to be
identical with those obtained under AC++ (if, in the case of JetClu, the
same type of input quantities is used). These checks were based on 25,000
events (calorimeter jets) and 7,000 events (hadron level jets), so I am
confident that the code is okay. I was able to build the libraries and
executables using various gcc versions (2.95.3, 2.96, 3.2.3, 3.3.1) on
RedHat/Fermi/Scientific Linux.