Long answer: as long as the jet definition is identical (same algorithm and same parameters), and as long as your input particles do not involve degenerate clustering distances (see below) any two releases of fastjet should give identical answers. If you find that two versions of fastjet give different answers for identical jet definitions, then you should let us know.
Very occasionally we might choose to change a default parameter in an algorithm's constructor, if there is a good physical reason for this. If this happens we will indicate it very clearly.
The one exception to this rule so far was in the v2.1.0-beta series during which the SISCone formulation was still under development. Since the official v2.1.0 release (SISCone's v1.1.1), results have been stable.
The one exception to this, going from 2.3 to 2.4, is that we have removed certain default arguments in the constructors of jet definitions (specifically the overlap parameter for certain cone algorithms, and R for native jet definitions). This was because it was felt the default values that were present in versions 2.3 and earlier were either substantially non-optimal, or did not correspond to experiments' default choices.
Across major releases (e.g. v2.X to v3.X) we may change certain aspects of the API. We will still endevaour to keep as much backwards compatibility as possible, and indicate clearly, where relevant, any changes that do need to be made to user code.
Currently FastJet does not have a uniquely-defined behaviour for resolving degeneracies (and the behaviour may differ according to the precise computational strategy used internally). The ill-defined nature of equality tests for floating-point numbers essentially means that this is not likely to change in the future.
If you are concerned about the impact of degeneracies, you might explicitly add some randomness yourself to the calorimeter-tower positions (i.e. break the degeneracy) and check how much this changes any results. Or you might deform your calorimeter very slightly, as with the following transformations of rapidity and azimuth (phi)
// Deform calorimeter: low eta, low phi cells are marginally
// closer together than high eta, high phi cells.
//
// It's best to use slightly different deformations for eta and phi.
rap += 1.000000e-9 * pow(rap,2)
phi += 1.047198e-9 * pow(phi,2)
Alternatively, if you have the information, you might give each calorimeter tower the correct rapditiy-phi position based on its contents.
Workarounds include: (a) using repeat=1, (b) catching the exception on the rare events where it occurs and using repeat=1 specifically for those events, or (c) breaking the degeneracy of the input particles (see earlier FAQ entry).
Two kinds of solution are possible:
Long answer: To calculate the UE or pileup density ρ using the median pt/area of the jets, it is important to avoid algorithms with extreme behaviours for the areas. In particular one should not use anti-kt (which has many jets with near-zero area) or SISCone (which can have jets with near-zero area, as well as monster jets with huge areas if the overlap parameter f is too small). In contrast the kt and Cambridge/Aachen algorithms are suitable.
NB: If you try to calculate ρ with an unsuitable algorithm, FastJet will print a warning.
You should determine ρ with the kt or Cambridge/Aachen algorithms (see above), but you can then use that ρ value to perform the area-based subtraction for whichever algorithm you prefer to use in your analysis (including anti-kt and SISCone).
Long answer: CGAL is presently used only to provide the
NlnN methods for the kt and
anti-kt algorithms. These are faster than other N2 methods
only at very
high multiplicities, > 15-30k for the kt algorithm,
>50-70k for the
anti-kt one. If the multiplicities you deal with are
usually lower, or if
you use other jet algorithms, having CGAL or not is immaterial.
Note that running active areas with a large number of ghosts can
considerably increase the multiplicity. For instance, in the default
setup (ghost_area = 0.01, |y|<6 range) about 7500 ghosts are added.
Long answer:There are some expected warnings that one should not worry about, listed below for fastjet 3.0.1 with gcc-4.6.1 with "-Wall" on a 32-bit Linux machine:
./configure CXXFLAGS="-O2 -m32 -g -Wall" CFLAGS="-O2 -m32 -g -Wall"
On some systems we have found it necessary to also include flags
such as
--build=i386 --host=i386
but this sometimes prevents shared libraries from being built
(issue reported by Eleanor Dobson).
For ROOT v5, you can only use FastJet through files compiled with ACLiC, e.g.
.L my-file-that-uses-fastjet.cc+
In ROOT v6, CINT has been replaced by a much better interpreter, and so you have the choice between interpreted and compiled usage, i.e. either of the following should work:
.L my-file-that-uses-fastjet.cc
.L my-file-that-uses-fastjet.cc+
In both cases, you need to set the include path and load the
libraries within ROOT. If you compiled FastJet with CGAL support,
you will need to load the CGAL library into ROOT before
loading the FastJet libraries.
ACX_CHECK_FASTJET([action-if-found],[action-if-not-found])Note that the m4 script sets the FASTJET_CXXFLAGS and FASTJET_LIBS variables if FastJet is found and functional. It supports the --with-fastjet=<path_to_my_installation_of_fastjet> option.
sudo -i umask 022 # or any desired mask make install exitHowever, if you have already performed an installation with a restrictive umask, this will not change the permissions of the existing directories. You can then instead do
chmod -R go+rX PREFIX/
If your plugin is based on pairwise sequential recombination, you may wish to investigate whether the NNH template class can help you write it.
Generally, we advise that you
If you use the area (JHEP 0804 (2008) 005) and/or subtraction (Phys. Lett. B659 (2008) 119) facilities, please also cite the corresponding papers.