Monte Carlo Reconstruction
Thomas Lohse
Dear Monte Carlo Producers
thank you very much for the good work in producing the first
sets of Monte Carlo events. It is time now to also run the
simulated events through the reconstruction chain. Here are the
instructions for the default procedures (full detector scenario).
This is a first trial in which you are normally going to reconstruct
individual simulated events. For final reconstruction we have
to mix rare physics events with an average of 4 minimum bias
events (poisson distributed). This means that each reconstruction
site needs access to large minimum bias samples. We are thinking
about the technical solution at the moment.
(0) Reconstruction should use ARTE-03-01-r2 !!!!!!!!!
(1) Use
/afs/desy.de/user/t/tlohse/public/mcrec/mcrec.kumac
/afs/desy.de/user/t/tlohse/public/mcrec/usevnt.C
(2) Set the parameters
physproc
directory
production_site
n_mb_files
(3) Set the parameters
int_phys_per_bx = -1
int_mb_per_bx = 0
for testing. If you want to mix in underlying events you
should use
int_mb_per_bx = 4
but then you also have to specify the minimum bias input files
n_mb_files = ...
mbfile1 = ...
mbfile2 = ...
etc.
(4) Plug and Play; Run and Fun
Comments: Some changes have been made to the standard mcrec.kumac!!!
(1) Starting with ARTE-03 we had to change the command
dglev OTR 1 into hbdigi/dglev OTR 1
(2) Formats are predefined for you such that all simulation/geometry
output is read in in ZEBRA format (L) while the reconstruction
output is now written in GPACK format (G) since all bugs in
GPACK are now hopefully corrected.
(3) By default you'll get a ROOT output file for the analysis
using CLUE. Shortly, an example file, written by Christoph
Borgmeier, will be made public, so that you can experience
yourself how easy and elegant the analysis of the reconstruction
output becomes in the CLUE environment.
(4) You may wonder why we are still using "ideal" VDET pattern
recognition although we have beautiful honest algorithms
(CATS, HOLMES). The reason is that the geometry version which we
used for the production is by now known to have (at least) one
bug which causes some hits in the VDET to be not generated.
The track reconstruction efficiency suffers enough that
we can expect quite big effects for multi track channels
like the golden decay + tags (at least 5 tracks have to be
simultaneously found). Therefore the Monte Carlo truth
is a better choice in this case.
Finally I'd like to thank R.Mankel and S.Nowak for doing basically
all the work (and tests) for making mcrec.kumac work, Christoph
Borgmeier spending a large fraction of his time (he in principle
would have needed to wirte his thesis) on the technical aspects of
providing appropriate analysis tools for the collaboration, and
Norbert Tesch who did a great job in producing, collecting
and documenting the Monte Carlo production.
Please give me feedback if problems with mcrec arise.
Good luck
Thomas
-------------------------------------------------------------------------
Thomas Lohse phone: +49 30 2093-7820
Humboldt University Berlin fax: +49 30 2093-7642
Department of Physics
Invalidenstr. 110
D-10115 Berlin email: lo...@ifh.de
-------------------------------------------------------------------------