Attic

Archive of old Simulation pages.

Event Generators, event mixing

B0/B+ simulation and event mixing

Decays

  • weight 28% : B0-> D- + (e+) + (nu)
  • weight 72% : B0-> D*(2010) + e + nu
    • D*(2010) -> (D0) + (pi+) b.r.69%
    • D*(2010) -> (D+) + (pi0) b.r.31% neglect D*->gamma
  • weight 25% : B+ -> (D0bar) + (e+) + nu
  • weight 75% : B+ -> D*bar(2007) + (e+) + nu
    • D*(2007) -> D0+ (pi0) b.r.62%
    • D*(2007) -> D0+ (gamma) b.r.38%

Hijing

To use Hijing for simulation purposes, one must first run Hijing proper and generate event files, then feed these data to starsim to complete the GEANT part.

The Hijing event generator codes and makefile can be found in the STAR code repository at the following location:$STAR/pams/gen/hijing_382. Once built, the executable is named hijjet.x. The input file is called hijev.inp and should be modified as per user's needs. When the executable is run multiple times in same directory, a series of files will be produced with names like evgen.XXX.nt, where XXX is an integer. The format of the file is PAW Ntuple. The starsim application is equipped to read that format as explained below. If a large number of events are needed, a request should be made to the STAR simulation leader or any member of the S&C.

Listed below is the KUMAC macro that can be used to run your own GEANT simulation with pre-fabricated Hijing events . Unlike the Pythia simulation, events aren't generated on the fly but are read from an external file instead. Look at the comments embedded in the code. Additional notes:

  • don't forget to seed the random number generator if you'll be doing a series of runs
  • make sure you specify the correct geometry tag
  • specify a different output file for each run
  • the location of the input file (current directory) and the name (evgen.1.nt) are given as an example
  • you can browse the directory /star/simu/evgen to look at what input Hijing files are already available
  • the number of triggers on the bottom of the macro can be set to anything, just remember that the resulting files can be large and unwieldy if that number is too large. As a rule of thumb, we usually don't go over 500 events per file in production for min-bias AuAu, and 100 event for central gold
gfile o my_hijing_file.fz
detp geom y2006
make geometry
gclose all
* define a beam with 100um transverse sigma and 60cm sigma in Z
vsig  0.01  60.0
* introduce a cut on eta to avoid having to handle massive showers caused by spectators
gkine -1 0 0 100 -6.3 6.3 0 6.3 -30.0 30.0
gexec  $STAR_LIB/gstar.so
us/inp hijing evgen.1.nt
* seed the random generator
rndm 13 17
* trigger - change to trigger the desired number of times
trig 10

Pythia

Introduction

There are two ways, which are slightly different, to run the Pythia event generator in the context of the Starsim application. In the original (old) design, the dynamic library apythia.so served both as an adapter and a container for the standard Pythia library that would typically come with a CERNLIB distribution. The problem with this approach is of course that Pythia in itself is not a static piece of software and receives periodic updates. It is difficult or impossible, therefore, to modify the apythia.so component without affecting, in one way or another, various analyses as the consistency of the code is broken at some point.

It possible, however, to refactor the Pythia adaptor in such a way that the Pythia library proper can be loaded separately. This gives the user the ability to choose a specific version of the Pythia code to be run in their simulation. Different users, therefore, can use different versions of Pythia concurrently in Starsim, which is in everybody's interest. The thus modified wrapper was given the mneumonic name bpythia.so (it should be easy to memorize since "b"-pythia follows "a"-pythia). We have also decided the freeze the Pythia version linked into apythia.so at 6.205, and select subsequent versions bpythia.so as explained on the bottom of this page.

In the following, we present both the "old way" of running Pythia (i.e. tied to a specific version) and the new one (whereby the version can be requested dynamically at run time).

Using Pythia 6.205

Listed below is the KUMAC macro that can be used to run your own Pythia simulation, specifically utilizing version 6.205 of the Pythia code and without the ability to switch. This would be fine for most STAR applications at the time of this writing (mid-2007). Please pay attention to the comments embedded in the code. Additional notes:
  • the script below explicitely refers to apythia.so which contains Pythia 6.205
  • don't forget to seed the random number generator if you'll be doing a series of runs
  • make sure you specify the correct geometry tag
  • specify a different output file for each run
  • pay attention to the physics parameters used in the simulation; you will need to consult the Pythia manual for meaning fo those
  • the number of triggers on the bottom of the macro can be set to anything, just remember that the resulting files can be large and unwieldy if that number is too large. As a rule of thumb, we usually don't go over 5k event per file in production
gfile o my_pythia_file.fz
detp geom y2006
make geometry
gclose all
* define a beam with 100um transverse sigma and 60cm sigma in Z
vsig  0.01  60.0
* Cut on eta (+-6.3) to avoid having to handle massive showers caused by the spectators
* Cut on vertex Z (+-30 cm)
gkine -1 0 0 100 -6.3 6.3 0 6.29 -30.0 30.0
* load pythia
gexec $STAR_LIB/apythia.so
* specify parameters
ENER 200.0     ! Collision energy
MSEL 1         ! Collision type
MSUB (11)=1    ! Subprocess choice
MSUB (12)=1
MSUB (13)=1
MSUB (28)=1
MSUB (53)=1
MSUB (68)=1
*
* Make the following stable:
*
MDCY (102,1)=0  ! PI0 111
MDCY (106,1)=0  ! PI+ 211
*
MDCY (109,1)=0  ! ETA 221
*
MDCY (116,1)=0  ! K+ 321
*
MDCY (112,1)=0  ! K_SHORT 310
MDCY (105,1)=0  ! K_LONG 130
*
*
MDCY (164,1)=0  ! LAMBDA0 3122
*
MDCY (167,1)=0  ! SIGMA0 3212
MDCY (162,1)=0  ! SIGMA- 3112
MDCY (169,1)=0  ! SIGMA+ 3222
MDCY (172,1)=0  ! Xi- 3312
MDCY (174,1)=0  ! Xi0 3322
MDCY (176,1)=0  ! OMEGA- 3334
* seed the random generator
rndm 13 19
* trigger - change to trigger the desired number of times
trig 10

Specifying the Pythia version dynamically

In addition to the "frozen" version 6.205 which can be used as explained above, there is currently one more version that can be loaded, namely 6.410. Going forward, more versions will be added to the code base and to the collection of STAR libraries, as needed.

In order to use version 6.410, the user needs to simply replace the following line in the above script
gexec $STAR_LIB/apythia.so
With:
gexec $STAR_LIB/libpythia_6410.so
gexec $STAR_LIB/bpythia.so

The Magnetic Monopole in STAR

Introduction

It is possible to simulate the production and propagation of the magnetic monopoles in the STAR experiment, using a few modification in the code base of GEANT 3.21, and in particular in our GEANT-derived application, the starsim. Our work is based on a few papers, including:

The flow of the GEANT code execution is illustrated by the following diagrams from the above publication:

 

 

 

First Results

As as demonstration of principle, we present here a few Starsim event display pictures. First, we propagate 12 magnetic monopoles of varying momenta, in the STAR detector:

 

 

Now, let's take a look at a minimum bias gold-gold event that contains a pair of magnetic monopoles:

 

 

Salient features can already be seen in these graphics: large dE/dx losses and characteristic limit on the maximum radius of the recorded monopole track (this is due to the fact that the trajectory of the mm is not helix-like, but rather parabole-like). Now, lets take a look at the phi distribution of the hits, for central and peripheral gold-gold events containing monopoles:

 

 

 

Again, the rather intuitive feature (large peaks in phi due to a very large dE/dx produced by the monopoles) is obviously borne out in the simulation.

 

This is work in progress and this page is subjec to updates.

Grid-friendly Starsim production scripts

Since the production activity of STAR is migrating to, and eventually will end up running mostly in the Grid environment, this necessitates modification (which often means simplification) of the production scripts we use when running on a local or another "traditional" Unix farm facility. Here is an example of the script we have successfully used to run a Pythia simulation on the Grid (utilizing the Fermilab facility), as well as the SunGrid, with cosmetic modifications.

A few things worth noting:

  • The bulk of the script has to do with establishing the Pythia settings which are often required in the simulations requested by the Spin PWG; the starsim proper part is located on top is is uncomplicated; it invloves dynamic loading of the necessary libraries, setting up the beam interaction diamond parameters ets
  • The script needs the contents of the tarball (listed on the bottom of the page) located in its working directory; this "payload" contains the Starsim executable as well as a few shared libraries and accessory scripts necessary for its function. To be able to run on the Grid, therefore, on needs to
    • Transfer the tarball and make provisions for extraction of the files
    • Transfer the script below and configure it for submission with a unique serial number (any integer, really)
  • The script takes only one argument, which is the serial number of the run. The rest of the run parameters are encoded in its body, which minimizes the chances of human error when submitting a large number of scripts, potentially for many different datasets
  • The random number generator is seeded with the serial run number and with the Unix process ID of the script on the target machine, which for all intents and purposes guarantees the uniqueness of a sequence in each run
#!/usr/bin/ksh
echo commencing the simulation
export STAR=.
echo STAR=$STAR
#
run=$1
geom=Y2006C
ntrig=2000
diamond=60
z=120
# >> run.$run.log 2>&1
node=`uname -n`
echo run:$run geom:$geom ntrig:$ntrig diamond:$diamond z:$z node:$node pid:$$
./starsim -w 0 -g 40 -c trace on .<<EOF
trace on
RUNG $run 1 $$
RNDM $$ $run
gfile o gstar.$run.fz
detp geom $geom
vsig 0.01 $diamond
gexec $STAR/geometry.so
gexec $STAR/libpythia_6410.so
gexec $STAR/bpythia.so
gclose all
gkine -1 0 0 100 -6.3 6.3 0 6.28318 -$z $z
ENER 200.0
MSEL 1
CKIN 3=4.0
CKIN 4=5.0
MSTP (51)=7
MSTP (81)=1
MSTP (82)=4
PARP (82)=2.0
PARP (83)=0.5
PARP (84)=0.4
PARP (85)=0.9
PARP (86)=0.95
PARP (89)=1800
PARP (90)=0.25
PARP (91)=1.0
PARP (67)=4.0
MDCY (102,1)=0 ! PI0 111
MDCY (106,1)=0 ! PI+ 211
MDCY (109,1)=0 ! ETA 221
MDCY (116,1)=0 ! K+ 321
MDCY (112,1)=0 ! K_SHORT 310
MDCY (105,1)=0 ! K_LONG 130
MDCY (164,1)=0 ! LAMBDA0 3122
MDCY (167,1)=0 ! SIGMA0 3212
MDCY (162,1)=0 ! SIGMA- 3112
MDCY (169,1)=0 ! SIGMA+ 3222
MDCY (172,1)=0 ! Xi- 3312
MDCY (174,1)=0 ! Xi0 3322
MDCY (176,1)=0 ! OMEGA- 3334
trig $ntrig
exit
EOF

The contents of the "payload" tarfile:

143575 2007-05-31 18:02:47 agetof
65743 2007-05-31 18:02:39 agetof.def
44591 2007-05-31 19:05:34 bpythia.so
5595692 2007-05-31 18:03:10 geometry.so
183148 2007-05-31 18:03:15 gstar.so
4170153 2007-05-31 19:05:27 libpythia_6410.so
0 2007-05-31 18:00:06 StarDb/
0 2007-05-31 18:00:59 StarDb/StMagF/
51229 2007-05-31 18:00:57 StarDb/StMagF/bfield_full_negative_2D.dat
2775652 2007-05-31 18:00:57 StarDb/StMagF/bfield_full_negative_3D.dat
51227 2007-05-31 18:00:57 StarDb/StMagF/bfield_full_positive_2D.dat
2775650 2007-05-31 18:00:58 StarDb/StMagF/bfield_full_positive_3D.dat
51227 2007-05-31 18:00:58 StarDb/StMagF/bfield_half_positive_2D.dat
2775650 2007-05-31 18:00:58 StarDb/StMagF/bfield_half_positive_3D.dat
1530566 2007-05-31 18:00:59 StarDb/StMagF/boundary_13_efield.dat
51231 2007-05-31 18:00:59 StarDb/StMagF/const_full_positive_2D.dat
1585050 2007-05-31 18:00:59 StarDb/StMagF/endcap_efield.dat
1530393 2007-05-31 18:00:59 StarDb/StMagF/membrane_efield.dat
15663993 2007-05-31 18:03:31 starsim
36600 2007-05-31 18:03:37 starsim.bank
1848 2007-05-31 18:03:42 starsim.logon.kumac
21551 2007-05-31 18:03:48 starsim.makefile

Production overview

As of spring of 2007, the Monte Carlo production is being run on three different platforms:

  • the rcas farm
  • Open Science Grid
  • SunGrid

 

Miscellaneous scripts

a

VMC

VMC C++ Classes

StarVMC/StarVMCApplication:

  • StMCHitDescriptor
  • StarMCHits
    • Step
  • StarMCSimplePrimaryGenerator

 

Example of setting the input file: StBFChain::ProcessLine ((StVMCMaker *) 0xaeab6f0)->SetInputFile("/star/simu/simu/gstardata/evgenRoot/evgen.3.root");

In general, StBFChain sets various attributes of the makers.

 

New chain options must be added in BigFullChain.h