This class represents a cluster, which is a colour singlet made usually
of two components (quark-antiquark, quark-diquark, antiquark-antidiquark)
or rarely by three components (quark-quark-quark, antiquark-antiquark-
antiquark).
A reference to the container with the pointers to its Components is
provided.
The class provides access to the pointer to:
- the cluster father, in the case that the cluster it is a fission
product
of an heavy cluster; or, occasionally, in the case that the cluster is
the "redefinition" of another cluster (his father), for example in
the case
that its three quarks or anti-quarks components have been redefined
as two
components (quark+diquark, or antiquark+antidiquark), or when the
cluster
has been the partner of the momentum reshuffling necessary to conserve
energy-momentum when a light cluster decays into a single hadron.
- its children clusters (usually two), in the case the cluster is an
heavy cluster
that undergoes to fission; or occasionally, in the case the cluster
has been "redefined" (re-interpreted) for example in the case that
its three quarks or
anti-quarks components have been redefined as two components (quark+
diquark, or
antiquark+antidiquark), or when its momentum has been reshuffled.
- its (eventual) reshuffling partner, necessary for energy-momentum
conservation when light clusters are decayed into single hadron.
- its Hadrons (Particle class objects) decays.
Notice that, differently from what is in Fortran Herwig, in the (rare)
cases in which an heavy cluster undergoes to fission and one of its
two fission products is light (that is below the threshold to produce
the lightest pair of hadrons with proper flavours), such light
product is identified with the lightest single hadron (with proper
flavours) without create an cluster. Therefore, in these cases, the
father (heavy) cluster has one single cluster child and one single
hadron child (rather than to have two cluster children as usual).
The rationale behind the design of this class has been to allow to save
completely all of the information on any transformation process which
affect the clusters, from their formation through their entire life.
This, in its turn, is motivated to allow any kind of future extension
in the Cluster Hadronization model, to avoid the typical, albeit familiar,
bad situation in which one does not have (because not stored somewhere!)
the information that he would need... Furthermore, this pletora of
information is quite useful as debugging tool, providing many possible
consistent checks.
Notice that in order to determine the cluster position from the positions
of the components, Cluster class needs some global parameters.
Because Cluster class is neither interfaced nor persistent,
a static pointer to the GlobalParameters class instance,
where the global parameters are, is used. Such static pointer is
set via the method setPointerGlobalParameters, during the
run initialization, doinitrun(), in the steering class
ClusterHadronizationHandler.