Introduction

This document describes the header release of PMCS. The lastest test release should contain similar code. To find the latest test release, do an "ls" of /d0dist/dist/releases, and look at directories with names in the format "txx.xx.xx", where xx is a number. This documents the versions with the highest numbers.

PMCS (Parameterized Monte Carlo Simulation) is available as official D0 released code.. In order to meet as many needs as possible in D0, the PMCS packages have been conceptually divided into three categories : FAST, MEDIUM, and DETAILED. Packages in the FAST category directly model high level physics objects directly from the event generator; such as jets, electrons, muons, photons, charged tracks, and vertices. Packages in the MEDIUM category model some lower level objects, such as calorimeter towers. If packages in the MEDIUM category are run, it is expected that the user will also run RECO packages on top to provide a more detailed simulation of physics objects. Finally, packages in the DETAILED category model the lowest levels of detector performance such as calorimeter cells, preshower hits, and tracking hits.

It is a priority of the PMCS group to give highest attention to the FAST packages and the pmcs_cal package. In the current of PMCS, the following CVS packages have been implemented :

• pmcs
• pmcs_util
• pmcs_output
• pmcs_cal (medium)
• pmcs_chprt (fast)
• pmcs_em (fast)
• pmcs_jet (fast)
• pmcs_muon (fast)
• pmcs_met (fast)
• pmcs_tau (fast)
• pmcs_vtx (fast)
• pmcs_trig (fast)

In order to better meet the design goals of flexibility and modularity, it was decided to release PMCS as a set of cooperating framework packages. However, the design also needs to meet the requirements of speed and of faithful representation of physics events with full account of correlations between the different framework packages. Since a large portion of time is spent doing chunk lookup in the event, it was decided to collect all MCKineChunk information ( possibly more than one chunk) into a single pmcsInputChunk. The pmcs_setup package is responsible for doing this. For similar reasons, each PMCS package deposits its smeared information in a pmcsOutputChunk. At the end of PMCS processing, a single pmcsOutputChunk is deposited into the event. In order to accomplish this, both the pmcsInputChunk and the pmcsOutputChunk are held by a singleton pmcsCustodian class during processing. The pmcsInputChunk is dropped into the event after pmcs_setup processing has finished. Thus, access to the pmcsInputChunk is read-only even though its pointer is still accessible via the custodian. The pmcsOutputchunk is dropped into the event by option only after all PMCS processing has finished, so that access is read-write. Note that this also allows for correlated processing in that the information in pmcsOutputChunk can be changed if necessary.

In order to retain flexibility and modularity, great care has been taken to define the pmcs physics objects in a general manner so that the pmcsInputChunk and pmcsOutputChunk are ignorant of the type implementations. Each pmcs package is nominally in control of its generator and smeared level physics object types; although at present these type definitions remain in the pmcs_util package to avoid package level circular dependencies during the build.

In addition to writing smeared level information to the pmcsOutputChunk, the PMCS packages can by option create a standard D0 chunk containing the same information. These chunks will created and dropped into the event at the finishEvent hook so that correlations can be processed earlier. In order to handle correlations between the packages, the standard D0 chunks cannot be dropped into the event during earlier hooks.

Finally, smearing constants and detector parameters are held in special singleton classes. Upon instantiation, the singleton objects read their constants from the corresponding package RCP files and are available throughout the program.

Each PMCS package uses at least one RCP file. In some cases, PMCS has special classes that hold constants for smearing. These are also read in by RCP file. On startup, PMCS will access the RCPs via special exception handling objects that will provide a default value for each requested variable. These objects also dump their status to the screen so that every RCP variable automatically has a record on startup. For example, during the startup of the pmcs_setup package,

--------> Initializing pmcs_setup package.

Value of doMET is 0, which is the default value.

Value of doSortPt is 1, which is the default value.

Value of doRecoil2lep is 0, which is the default value.

Value of useFirstChunkOnly is 1, overriding default value.

Value of gf_track_etamax is 4.2, script has the default value.

Value of gf_em_etamax is 4.2, script has the default value.

Value of gf_track_ptmin is 10, script has the default value.

Value of gf_em_ptmin is 10, script has the default value.

--------> pmcs_setup package initialized.

The final value of each variable is printed out with status :

"which is the default value" : The RCP variable was not found in the script. The hardcoded default value was used.

"overriding default value" : The RCP variable was found in the RCP script and was used instead of the hardcoded default.

"script has the default value" : The RCP variable was found in the RCP script. It happened to be the same as the script value.