Monte Carlo Production Code Tracking Page

How To Determine Which Code Has Been Used in Production

All Monte Carlo production runs are identified by a run number. The run number is the key used to track the generation and analysis of these events. Descriptions of final states and run numbers can be found via the physics web page. Follow the hyperlinks for for the "Batch*" next to "Production Plan"

The bfreport command can be used to track the status of production. Type "bfreport --help" for instructions on how to use the bfreport command. For example:

>bfreport 092003
  Run    Nev   Description
   Version    s/ev    Size  Machine  Tape File  Where Who      Status
==============================================================================
092003    1k   B0 -> X, B0~ -> D*(2010)+ l- nub + c.c.
  S7.11.2g     8.1    90MB  *onco103 HQ0017   5 slac  rom      Done
  M8.1.10h     2.1    1000  *onco124            slac  young    Done
   B8.1.10h    7.4    1000  *onco112            slac  young    Done
  M8.1.10h    13.1    1000  *onco117 HQ0015 399 slac  young    Done
   B8.1.10h    9.5     999  *onco118            slac  young    Done

The first column lists the software release number used to do that stage of the prodiction. The prefix "S" stands for simulation, which is normally run with the BbsimModule program. The prefix "M" stands for background mixing and digitization, which is done with the SimAppApp program. The 6'th column of an "M" line lists the name of the background file. In this case it is 399. The column labeled tape tells you what tape to use to retrieve the xdr file at SLAC. The prefix "B" stands for reconstruction which is done with the BearApp program.

The output of both the SimAppApp and BearApp stages are into an Objectivty database. The contents of a typical production federation can be found on the web. The production work is organized in named blocks such as PRV0, SP1, SP1.5 etc.

Simulation Code

The simulation code is documented in its own web page.

Summary and Caveats

PRV0

PRV0 used release 7.11.2d for simulation and releases 7.12.7a and 7.12.7b for mixing and reconstruction. Run numbers were in the range of 071xxx.

Known problems with PRV0 include:
There is an extra 5% of a radiation length of material in the support tube.
There were discrepencies between the magnetic field used for simulation and the field used for reconstruction.
Drift chanber wire sag was not used in the simulation but was used in reconstruction.
The forward magnetic field and the magnetic field used to reconstruct outside of the magnet coil were wrong.
There may be a 2-3 cm gap in the vicinty of the coil where Monte Carlo truth information concerning decays and Bremstrahlung were not recorded.

SP1

SP1 used release 7.11.2f for simulation and releases 8.1.10b and 8.1.10h for mixing and reconstruction. Run numbers were in the range 091xxx.

Known problems with SP1 include:
The production code in release 8.1.10h is known to core dump under OSF at Livermore.
There is an extra 5% of a radiation length of material in the support tube.
The forward magnetic field and the magnetic field used to reconstruct outside of the magnet coil were wrong.
There is a 2-3 cm gap in the vicinty of the coil where Monte Carlo truth information concerning decays and Bremstrahlung were not recorded.

SP1.5

SP1.5 used release 7.11.2g for simulation and releases 8.1.10h and 8.1.12a for mixing and reconstruction. Run numbers are in the range 092xxx and 093xxx.

Known problems with SP1.5 include:
The production code in releases 8.1.10h and 8.1.12a is known to core dump under OSF at Livermore.
The 7.11.2g version of BbsimModule has core dumped under SunOS at IN2P3.
The 8.1.12a version of SimApp core dumps at Dallas. The forward magnetic field and the magnetic field used to reconstruct outside of the magnet coil were wrong in releases 8.1.10h and 8.1.12. This problem only effects the reconstruction of simulated data. It is fixed in 8.1.12a.
There is a 2-3 cm gap in the vicinty of the coil where Monte Carlo truth information concerning decays and Bremstrahlung were not recorded.
While 8.1.10h and 8.1.12 were built from the same tags there are known differences. It has been reported by users that data read with 8.1.10h doesn't have PrimaryVertex info but it is found when read with 8.1.12.

The 8.1.12a release no longer has the magnetic field problems. Core dumps under 8.1.12a for OSF have been traced to uninitialized data in IfrGeom/IfrStripLayer.cc. With this patch SimApp and Bear run on OSF at Livermore.

Rerunning of the 8.1.12a version of SimApp on the same input at SLAC produces different outputs. The histograms for all subsystems are different.

All Production Releases -- PRV0 through SP1.5

Known problems with all production releases to date are that duplicate jobs run at different sites do not always agree. They do not produce identical log files. No comparison has been made of the output database. Comparison of release 8.1.12a has been made of the same job run twice on the same input at the same site. SimApp is not reproducible. Bear has not yet been fully compared.

SP2

SP2 used releases 8.2.11b, 8.3.1b, 8.3.1c for simulation, mixing and reconstruction. Run numbers are in the range 15xxxx. Release 8.2.11c was used for offsite startup. Offsite production was done with 8.3.1c

This first phase of SP2 produced about 6 million events, 2/3 done at SLAC and most of the rest done at IN2P3 and Colorado.

SP2 used true random beam-beam triggers to estimate the background in simulated events. Background installed on November 15'th 1999 is known as x5 (19991105-19991115r1V01).

Some known problems are that SimApp hangs on exit on a large fraction of jobs run with background mixing in release 8.2.11b. and BearApp is known to core dump on a very small fraction of runs in 8.3.1b. There are known tracking problems in the 8.2.11 series of releases.

The 8.3.0a and 8.3.1a releases have serious memory leaks in BearApp that make them impractical to be used for reconstruction.

The 8.3.1 series of releases do not have the SimApp hangs of earlier releases. The 8.3.1b release is known to have a problem in TrkOprMon that causes crashes on 3-4% of all runs. This problem is not present in 8.3.1c.

SP2 -- possible problems

Runs in the ranges 151000-151011 and 151051-151168 were processed with the "x2" background file. These backgrounds from 19991023-19991024r1V01 exhibited "cyclic" properties, not typical of most beam-beam backgrounds. All runs with the "x2" background were processed with release 8.2.11*.

The simulation generates bad drift chamber timings on about 5% of the hits when the code is run on OSF or Linux. LLNL and Colorado are production sites running OSF.

There are suspected problems with IFR, tracking, calorimetry and dirc reconstruction in the 8.3.1 series of releases. The Monte Carlo IFR sees too many strips firing. The calorimeter sees E/P=2 for single prong tracks in background free Monte Carlo runs. The DIRC issues ominous timing warnings. The IFR reports a low match rate with the calorimeter when comparing single muons.

SP2 -- later releases

Runs 16xxxx of SP2 have been done with the 8.4.1 releases, 8.4.1a and 8.4.1c. Problems similar to those noted for 8.3.1e are present. The 8.4 release used an updated conditions database. But the same background file (x5) is used as for the 8.3 releases. There were about 1.6 million events produced, all at SLAC.

Runs 17xxxx of SP2 have been done with the 8.5.1 releases, 8.5.1a, 8.5.1b and 8.5.1c. Problems similar to those noted for 8.3.1e are present. Again the 8.5 release used a conditions database that was updated from the 8.4 release one. But the same background file (x5) is used as for the 8.3 and 8.4 releases.

Known problems with 8.5.1 releases include a very large SimAppApp time which seems to be due to EMC conditions. The large SimAppApp run times were not seen when running into sp2testboot. For 8.5.1c and perhaps earlier releases the reconstruction time, with BearApp, into sp2prodboot is about 0.4 seconds longer per event than for the same run into sp2testboot.

Early running with 8.5.1 was unreliable at SLAC. This may have been due to database lock problems and server crashes associated with access to the same database federation from Livermore.

Performance improvements in the 8.5 release came about through code improvements and upgrades of the SLAC farm to faster processors.

This final phase of SP2 produced 3.2 million events, 80% done at SLAC and most of the rest done at IN2P3 and Colorado

SP3

SP3 began March 21, 2000. Each month a conditions snapshot is taken which represents conditions for the previous month. Background files are obtained mixed. This and other aspects of production are documented in the HOWTO package in HOWTO-Setting-Up-SP3-FDB. This contains a table which is updated each month with the relevant release, CONDALIAS, conditions and BG files and the tag of ProdTools used for production:

Run numbers start with 200000 for Feb and increment by 10000 each month for Feb2000-Jul2000. Starting in early October, we began to use a single release (8.8.0c) to redo all MC to match 2000 data. We started a scheme where the replication is done to approximately luminosity weight the various months. The weightings are (Feb-Oct) 1,2,2,2,3,3,2,2,2. Jun, Jul, Aug2000 are in progress as of the end of October and Sep2000 will begin soon. Earlier months will be done as others are finished.

Useful Contacts