One of the difficulties in using single-particle monte carlo in analysis is that tracking will
 not reconstruct a primary vertex without multiple tracks.  Previously, the way around this
 was to have hard-coded assumptions on the primary vertex, but without delving into
StEvent, the tracks still did not come as children of the primary vertex.
Jan Balewski suggests throwing not only the particle of interest, but also multiple muons
aimed toward unused parts of the detector, giving the tracking algorithms enough
 information to reconstruct the vertex.  There are no doubt many ways to accomplish this,
 here's one:

Basically, we will write tailored events out, and then run the set through starsim, and on
through the chain.

Step 1:  Generate a text file describing the events.

(need to provide link to code) is a working example of a short piece of C++ that
throws one photon in the given range of pt, eta, and phi, and then four supporting
 muons to provide the primary vertex.  It runs in the star framework, using the
command

root -l writeEventList.C\(500\)

where 500 is the number of events desired.  The range of pt, eta, and phi, as well
 as the ID of the particle and the name of the output file, can be changed fairly
 simply in the code.
starsim expects a very specific format for the file it will read.  The above code
 provides a list of events that look like this:


event 5 1
6 50.000000 0.000000 -51.325840
6 -50.000000 0.000000 -51.325840
6 0.000000 50.000000 -51.325840
6 0.000000 -50.000000 -51.325840
1 -10.207415 1.598150 24.001463

In the first line, '5' is the total number of particles in this event, and '1' refers to the
 place this event has in the list of events.  The next event would read '2' and so on.
 The second line, and all the remaining lines, describe a single particle in the event
each.  The first number is the particle id (1=photon, 6=muon, lists are avialable
 elsewhere).  The next set are px, py, and pz, in that order.  The list should end in a
newline.

The end result of this step is a text file containing a list of event descriptions like the
 example above.

Step 2: Feed the text file through starsim.

(need to provide link to code) is a working example of a macro that will take the
 named event list and generate an fzd file from it.  It runs in starsim, using the command

starsim -b -q simulateEvents.kumac

The number of events is set at 10,000, so if the text file gives more than this, anything
 after event 10,000 will not be recorded.  This can be easily changed.  The key line of
 code is

user/input TXOLD [file].txt

which instructs starsim to read events from that file instead of defining them locally.  If the
 number of particles stated in the first line of the .txt does not match the number actually
 given, starsim will fail.

The end result of this step is a .fzd file containing the simulated events that were described
in the text file.

Step 3: Feed the .fzd file through the chain.

The chain used in this analysis (so far) is

bfc.C(1,10000,"trs,srs,fss,y2006,Idst,l0,tpcI,tcl,ftpc,Tree,-SvtCL,svtDb,
logger,ITTF,Sti,-SvtIT,VFPPV,geant,tags,emcY2,EEfs,evout,geantout,big,fzin,
MiniMcMk,clearmem, eemcDb,beamLine, ppOpt, dstout,cmudst,dEdxY2","input.fzd")

where input.fzd is the name and of the .fzd file generated in the previous step.  Click here(need
 to provide link) to see a description of what each option does.
The chain will simulate the detector response to each of the simulated events, and creates a
 set of output files,

input.dst.root    input.geant.root  input.minimc.root  input.runco.root
input.event.root  input.hist.root   input.MuDst.root   input.tags.root

The two we are primarily concerned with are .geant.root, which contains all the geant
 information, and .MuDst.root, which contains c++ objects describing detector response.

More Steps:  Once the basic machinery is working, we start thinking about how to automate the process.
 I'll fill this section in as I write the scripts.


01/23/08 Update:
We're having trouble getting the calorimeter information to appear in the mudst.
I'm going to change the chain used:

bfc.C(1,10000,"trs,srs,fss,y2006,Idst,l0,tpcI,tcl,ftpc,Tree,-SvtCL,svtDb,
logger,ITTF,Sti,-SvtIT,VFPPV,geant,emcY2,EEfs,MuDST,evout,McEvOut,geantout,
big,fzin,MiniMcMk,eemcDb,beamLine,ppOpt,dstout,dEdxY2,notags","input.fzd")

Still, I don't think this will fix the problem.  The StMcEvent container has calorimeter information present.