The so-called "TAUOLA" in CDF is formed by two programs: one is "true TAUOLA" and another is the "interface to decide tau chirality". The "true TAUOLA" needs to know the chirality information of tau before performing the tau decay.
The "interface to decide tau chirality" sets the tau chirality using a certain approximation to pass the "true TAUOLA". The information of the mother particle of taus is used for this approximation. However, ME-generators already output the tau chirality as the result of the ME calculation in the event file. Thus, we don't need the approximated formula by the "interface to decide tau chirality".
That is, when ME-generator is used in LesHouchesModule and if the input file of the ME-generator contains the helicity information, LesHouchesModule automatically takes over this "interface", the chirality information from the ME-generator is directly fed into the "true TAUOLA". Therefore, even if the event history does not have "Z mother", the tau chirality is correctly handled by TAUOLA.
For example, however, Alpgen does not output the helicity information so that the "interface" is used instead of passing the chirality directly from ME-generator. And this interface failed to find the mother, then assigned it with the random order. (it makes flat.)
This code sets the mother information for the hard photon from ME based on kT algorithm. The kT clustering runs for stable ELWK particles (leptons and photons) at hard interaction level, tries to assign the mother particle of the photons based on the measured Y cut. The possible mother candidates are leptons or initial quark line if the hard photon is isolated kt-jet. This code will work for many photon processes.
The definition to set the mother of photons are so far:
Because PYTHIA and HERWIG generate the events until being the given number of events. For example, when we set 100 events for the total number of events, PYTHIA and HERWIG make exactly 100 events even if PYTHIA and HERWIG failed to produce events somewhere. This feature is different from those of the detector simulation. In the detector simulation, when we apply 100 events, if the simulation fails 1 event, we get 99 events in the end.
The safety factor is applied to avoid to simulate the same event twice. For example, when we simulate 100 events from ME generator with two run number, we have
50 events for run#1
50 events for run#2 .
The first 50 events are read from the input file of the ME generator, and then the last 50 events are read from the input file. The first events to read for each run are 1 and 51, respectively. If PYTHIA/HERWIG fails producing 1 event in run #1, PYTHIA/HERWIG tries to read the next event, and ends up to 51th event.
But the 51th event is already assigned in the run#2.
And the 51th event is simulated twice.
Each job with each run works as independent process. (for CAF jobs.) Thus, I can not handle when this error happens. Instead of producing 50 events each, I put the interval between runs.
49 events for run#1 ( 1 -- 49)
49 events for run#2 (52 -- 100)
The first events to read for each run are 1 and 52, respectively. Even if events are failed, the same event is not simulated twice until the number of errors is 3 in run#1. This interval is the safety factor which I set.
The fraction of this failure is very small for PYTHIA, but large for HERWIG. The current code sets the safety factor as 5% in each run.