Introduzione
Flyo is a Montecarlo written in C + + for the simulation of the events inside an experimental apparatus described by the user in ascii files with .app or .epc extensions. The description of the device, divided into logical segments, called block, is made up with keywords, also called control words, that are followed by parameters written in free-format.
Flyo reads all input data and creates a logical pattern that reflects the experimental setup and describes the series of nuclear reactions desired by the user. After a short initialization, the simulation procedure for each event generates the beam and all the particles required in the reactions. Each particle is drawn through the experimental apparatus taking into account the materials found in detectors traversed along the path. In the case of dense material, Flyo, if enabled by the user, generates bremsstrhalung and pair production.
After the tracking, the data generated and filtered by different simulators, are similar to the rough data generated by a real experimental setup, but with more information of Monte Carlo. So Flyo, if instructed, processes the data generated by reconstructing the events (geometrically and kinematically) according to certain assumptions set by the user in the file type epc.
Flyo produces output in two files, a complete listing with all the information of the parameters of production and a Root file containing all or some of these events accepted by a user-defined criteria.
Typically a first file type app contains basic information on the material used in construction equipment. Flyo takes account of these data, tracing the particles, to generate the multiple scattering and estimate the energy loss by ionization, to produce pairs or emit gamma rays via bremsstrhalung.
A second file type app describes, in detail if necessary, the optical beam from the target production to the useful area of the detectors. A third file app describes the detectors used in the experiment designed by researchers
The file epc is the file that contains all the parameters and the description of nuclear reactions expected in a simulation run. With the same experimental setup, you can use different file epc with descriptions of chains of different reactions. The file epc shall include, at appropriate points, the file app needed for a complete description dell'appparato experimental.
In later chapters we will talk mainly of the file app or epc. It describes the meaning and format of the keywords that are read by Flyo for the initiation of the various procedures of simulation and analysis. Then we'll turn to specific chapters still in progress.
How and where do you get Flyo
Open a web browser and go to http://pierazzini.unipi.it/giuseppe/FlyoHtml/flyoindex.html and then download.
Here is the place where you can find the latest versions of Flyo in tgz. For example, Flyo62_11.07.24h1825.tgz is the version of Flyo generated in July 24 2011 at 06.25 pm.
With one click, you are prompted to download the file to your computer. The file will be in a directory where you can decompress it with the command gunzip Flyo62_11.07.24h1825.tgz to get Flyo62_11.07.24h1825.tar. Then proceed to extract the software with the command tar-xvf Flyo62_11.07.24h1825.tar
Now type make to compile the sources to a binary program that you will find in the bin/ as Flyo.
Your computer, running Linux (CERN Scientific Linux or Ubuntu 10.04 or even more recent version), must have good C++ compiler, version 3.2.3 or greater and the Root library of CERN.
How to operate FlyoWhen you turn on your computer, navigate to the folder Epc (this is not mandatory, but that's how I work) and here you write .. /bin/Flyo -h to get a mini help, which explains the information to be added in line to command. For example, always in your Epc folder, write:
../bin/Flyo -d path/risultati/ -i kpivv/Kpivv.epc -t root -r 3333 -e 20000
Command that prompts you to generate 20,000 events as described in the file Kpivv.epc and create two files, the file listing and the Root with the 3333 run, in the output folder path/results. The output folder can be anywhere, but for clarity, and not confuse the source of the program with the results, it is better to place it somewhere else. Such as in home/user/results folder that should be created before using it with a mkdir home/user/results command.
Remember that the paths have to be adjusted if you put yourself in a different folder. You must then pass the path relative to the point where you run, or you write the absolute path!
If you repeat the run with the same number the results fortunately are not overwritten!, but are written in other files with the same number as before followed by a + (plus).order_number.
Because Root does not handle files too much larger than 1 Gb, you must be careful to define the max number of events to generate. If they are too many then the run jump. Consider doing more short runs by changing the run number with correlation = 1 (The random initialization is dependent on run number).
Description of equipment
The file app are text files that describe geometrically the detectors with the materials they are made and the lists of detectable particles.
Before going into the contents of the file is good to remember that the lines that begin with some asterisk or slash are considered comment lines and thus ignored by Flyo reading. The information is usually started by a control word or keyword. Multiple lines form a block which is usually closed by an end or fine. The labels or numbers after the word control follow a logical pattern: they must be separated by one or more spaces, but it is not necessary to write data in fixed fields.
The parameters of the materials are memorized directly into the Flyo source. Refer to the source matter.cpp With the keyword pr_material Flyo prints a list of materials in the listing output. The parameters that describe the particles are generated as can be seen in the procedures part_db.cpp and the like. The command pr_data_bas does print the list of particles used by Flyo.
The file xyznl.app
Here I report, as an example, the file Beamk60.app which refers to the description of the optical beam K of 60 GeV / c, p Take for example what is written in the file *.app:
An apparatus consists of many sub devices: detectors, dump magnets, chambers, .... In the files Beamk60.app are several examples such as magnet, rectangle, ytax, quadrupole. Similar devices are all described by the same geometry, of course, followed by different values of the parameters. However Flyo in the creation of the class corresponding to one device, interprets the parameters in a correct way to take into account its real geometric structure and its functions.
The dependence of a class from the others is shown in the diagrams with detailed descriptions of the sources as reported in the doxygen documentation. Each class represents a device with all its characteristics, geometry and materials, but also with its own rules or procedures that it will apply to the particles when they pass through.
The file Apparato.app
This is the file of the experimental apparatus. Please look to one file, as example, to discover some key words not yet explained. The description of detectors does not change much compared to what we have already learned.
Note that splitting the file is only instrumental, because the three files mentioned so far may be combined into one large file. It is preferred to separate them just to make it easier to edit without the risk of confusion. For example the first two files are more stable, but the third, which describes in particular the detector apparatus, should be promptly updated according to user requirements.
The epc file.Let's start with a sample file, the file Kpipi060.epc for example. This is one of the files that defines the parameters of a simulation run and describes the reactions to generate. The extension epc is different from that used for other files, but that is only for convenience and to avoid confusion with other files of type app. As usual, nothing prevents you to join the file app with this file and use it directly in Flyo. In fact, the other file system can easily be included with a simple command include file in the epc to restore the continuity of information for Flyo. Remember that in launching Flyo from the Epc directory, as mentioned above you type
../bin/Flyo -d path/risultati/ -i kpivv/Kpivv.epc -r 3333 -e 20000
Once you are in the folder Epc, you will see all the other folders containing the descriptions of the apparatus and the file epc with the reactions to be performed. If you launch Flyo from another location please adjust the paths in relation to the new location.
And now we come to the explanation of the contents of this last file. It actually can be divided into two parts: one defines the parameters of running, while a second part describing the nuclear reactions that will be generated in the simulation.
Words of the overall control of the run:
Analysis control
The reactions are described in a block in which they appear: information on the target, the production of the beam, the maximum divergence of the beam and the specs on the desired reactions. You can write multiple blocks, with different reactions and if you wish, with different beam and target. In general, the target and the beam parameters are the same unless you want to generate events simultaneously from two or more different targets.
The control word:
The lists of particles.
The reactions are organized by Flyo with the information of particles linked by C++ pointers.
The particles are made of objects with all the information derived from Data_Base, but are also arranged in the sequence in which they are created (see id here below).
Each particle is identified by a:
name, written into the epc, (the same name that appears also in Data_Base); by a number
idm, i.e. an index of matter that corresponds to its position in Data_Base and by an index
id that places the particle within the reaction and, of course,
by all the physical parameters as mass, lifetime, charge ecc. See in detail the class particles.
Flyo generates events according to their probability of production, which depends on the rate and on the cross section of production from the beam in the target. So Flyo begins tracing each particle, starting just from the first, the beam, which tracks up to the moment of its natural decay if not terminated prior by a colliding with some part of the apparatus.
The decay is a standard procedure which takes into account the possible phase space and matrix. Each particle at the end of its travel, always for natural death or for absorption by a detector, is terminated by a code, which is called by Flyo fate and is also stored on the Root file output.
A decay to several bodies, such as the KL -> pi0 pi0 pi0, it is automatically split into two or more sub-decays.
K = pi0 res | first decay |
res = pi0 pi0 | second decay |
pi0 = gam gam | first pi0 decay into two photons |
pi0 = gam gam | second pi0 decay into two photons |
pi0 = gam gam | third pi0 decay into two photons |
where the particle res is generated with a mass compatible with the phase space; res is a virtual particle which also appears in Data_Base (among others), but it has the sole purpose of forcing Flyo to use the phase space. This process of fragmenting a decay in simple steps is useful because it allows us to use recursive kinematic procedure for the decay in three or more bodies.
Incidentally I should also mention that the above model allows us to easily enumerate the particles produced in the decay: with id = index of the mother, the first daughter is 2*id, the second 2*id+1; with this technique is easy to trace back the history of a particle.
Today Flyo numbers the particles within a reaction as mentioned above, but more for historical reasons than practical. Really C++ today provides methods (pointers) more flexible to take a complete assessment of a reaction chain.
To return to our problem of decay, we also recall the cases where you need to deal with a matrix elementy. The Monte Carlo Flyo generates events according to the matrix of decay. Of course, the procedure for the decay under consideration must be planned and scheduled in the source code. The technique is to insert for any particular decay a virtual particle automatically or manually into the appropriate point of the decay chain to force Flyo, when called, to follow specific probability distributions.
The number of particles of a reaction can also be changed dinamically during the generation of an event; that is usually done to take account, for example, of the pair production or of the photon emission by bremsstrhalung, if the pairproduction and/or bremsstrahlung are enabled.
Gmp