STAR  Computing  Simulation  
Mixing decays and/or tracks into events produced with event generators
  Maintenance

1. Phase Space tracks

Mixing

It is often desirable to be able to add tracks generated by the user, according to certain kinematic parameters, to the events produced with some event generator. This process can be characterized as "MC embedding", whereby both the underlying event and the additional track come from Monte Carlo.

This can be done in a number of ways. There is, however, a quick solution that does not require writing additional Geant code and which instead uses the existing STAF/GSTAR facilities for mixing "process" and "background" events:


gfile p event_generator_file
gfile b phasespace_track_file
gback 0 0 -1 0 0
trig
...
trig
* as many triggers as needed

where both files are pre-generated by the user. The only problem here is that it's necessary to guarantee that the positions of the vertices of individual events in both files should be the same. This is done by running a short shell script, accompanied by two simple KUMAC files as listed below.

Install

Run

  • run zxtract.tcsh foo.fz, where foo.fz is the pre-existing file produced by the event generator of user's choice (e.g. Hijing). The file extension doesn't matter, but there should be an extension separated by a period from the rest of the filename.
    This will create a "phase space" event file foo.phase
  • In case of the "phase space" tracks generation, use the script phase_gen.tcsh. If needed, adjust the parameters of the tracks by editing the self-documented variables on top of the script. These serve as GKINE inputs.
    Running the script will result in the creation of a file containing the tracks propagated in GEANT
  • access this file inside a STAF session, superimposing the phase space tracks onto events read from "foo.fz", on event per event basis:
    
    gfile p foo.fz
    gfile b foo.phase
    gback 0 0 -1 0 0
    
    * as many triggers as needed
    trig
    * do something useful
    * ...
    * loop here?
    
    
  • Optionally, delete the file foo.vertex (if you don't need it anymore) which contains the vertices of events in foo.fz and foo.phase. It is useful to count the number of lines in this file with the command wc -l foo.vertex and compare it with the number of events in foo.fz. They should match.


2. Decays --- UNDER CONSTRUCTION! ---

Mixing

One may also wish to study decays of certain particles in the context of events coming from an event generator. There appears to be two approaches here:
  • Inhibit the decay of that type of particle in the event generator and in GEANT. This may be desirable in case of many decay modes for the particle (GEANT only allows 6 decay modes whereas particles like D0 have many times more). Then, extract those particles and decay them "by hand" into the decay channel being studied, thus enhancing the statistics. The resulting file, containing the decay products propagated in the GEANT detector model, can then be merged with the original event file and analyzed.
  • Generate the desired particles (e.g. J/psi) externally, according to a certain parametrization of phase space, or using a different event generator. Decay them "by hand" into the decay channel being studied, then follow the rest of the logic described above.
Similarly to the process described above, we prepare a file

gfile p event_generator_file
gfile b phasespace_track_file
gback 0 0 -1 0 0
trig
...
trig
* as many triggers as needed

where both files are pre-generated by the user. The only problem here is that it's necessary to guarantee that the positions of the vertices of individual events in both files should be the same. This is done by running a short shell script, accompanied by two simple KUMAC files as listed below.

Install

Run

  • adjust the parameters of "phase space" tracks by editing the self-documented variables on top of the script zxtract.tcsh. These are identical to GKINE inputs.
  • run zxtract.tcsh foo.fz, where foo.fz is the pre-existing file produced by the event generator of user's choice (e.g. Hijing). The file extension doesn't matter, but there should be an extension separated by a period from the rest of the filename.
    This will create a "phase space" event file foo.phase
  • access this file inside a STAF session, superimposing the phase space tracks onto events read from "foo.fz", on event per event basis:
    
    gfile p foo.fz
    gfile b foo.phase
    gback 0 0 -1 0 0
    
    * as many triggers as needed
    trig
    * do something useful
    * ...
    * loop here?
    
    
  • Optionally, delete the file foo.vertex (if you don't need it anymore) which contains the vertices of events in foo.fz and foo.phase. It is useful to count the number of lines in this file with the command wc -l foo.vertex and compare it with the number of events in foo.fz. They should match.


Last updated by Maxim Potekhin on 06/30/2003