This class is responsible of two related tasks:
- it finds the partners (pairs of ShowerParticles objects)
for each interaction types (QCD,QED,EWK...) and within the
scale range specified by the ShowerConstrainer object;
- for each pair of partners (and interaction therefore)
it sets the initial evolution scales of both of them.
Notice that a given particle has, in general, a different partner
for each different interaction; however, given a partner, its
initial evolution scale, Q, is purely a kinematical relationship
between the pair, without dependence on the dynamics (i.e. type of interaction).
Therefore, there must be different methods for finding partners of different
interaction types, but an unique common method to calculate the initial evolving
showering scale.
Notice that:
- to be more general, one should define an abstract class
AbsPartnerFinder
which has, exactly like the present PartnerFinder class,
the definition of the methods:
setQCDInitialEvolutionScales
setQEDInitialEvolutionScales
setEWKInitialEvolutionScales
which are quite general, whereas the other one is declared pure virtual,
without definition:
virtual ... calculateInitialEvolutionScales(...) = 0;
and then having a concrete PartonFinder class which inherits
from AbsPartnerFinder and provides a definition for this virtual method.
In fact, it is only in this method that a specific choice of ordering variable
must be made. Therefore, if we wanted a different choice, we could define another
class, AlternativePartonFinder,
which also inherits from AbsPartnerFinder,
but provides a different definition of the method
calculateInitialEvolutionScales.
***LOOKHERE***
- If the method calculateInitialEvolutionScales
were not used anywhere else a part in this class,
then it should be moved in the private part of the class.
- It could be easy and straightforward to add to
setQCDInitialEvolutionScales
(and, maybe, but less likely, also for the other ones)
either a pointer to the Collision object (which is
already available in the class InsideRangeShowerEvolver
that calls this class Partner Finder) --- in the
case some information from the hard subprocess is
necessary to find colour partners (expecially in the
case of baryon number nonconserving processes in
Rp violating Susy) --- and/or a boolean flag that
tells whether or not the input particles are
associates to a decay --- and therefore finding
the colour partners, at least for the scale of
the decay, should not involved searches through
the particle history.
***endLOOKHERE***