1 \documentclass[]{Photos_interface_design}
12 \renewcommand*\l@subsection{\@dottedtocline{2}{1.5em}{2.0em}}
13 \renewcommand*\l@subsubsection{\@dottedtocline{3}{3.0em}{3.0em}}
20 \tableofcontents\pdfbookmark[0]{Table of Contents}{toc}
24 \section{Introduction}
25 For a long time, {\tt PHOTOS} Monte Carlo \cite{Barberio:1990ms,Barberio:1993qi}
26 has been used for the generation of bremsstrahlung in the decay of particles and resonances.
27 Over the years the program has acquired
28 popularity and it evolved into a high
29 precision tool \cite{Golonka:2006tw}. Since version 2.15 of the program become
30 public in the year 2005 and multi-photon radiation was
31 introduced \cite{Golonka:2005pn}, there were no further public upgrades
32 of the program. However the effort on documentation and tests was going on;
33 phase space treatment was shown to be
34 exact \cite{Nanava:2006vv} and for several
35 processes \cite{Golonka:2006tw,Nanava:2006vv,Nanava:2009vg}
36 an exact matrix element was studied with the help of optional weights.
37 Benchmark distributions, including comparisons with
38 other simulation programs, were collected on the program web page \cite{Photos_tests}.
40 Such high precision applications require good control of the event record content on which {\tt PHOTOS} operates. On one side it
41 requests skills and experience of the user and on the other it provides
42 the flexibility necessary for the study of effects like, for example, systematic errors for
43 measurements of anomalous couplings or W cross section. Methods of
44 correlated samples can be applied\footnote{To exploit such methods in
45 the high precision regime, good control of matrix element properties is necessary.
46 As was shown in \cite{Kleiss:1990jv}, complications for such methods arise at the second order matrix element only, thus at the precision level of
47 $(\frac{\alpha_{QED}}{\pi})^2 \simeq 10^{-5}$.}.
49 Until recently {\tt HEPEVT} \cite{Altarelli:1989wu} was used as the structure for
50 communication between physics Monte Carlo programs and detector/reconstruction
51 packages. Experimental physicists used {\tt HEPEVT}
52 for their own applications as well. Recently, to gain flexibility, {\tt FORTRAN} is being replaced by C++ and
53 instead of {\tt HEPEVT}, the C++ event structure called {\tt HepMC} \cite{Dobbs:2001ck}
54 is used. Nothing prevents
55 moving {\tt PHOTOS} to an environment based on {\tt HepMC}
56 and to rewriting the whole (beginning with the event record interface)
57 of {\tt PHOTOS}\footnote{An up-to-date version of the code described in this paper is
58 available from the web page of our project~\cite{photosC++}.
60 to C++. In fact implementation of the algorithm in that language
61 is clearer and easier to
62 maintain. Because of its design the {\tt PHOTOS} algorithm benefits from the object
63 oriented features of C++. It is our third program, after {\tt MC-TESTER} \cite{Davidson:2008ma}
64 and the {\tt TAUOLA} interface \cite{Davidson:2010rw}, previously ported to {\tt HepMC} and C++.
65 This completes the main step of migration of these three programs to the new style.
67 Such migration is convenient for the users too; they can now work
68 with homogeneous C++ software. From the physics point of view, transformation
70 from {\tt FORTRAN} to C++ brings some benefits as well.
71 The channel dependent, complete first order matrix elements of {\tt PHOTOS}, in {\tt FORTRAN},
74 kinematical configurations. With the help of the new event record interface they will become
75 available for general use.
76 For that purpose, better access to the information necessary to orient the spin state of decaying particles
81 Our paper is organized as follows. Section \ref{sec:requrements} is devoted
82 to a description of physics information which must be available in the event
83 record for the algorithm to function. Later, particular requirements for the
84 information stored in {\tt HepMC} are given. Section \ref{sec:design} describes
85 the program structure. In Section \ref{sec:extensibility} methods prepared for
86 future extensions to improve the physics precision of the generator are explained.
87 Section \ref{sec:tests} presents the program tests and benchmarks.
88 A summary, section \ref{sec:summary}, closes the paper.
89 There are three appendices \ref{Interface to PHOTOS},
90 \ref{sec:User Guide} and \ref{sec:User Configuration} attached to the paper.
91 Respectively, they describe the interface to the old {\tt FORTRAN} part of the code,
92 provide a user guide and explain the program configuration methods and parameters.
95 \section{Requirements of the {\tt PHOTOS} Interface}
96 \label{sec:requrements}
97 The algorithm of {\tt PHOTOS} Monte Carlo can be divided into two parts.
98 The first, internal part, operates on elementary decays. Thanks to carefully
99 studied properties of the
100 QED (scalar QED) algorithm, with certain probability,
101 it replaces the kinematical configuration of the Born level decay with a new one,
102 where a bremsstrahlung photon or photons
103 are added and other particle momenta are modified. This part of the program is sophisticated from the physics
104 point of view \cite{Golonka:2006tw,Nanava:2006vv},
105 but from the point of view of data structures the algorithm is simple.
106 That is why the gain from re-writing this part of the program to C++ is rather
107 limited and will be postponed to a later step of the project development.
108 On the other hand, there are not many obstacles for such a transformation to be
109 performed. In fact it was already done
110 previously \cite{photosplus}, but the resulting program was developed too early
111 and did not attract users because of a lack of a C++ event record format standard at that time.
113 The typical results of high energy process simulation are events of complex structure.
114 They include, for example, initial state parton showers, hard scattering parts,
115 hadronization and finally chains of cascade decays of resonances.
116 A structure similar to a tree is created, but properties of such data structures
117 are sometimes violated.
118 For its action, {\tt PHOTOS} needs to scan an event record (tree)
119 and localize branchings where
120 it is supposed to act. The decaying particle (mother) and its primary decay products
121 (daughters) have to be passed into the internal event structure of {\tt PHOTOS}.
122 Finally for each daughter a list of all its subsequent decay products has to be
123 formed. Kinematical modifications need to be performed on all descendants of the modified daughter.
125 In the new, C++ version of this part of the algorithm, additional functionality
127 The first mother of the decaying particle will be localized and passed together with
128 the elementary branching to the internal part of the program.
129 Prior to activation of the algorithm for photon(s) generation and kinematic construction,
130 the whole decay branching
131 (supplemented with its mother(s))
132 will be boosted into the decaying particle's rest frame and the first mother
133 will be oriented along the $z$ axis.
134 In many cases, the spin state of the decaying particle can be calculated from kinematics of its production process.
135 Later it can be passed on to the code which calculates the matrix element for our branching.
138 At present, the part of the code responsible for photon(s) generation and kinematic
139 construction is left in {\tt FORTRAN}. It does not feature the options presented above yet.
142 Before an actual description of the program, let us list the tasks the event record interface must be able to perform:
144 \item a method to read particles stored in the event tree.
145 \item a method to add or modify particles of the event tree.
146 \item a method to search for elementary decays over the entire tree of the event.
147 \item a method to form lists of all subsequent decay products originating from each elementary decay product.
148 \item a method to localize the first mother of the decaying particle.
149 \item a method to localize the second mother for a special case of $t \bar t$ pair.
153 \subsection{C++ and HepMC Specific Requirements}
155 The C++ version of the {\tt PHOTOS} interface implements all functionality
156 of its predecessor, the {\tt PHOTOS} version 2.15 \cite{Golonka:2005pn} coded in {\tt FORTRAN}.
157 The program is prepared for installation of the process-dependent correcting weights of refs
158 \cite{Golonka:2006tw,Nanava:2009vg} into its public available version.
159 {\tt PHOTOS} can be attached to any Monte-Carlo program,
160 provided that its output is available through a {\tt HepMC} \cite{Dobbs:2001ck} event record.
161 It seems that {\tt HepMC} will
162 remain a generally accepted standard for the near future. However,
163 already now several different options for how {\tt HepMC} is used are
164 widespread. The possibility of the flexible adaptation of our event record
165 interface to different
166 options has been considered in the design, drawing experience
167 from {\tt MC-TESTER} \cite{Davidson:2008ma,Golonka:2002rz}.
169 envisaged the possibility that {\tt HepMC} may one day be replaced by another
170 standard of event record, and we have provided a way to extend
171 the interface to a possible new event record standard as well.
173 \subsection{Object Oriented Event Records -- The Case of {\tt HepMC}}
174 % nd-the next paragraph repeats information that's already stated in other places.
175 % zbw: this is short intro to HepMC, later contexts of our use dominate. Nadia is it OK for you?
176 In adapting the {\tt PHOTOS} interface to the C++ event record format
177 the difference between the {\tt HEPEVT} event record, used in the {\tt
178 FORTRAN} version of the {\tt PHOTOS} interface, and the {\tt HepMC} event
179 record, which is used for the C++ based interface, has to be taken into
180 account. In the first case
181 a {\tt FORTRAN common block} containing a list of particles with their properties and
182 with integer variables denoting pointers to their origins and
183 descendants is used. The {\tt HepMC} event structure is built from vertices,
184 each of them having pointers to their origins and descendants. Links
185 between vertices represent particles or fields. Fortunately, in both {\tt
186 FORTRAN} and C++ cases, the event is structured as a
187 tree\footnote{At least in principle, because in practice its
188 properties may be rather like a graph without universally defined
189 properties. This makes our task challenging.}; the necessary
190 algorithms are analogous, but nonetheless different. The {\tt HepMC}
191 structure based on vertices is more convenient for the {\tt PHOTOS}
194 In {\tt HepMC}, an event is represented by a {\tt GenEvent} object,
195 which contains information such as event id,
196 units used for dimensional quantities in the event and the list of produced particles. The particles
197 themselves are grouped into {\tt GenVertex} objects allowing access to mother
198 and daughter particles of a single decay. Vertices provide an easy way
199 to point to the whole branch in a decay tree that needs to be accessed,
200 modified or deleted if needed. The information of a particle itself is stored
201 in a {\tt GenParticle} object containing the particle id, status and momentum
202 as well as information needed to locate its position in the decay tree.
203 This approach allows traversing the event record structure in several different
206 The {\tt HepMC} event record format is evolving with time, making it necessary
208 the code to new versions. The
209 {\tt HepMC} versions 2.06, 2.05 and 2.03 were used in the final tests of our
212 Evolution of the {\tt HepMC} format itself is not a crucial problem.
213 In contrast, conventions on how physics information is filled into {\tt HepMC}
214 represent the main source of technical and also physics
215 challenges for our interface.
216 This is quite similar to the previous
217 {\tt HEPEVT - FORTRAN} case. Let us discuss this point in more detail now.
219 \subsubsection{Event Record Structure Scenarios}
223 While many Monte-Carlo generators (e.g. {\tt PYTHIA 8.1} \cite{Sjostrand:2007gs},
224 HERWIG++ \cite{Bahr:2008pv}), SHERPA \cite{Gleisberg:2008ta} can
225 store events in {\tt HepMC} format, the representations of
226 these events are not subject to strict standards, which can therefore
227 vary between Monte-Carlo generators or even physics processes. Some examples
228 of these variations include the conventions of status codes, the way
229 documentary information on the event is added, the direction of pointers at a vertex
230 and the conservation (or lack of conservation) of energy-momentum at a vertex.
231 Below is a list of properties for basic scenario we have observed in Monte-Carlo
232 generators used for testing the code.
234 This list will serve as a declaration for convention of {\tt HepMC} filling, which the
235 interface should be able to interpret correctly.
238 \item \textbf{4-momentum conservation} is assumed for all vertices in the event record where {\tt PHOTOS} is expected to act.
239 \item \textbf{Status codes:} only information on whether a given particle is incoming, outgoing or intermediate will be used. We assume the codes used will be 0, 1 or 2 like in HEPEVT. All other codes will be treated as
240 equivalent to the status 2.
241 \item \textbf{Pointers at a vertex} are assumed to be bi-directional. That is, it is possible to traverse the record structure from mother to daughter and from daughter to mother along the same path.
245 \textbf{ Extensions/Exceptions} to these specifications are handled in some cases. We will call them
246 options for conventions of event record filling.
248 \item Vertices like $\tau^\pm \rightarrow \tau^\pm$ and $\tau^\mp \rightarrow \tau^\mp \gamma$
249 where the decaying particle flavor is among its decay products will prevent {\tt PHOTOS} being invoked.
251 \item If there is 4-momentum non-conservation\footnote{For details see
252 Appendix~\ref{subsection:other_methods} for details.} in the vertex,
253 {\tt PHOTOS} will not be invoked too. A special kinematic correcting
254 method to remove smaller inconsistencies resulting e.g. from rounding errors is available too.
257 As in the {\tt FORTRAN} cases, we expect that new types of
258 conventions for filling the event record
259 will appear, because of physics motivated requirements.
260 Unfortunately, the resulting options do not always guarantee
261 an algebraically closed structure.
262 Host program-specific patches may need to be defined for
264 Debugging can then be time consuming, and will need to be repeated for every new
269 In the future, an important special case of event record's filling, with
270 information extracted from experimentally observed events (e.g. $Z\to \mu^+\mu^-$
271 modified later to $Z\to \tau^+\tau^-$) should be allowed.
272 Obviously, a new type (or types) of {\tt HepMC} filling will then appear.
274 A good example is the evolution of {\tt PYTHIA}. While in version 8.108 the status codes for
275 our example processes took the values 0, 1 or 2 only (in the part of the record
276 important for {\tt PHOTOS}), other values were already present in
277 version 8.135. As a consequence the status code for
278 otherwise nicely decaying particles was not always 2 anymore. We have introduced
279 a change in the file PhotosEvent.cxx to adjust. After the change
280 the program should work for all previous cases as before,
281 changes like this one are usually difficult to validate
282 and complicated tests are necessary. One could investigate
283 if instead of changes on the side of the {\tt PHOTOS} algorithm a different choice of input for {\tt PYTHIA} would not
284 be a more appropriate
285 solution, but in this case we choose to adopt our algorithm.
287 We have yet to decide on bar code conventions. Our programs, {\tt TAUOLA} and
288 {\tt PHOTOS}, supplement the event record with new particle entries carrying bar codes
289 with values starting from 10001. That is the choice resulting from our use
290 of {\tt HepMC} methods and defaults.
292 \subsection{Interface to the Event Record of {\tt FORTRAN}}
295 In principle it would be rather simple to completely rewrite {\tt PHOTOS} to
296 C++. However to profit from numerical tests, for the time being the numerical core of {\tt PHOTOS}
297 is still left in {\tt FORTRAN}. The C++ part of the code searches the whole event for
298 suitable HepMC vertices for the generation of bremsstrahlung. Once such
299 a vertex is found it is copied to an internal event record which is
300 called {\tt PH$\_$HEPEVT} (this is effectively the same structure as {\tt HEPEVT};
301 the event record of {\tt FORTRAN}).
302 The {\tt FORTRAN} code of {\tt PHOTOS} is then executed.
303 The data structure passed in this way is rather simple. Only a single vertex consisting
304 of the decaying particle along with its mothers and daughters is passed. Information
305 on mothers will be useful in future for the calculation of process dependent
310 A description of the interface to the remaining {\tt FORTRAN} parts of the code is
311 given in Appendix \ref{Interface to PHOTOS}.
316 \subsection{Classes and Responsibilities}
318 The choice of splitting the source code into three main modules
319 allows the separation of the {\tt FORTRAN} related code from the abstract C++ interface
320 and the concrete implementation of the interface created for the appropriate
325 \includegraphics[scale=0.6]{interface_design.eps}
327 \caption{{\tt PHOTOS} C++ interface class relation diagram}
331 \item {\bf {\tt PHOTOS FORTRAN} Interface}\\
332 This part of the code provides an interface
333 to the {\tt FORTRAN} library of {\tt PHOTOS}. In particular,
334 a wrapper for the routine which invokes the processing
335 of a single branch. Parts of the interface code are still left in {\tt FORTRAN}, but
336 can be rather easily rewritten to C++.
337 The most important part of this module, the {\tt PH\_HEPEVT\_Interface\_} class,
338 is already implemented in C++. This class is responsible for writing
339 the decay branch to be processed into the internal event record {\tt PH\_HEPEVT}.
340 For further details regarding the interface to {\tt FORTRAN}
341 common blocks and routines see Appendix \ref{Interface to PHOTOS}.
342 \item {\bf {\tt PHOTOS} C++ Interface} \\
343 This is an abstract interface to the event record.
344 The class {\tt PhotosEvent} contains information regarding the whole event
345 structure, while {\tt PhotosParticle} stores all information regarding a single particle.
346 All particles used by the interface are located in the event in the form of
347 a list of {\tt PhotosParticle} objects.
348 The last class located here, {\tt PhotosBranch}, contains information regarding
349 elementary branching to be processed by {\tt PHOTOS}.
350 \item {\bf Event Record Interface} \\
351 This contains the event record implementation classes. All classes stored here represent
352 the implementation of specific event record interfaces and are responsible for reading,
353 traversing and writing to the event record structure.
354 Only the {\tt PhotosEvent} and {\tt PhotosParticle} classes must be implemented.
355 The {\tt HepMC} event record interface is implemented
356 through {\tt PhotosHepMCEvent} and {\tt PhotosHepMCParticle}. These classes are similar to the
357 analogous {\tt TAUOLA} \cite{Davidson:2010rw} event record classes.
358 An example of a minimalistic interface to an event record has been provided
359 through the classes {\tt PhotosHEPEVTEvent} and {\tt PhotosHEPEVTParticle}\footnote{This interface is the only way of implementing NLO corrections in programs based on {\tt HEPEVT} event record}.
360 %TP: we have to write something regarding the limitations of the HEPEVT interface
361 They can be used as a template for a new interface to any other event record%
362 \footnote{Thanks to the polymorphism, abstract part of the algorithm
363 is well separated from the specific event record implementations.
364 It even allows simultaneous use of several distinct event record implementations.}.
367 \subsection{Directory Structure}
370 \item {\bf src/eventRecordInterfaces/ } - source code for classes which interface with event records.
371 Currently only the {\tt HepMC} interface is located here.\\
374 \item { \bf PhotosHepMCEvent} - interface to HepMC::GenEvent objects.
375 \item { \bf PhotosHepMCParticle} - interface to HepMC::GenParticle objects.
376 \item { \bf PhotosHEPEVTEvent} - interface to the event structure of the {\tt HEPEVT} format.
377 \item { \bf PhotosHEPEVTParticle} - interface to a single particle from the {\tt HEPEVT} event record.
380 \item {\bf src/photosCInterfaces/ } - source code for the general {\tt PHOTOS} interface. \\
383 \item { \bf Photos } - controls the configuration and initialization of {\tt PHOTOS}.
384 \item { \bf PhotosEvent } - abstract base class for event information.
385 \item { \bf PhotosParticle } - abstract base class for particles in the event.
386 \item { \bf PhotosBranch } - contains one {\tt PhotosParticle}, and pointers to its mothers and daughters.
387 The filtering of branchings to be tried by {\tt PHOTOS} for photons emission is done here.
390 \item {\bf src/photosFortranInterfaces/ } - interface to {\tt PHOTOS FORTRAN} routines and common blocks. \\
393 \item { \bf f\_Init } - contains a wrapper for the {\tt PHOTOS FORTRAN} routines for initialization.
394 \item { \bf PH\_HEPEVT\_interface } - contains a wrapper for accessing the
395 {\tt PH\_HEPEVT} common block.
396 \item { \bf photos\_make.f } - contains {\tt FORTRAN} routines to be migrated to C++ rather soon.
397 \item { \bf forW-ME.f } - c {\tt FORTRAN} routines to calculate matrix element in W decay, own programming style.
398 \item { \bf forZ-ME.f } - {\tt FORTRAN} routines to calculate matrix element in Z decay, own programming style.
401 \item {\bf src/utilities/ } - source code for utilities.\\
404 \item { \bf Log} - general purpose logging class that allows filtering out output messages
405 of {\tt PHOTOS C++ Interface} and tracks statistics for each run.
406 \item { \bf PhotosRandom} - random number generator taken from {\tt PHOTOS FORTRAN} and rewritten to C++.
408 \item {\bf src/photos-fortran/ } - {\tt PHOTOS FORTRAN} core rewritten to C++. Since version 3.54 {\tt PHOTOS} has been
409 fully rewritten to C++ and located in its own namespace {\tt Photospp}\footnote{This means that no part of
410 the code is shared with old {\tt PHOTOS FORTRAN} and both versions can be loaded simultanously without the
411 risk of one version overwriting the options of the other.}. From the algorithmic point of view
412 full compatibility\footnote{The resulting modules are however not interchangeable and the program
413 will not function if the {\tt PHOTOS FORTRAN} library is loaded instead of code encapsulated
414 in {\bf src/photos-fortran/ } directory.
416 with the {\tt FORTRAN } version is kept. The appropriate descriptions remain vaild;
417 in publications as well as in the code, now in C++.
418 \item {\bf examples/ } - examples of different {\tt PHOTOS} C++ Interface uses.
420 \item {\bf photos\_hepevt\_example} - stand alone example with a simple
421 $e^+e^- \rightarrow \tau^+\tau^-$ event written in {\tt HEPEVT} format
422 and then processed by {\tt PHOTOS}.
423 \item {\bf photos\_standalone\_example} - the most basic example which loads pre-generated
424 events stored in a file in {\tt HepMC} format which are then processed by {\tt PHOTOS}.
425 \item {\bf single\_photos\_gun\_example} - an example of using the {\tt processOne} method
426 to process only selected particles within the event record.
427 \item {\bf photos\_pythia\_example} - an example of $e^+e^- \rightarrow Z \rightarrow \mu^+\mu^-$ events
428 generated by {\tt PYTHIA 8.1} and processed by {\tt PHOTOS}. The analysis is done using {\tt MC-TESTER}.
429 \item {\bf tauola\_photos\_pythia\_example } - an example of {\tt TAUOLA} linked with {\tt PYTHIA 8.1}.
430 The decay chain is processed by {\tt PHOTOS} and then analyzed with {\tt MC-TESTER}.
432 \item {\bf include/} - directory for the header files.
433 \item {\bf lib/ } - directory for the compiled libraries.
434 \item {\bf documentation/ } - contains doxygen documentation and this latex file.
437 \subsection{Algorithm Outline}
440 An overview of the algorithm for the {\tt PHOTOS C++ Interface} is
441 given below. For clarity, the example assumes that the processed event
442 is stored in the {\tt HepMC} event record structure.
444 The first step is creation of a {\tt PhotosHepMCEvent} object from
445 a {\tt HepMC::GenEvent} event record. After that, the {\tt process()} method should
446 be executed by the user's code\footnote{Instead of creating a {\tt PhotosHepMCEvent} and processing the whole event,
447 a user may want to execute {\tt Photos::processParticle(...)} or {\tt Photos::processBranch(...)}
448 for branching or branch, where {\tt PHOTOS} is expected to perform its tasks.
449 For details see Appendix~\ref{PHOTOSgun}.
450 }, invoking the following process:
453 \item The {\tt HepMC} event record is traversed and a list of all decaying
454 particles is created.
455 \item Each particle is checked and if the resulting branching is a self-decay\footnote{A history entry in the event record, like
456 $Z\to Z$ or $\tau \to \tau$.} it is skipped.
457 \item For each remaining particle a branching including the particle's mothers and daughters
458 is created. Special cases consisting of mothers and daughters but without intermediate particle
459 to be decayed are also added to the
461 \item Branchings are filtered out again, this time with the user's choice of processes
462 to be skipped by the photon adding algorithm.
463 \item Each branching is processed by {\tt PHOTOS} separately:
467 \item The branching is written to {\tt PH\_HEPEVT}
468 \item The {\tt PHOTOS} photon adding algorithm is invoked
469 \item The resulting branching is taken back from {\tt PH\_HEPEVT} and any changes made by {\tt PHOTOS}
470 to the already existing particles and their whole decay trees are integrated into the event record.
471 \item Finally, the created photons are added to the event record.
476 The underlying HepMC::GenEvent is hence modified with the insertion of photons.
478 \section{Extensibility}
479 \label{sec:extensibility}
480 The purpose of the present version of the C++ interface to {\tt PHOTOS} is to enable
481 all the functionality of its {\tt FORTRAN} predecessor to be available for the HepMC data
482 structure. Some methods for improved initialization are already introduced in this version. The new program
483 functionality has been prepared to enable further extensions in the future.
484 Let us briefly discuss some of these points.
486 \subsection{{\tt PHOTOS} Extensions}
487 In this paper we have presented an algorithm as it is today.
488 That is, a version which is compatible with the one implemented in {\tt FORTRAN}.
494 As can be seen from the text presented, we have prepared the structure
495 for the implementation of channel dependent matrix elements. This work, requiring
496 special modifications to the {\tt FORTRAN} code and applicable one at a time only can
497 be simply integrated all together into the C++ version. This is not urgent.
498 We are not convinced if such complication is worth
499 the inconvenience for the user as it requests more strict control of the event
500 record content. The gain of precision is
501 not that important because the precision is already quite good.
502 This is why we have not incorporated these auxiliary upgrades to C++ already now.
503 Instead, as an intermediate step, we developed validation techniques
504 for the program. These are required prior to a re-write of the
505 numerically sensitive part of the program (which is algorithm-wise
506 rather simple) anyway.
509 Methods devised to check the content of HepMC as used by {\tt PHOTOS} are
510 described in Appendix \ref{App:Logging}.
511 They need to be used whenever {\tt PHOTOS}
512 processes events from a new generator e.g. upgraded versions of {\tt PYTHIA},
513 which may fill the event record in an unexpected way.
514 Experience gained from many years of developing and maintaining the algorithm
515 have shown, that this is the most demanding task; the necessity to
516 adapt to varying physics and technical input of the event record pose
517 a multitude of problems. The nature of these difficulties cannot be
518 predicted in advance.
521 For the sake of debugging we have introduced new control methods
522 and ones which activate
523 internal printouts of the {\tt FORTRAN} part of the code.
524 The routine {\tt PHLUPA} \cite{Barberio:1993qi} can be activated to verify
525 how an event is constructed/modified, and to investigate energy
526 momentum (non-) conservation or other inconsistencies.
527 This is quite convenient, for example, for tracing problems in the
528 information passed to {\tt PHOTOS}.
532 Numerical stability is another consideration; it cannot be separated from
533 physics constraints. The condition $E^2-p^2=m^2$ may be broken because of
534 rounding errors. However, due to intermediate particles with
535 substantial widths, the on mass shell condition may not be applicable.
536 {\tt PHOTOS} may be adapted to such varying conditions, but it requires
537 good interaction with users. The protection which removes
538 inconsistencies in the event record may be a source of unexpected difficulties
540 At present, such methods are left in the {\tt FORTRAN} part of the algorithm,
542 will be gradually reviewed and migrated to C++.
546 \subsection{Event Record Interface}
547 In the times of {\tt FORTRAN}, the {\tt PHOTOS} interface used an internal event structure which was
548 based on {\tt HEPEVT},
549 adding to it (understood as a data type) an extra variable defining
550 the status of particles with respect to QED Bremsstrahlung. In some cases, like
551 $\tau \to l \nu_l \nu_\tau$, bremsstrahlung was already generated earlier
552 by other generator, and {\tt PHOTOS} should not be activated on such decays.
553 At present, instead, a set of initialization methods is
554 prepared as described in Appendix \ref{section:suppress}.
556 There is definite room for
557 improvement. For example if the vertex $q \bar q \to l^\pm l^\mp g$ is encountered
558 (note the presence of $g$ in the final state),
559 the interface could `on the fly' add an intermediate $Z$ into the record and enable {\tt PHOTOS}
560 on the temporarily constructed decay branching, $Z \to l^\pm l^\mp $.
562 Internally, in the {\tt FORTRAN} part of {\tt PHOTOS}, the data
563 structures based on {\tt HEPEVT}: {\tt PH\_HEPEVT} and {\tt PHOEVT},
564 are used, but they store only a single elementary decay.
565 At this step in the program
566 evolution it might not be the most elegant solution, but it prevents
567 the need to redo many of the {\tt FORTRAN} era benchmarks.
576 One of the most important parts of the {\tt PHOTOS} project are its physics oriented tests.
578 of physics tests should be mentioned. Users interested in precision
579 simulations of Z or W decay will
580 find the papers \cite{Nanava:2009vg,Golonka:2006tw,Golonka:2005pn}
581 most interesting. There, careful comparison with the first order matrix element
582 and confirmation of the agreement is concluded first.
583 For $Z$ decays, comparisons with Monte Carlo program based on exclusive
584 exponentiation with up to second order matrix element
585 is possible and was performed on some benchmark distributions.
586 Inclusion of a correcting weight was found to be numerically less important
587 than absence of the second order matrix element in the YFS exponentiation scheme.
588 In these comparisons the Monte Carlo programs from LEP times
589 \cite{koralz4:1994,kkcpc:1999} were used. In numerical tests {\tt MC-TESTER} \cite{Davidson:2008ma}
590 was used. The advantage of the method is that C++ and {\tt FORTRAN} program
591 results can be easily compared\footnote{We thank Andy Buckley for checking numerically
592 that our conclusions on the first order exact YFS exponentiation results extend
593 to the programs presently used at the LHC such as
594 SHERPA and HERWIG++. }.
596 For inclusive calculations, FSR radiative corrections are at the one permille level.
597 For semi-inclusive cross sections, such as the total rates of Z decay for events
598 where the hardest photon energy (or two hardest photon energies) exceed 1 GeV in the Z rest frame, differences
599 between results from {\tt PHOTOS} ({\tt PHOTOS} without the matrix element correcting weight)
600 and YFS based generators of the first or second order were also
602 On the other hand, if two hard photons were requested and invariant masses constructed from leptons
603 and hard photons were monitored,
604 the level of differences exceeded
605 30 \%. However, even in this region of phase space {\tt PHOTOS}, without the correcting
606 weight, performs better\footnote{In
607 the phase space region were only one hard photon is tagged this conclusion seems to depend
608 on the variant of exponentiation in use, \cite{koralz4:1994} or \cite{kkcpc:1999}.
610 than programs based on exponentiation and the first order matrix element only.
612 This conclusion needs to be investigated if
613 realistic experimental
614 cuts are applied. Fortunately the necessary programs are available for Z decay.
615 In the case of $W$ decay, second order Monte Carlo generators supplemented with
616 exponentiation are not available at this moment.
618 For users interested in the simulation of
619 background for Higgs searches at the LHC and for any other applications where
620 two hard photon configurations are important, studies based on the comparison with
621 a double photon matrix element are of
622 interest. For {\tt PHOTOS} Monte Carlo such tests were initiated
623 in refs.~\cite{Barberio:1993qi,RichterWas:1994ep,RichterWas:1993ta}.
624 Finally, users interested in low energy processes where the underlying physics model
625 for photon emission cannot be controlled by theory sufficiently well
627 be considered only as the starting point), will profit
628 from \cite{Nanava:2006vv,Nanava:2009vg}. In all cases it is important that
629 the program generation cover the full phase-space and that there are no
630 approximations in phase-space. As in the {\tt FORTRAN} version, the code
631 features approximation in the kernel. In some cases the process dependent
633 kernel is available but it is not always installed in the public version,
634 because the resulting approximation is
635 numerically unimportant and requires control of the spin state for the decaying
636 particle. This requires better control of the event record than what was available
637 in {\tt FORTRAN}. At present such an option is prepared (see Section \ref{sect:F77fill}) for $W$ and $Z$ decays. It is also available for the two body decays of scalar into scalars. Then, exact mean exact with respect to scalar QED only.
639 The main purpose of the present paper is program documentation. That is why
640 we also need to cover the program tests required to guarantee its proper installation.
641 The physics tests discussed above
642 do not guarantee that the program will perform well on a particular platform and installation. Tests and debugging of the installation
643 are necessary too. If the content of the event record is non-standard or rounding errors are large, the performance of {\tt PHOTOS} will deteriorate.
646 The first check after installation of {\tt PHOTOS} is whether some energy momentum non
647 conservation appears. Such offending events should be studied
648 before {\tt PHOTOS} and after {\tt PHOTOS} is run to modify them.
649 If it is impossible to understand why inconsistencies for energy momentum non
650 conservation were created by {\tt PHOTOS}, the authors should be contacted. Sometimes
651 monitoring how an event is constructed inside the {\tt FORTRAN} part of the code
652 may be useful. For that purpose the steering of monitoring\footnote{See Appendix \ref{App:Logging}
653 for the command {\tt Log::LogPhlupa(int from, int to)}}
655 available from the C++ part of the code. In practice only rather
656 advanced users will profit from the printouts. However, it may be sent to
657 the authors and help to quickly identify the cause of the problems.
660 The next step in benchmarking relies on comparisons with benchmark distributions.
661 At present, we store these tests with the help of {\tt ROOT} \cite{Antcheva:2009zz} and our {\tt MC-TESTER} program \cite{Davidson:2008ma}.
665 \subsection{{\tt MC-TESTER} Benchmark Files}
669 Over years of development of the {\tt TAUOLA} and {\tt PHOTOS} programs a certain level
670 of the automation of tests was achieved. It was found that monitoring all the invariant mass distributions which can be constructed out of a given decay represent
671 a quite restrictive but easy to implement test.
672 Finding the relative fraction of events for each distinct final state
673 complemented that test and is implemented now in the public version of {\tt MC-TESTER}.
674 We have applied this method
675 for {\tt PHOTOS} too. In this case, some soft final state particles have to be ignored because we are bound to work with samples which otherwise would
676 exhibit properties of unphysical infrared regulators (see Section 6.1 of
677 ref \cite{Davidson:2008ma} for more details). For the most popular
678 decays the benchmarks are collected on our project web page \cite{Photos_tests}.
679 In our distribution, we have collected numerical results in the directory
680 {\tt examples/testing} and its subdirectories:
681 {\tt Htautau, ttbar, Wenu, Wmunu, Zee and Zmumu}. Each of them includes
682 an appropriate initialization files for the particular run of {\tt PYTHIA}. Numerical results from long runs of {\tt MC-TESTER} based tests
683 are stored for reference\footnote{Details on the initialization for the
685 {\tt README-benchfiles}.}. At present, our choice of tests is oriented toward
686 the LHC user and radiative corrections in decay of W's, Z's and Higgs particles.
687 Most of the users of low energy experiments use the {\tt FORTRAN} version
688 of the code, which is why our tests and examples for the C++ version are not geared toward
689 low energy applications.
694 In principle, for the algorithm of photon(s) construction, the C++ interface of
695 {\tt PHOTOS} introduces nothing new with respect to the
696 version of {\tt PHOTOS} as available in {\tt FORTRAN}.
697 That is why the tests which are collected in \cite{Photos_tests} are not
698 recalled here, they were only reproduced and found to be consistent with the ones for
699 old {\tt PHOTOS FORTRAN}.
700 However the algorithm for combining a modified branching, including the added
701 photon(s), to the rest of the event tree was rewritten.
702 Examples of spin dependent observables are of more interest because they test this new part of the code.
703 The $\pi$ energy spectrum in the decaying
704 Z boson rest-frame is the first example.
705 The $\pi^\pm$ originates from $\tau^\pm \to \pi^\pm \nu $ decay and,
706 as was already shown a long time ago \cite{Boillot:1988re}, its energy spectrum is modified by bremsstrahlung both in $\tau$ and $Z$ decays. The net
707 bremsstrahlung effect is similar to the one of e.g. Z polarization. In Fig.~\ref{fig:KKMC} this result is reproduced.
709 Let us now turn to tests using observables which are sensitive to
710 transverse spin effects. For that purpose we study the decay chain:
711 $H\to \tau^+\tau^-$, $\tau^\pm \to \rho^\pm \nu_\tau$, $\rho^\pm \to
712 \pi^\pm \pi^0$, where {\tt PHOTOS} may act on any of the branchings
713 listed above. An inappropriate action of the C++ part of {\tt PHOTOS}
714 could result in faulty kinematics, manifesting itself in a failure of
715 energy-momentum conservation checks of the event record or faulty spin
716 correlation sensitive distributions. However, as we can see from Fig.~\ref{fig:acoplanarity},
717 the distributions (as they should be) remain nearly identical to the ones given in
718 \cite{tauolaC++,Davidson:2010rw}. The emission of soft and/or
719 collinear photons to the $\tau^+$ or $\tau^-$ does not change the
720 effects of spin correlations. The kinematical effects of hard,
721 non collinear photons are responsible for dips in
722 the acoplanarity distributions at $0$, $\pi$ and $2\pi$.
726 \subfigure[bremsstrahlung from $\tau^+ $ decay only]{
727 \includegraphics[scale=0.35]{bremdec.eps}
729 \subfigure[bremsstrahlung from $Z$, $\tau^+ $ and $\tau^- $ decays]{
730 \includegraphics[scale=0.35]{bremall.eps}
732 \caption{ Bremsstrahlung effects for longitudinal spin observables
733 for the cascade decay: $Z \to \tau^+ \tau^-$, $\tau^\pm \to \pi^\pm\nu$.
734 $\pi^+$ energy spectrum in the Z rest-frame is shown. The red line is for
735 bremsstrahlung switched off
736 and green (light grey) when its effect is included.
737 In the left plot, bremsstrahlung is in $\tau^+ $ decay only.
738 In the right plot, bremsstrahlung from $Z$ and $\tau^\pm$ decays is
740 These plots have been prepared using a custom {\tt UserTreeAnalysis} of {\tt MC-TESTER}.
741 They can be recreated with the test located in the {\tt examples/testing/Ztautau} directory, see {\tt examples/testing/README-plots} for technical details. Results are
742 consistent with Fig.~5 of Ref.~\cite{Eberhard:1989ve}.
748 \subfigure[selection C]{
749 \includegraphics[scale=0.35]{coplanarity-angle-C-photon-over-1-GeV.eps}
751 \subfigure[selection D]{
752 \includegraphics[scale=0.35]{coplanarity-angle-D-photon-over-1-GeV.eps}
754 \caption{Bremsstrahlung effects for transverse spin observable:
755 The distribution of the acoplanarity angle of oriented planes spanned respectively on
756 the $\pi^+\rho^+$ and $\pi^-\rho^-$ momenta is shown.
757 The distribution is defined in the rest frame of the
758 $\rho^+ \rho^-$ pair for the scalar Higgs decay chain $H\to
759 \tau^+\tau^-$, $\tau^\pm \to \rho^\pm \nu_\tau$, $\rho^\pm \to
760 \pi^\pm \pi^0$. {\tt PHOTOS} is used to generate
761 bremsstrahlung. The red curve indicates the distribution when
762 bremsstrahlung effects are ignored and for the green curve (light grey)
764 with bremsstrahlung photons of energy larger than 1 GeV
765 in the $H$ rest frame are taken. For the definition of selections C
766 and D see.~\cite{Bower:2002zx,Desch:2003rw}. These plots have been created using
767 a custom {\tt UserTreeAnalysis} of {\tt MC-TESTER}. They can be
768 recreated by the test located in the {\tt
769 examples/testing/Htautau} directory, see {\tt
770 examples/testing/README-plots} for technical details.
771 \label{fig:acoplanarity}
776 In Ref.~\cite{Adam:2008ge} a discussion of the systematic errors for the measurement of the Z cross
777 section at the LHC is presented. One of the technical tests of our software is to obtain
778 Fig. 1b of that paper. In our Fig.~\ref{fig:lineshape} we have
779 reproduced that plot using {\tt PYTHIA 8.1} and {\tt PHOTOS}. Qualitatively, the effect
780 of FSR QED bremsstrahlung is in the two cases quite similar.
783 In Fig.~\ref{fig:lineshape} we present a plot of the bare electron pair
784 (which means electrons are not combined with the collinear photons that accompany them) from $Z$
785 decay with and without {\tt PHOTOS}. It is similar to
786 the plots shown for {\tt Horace} or {\tt Winhac}; see Refs.~\cite{CarloniCalame:2003ux,Winhac} and related
788 One should bear in mind that this is again a technical test with little
789 direct application to physics. As explained in the figure caption, the LHC production process was used.
792 \includegraphics[scale=0.85]{lineshape.eps}
793 \caption{Distribution of the bare $e^+e^-$ invariant mass. The green curve
794 (light grey) represents results when final state
795 bremsstrahlung is generated (with the help of {\tt PHOTOS} Monte Carlo). For the red curve FSR
796 bremsstrahlung is absent. The event sample is generated with the help of {\tt PYTHIA 8.1}.
797 The simulation of pp collisions at 14 TeV center-of-mass energy is performed.
798 The $Z/\gamma$ mediated hard process is used.
799 This plot has been created using a custom {\tt UserTreeAnalysis} of {\tt MC-TESTER}.
800 It can be recreated with the test located in the {\tt examples/testing/Zee} directory, see {\tt examples/testing/README-plots} for technical details.
801 \label{fig:lineshape}
807 We have also checked that {\tt PHOTOS} works for $t \bar t$ events and the simulations explained in \cite{RichterWas:1993ta} can be repeated.
808 For this purpose we have produced $t \bar t$ pairs in $pp$ collisions at
809 14 TeV center-of-mass energy. We have produced rates for events with zero, one or
810 at least two photons of energy above 0.001 of the $t \bar t$ pair mass
811 (energies are calculated in the hard scattering frame).
812 Results are given in the following table which is constructed from
813 $gg \to t \bar t$ events only:
818 { \begin{tabular}{c c}
820 Final state & Branching Ratio (\%) $\pm$ Statistical Errors (\%) \\
822 {$ \widetilde{t} t \; \;\; \;$} & {99.0601 $\pm$ 0.0315} \\
824 {$ \widetilde{t} t \gamma \;\;$} & { 0.9340 $\pm$ 0.0031} \\
826 {$ \widetilde{t} t \gamma \gamma$} & { 0.0060 $\pm$ 0.0002} \\
832 10 million events were generated and a slightly modified
833 version of {\tt MC-TESTER}'s {\tt LC-analysis} from Ref.~\cite{Golonka:2002rz}
834 was used for calculation of the event rates\footnote{ We do not supplement the list of
835 final state particles with the second mother, in contrast to the choice used in {\tt LC-analysis} from Ref.~\cite{Golonka:2002rz}. }.
836 {\tt ROOT} files for differential distributions are
837 collected in the directory {\tt examples/testing/ttbar}.
839 \subsection{Tests Relevant for Physics Precision}
842 Let us now turn to an example of the test for the two photon final state configuration.
843 We compare (i) KKMC \cite{kkcpc:1999} with exponentiation and second order matrix element (CEEX2), (ii) KKMC with exponentiation and first order matrix element (CEEX1)
844 and finally (iii) the results of {\tt PHOTOS} with exponentiation activated. As one can see from the table below, the rates
845 coincide for the three cases up to two permille for the event configurations
846 where zero, one or at least two photons of energy above 1 GeV are accompanying the $\mu^+\mu^-$ pair.
850 \begin{tabular}{lrrr}
852 Decay channel &\multicolumn{3}{c}{ Branching Ratio $\pm$ Rough Errors (100M event samples)} \\
853 & {KKMC CEEX2} (\%) & {KKMC CEEX1} (\%)& {\tt PHOTOS} exp. (\%)\\
855 {$Z^{0} \rightarrow \mu^{+} \mu^{-} $} & {83.9190 $\pm$ 0.0092} &{ 83.7841 $\pm$ 0.0092} & 83.8470 $\pm$ 0.0092\\
857 {$Z^{0} \rightarrow \gamma \mu^{+} \mu^{-} $} & {14.8152 $\pm$ 0.0038} &{ 14.8792 $\pm$ 0.0039} & 14.8589 $\pm$ 0.0039 \\
859 {$Z^{0} \rightarrow \gamma \gamma \mu^{+} \mu^{-} $} & { 1.2658 $\pm$ 0.0011} &{ 1.3367 $\pm$ 0.0012} & 1.2940 $\pm$ 0.0011\\
864 Agreement at this level is not seen in the differential distributions, see Fig.~\ref{fig:gamgam}. For example the spectrum of
865 the two photon mass is quite different between the first and second order
866 exponentiation result. This is of potential interest for background simulations
867 for $H \to \gamma \gamma$. In contrast, the difference between the results from {\tt PHOTOS} and CEEX2 are much smaller. {\tt PHOTOS} exploits the first order matrix element
868 in a better way than exponentiation. As a consequence it reproduces terms resulting in second order leading logarithms. This observation is important not only for
869 the particular case of $Z$ decay but for the general case of double bremsstrahlung in any decay as well.
873 \subfigure[CEEX2: red; CEEX1: green]{
874 \includegraphics[scale=0.35]{{M1@0001.eps}}
876 \subfigure[ CEEX2: red; PHOTOS: green]{\label{plot:b}
877 \includegraphics[scale=0.35]{b-M1@0001.eps}
879 \caption{ The spectrum of the $\gamma \gamma$ invariant mass in $Z \to \mu^+\mu^-$
880 decay. Events with two hard photons, both of energy above 1 GeV in the $Z$ rest
881 frame are taken. Comparisons are shown for CEEX2 and CEEX1 (left plot), and CEEX2 and {\tt PHOTOS}
882 (right plot). The prediction from {\tt PHOTOS} is clearly superior for applications aimed at
883 the simulation of Higgs boson backgrounds. In the case of solutions based on YFS
884 exponentiation, the second order matrix element must be taken into account. Fig.~\ref{plot:b} was obtained
885 from our example, {\tt examples/testing/Zmumu}, after adaptation of the center-of-mass energy
887 energy threshold (1 GeV). Samples of 100 million events were used.
888 See {\tt examples/testing/README-plots} for technical details. Reference
889 {\tt ROOT} files for KKMC CEEX samples are, however, created outside of the distribution.
895 The numerical results collected here provide part of the program benchmarks.
896 They are of limited but nonetheless of some physics interest as well.
897 {\tt PHOTOS} provides only one step in the simulation chain:
898 bremsstrahlung in decays or final state bremsstrahlung. One can ask
899 the question of whether such a specialized unit is of interest and whether it is not better
900 to provide the complete chain for ``truth physics simulation'' as a single simulation package. Obviously, this will
901 depend on particular needs. Final state QED corrections can be
902 separated from the remaining genuine electroweak corrections and
903 in particular the initial state QED bremsstrahlung from quarks.
904 One should bear in mind, that final state bremsstrahlung
905 needs to be disentangled from detector acceptance dependencies and is not of
906 interest in itself. This must be done e.g. to measure the properties of weak bosons.
908 One should bear in mind that even for QED FSR alone, the discussion of the physics
909 precision of the simulation result requires further checks. In the case of
910 $Z$ decays, Refs.~\cite{Golonka:2005pn,Golonka:2006tw} may not be enough.
911 With increasing precision, the estimation of uncertainty becomes dependent on
912 the particular choice of details for the experimental cuts. Comparisons of different
913 calculations become important too. A good example of such work in the conext of
914 other measurements can be found in Refs.~\cite{Jadach:1995pd,Arbuzov:1996eq};
915 for the simulation of
916 FSR QED corrections, the Monte Carlo programs collected for {\tt PHOTOS} generator
917 tests are probably enough.
918 A discussion of QED initial final state interference may follow the strategy presented
919 in \cite{Jadach:1999gz}. There, the question of experimental cuts must be included
920 as well. Once these steps are completed, discussion
921 of complete electroweak corrections in the context of realistic observables should
926 Genuine weak corrections have to be taken into account separately.
927 Such solutions may be possible, if together with the {\tt PHOTOS Interface},
928 weak corrections are provided for example with the help of the {\tt TAUOLA Interface}.
930 of the complete electroweak corrections, as shown in Fig. 1a of \cite{Adam:2008ge},
931 is not the purpose of our document. Let us point out however that electroweak
932 non-QED corrections can be in principle installed into the {\tt PYTHIA 8.1} + {\tt PHOTOS} simulation with
933 the help of the e.g. {\tt TAUOLA} interface \cite{Davidson:2010rw}.
934 But for such a solution to be precise, further work is needed \cite{Bardin-private}.
936 Sizeable initial state QED corrections are usually embodied in units
937 simulating parton showers. This may need some experimental analysis as well.
938 Recently experimental data from LEP1 times were revisited by the DELPHI collaboration \cite{Abdallah:2010tk}.
939 Tension between data and the theoretical description is
940 mentioned. This may mean that the description of initial state QED bremsstrahlung
941 at the LHC will need to be re-investigated with the help of LHC data as well.
942 That is also why it might be useful to keep initial state QED, final state QED and their interference corrections in separate modules.
944 We leave such estimations of the theoretical uncertainty for $Z$ and $W$
945 production at the LHC
946 to the forthcoming research, where a realistic choice of experimental conditions and
948 will become an integrated part. \vskip -2 mm
950 \section{Summary and outlook}
952 We have presented a new version of {\tt PHOTOS} Monte Carlo. The part of
953 {\tt PHOTOS} which operates on
954 event records is now rewritten into C++ and uses the HepMC event record
955 format for input and output. The physics performance of the program is the
956 same as that of the {\tt FORTRAN/HEPEVT} version, but better steering options are introduced.
957 Also, when an elementary decay is to be modified by {\tt PHOTOS},
958 it is first transformed to its rest frame. The $z$-axis is orientated along the decaying particle's mother's direction, as seen in this rest frame. Such modification is
959 necessary to calculate process dependent kernels
960 featuring the complete first order matrix element. If the interest will arise,
961 the appropriate kernels explained in
962 Refs.~\cite{Golonka:2006tw,Nanava:2006vv,Nanava:2009vg} can be installed
963 into the C++ version of {\tt PHOTOS}. The necessary information is extracted
964 from the event record and can be used.
965 At present some parts of the algorithm are left in {\tt FORTRAN}.
966 This remaining {\tt FORTRAN} part of the code
967 can be recoded to C++ rather easily, but the necessary numerical tests
968 are time consuming. That is why we have left these changes for later
971 {Finally let us point to ref.~\cite{Arbuzov:2012dx}. Thanks to this work, for LHC applications in $Z$, $W$ decays,
972 {\tt PHOTOS} Monte Carlo systematic error was established at 0.3\%, even 0.2\% for the case of matrix element correction activated. The estimation is valid
973 for complete final state radiative corrections, not for photonic bremsstrahlung
979 \centerline{\large\bf Acknowledgements}
982 Useful discussions with P. Golonka during the early stage of project development and discussions
983 with members of the ATLAS and CMS collaborations and the LCG/Genser team
985 %We are especially indebted to the pilot users of the interface.
990 Partial support by the Polish-French collaboration
991 no. 10-138 within IN2P3 through LAPP Annecy and
992 during the final completion of this work is
997 \bibliography{Photos_interface_design}{}
998 % \bibliographystyle{plain}
999 \bibliographystyle{utphys_spires}
1005 %------------------------------------------------------------------------------
1009 \section{Appendix: Interface to {\tt PHOTOS FORTRAN}}
1010 \label{Interface to PHOTOS}
1013 This appendix is addressed to developers of the interface,
1014 and special users interested in advanced options of {\tt PHOTOS}.
1015 The discussed below {\tt COMMON} blocks of {\tt FORTRAN} were used in the
1016 program up to version 3.53 only.
1017 Starting from version 3.54 some of these {\tt COMMON} blocks were preserved,
1018 as the struct objects of C. The following ones may be of some interest for the
1020 {\tt PHOCOP, PHOKEY, PHOSTA, PHLUPY}.
1022 Names of variables and structs are not modified with respect to {\tt FORTRAN},
1023 the C++ definition style is adapted, small letters are used and underscore is added at the
1024 end of structs names.
1025 Common {\tt HEPEVT} is preserved for use of example and future applications,
1026 where the main program is in {\tt FORTRAN}.
1027 The interface is available
1028 through the classes {\tt PhotosHEPEVTEvent.h} and {\tt PhotosHEPEVTParticle.h}.
1029 Internally in C++ {\tt Photos} code, the {\tt HEPEVT}-like data type
1032 \subsection{Common Blocks}
1034 In the following let us list the common blocks of {\tt PHOTOS} which are accessed
1038 \item[PHOCOP] coupling constant and related parameters.
1040 \item[ALPHA] \textit{double} coupling constant $\alpha_{QED}$.
1041 \item[XPHCUT] \textit{double} minimal energy (in units of half of the decaying particle's mass) for photons to be explicitly generated.
1046 \item[PHOKEY] keys and parameters controlling the algorithm options.
1048 \item[FSEC] \textit{double} internal variable for algorithm options, the default is FSEC=1.0\; .
1049 \item[FINT] \textit{double} maximum interference weight.
1050 \item[EXPEPS] \textit{double} technical parameter, blocks crude level high photon multiplicity from configurations less probable than EXPEPS, the default is $10^{-4}$.
1051 \item[INTERF] \textit{bool} key for interference, the matrix element weight.
1052 \item[ISEC] \textit{bool} switch for double bremsstrahlung generation.
1053 \item[ITRE] \textit{bool} switch for bremsstrahlung generation up to a multiplicity of 4.
1054 \item[IEXP] \textit{bool} switch for exponentiation mode.
1055 \item[IFTOP] \textit{bool} switch for photon emission in top pair production in quark (gluon) pair annihilation.
1056 \item[IFW] \textit{bool} switch for leading effects of matrix element in leptonic W decays.
1061 \item[PHLUPY] debug messages handling.
1063 \item[IPOIN] \textit{int} messages above this value will not be displayed.
1064 \item[IPOINM] \textit{int} messages below this value will not be displayed.
1069 \item[PH\_PHOQED] supplement for the PH\_HEPEVT event record to block emission
1070 from some particles.
1072 \item[QEDRAD[ 10000]] \textit{bool} flag enabling a {\tt FORTRAN} users
1073 to block emission from particles stored in PH\_HEPEVT. Not used in
1079 \item[PHOSTA] Status information.
1081 \item[STATUS[ 10]] \textit{int} Status codes for the last 10 errors/warnings
1087 \item[PHPICO] $\pi$ value definition.
1089 \item[PI] \textit{double} $\pi$.
1090 \item[TWOPI] \textit{double} $2*\pi$.
1094 \subsection{Routines}
1096 In the following let us list routines which are called from the interface.
1099 \item[PHODMP] prints out the content of HEPEVT. \\
1100 Return type: \textit{void} \\
1105 \item[PHOTOS\_MAKE] {\tt FORTRAN} part of interface. \\
1106 Return type: \textit{void} \\
1109 \item \textit {int id} ID of particle from which {\tt PHOTOS} starts processing. In the C++ case the importance of this parameter is limited as only one branch is in HEPEVT at a time.
1114 \item[PHCORK] initializes kinematic corrections. \\
1115 Return type: \textit{void} \\
1118 \item \textit {int modcor} type of correction. See Ref.~\cite{Golonka:2005pn} for details.
1124 \item[IPHQRK] enables/blocks (2/1) emission from quarks. \\
1125 Return type: \textit{int} \\
1126 Parameters: \textit{int}
1130 \item[IPHEKL] enables/blocks (2/1) emission in: $\pi^0 \rightarrow \gamma e^+ e^-$. \\
1131 Return type: \textit{int} \\
1132 Parameters: \textit{int}
1135 \section{Appendix: User Guide}
1136 \label{sec:User Guide}
1138 \subsection{Installation}
1139 \label{sec:Installation}
1141 {\tt Photos C++ Interface} is distributed in a form of an archive containing source files and examples.
1142 Currently only the Linux and Mac OS\footnote{For this case LCG configuration
1143 scripts explained in Appendix \ref{sec:autotools} have to be used.} operating systems are supported: other systems may be
1144 supported in the future if sufficient interest is found.
1146 The main interface library uses {\tt HepMC} \cite{Dobbs:2001ck} (version 2.03 or later) and requires that either
1147 its location has been provided or option of compilation without {\tt HepMC} has been chosen during the configuration step. This is sufficient to compile the interface and to run the simple, stand-alone example.
1149 However, in order to run the more advanced examples located in the {\tt /examples} directory, {\tt HepMC} is required. It is also required to install:
1152 \item {\tt ROOT} \cite{root-install-www} version 5.18 or later
1153 \item {\tt PYTHIA 8.1} \cite{Sjostrand:2007gs} or later. {\tt PYTHIA 8.1} must be compiled with {\tt HepMC} 2.xx
1154 so that the {\tt PYTHIA} library {\tt hepmcinterface} exists.
1155 \item {\tt MC-TESTER} \cite{Golonka:2002rz,Davidson:2008ma} version 1.24 or later.
1156 Do not forget to type {\tt make libHepMCEvent} after compilation of {\tt MC-TESTER} is done.
1157 \item {\tt TAUOLA} \cite{Davidson:2010rw} version 1.0.5 or later. {\tt TAUOLA} must be compiled with {\tt HepMC}.
1160 In order to compile the {\tt PHOTOS} C++ Interface:
1162 \item Execute {\tt ./configure} with the additional command line options:
1163 \subitem {\tt --with-hepmc=$<$path$>$} provides the path to the {\tt HepMC} installation directory. One can also set the {\tt HEPMCLOCATION} variable instead of using this directive. To compile the interface without {\tt HepMC} use {\tt --without-hepmc}
1164 \subitem {\tt --prefix=$<$path$>$} provides the installation path. The {\tt include} and {\tt lib} directories will be copied there if {\tt make install} is executed later. If none has been provided, the default directory for installation is {\tt /usr/local}.
1165 \item Execute {\tt make}
1166 \item Optionally, execute {\tt make install} to copy files to the directory provided during configuration.
1169 The {\tt PHOTOS} C++ interface will be compiled and the {\tt /lib} and {\tt /include} directories will contain the appropriate libraries and include files.
1171 In order to compile the examples, compile the {\tt PHOTOS} C++ interface, enter the {\tt /examples} directory and:
1173 \item Execute {\tt ./configure} to determine which examples can be compiled.
1174 Additional paths can be provided as command line options:
1175 \subitem {\tt --with-pythia8=$<$path$>$} provides the path to the {\tt Pythia8} installation
1176 directory. One can set the {\tt PYTHIALOCATION} variable instead of using this directive.
1177 This path is required for all examples and tests.
1178 \subitem {\tt --with-mc-tester=$<$path$>$} provides the path to the {\tt MC-TESTER} installation
1179 directory (the {\tt libHepMCEvent} must be compiled as well, see Ref.~\cite{Davidson:2008ma}
1180 for more details). One can set the {\tt MCTESTERLOCATION} variable instead of using this
1181 directive. This path is required for all additional examples and tests. This option
1182 implies that {\tt ROOT} has already been installed (since it is required by {\tt MC-TESTER}).
1183 The {\tt ROOT} directory {\tt bin} should be listed in the variable {\tt PATH} and the {\tt ROOT}
1184 libraries in {\tt LD\_LIBRARY\_PATH}.
1185 \subitem {\tt --with-tauola=$<$path$>$} provides the path to the {\tt TAUOLA} installation directory.
1186 One can set the {\tt TAUOLALOCATION} variable instead of using this directive.
1187 This path is required for additional examples only.
1188 \item Execute {\tt make}
1191 If neither {\tt HepMC}, {\tt Pythia8} nor {\tt MC-TESTER} are accessible, the most basic
1192 example will be nonetheless provided. The {\tt /examples} directory will
1193 contain the executable files for all examples which can be compiled and
1196 On {\tt CERN} platforms, ready to use software is located in the {\tt /afs/cern.ch/sw/lcg/}
1197 directory. To set the appropriate paths, the scripts
1198 {\tt platform/afs.paths.sh} and {\tt platform/afs.paths.csh} are prepared and should be executed before
1199 {\tt ./configure}. For details see {\tt README} in the {\tt PHOTOS} main directory.
1201 \subsection{ LCG configuration scripts; available from version 3.1 }
1202 \label{sec:autotools}
1204 For our project still another configuration/automake system was
1205 prepared for use in LCG/Genser project\footnote{We have used the expertise and advice
1206 of Dmitri Konstantinov and Oleg Zenin in organization of configuration scripts
1207 for our whole distribution tar-ball as well. Thanks to this choice, we hope, our solution
1208 will be compatible with the ones in general use.} \cite{LCG,Kirsanov:2008zz}.
1210 For the purpose of activation of this set of autotools\cite{autotools}-based installation scripts
1211 enter {\tt platform} directory and execute there {\tt use-LCG-config.sh} script.
1212 Then, installation procedure and the names of the configuration script parameters will differ from the one
1213 described in our paper. Instruction given in './INSTALL' readme file created by {\tt use-LCG-config.sh} script
1214 should be followed. One can also execute {\tt ./configure --help}, it will
1215 list all options available for the configuration script.
1217 A short information on these scripts can be found in {\tt README} of main directory as well.
1219 \subsection{Elementary Tests}
1222 The most basic test which should be performed, for our custom examples but also for a user's own generation chain,
1223 is verification that the interface is installed correctly,
1224 photons are indeed added by the program and that energy momentum
1225 conservation is preserved\footnote{
1226 We have performed such tests for all choices of the {\tt HepMC} event record obtained
1227 from {\tt PYTHIA 8.1} and {\tt PYTHIA 8.135} processes and
1228 listed in the paper. Further options for initializations
1229 (parton shower hadronization or QED bremsstrahlung on/off etc.) were also studied.
1230 This was a necessary step in our program development.}.
1232 In principle, these tests have to be performed for any new hard
1233 process and after any new installation. This is to ensure that
1234 information is passed from the event record to the interface
1235 correctly and that physics information is filled into {\tt HepMC}
1236 in the expected manner. Misinterpretation of the event record content may result in
1237 faulty {\tt PHOTOS} operation.
1240 \subsection{Executing Examples}
1242 Once elementary tests are completed one can turn to the more advanced ones.
1243 The purpose is not only to validate the installation but to demonstrate the
1246 The examples can be run by executing the appropriate {\tt .exe} file in the {\tt /examples} directory.
1247 In order to run some more specific tests for the following processes:
1248 $H \rightarrow \tau^+ \tau^-$, $ e^+ e^- \rightarrow t \bar t$,
1249 $W \rightarrow e \nu_e$, $W \rightarrow \mu \nu_\mu$,
1250 $Z \rightarrow e^+ e^-$, $Z \rightarrow \mu \mu$ or $Z \rightarrow \tau^+ \tau^-$,
1251 $K_{0}^{S} \rightarrow \pi \pi$,
1252 the main programs residing in the subdirectories of {\tt /examples/testing} should be executed.
1253 In all cases the following actions have to be performed:
1256 \item Compile the {\tt PHOTOS } C++ Interface.
1257 \item Check that the appropriate system variables are set. Execution of the script \\
1258 {\tt /configure.paths.sh} usually can perform this task; the configuration step
1259 announces this script.
1260 \item Enter the {\tt /examples/testing} directory. Execute {\tt make}. Modify test.inc if needed.
1261 \item Enter the sub-directory for the particular process of interest
1262 and execute {\tt make}.
1265 The appropriate {\tt .root} files as well as {\tt .pdf} files generated by {\tt MC-TESTER}
1266 will be created inside the chosen directory. One can execute 'make clobber' to
1267 clean the directory. One can also execute 'make run' inside the {\tt /examples/testing}
1268 directory to run all available tests one after another. Changes in source
1269 code can be partly validated in this way.
1270 Most of the tests are run using the executable {\tt examples/testing/photos\_test.exe}. The
1271 $K_{0}^{S} \rightarrow \pi \pi$, $H \rightarrow \tau^+ \tau^-$ and $Z \rightarrow \tau^+ \tau^-$ examples
1273 {\tt examples/testing/photos\_tauola\_test.exe} to be run.
1274 After generation, {\tt MC-TESTER} booklets will be produced,
1275 comparisons to the benchmark files will be shown.
1276 A set of benchmark {\tt MC-TESTER} root files have been included with the interface
1277 distribution. They are located in the subdirectories of {\tt examples/testing/}.
1278 Note that for the $W \rightarrow e \nu_e$,
1279 $W \rightarrow \mu \nu_\mu$ and $Z \rightarrow \mu \mu$
1280 examples, differences higher than statistical error will show.
1281 This is because photon symmetrization
1282 was used in the benchmark files generated with {\tt KKMC}, and not in the ones
1283 generated with {\tt PHOTOS}.
1284 In the case of {\tt KKMC} the generated photons are strictly ordered in energy.
1285 In the case of {\tt PHOTOS} they are not. Nonetheless, on average,
1286 the second photon has a smaller energy than the one written as the first
1287 in the event record.
1290 The comparison booklets can be useful
1291 to start new work or simply to
1292 validate new versions or new installations of the {\tt PHOTOS} interface.
1294 In Appendix \ref{sec:User Configuration}, possible modifications to the
1295 example's settings are discussed. This may be interesting as an initial step for user's
1296 physics studies. The numerical results of some of these tests are collected in Section \ref{sec:results}
1297 and can be thus reproduced by the user.
1299 \subsection{How to Run {\tt PHOTOS} with Other Generators}
1300 If a user is building a large simulation system she or he may want to avoid
1301 integrating into it our configuration infrastructure and load the libraries only.
1302 For that purpose our stand-alone
1303 example {\bf examples/photos\_standalone\_example.exe} is a good starting point.
1305 In order to link the libraries to the user's project, both the static libraries and shared objects are
1306 constructed. To use the {\tt PHOTOS} interface in an external project, additional
1307 compilation directives are required. For the static libraries:
1309 \item add {\tt -I<PhotosLocation>/include} at the compilation step,
1310 \item add {\tt <PhotosLocation>/lib/libPhotosCxxInterface.a <PhotosLocation>/lib/libPhotosFortran.a} at the linking step of your project.
1312 For the shared objects:
1314 \item add {\tt -I<PhotosLocation>/include} at the compilation step,
1315 \item add {\tt -L<PhotosLocation>/lib} along with {\tt -lPhotosCxxInterface -lPhotosFortran} at the linking step.
1316 \item {\tt PHOTOS} libraries must be provided for the executable; e.g. with the help of {\tt LD\_LIBRARY\_PATH}.
1318 {\tt <PhotosLocation>} denotes the path to the {\tt PHOTOS} installation directory.
1319 In most cases it should be enough to include within a users's program {\tt Photos.h} and {\tt PhotosHepMCEvent.h} (or any other header file for the class implementing abstract class {\tt PhotosEvent})
1320 With that, {\tt Photos} class can be used for configuration and {\tt PhotosHepMCEvent}
1321 for event processing.
1323 \subsubsection{Running {\tt PHOTOS C++ Interface} in {\tt FORTRAN} environment}
1325 For backward-compatibility with {\tt HEPEVT} event record, an interface has been prepared
1326 allowing {\tt PHOTOS C++ Interface} to be invoked from the {\tt FORTRAN} project. An example
1327 {\tt photos\_hepevt\_example.f} has been prepared to demonstrate how {\tt PHOTOS} can be
1328 initialized and executed from {\tt FORTRAN} code. Since {\tt PHOTOS} works in C++ environment,
1329 {\tt photos\_hepevt\_example\_interface.cxx} must be introduced to invoke {\tt PHOTOS}.
1331 Since version 3.54 {\tt PHOTOS} is fully in C++ and initialization can no longer
1332 be performed from {\tt FORTRAN} code through the use of common blocks.
1334 \section{Appendix: User Configuration}
1335 \label{sec:User Configuration}
1337 \subsection{Suppress Bremsstrahlung}
1338 \label{section:suppress}
1340 In general, {\tt PHOTOS} will attempt to generate bremsstrahlung for every
1341 branching point in the event record. This is of course not always appropriate.
1342 Already inside the {\tt FORTRAN} part of the new {\tt PHOTOS}, bremsstrahlung is prevented for vertices involving gluons or quarks
1343 (with the exception of top quarks).
1345 This alone is insufficient. By default we suppress bremsstrahlung
1346 generation for vertices like $l^\pm \to l^\pm \gamma$ because a
1347 ``self-decay'' is unphysical. We cannot request that all incoming
1348 and/or outgoing lines are on mass shell, because it is not the case in
1349 cascade decays featuring intermediate states of sizeable width. If a
1350 parton shower features a vertex with $l^\pm \to l^\pm \gamma$ with the
1351 virtuality of the incoming $l^\pm$ matching the invariant mass of the
1352 outgoing pair then the action of {\tt PHOTOS} at this vertex will
1353 introduce an error. This is prevented by forbidding bremsstrahlung
1354 generation at vertices where one of the decay products has a flavor
1355 which matches the flavor of an incoming particle.
1358 Some exceptions to the default behavior may be necessary. For example
1359 in cascade decays, the vertex $\rho \to \rho \pi$ may require the
1360 {\tt PHOTOS} algorithm to be activated.
1362 Methods to re-enable these previously prevented cases or to prevent generation in special
1363 branches have been introduced and are presented below. \\ \\
1366 For the user's convenience the following configuration methods are provided:
1368 \item {\tt Photos::suppressBremForDecay(daughterCount, motherID, d1ID, d2ID, ...)} \hfill \\
1369 The basic method of channel suppression. The number of daughters,
1370 PDGID of the mother and the list of PDGIDs of daughters must be provided.
1371 There is no upper limit to the number of daughters.
1372 If a decay with the matching pattern is found, {\tt PHOTOS} will skip the decay.
1373 \item {\tt Photos::suppressBremForDecay(0, motherID)} \hfill \\
1374 When only the PDGID of the mother is provided, {\tt PHOTOS} will skip all decay channels
1375 of this particle. Note that the number of daughters is to be provided,
1376 but set for this case to zero.
1377 \item {\tt Photos::suppressBremForBranch(daughterCount, motherID, d1ID, d2ID, ...)} \hfill \\
1378 {\tt Photos::suppressBremForBranch(0, motherID)} \hfill \\
1379 The usage of these methods is similar to the previous functions. The difference is
1380 that {\tt PHOTOS} will skip not only the corresponding channel,
1381 but also all consecutive decays of its daughters, making {\tt PHOTOS} skip the entire branch
1382 of decays instead of just one.
1383 \item {\tt Photos::suppressAll() }
1384 All branchings will be suppressed except those that are forced using the methods
1385 described in the next section.
1386 \item \textbf{Example:} \hfill \\
1387 {\tt Photos::suppressBremForDecay(3, 15, 16, 11, -12); } \\
1388 {\tt Photos::suppressBremForDecay(2, -15, -16, 211); } \\
1389 {\tt Photos::suppressBremForDecay(0, 111); } \\
1390 \emph{If the decays $\tau^- \rightarrow \nu_\tau e^- \bar \nu_e$ or
1391 $\tau^+ \rightarrow \bar \nu_\tau \pi^+$ are found, they will be skipped by {\tt PHOTOS}.
1392 In addition, all decays of $\pi^0$ will also be skipped. Note, that the minimum
1393 number of parameters that must be provided is two - the number of daughters
1394 (which should be zero if suppression for all decay channels of the particle is chosen)
1395 and the mother PDGID.} \\ \\
1396 {\tt Photos::suppressBremForBranch(2, 15, 16, -213); } \\
1397 \emph{When the decay $\tau^- \rightarrow \nu_\tau \rho^-$ is found, it will be skipped by
1398 {\tt PHOTOS} along with the decays of $\rho^-$
1399 (in principle also $\nu_\tau$) and all
1400 their daughters. In the end, the whole decay tree starting with
1401 $\tau^- \rightarrow \nu_\tau \rho^-$ will be skipped.}
1404 In future, an option to suppress a combination of consecutive branches may be introduced.
1405 For example if bremsstrahlung in leptonic $\tau$ decays is generated by
1406 programs prior to {\tt PHOTOS}, and the decay is stored in HepMC as the cascade
1407 $\tau^\pm \to W^\pm \nu$, $W^\pm \to l^\pm \nu$, {\tt PHOTOS} must
1408 be prevented from acting on both vertices, but only in cases when they are present one after another.
1409 One can also think of another {\tt PHOTOS} extension for the following type of special case: if a vertex $q
1410 \bar q \to l^\pm l^\mp$ is found then it should not be ignored but
1411 passed for generation as $q \bar q \to Z \to l^\pm l^\mp$ where
1412 the intermediate Z is created internally for {\tt PHOTOS}.
1414 \subsection{Force {\tt PHOTOS} Processing }
1415 \label{section:force}
1417 Forcing {\tt PHOTOS} to process a branch can be used in combination with
1418 the suppression of all branches i.e. to allow selection of only a particular
1419 processes for bremsstrahlung generation.
1421 Forced processing using the methods below has higher priority than the suppression described
1422 in the previous section, therefore even if both forcing and suppressing of the same
1423 branch or decay is done (regardless of order), the processing will not be
1428 \item {\tt Photos::forceBremForDecay(daughterCount, motherID, d1ID, d2ID, ...)} \hfill \\
1429 {\tt Photos::forceBremForDecay(0, motherID)} \hfill \\
1430 The usage of this routine is similar to {\tt Photos::suppressBremForDecay(...)}
1431 described in the previous section. If a decay with the matching pattern is found,
1432 {\tt PHOTOS} will be forced to process the corresponding decay, even if it was suppressed
1433 by any of the methods mentioned in the previous section.
1434 \item {\tt Photos::forceBremForBranch(daughterCount, motherID, d1ID, d2ID, ...)} \hfill \\
1435 {\tt Photos::forceBremForBranch(0, motherID)} \hfill \\
1436 The usage is similar to the above functions. The difference is
1437 that {\tt PHOTOS} will force not only the corresponding channel,
1438 but also all consecutive decays of its daughters, making {\tt PHOTOS} process the entire branch
1439 of decays instead of just one.
1440 \item \textbf{Example:} \hfill \\
1441 {\tt Photos::suppressAll(); } \\
1442 {\tt Photos::forceBremForDecay(4, 15, 16, -211, -211, 211); } \\
1443 {\tt Photos::forceBremForDecay(2, -15, -16, 211); } \\
1444 {\tt Photos::forceBremForBranch(0, 111); } \\
1445 \emph{Since suppression of all processes is used, only the listed decays will be processed,
1446 these are $\tau^- \rightarrow \nu_\tau \pi^- \pi^- \pi^+$, $\tau^+ \rightarrow \bar \nu_\tau \pi^+$
1447 and all instances of the decay of $\pi^0$ and its descendants.}
1450 \subsection{Use of the {\tt processParticle} and {\tt processBranch} Methods}
1453 In Section~\ref{sect:Outline} the algorithm for processing a whole
1454 event record is explained and is provided through the {\tt process()}
1455 method. To process a single branch in the event record, in a way
1456 independent of the entire event, a separate method is provided.
1459 \item {\tt Photos::processParticle(PhotosParticle *p) } \hfill \\
1460 The main method for processing a single particle. A pointer to a particle must
1461 be provided. Pointers to mothers and daughters of this particle should be
1462 accessible through this particle or its event record.
1463 From this particle a branch containing its mothers and daughters
1464 will be created and processed by {\tt PHOTOS}.
1465 \item {\tt Photos::processBranch(PhotosParticle *p) } \hfill \\
1466 Usage is similar to the above function. When a pointer to a particle is provided,
1467 {\tt PHOTOS} will process the whole decay branch starting from the particle provided.
1470 An example, {\tt single\_photos\_gun\_example.c}, is provided in the directory {\tt /examples}
1471 showing how this functionality can be used to process the decay of selected particles.
1472 $Z^0 \rightarrow \tau^+ \tau^-$ decays are generated and the event record is traversed
1473 searching for the first $\tau^-$ particle in the event record.
1474 Instead of processing the whole event, only the decay of $\tau^-$ is processed by {\tt PHOTOS}.
1477 \subsection{Logging and Debugging}
1479 This section describes the basic functionality of the logging and debugging tool.
1480 For details on its content we address the reader to comments in the {\tt /src/utilities/Log.h} header file.
1482 Let us present however some general scheme of the tool's
1483 functionality. The {\tt PHOTOS} interface allows control over the
1484 amount of message data displayed during program execution and
1485 provides a basic tool for memory leak tracking. The following
1486 functions can be used from within the user's program after including the
1489 \item {\tt Log::Summary() } - Displays a summary of all messages.
1490 \item {\tt Log::SummaryAtExit() } - Displays the summary at the end of a program run.
1491 \item {\tt Log::LogInfo(bool flag) } \\
1492 {\tt Log::LogWarning(bool flag) } \\
1493 {\tt Log::LogError(bool flag) } \\
1494 {\tt Log::LogDebug(int s, int e) } \\
1495 {\tt Log::LogAll(bool flag)} \\
1496 Turns the logging of \textit{info}, \textit{warning}, \textit{error} and \textit{debug} messages on or off depending
1497 on the flag value being true or false respectively. In the case of \textit{debug} messages - the range of message codes
1498 to be displayed must be provided. By default, only \textit{debug} messages
1499 (from 0 to 65535) are turned off. If the range is negative ($s>e$) \textit{debug} messages
1500 won't be displayed. The last method turns displaying all of the above messages on and off.
1501 \item {\tt Log::LogPhlupa(int from, int to) } \\
1502 Turns logging of debug messages from the {\tt FORTRAN} part of the program on and off.
1503 Parameters of this routine specify the range of debug codes for the {\tt phlupa\_} routine.
1506 At present only the following debug messages can be printed:
1508 \item Debug(0) - seed used by the random number generator
1509 \item Debug(1) - which type of branching was found in {\tt HepMC}
1510 (regular or a case without an intermediate particle, for details see {\tt PhotosBranch.cxx})
1511 \item Debug(700) - execution of the branching filter has started
1512 \item Debug(701) - branching is forced
1513 \item Debug(702) - branching is suppressed
1514 \item Debug(703) - branching is processed (i.e. passed to the filter)
1515 \item Debug(2) - execution of the branching filter was completed
1516 \item Debug(1000) - the number of particles sent to and retrieved from {\tt PHOTOS FORTRAN}
1519 The option {\tt Log::SetWarningLimit(int limit)} results in
1520 only the first {\tt `limit'} warnings being displayed. The default for {\tt limit} is 100.
1521 If {\tt limit}=0 is set, then there are no limits on the number of warnings to be displayed.
1523 The memory leak tracking function allows checking of whether all memory allocated within {\tt PHOTOS Interface}
1524 is properly released. However, using the debug option significantly increases the amount of time needed for
1525 each run. Its use is therefore recommended for debugging purposes only. In order to use this option
1526 modify {\tt make.inc} in the main directory by adding the line: \\
1527 {\tt DEBUG = -D"\_LOG\_DEBUG\_MODE\_" } \\
1528 Recompile the interface.
1529 Now, whenever the program is executed a table will be printed at the end of the run,
1530 listing all the pointers that were not freed, along with the memory they consumed.
1531 If the interface works correctly without any memory leaks, one should get an empty table.
1533 It is possible to utilize this tool within a user's program; however there are a few limitations.
1534 The debugging macro from "Log.h" can create compilation errors if one compiles
1535 it along with software which has its own memory management system (e.g. {\tt ROOT}).
1536 To make the macro work within a user's program, ensure that {\tt Log.h} is the last header file
1537 included in the main program.
1538 It is enough to compile the program with the {\tt -D"\_LOG\_DEBUG\_MODE\_"} directive added,
1539 or {\tt \#define \_LOG\_DEBUG\_MODE\_} placed within the program before inclusion of
1540 the {\tt Log.h} file%
1541 \footnote{Note that {\tt Log.h} does not need to be included within
1542 the user's program for the memory leak tracking tool to be used only for the {\tt PHOTOS} interface.
1545 \subsection{Other User Configuration Methods}
1546 \label{subsection:other_methods}
1548 The following auxiliary methods are prepared. They are useful for initialization
1549 or are introduced for backward compatibility.
1552 \item {\tt Photos::setRandomGenerator(double (*gen)()) } {\it installed in {\tt PHOTOS 3.52}}\\
1553 Replace random number generator used by {\tt Photos}.
1554 The user provided generator must return a {\tt double} between 0 and 1.
1555 {\tt Photos::setRandomGenerator(NULL)} will reset the program back to
1556 the default generator, which is a copy of {\tt RANMAR}\cite{James:1988vf,marsaglia:1987}.
1557 \item {\tt Photos::setSeed(int iseed1, int iseed2)} \\
1558 Set the seed values for our copy of the random number generator {\tt RANMAR} \cite{James:1988vf,marsaglia:1987}.
1559 \item {\tt Photos::maxWtInterference(double interference)} \\
1560 Set the maximum interference weight. The default 2 is adopted to decays where at most two charged decay products
1561 are present\footnote{For
1562 the decays like $J/\psi \to 5\pi^+ 5\pi^-$ higher value, at least equal to the number of charged decay
1563 products, should be set. The algorithm performance will slow down linearly with the maximum interference weight but all
1564 simulation results will remain unchanged.
1566 \item {\tt Photos::setInfraredCutOff(double cut\_off)} \\
1567 Set the minimal energy (in units of decaying particle mass)
1568 for photons to be explicitly generated.
1569 \item {\tt Photos::setAlphaQED(double alpha)} \\
1570 Set the coupling constant, alpha QED.
1571 \item {\tt Photos::setInterference(bool interference)} \\
1572 A switch for interference, matrix element weight.
1573 \item {\tt Photos::setDoubleBrem(bool doub)} \\
1574 Set double bremsstrahlung generation.
1575 \item {\tt Photos::setQuatroBrem(bool quatroBrem)} \\
1576 Set bremsstrahlung generation up to a multiplicity of 4.
1577 \item {\tt Photos::setExponentiation(bool expo)} \\
1578 Set the exponentiation mode.
1579 \item {\tt Photos::setCorrectionWtForW(bool corr)} \\
1580 A switch for leading effects of the matrix element (in leptonic W decays)
1581 \item {\tt Photos::setMeCorrectionWtForScalar(bool corr)} \\
1582 A switch for complete effects of the matrix element (in scalar to 2 scalar decays) {\it installed in {\tt PHOTOS 3.3}. At present tests are missing. }
1583 \item {\tt Photos::setMeCorrectionWtForW(bool corr)} \\
1584 A switch for complete effects of the matrix element (in leptonic W decays) {\it installed in {\tt PHOTOS 3.2} }
1585 Because of lack of reinitialization in a particular decay channel this option can be used for the fixed
1586 decay channel, and either for W+ or for W-, also for fixed (not strongly varying) wirtuality.
1587 This option will be elaborated further.
1588 \item {\tt Photos::setMeCorrectionWtForZ(bool corr)} \\
1589 A switch for complete effects of the matrix element (in leptonic Z decays) {\it installed in {\tt PHOTOS 3.1} }
1590 \item {\tt Photos::initializeKinematicCorrections(int flag)} \\
1591 Initialize kinematic corrections.
1592 \item {\tt Photos::forceMassFrom4Vector(bool flag)} \\
1593 By default, for all particles used by {\tt PHOTOS},
1594 mass is re-calculated and $\sqrt{E^2-p^2}$ is used.
1595 If {\tt flag=false}, the particle mass stored in the event record
1596 is used. The choice may be important for the control
1597 of numerical stability in case ov very light stable particles, but may be incorrect for decay products
1598 themselves of non-negligible width.
1599 \item {\tt Photos::forceMass(int pdgid, double mass)} {\it installed in {\tt PHOTOS 3.4}} \\
1600 For particles of PDGID (or -PDGID) to be processed by {\tt PHOTOS},
1601 mass value attributed by user will be used instead of the one calculated
1602 from 4-vector. Note that if both {\tt forceMass} and {\tt forceMassFromEventRecord} is
1603 used for the same PDGID, the last executed function will take effect.
1604 Up to version 3.51, option active if {\tt forceMassFrom4Vector = true} (default).
1605 From version 3.52, option works regardless of setting of {\tt forceMassFrom4Vector}.
1606 \item {\tt Photos::forceMassFromEventRecord(int pdgid)} {\it installed in {\tt PHOTOS 3.4} \\
1607 For particles of PDGID (or -PDGID} to be processed by {\tt PHOTOS},
1608 mass value taken from the event record will be used instead of the one
1609 calculated from 4-vector. Note that if both {\tt forceMass} and {\tt forceMassFromEventRecord} is
1610 used for the same PDGID, the last executed function will take effect.
1612 Up to version 3.51 option active if {\tt forceMassFrom4Vector = true} (default).
1613 From version 3.52, option works regardless of setting of {\tt forceMassFrom4Vector}.
1614 \item {\tt Photos::createHistoryEntries(bool flag, int status)} {\it installed in {\tt PHOTOS 3.4}} \\
1615 If set to {\tt true}, and if event record format allows,
1616 {\tt Photos} will store history entries consisting of particles
1617 before processing. History entries will have status code equal {\tt status}.
1618 The value of {\tt status} will also be added to the list of status
1619 codes ignored by {\tt Photos} (see {\tt Photos::ignoreParticlesOfStatus})\footnote{In case of {\tt HepMC}, creates copies
1620 of all particles on the list of outgoing particles in vertices where
1621 photon was added and will be added at the end of the list.}.
1622 An example is provided in {\tt photos\_pythia\_example.cxx}.
1623 \item {\tt Photos::ignoreParticlesOfStatus(int status)} Decay products with the status code
1624 {\tt status} will be ignored in check of momentum conservation and will not be passed
1625 to algorithm generating bremsstrahlung.
1626 \item {\tt Photos::deIgnoreParticlesOfStatus(int status)} Removes {\tt status} from
1627 the list of status codes created with {\tt Photos::ignoreParticlesOfStatus}).
1628 \item {\tt bool Photos::isStatusCodeIgnored(int status)} Returns {\tt true} if {\tt status}
1629 is on the list of ignored status codes.
1630 \item {\tt Photos::setMomentumConservationThreshold(double momentum\_{}conservation\_{}threshold)} \\
1631 The default value is 0.1 (in {\tt MEV/GEV}, depending
1632 on the units used by {\tt HepMC}). If larger energy-momentum non conservation
1633 is found then in the vertex, photon generation is skipped.
1634 At present, for the evaluation of non conservation the standard method of {\tt HepMC}
1636 \item {\tt Photos::iniInfo()} \\
1637 The printout performed with {\tt Photos::initialize()} will exhibit
1638 outdated information
1639 once the methods listed above are applied. The reinitialized data can be printed with
1640 the help of {\tt Photos::iniInfo()} method.
1641 The format as in {\tt Photos::initialize()} will be used.
1645 \subsection{Creating Advanced Plots and Custom Analysis}
1648 In Section \ref{sec:results}, we have presented results of a non-standard
1649 analysis performed by {\tt MC-TESTER}. Figure \ref{fig:lineshape} has been
1650 obtained using a custom {\tt UserTreeAnalysis} located in the {\tt ZeeAnalysis.C} file
1651 residing in the {\tt examples/testing/Zee} directory. This file serves as an
1652 example of how custom analysis can be performed and how new plots can be
1653 added to the project with the help of {\tt MC-TESTER}.
1655 The basic {\tt MC-TESTER} analysis contains methods used by pre-set examples
1656 in the subdirectories of {\tt examples/testing} directory to focus on at most one or two
1657 sufficiently hard photons from all the photons generated
1658 by {\tt PHOTOS}. Its description and usage have already been documented in \cite{Davidson:2008ma}.
1659 The content of {\tt ZeeAnalysis.C} is identical to the default {\tt UserTreeAnalysis}
1660 of {\tt MC-TESTER} with the only addition being a method to create
1661 the previously mentioned plot.
1663 In order to create the $t \bar t$ example, an additional routine had to be added to {\tt photos\_test.c}.
1664 Since {\tt MC-TESTER} is not designed to analyze processes involving
1665 multiple incoming particles, we have used a method similar to that previously
1666 used in the {\tt FORTRAN} examples {\tt LC\_Analysis} mentioned in \cite{Golonka:2002rz}, Section 6.1.
1667 This routine, {\tt fixForMctester}, transforms the $X Y \rightarrow t \bar t$
1668 process to the $100 \rightarrow t \bar t$ process,
1669 where the momentum of the
1670 special particle $100$ is $X + Y$. With this modification, {\tt MC-TESTER} can be set
1671 up to analyze the particle $100$ in order to get a desirable result.
1673 For more details regarding the plots created for this documentation, see
1674 {\tt README-plots} located in {\tt examples/testing/} directory.
1676 %------------------------------------------------------------------------------
1683 \section*{Task List}
1684 In this section we provide a check-list of incomplete tasks.
1685 This could be used as a guide for project planning and is foreseen
1686 to be a working document.
1688 (prioritized: {\bf 1} - Highest priority. The program should not be
1689 released without this task being completed. {\bf 2} - Medium priority.
1690 It should be clearly documented for developers and users that this task has not
1691 been completed. {\bf 3} - Lowest priority such as a long term goal
1694 %\subsection*{Functionality}
1696 % \item[\ding{111}]{\bf 2} - Rewrite parts on HEPEVT type data structure %TP: DONE?
1699 \subsection*{Testing}
1701 % \item[\ding{111}]{\bf 3} - event record options %TP: DONE?
1702 \item[\ding{111}]{\bf 3} - further plots of some interest
1705 \subsection*{Usability}
1707 \item[\ding{111}]{\bf 3} - paper cleaning
1708 \item[\ding{111}]{\bf 3} - READMES
1709 \item[\ding{111}]{\bf 2} - User interaction and resulting fixes
1714 TXT\footnote{ {\bf remnant text to be removed. Parts may be moved to other places.}
1716 {\tt PHOTOS} act on such vertex and modifies four momenta of residing there daughters
1717 and eventually adds new ones that is photons.
1718 Such procedure is exact from the point of view of phase space; for details see e.g. approximation in on flight constructed matrix elements are based
1719 on factorization properties of QED.
1721 In case one is interested to go beyond that precision level, one has to provide
1722 more information. Spin state of the decaying particle has to be passed to the code calculating matrix element. For that it is enough to store into event record
1723 information on particles or fields resulting in creation of
1724 our particle under consideration that is mother for the decay vertex.
1725 It is then convenient to transform all particles to the rest frame of the Mother
1726 and orient Mothers mother along z axis before passing the information from HepMC to {\tt PHOTOS} internal data structure. Let us call resulting Lorentz transformation $L$. Once {\tt PHOTOS} internal algorithm complete
1727 its action all four momenta have to be transformed back by $L^{-1}$ and
1728 modification of remaining part of the event record (replacement of momenta
1729 add of new photons to HepMC and modification of all descendants of
1730 daughters would be performed as in more standard case explained above.