In this input mode, intended for diagnostic purposes, a single particle is entered explicitly into the program. The event will consist of this single particle only, unless secondaries are generated. The particle type, kinematics and vertex information are entered by using the PARTICLE, PKINE and ORIGIN (or GVERT) commands respectively (see also these commands in Sections 3.1 and 3.2). For example, the commands
INPUT_MODE ONEspecify a gold nucleus with kinetic energy per nucleon of 1.0 GeV originating in the geometrical center of the target and traveling downstream along the TPC axis. Five GEANT events are requested -- each is identical, in the absence of optional random physics processes. As another example, the commands
PARTICLE 79 197
PKINE HTPC 1. 0. 0. E
ORIGIN TARG
TRIG 5
INPUT_MODE ONEspecify a neon nucleus with momentum
PARTICLE 10 20
PKINE MUSI 0. 0. 100. P
ORIGIN MUSI 0. 0. -125.
GeV/c
in MUSIC coordinates
originating at a point 125 cm upstream of the MUSIC center and traveling
downstream along the MUSIC z-axis.
This input mode is functionally equivalent to input mode ONE, except that multiple particle definitions are possible (with the same sequence of commands to specify a particle as described for input mode ONE). This is once again a diagnostic feature, since the content of the multi-particle event is fixed for all events, unless smearing of the event vertex or physical processes are in effect. As an example, the commands
INPUT_MODE MANYspecify an event containing one proton of momentum
PARTICLE 1 1
PARTICLE 2 4
PARTICLE 3 6
PKINE MARS 0. 0. 1. P
PKINE MARS 1. 0. 0. E
ORIGIN FREE
GVERT SVTX 0. 0. 1. 0.5
GeV/c,
one 
He particle with 1.0 GeV kinetic energy per nucleon and one 
Li
particle also with 1.0 GeV kinetic energy per nucleon. The three particles
originate from a vertex located within the target and smeared, event by event,
with a mean corresponding to the target center and a Gaussian distribution in
x and y in target coordinates with VSIGMAX = 1.0 cm and VSIGMAY = 0.5 cm.
The smearing in the third coordinate z
is uniform throughout the target thickness.
(See also Section 3.1 for a description of the vertex specification.)
The scheme used to build the multi-particle event assumes that the multiplicity of the event is the number of entries in the PARTICLE or PKINE lists, whichever is greater, that have been input since the last INPUT_MODE MANY command (which has the effect of clearing the lists). The missing information in the shorter of the two lists is filled in from the last entry in that list. Therefore the commands
INPUT_MODE MANY
PARTICLE 1 1
PKINE MARS 1. 0. 0. P
PKINE MARS 0. 1. 0. P
PKINE MARS 0. 0. 1. P
ORIGIN FREE
GVERT SVTX 0. 0. 1. 0.5
will result in an event containing three protons with 1.0 GeV/c momentum each -- one traveling parallel to the x axis, one parallel to the y axis, and one parallel to the z axis in CAVE coordinates.
This input mode invokes the generators internal to EOSGX. The current internal generators are very simple, and are not intended as alternatives to external event generators based on detailed physical models. The internal generators do, however, have features which make them useful in diagnostic applications. There are currently three internal generators, numbered 1, 2, 3. The default is generator number 1. To choose a different generator, the number should be entered explicitly. For example,
INPUT_MODE INTG 3invokes generator 3. The scheme for the internal generators is designed in this way to make the definition of new generators straightforward.
Internal generator number 1 is a simple code that assigns a constant kinetic energy per nucleon to each of N particles. The N particles all have the same particle type and are assumed to emerge isotropically in the reference frame of a fictitious remnant nucleus. The appropriate sequence of commands for this generator would be, for example,
INPUT_MODE INTG 1The kinematics for the remnant are taken from the first PKINE command. The fragments (all
PARTICLE 2 4
PKINE MARS 1.1 0. 0. E
PKINE RAND 10 20 5. 15.
ORIGIN TARG
He's, from the PARTICLE command)
will emerge from a remnant
system with a kinetic energy per nucleon of 1.1 A GeV traveling downstream
along the CAVE (MARS) z axis. The second PKINE command, with the special
qualifier ``RAND'', specifies the limits on event-by-event
smearing of the event
multiplicity N and kinetic energy per nucleon of the fragments in the reference
system of the remnant. In the above example, the multiplicity of fragments is
smeared uniformly between 10 and 20, and the kinetic energy per nucleon of each
fragment in the remnant system is smeared uniformly between 5 and 15 MeV. The
fragments emerge from a vertex at the target center.
Internal generator number 2 is a code that steers N particles, all of the same particle type, into a certain solid angle in the CAVE reference system. The specification for this is taken entirely from the KINE command (or the KINE card in the FFREAD file). See also the description of the KINE command in Section 3.2. The commands
INPUT_MODE INTG 2specify 30
ORIGIN PLT1
KINE 1 0. 2. 0. 360. 1. 1.2 30 2. 4.
He's with kinetic energy per nucleon
between 1.0 GeV and 1.2 GeV
emerging from a vertex in the center of the first PLUTO and moving downstream
into the solid angle defined by the limits THETAMIN = 0.0, THETAMAX = 2.0,
PHIMIN = 0.0, and PHIMAX = 360.0 in the CAVE coordinate system.
Internal generator number 3 was historically intended as a predictive tool for fragment trajectories. Like generator number 1, it uses the PKINE command entries to determine the velocity components of the remnant in the laboratory. Unlike generator number 1, the PARTICLE command does not denote the particle type of the fragments. Instead the PARTICLE entries are used to specify the charge to mass ratio of the remnant, ZREM/AREM, which is used to limit the sum of fragment charges. The actual fragment types themselves are determined from the MASSES command. The command
MASSES A1 A2 A3 A4 A5 ...specifies the mass numbers of a series of fragments. The charge of each of the fragments is determined on the basis of natural abundances. Above Z = 6, the most frequently occurring isobar is used. For Z = 6 and below the choice between isobars is randomized and weighted according to abundance (stability). The sum of all fragment charges must obey the following relation:
The slope parameters in the kinetic energy distribution of fragments are chosen from p-nucleus data. The angular distribution is isotropic in the rest frame of the remnant. However, total energy and momentum are not conserved. The sequence of commands
INPUT_MODE INTG 3specifies an event containing six fragments emerging from a remnant system moving along the CAVE z-axis at 1.0 GeV per nucleon. The charges, and hence the particle types, of the fragments are computed quantities. The ratio of ZSUM/ASUM is assumed to be that of gold, 79/197.
PARTICLE 79 197
PKINE MARS 1. 0. 0. E
MASSES 1 2 4 4 6 20
ORIGIN TARG
This input mode is the default input mode for EOSGX. In input mode FILE, EOSGX gets simulated physics events from an unformatted (non-ASCII, machine readable) file, which allows reading of simulated events from an external event generator such as FREESCO, ISABEL, ARC, and etc. The file, historically referred to as an FRS (File Read Source) format file, is given the extension *.FRS. The FRS format is described later in this section. As FRS files are not user-formatted, they are not portable between platforms and must be translated to ASCII for copying from one platform to another.
The designation of a particular FRS file on disk or tape as the current input to EOSGX is handled by the command LUN (Section 3.6) i.e.
LUN unit filename Oopens a file named FILENAME on the FORTRAN logical unit UNIT, and makes UNIT the current input unit. If no file name is supplied, the logical unit UNIT is assumed to already have a file opened on it, and the current input unit is set to UNIT.
The command
LUN unit ! Ccloses the file on logical unit UNIT, and deassigns UNIT.
EOSGX maintains a list of those FORTRAN logical units opened for FRS input. While many FRS files may be open at the same time, only one file is designated to be the current source of input. This file is chosen by selecting its associated FORTRAN input logical unit with the command LUN. The sequence of commands
LUN 51 MYFILE_1.FRSopens two files MYFILE_1.FRS and MYFILE_2.FRS on units 51 and 52 respectively. (The third parameter ``O'' need not be given, as it is the default.) Because unit 52 is assigned last, it becomes the current source of input and the next GEANT event will come from MYFILE_2.FRS.
LUN 52 MYFILE_2.FRS
The sequence of commands
LUN 51 MYFILE_1.FRSopens three files on units 51, 52 and 54, then assigns unit 52 to be the current input.
LUN 52 MYFILE_2.FRS
LUN 54 MYFILE_3.FRS
LUN 52
At initialization time, EOSGX will attempt to open default units for files referenced by the VMS logical names (or UNIX environment variables) EOSG_FRS_1, EOSG_FRS_2 and EOSG_FRS_3. To use this default option, these names should be assigned to existing files. The FORTRAN units chosen will normally be 48, 49 and 50 unless these are already in use, in which case the nearest available units will be chosen. The last unit successfully assigned becomes the current source of input.
The read format for input mode FILE is as follows:
First a character string identifying the file. This may have a maximum length of 80 characters.
Read format for the character string is:
Then the run header.
EOSGX reads from various logical unit numbers. These units may all be open at the same time, and each of the files associated with these units may have a different number of optional parameters. These differences are accommodated internally. The maximum number of optional parameters is set in the include file EOSG_MGC.INC.
Additional parameters may vary as to their interpretation, depending on the particular event file. The meaning of the optional parameters is to be defined by the application.
Read format for the run header is
Then the event header.
The event number is not really necessary, but remains in the code for compatibility with previous event files.
Read format for the event header is
Finally the particle data block.
Read format for the particle data block is
Note that the GEANT particle ID is not a part of the format.
In this input mode, the event that is input to the GEANT simulation consists of the current contents of the TPC TRACKS table i.e., the output of the TPC analysis code is fed back into the simulation. This input mode is required in DATA run mode. The DATA input mode has been used in the event display to compare the TPC track projections (using command DDTRACKS, for tracks found without taking energy loss into account, and where the track projection is generated without energy loss) with the GEANT track projections for these same tracks (generated with energy loss). This comparison is useful as a check on the effect of energy loss on the trajectory, and is especially instructive when combined with a comparison of the initial GEANT trajectories of the tracks originally input to the simulation.
In this input mode, the event consists of the contents of the PARTS table filled by FREESCO. The scheme used to interpret the particle ID information in the PARTS table depends on the usual Z and A convention used in the other input modes (Section 2.3.1), despite the presence of an explicit GEANT particle ID in the PARTS table.