|
This is the principal BBSIM documentation. It draws on documentation written by Kral, Lockman, Wenaus, Wright, and probably others. If you have something to add in any area, or any nugget of wisdom, experience, or advice, please add it or send
it to lockman@slac.stanford.edu. How this document is maintained is discussed further below.
Outline
- Introduction
- Program management
- Program organization
- Installing offsite
- Checking out and building the program
- CVS summary
- Running BBSIM
- Subsystem control
- Debug control
- I/O
- Runtime control
- The geometry database
- Diagnostics and quality checks
- Adding personal and modified code
- Adding a subsystem
- Subsystem hooks
- Coding guidelines
- Analysis and histogramming
- Geant version selection
- Tools and packages used in BBSIM
- Hints and tips
- Gotchas: known problems
- How to get help
- Program history
- Subsystems:
-
- How this document is maintained
BBSIM is BaBar's Geant321-based simulation of the complete detector that is used for detailed detector performance, design optimization and physics analysis studies. It complements the Aslund fast parameterised simulation in that it provides much greater
detail and realism in terms of detector geometry, particle interactions in the detector, decays, showers, magnetic field, detector response, etc. at the expense of execution speed. BBSIM will remain BaBar's production simulation until the Geant4-based
replacement currently under development is complete and fully validated through comparisons with BBSIM and test beam data.
Detailed geometries for all active and inactive detector systems are included in BBSIM. Geometries are current with respect to design, with updates coordinated and often implemented by the subsystem coordinators. The active detectors produce hit level
output which is written along with MC truth and other info to an XDR output file; the output file in turn is read into the Framework where the hits are transformed into C++ objects and used to derive digitizations. Digitization code for all subsystems
resides in the Framework, not in BBSIM (though some relic digitization and reconstruction code still remains in BBSIM).
Geometry parameters are specified in an ascii geometry database using the dbin utility that provides Fortran and C++ access (both are used in BBSIM) to the database. The geometry files are also read by dbio, which provides
output of the database to the XDR output file (see I/O section). dbio should be used for all new simulation code (the Fortran access syntax differs from, and is an improvement over, dbin). dbin is still present only to support legacy code which is too
extensive to make syntax conversion to dbio worthwhile.
The field map is an interpolation of a 2D grid based on an ANSYS model of the field developed in Genoa. Field map selection (other options are the original default -- a 1994 LLNL-developed map you should not use -- and a version with fixed field within
the coil and Genoa map outside) is done with the fld_flg parameter in the 'run' structure in gnbase/run.db.
Physics generators (Jetset, KoralB) are interfaced via a BaBar-developed interface package beget that uses the STDHEP common block definition.
Hadronic interactions are selectable between GHEISHA, FLUKA, and GCALOR. GHEISHA is the default; contact B. Lockman if you are interested in using FLUKA or GCALOR.
BBSIM developers and users are distributed around the world and work on all BaBar platforms. CVS is used very successfully to manage distributed, concurrent program development. Since 1995 BBSIM has been maintained in the Software Release Tool
system to manage distribution, centralization of libraries, coordinated releases, platform dependencies and to provide (or strive towards) an easy to use environment for program development and use.
Thanks to the porting efforts of many BBSIM developers and users, BBSIM runs on all platforms supported by BaBar.
BBSIM is managed within the BaBar simulation group as part of the BaBar computing system by the simulation manager, Bill Lockman. Simulation coordinators from the BaBar subsystems provide a close coupling between the detector groups and the simulation
development effort (Terry Geld - PEP beam line, Bill Lockman - SVT, Tricia Rankin - DCH, Brian Meadows - DRC, Helmut Marsiske - EMC, Margaret Haire - IFR).
The program is organized as a collection of packages within the BaBar Software Release Tool (SRT) system. The packages making up BBSIM are named with a 'gn' prefix. Note that BBSIM's 4-character subsystem mnemonics predated the final 3-character mnemonics
now in common use. BBSIM will not be retrofitted with the new mnemonics, but new code adheres to the new conventions.
- gnbase
- Base package used to build the BBSIM executables, manage compile-time dependencies, incorporate user code and overrides
- gnbbg
- Framework code implementing initialization, closeout, event loop, Geant interface, etc.
- gnbpip
- PEP beam line simulation
- gnssvd
- SVT simulation
- DchSimGeom
- DCH simulation
- gndirc
- DRC simulation
- gnemca
- EMC simulation
- gnmuon
- IFR simulation
- gntrol
- TRG simulation (superseded by trgDC, trgEM packages which lie outside BBSIM)
- gnutil
- Miscellaneous utility code
- gnmisc
- Miscellaneous material, eg. kumacs, user hook routine templates
- euclid
- External package implementing C++-based Geant321 detector geometries, superceded by the EucIntfce package maintained by John Allison
- unt
- External package for histogramming
- dbin
- External package implementing the geometry and run control database
- dbio
- External package implementing data structure definition and I/O
- workdir
- External package used to run BBSIM interactively or in batch
Offsite installation is now via the offsite installation procedures of the SRT package. Once SRT is installed, BBSIM can be checked out and built as described below.
Once SRT is installed at your site, follow the SRT procedures to obtain the release you want. You can run off the BBSIM executables distributed with that release without checking out BBSIM yourself at all.
Check out the workdir package, 'addpkg workdir; gmake workdir.setup', or go to your existing workdir area, and set up the release link to point to the system-level release area, eg. 'gmake setup RELDIR=$BFDIST/releases/3.1.3'. You are then ready to run
BBSIM version 3.1.3 in the usual workdir way (via the 'bbrun' script; see the workdir README file).
If you want to build your own version of BBSIM, see the next section.
If at SLAC you have the proper login setup (make sure you're in the bfactory group; type groups to check), or if on a remote site the SRT package is set up, then building the program from scratch is done by getting the base module gnbase ('addpkg
gnbase') and typing 'gmake gnbase.all'. This will build the batch version ('gmake gnbase.batch' is equivalent). To build the interactive version, use 'gmake gnbase.int'. If you think things might be screwed up in your area, type 'rm -f bin lib tmp' and
gmake clean, then finally gmake gnbase.all. This procedure, though slow, can rescue you from a state of confusion.
If you are on an IBM, your compiler may not have available the preprocessor that converts VMS style Fortran structures (used in BBSIM) to Fortran 90 (this compiler became a pay-extra option at a certain point). You are advised to use 'setenv VMS2F90
yes' to use our own preprocessor to do the conversion (this is recommended as it works stably and avoids a host of problems that have shown up in trying to rely on the IBM preprocessor).
To build a package yourself into your own executable, check it out (eg. 'addpkg gnmuon'), make any mods you require to the gnmuon/ code, build gnmuon ('gmake gnmuon.all'), then build BBSIM ('gmake gnbase.all'). Read the section below on incorporating
personal code and modifications before you try this.
See the software administration page for information on SRT. Particularly helpful is the SRT
reference page.
There are two ways of running BBSIM within the SRT system. The original way is to use the 'bbsim' script in gnbase; from the top level SRT directory type 'bbsim'. As of release 6.10.11 (gnbase V00-12-27-03 or beyound), the bbsim script has been modified
so that it runs entirely in the current working directory. It no longer does a cd into gnbase. bbsim script can be used from any directory, including workdir. Type 'man bbsim' for more details.
The recommended means of running BBSIM is the workdir package. The user can either choose the bbsim script, or the bbrun script. Either script will run the desired bbsim executable (batch: bbsimb.exe, or interactive: bbsim.exe) in the workdir's
directory. workdir can be completely decoupled from SRT and moved to a stable private working area such as ~/workdir, and then used to work with whatever SRT version one wishes. Further information is available in the README file in the package.
For production batch running, a batch production system exists. For more information, contact Paul Raines, Adil Hasan or visit the Production web site.
Running interactively
When running BBSIM interactively, answer the "Workstation type?" prompt (normally with just a RETURN). When you get "Ready to read data cards", type read 1 (or other number if you're reading off another Fortran unit) to read the file on logical
unit 1 (ftn01 on HP, fort.1 on IBM, etc.) containing FFREAD cards. After initialization (geometry generation) you'll get the KUIP prompt (probably 'Geant> ') and you're off and running (see the Geant manual documentation on the interactive
environment). Some provided commands are babar z and babar xy to show views of the detector (these commands run the macro in kumac/babar.kumac in the workdir environment).
A few useful interactive commands (see the Geant manual, XINT section, for full details):
- TRIG: process next event. TRIG N to process N events.
- DHIT: draw hits.
- DXYZ: draw tracks. Requires that debug be active (DEBUG card, eg. 'DEBUG 0 100 1', in the FFREAD cards) and switch 3 be set to 1 ('SWIT 3=1 card in FFREAD cards))
- NEXT: clear screen.
- ZOOM: various options for zooming the view. See HELP ZOOM.
- HELP: comprehensive interactive help system.
Each subsystem, including user hook routines (controlled by the USER card) is controlled by a FFREAD data card with the subsystem name. If the card is not present or is set to 0, the subsystem geometry is not present. '1' turns on geometry only and '2'
turns on geometry and hits/digi/analysis. In the case of muon code '2' turns on hits only and '3' turns on analysis/histograms. eg. a line MUON 2 in the FFREAD card file will turn on MUON system geometry and hits.
There is a 'debug' structure in the database file gnbase/run.db for control of debug output level. Each subsystem can control its own output level via its own flags. Generally 0=no output except for error messages ... 9=lots of output. The EV flag
controls event number printout (1=ev# printed for each event). Consult run.db for more info.
I/O of event and (if we need it) geometry information is via the McFio package from Fermilab, which is based on XDR. I/O code for data structures and geometry is automatically generated by dbio. The default output file is bbsim.xdr. Filename is
controllable via runtime.db (see the dbio structure in gnbase/run.db).
The following is on the output file:
- A header block to transfer dbio (.ds file) defined data structures containing derived geometry data to digitization and reconstruction
- A header block to store the geometry and run control database (.db files) on the file (not turned on yet as of 3/97)
- Event-by-event:
- A block containing the HEPEVT common block providing info on generator particles
- A block containing the BBSIM event data, hits and MC tracks and vertices. The data structures are defined in the *.ds files of the XxxData packages read by the master file DbiEvent/bbdata.ds, and the set of data structures that is written is specified
by the DbiEvent/bbsim_event.c file.
The event data block contains the Geant3 tracks and vertices as well as hits. An event object is also written that contains run number, event number, and random number seeds.
Backward compatibility: When a data structure written to the XDR file changes its structure, via a change to one of the *.ds files, new versions of programs that read the XDR files are unable to read old XDR files. An XDR file version number is
maintained in DbiEvent/bbdata.ds (the top-level data structure definition file) in order to keep track of this; if any data structure changes in a release this version number is incremented.
Backward compatibility across releases involving structure changes is only possible via special coding; eg. see the DbiEvent/bbsim_event.c and event_to_xdr.c files' special provisions to read V100 data (search on '100'), introduced to read Feb'96
production data with later releases after a DIRC structure change.
Because of this limitation, we make an effort to keep structure changes infrequent and well-motivated.
A fix to this limitation has been foreseen for a long time. It involves modifying dbio to store structure descriptions on the file and dynamically accommodate changed structures. But no manpower is available to do this. So, we await a migration to
Objectivity based event store that will provide proper support for versioning.
A record of compatible versions is maintained on the web.
Conventional Geant I/O of initialization structures (geometry) and events (hits) is controlled by FFREAD cards. Init structures are Zebra RZ files and event structures are Zebra FZ files. Both contain standard Geant Zebra banks.
Geant initialization structures:
Geant data cards: RSAV 'INIT' to save
RGET 'INIT' to read
(don't have them both active at the same time.)
Structures are written to or read from a Zebra RZ file specified
in run.db, the default is "init.rz".
Event I/O:
Geant data cards: SAVE 'TRIG' to save
GET 'TRIG' to read
Specifying 'TRIG' saves all of HEAD,KINE,VERT,HITS,DIGI,JXYZ
Or, banks can be specified individually.
Events are written to or read from a Zebra FZ file specified
in run.db, the default is "event.fz".
The Geant initialization and event-level I/O are of very limited (essentially zero) usefulness. BBSIM's initialization is fast enough that there's never been much point to initializing from an input file, so there is no guarantee that initializing
a subsystem from an RZ file will generate the same results in a simulation run as initializing normally (normal initialization may, for example, fill common blocks which are not filled when simply reading the RZ file). As for the event file, no use is
made of this file in BaBar. The XDR file is the supported event format. Fred Kral has made use in the past of reading single or multiple FZ files into BBSIM for reprocessing, but this has not been exercised since '95.
Runtime control is currently split between dbin/dbio and FFREAD. See run.db for the dbin run time flags. See gnbase/dat/ftn01 for an example FFREAD deck. Details on FFREAD cards are in
doc//BFROOT/www/Computing/Offline/Simulation/web/input and for the trigger doc//BFROOT/www/Computing/Offline/Simulation/web/input.trigger. Absolutely no new FFREAD
controls should be implemented. Implement new controls in run.db or control structures in the subdetector .db files. No new FFREAD cards are to be implemented.
Parameters describing the geometry of the detector (as well as parameters describing materials, hits, control flags, runtime flags, etc.) are stored in an ascii database system based on the dbin/dbio packages (see the tools area on the simulation page).
Official database files are in *.db in gnbase and the subsystem gnxxxx packages. The master database file (which references other files specific to each subsystem) is gnbase/bbgeom.db.
This database is at the present time the official repository of BaBar geometry for offline software. Migration to an OODB in the future is foreseen.
The gmake procedure copies all .db files to a working area directory (tmp/$BFARCH/gnbase/) from which dbin and dbio are run to autogenerate the database interface code. At runtime personal mods to the database and runtime flags can be put into
workdir/runtime.db. If you want to change the archived version of a database file, you have to change the gnbase or subsystem version and commit it.
VERY IMPORTANT WARNING: if you change the structure of the database, eg. by adding a new structure, adding or removing parameters in an existing structure, or changing the dimension of an array in an existing structure, you have to
rebuild the database interface before proceeding: gmake gnbase.include followed by gmake gnxxxx.all and gmake gnbase.all to rebuild the package concerned and the full BBSIM program. There is no mystery to this: if you change the db
structure you have changed the Fortran/C++ structures that map the database so you have to rebuild the database include files and interface code and recompile.
Note that this procedure is not necessary if you just change the values of parameters in the database. If you just change values, you can rerun the program immediately.
xdrCat program: The xdrCat program is part of the SimUtils package that was added to the SRT distribution with 1.2.1. It is used to concatenate XDR files together and to scan the XDR file content to look for problems. Presently some simple checks
are implemented, checking for zero instances on the file of expected structures like hits, and checking the ranges of parameters (presently only for drcGHits). The concatenation function is to be used in production to merge like runs. ALL structures on
the file appear on the concatenated output.
'xdrcat file1.xdr file2.xdr fil3.xdr' will scan the files, report detected warnings, and print an end-of-file summary of structure counts on the file, similar to
scanXdr End Of File Summary:
gEvent avg n/ev = 1 lo = 1 hi = 1
gTrack avg n/ev = 78 lo = 64 hi = 90
svtGHit avg n/ev = 74 lo = 61 hi = 86
dchGLayHit avg n/ev = 668 lo = 597 hi = 756
dchGWirHit avg n/ev = 838 lo = 737 hi = 966
drcGTrkHit avg n/ev = 201 lo = 127 hi = 304
drcGHit avg n/ev = 550 lo = 491 hi = 655
emcGHit avg n/ev = 214 lo = 200 hi = 229
ifrGHit avg n/ev = 21 lo = 3 hi = 55
The '-v' option sets the verbosity level, 1=low (production), 9=high (full debug). The '-h' option gives help. The '-o filename' option turns on concatenation, output to the specified file. The '-n' option turns off diagnostic scanning.
To incorporate personal code, after checking out gnbase with the 'addpkg' command and before building BBSIM with gmake, put your personal routines in the provided gnbase/src/user directory. Code placed here will be built into the executable. If you also
have include files of your own, referenced in your personal code, put these there too, and reference the include files as #include "myinclude.inc", ie. no directory prefix. The current directory is on the include search path.
A subsystem USER with a set of hook routines identical to a normal subsystem is defined for personal use. Template routines are found in doc/templates in the gnmisc package (ie. 'addpkg gnmisc'). To use these routines, put your versions in the
gnbase/src/user/ directory. The USER subsystem is controlled in the same way the other subsystems are; in particular, be sure the FFREAD card USER 2 is present to activate the subsystem.
If you want to override the 'official' version of a BBSIM routine, the reliable and recommended way to do it is to check out the package containing the routine, modify the routine in the package, 'gmake package.all' to build its library with the
modified routine, and then build BBSIM. Just putting the modified routine in gnbase/src/user can expose you to dependencies on linker behaviour that may result in your modified routine not being the one used in the built executable.
If you are incorporating modified versions of routines such as gnbbg/gustep.F that start with a line `#include "gnbase/Flags.h"' you have to take special action to successfully incorporate your mods in the link. It is not sufficient to
'gmake gnbbg.all' to compile your modified routine into the libgnbbg.a library before the link (and putting your modified routine in gnbase/src/user doesn't work consistently either). These routines contain conditional compilation directives which are
handled by gnbase/src/bbsimb_out.F; this routine pulls in all the files such as gustep.F which use conditional compilation and compiles them into a .o file which goes into the link and overrides the version in libgnbbg.a, even if you've privately
checked out and built gnbbg, and can also override a version copied to gnbase/src/user. It has to be done this way so that one can set the conditional compilation flags in gnbase/src/Flags.h, do gmake gnbase.all, and get an executable in which all the
conditional compilation is properly handled. I'd like to have rebuilding bbsimb_out.F handled automatically by proper dependencies but noone has made that work yet. You have to 'touch gnbase/src/bbsimb_out.F' after editing any routine appearing in
gnbase/src/bbsim.h, which is the list of conditional compilation routines used by bbsimb_out.F and then do the gmake gnbase.all. The procedure is thus (to eg. modify gustep.F)
- addpkg gnbbg and addpkg gnbase
- make your mods to gnbbg/gustep.F
- touch gnbase/src/bbsimb_out.F (or bbsim_out.F for the interactive version)
- gmake gnbase.all
We aren't doing this much anymore. Consult B. Lockman for information.
Subsystems have a standard set of hook routines available named XX_NAME where XX is the unique subsystem identifier (first 2 characters of the subsystem name) and NAME is the hook name. If you are implementing a new subsystem, look at the existing
subsystems for guidance on how to use these hooks. Hooks are as follows:
- XX_DEFS: baggage; doesn't do anything other than load one variable.
- XX_VRFY: called after database, runtime parameters are loaded; can be used to verify consistency, report parameters, etc.
- XX_TMED(ITMED,ITMAT): for defining materials. ITMED is media index which must be maintained, increment before using; ITMAT is similar material index.
- XX_VOLU(IROT): Volume definition routine. Geometry and sensitive detectors are defined here. IROT is the rotation matrix index which must be maintained; increment before using.
- XX_STEP: Called by GUSTEP when inside active detectors of this subsystem. Hook for creating hits.
- XX_OUTP(ISKIP): Called at the end of each event. If ISKIP is set to one by this routine, event will not be written to the output event stream (thus a filter can be implemented). This is the hook routine for analysis and histogramming.
- XX_LAST: Called at end of run. For closing out analysis, final report, etc.
In order to produce BBSIM code which is portable (ie, which can be compiled and run with reproducible results on different unix platforms), please observe the following:
- Use strong typing in Fortran. IMPLICIT NONE should appear in each routine.
- Use #include "package/fname.inc" for include files. The makefile is set up to expect and properly interpret this form to build dependency lists.
- For PARAMETERs, declare the TYPE before the PARAMETER statement. Some compilers won't have it any other way.
- Data on declaration lines not allowed! eg. LOGICAL FIRST /.TRUE./ is a no-no. Data must be in a separate DATA statement.
- List-directed I/O on internal strings is not allowed. eg. WRITE(LINE,*)...
- DOUBLE PRECISION should be used rather than REAL*8.
- Strings in a common block must come last in order that non-string variables are word-aligned.
- Degree trig functions (eg. TAND) should not be used.
Thank you.
This being migrated out of BBSIM into the Framework. Subsystem analysis code (xx_outp hook) is generally activated when the subsystem flag is 2. How analysis is controlled is rather ad-hoc and subsystem dependent.
The Geant version used in BBSIM is 3.21.
The full Geant sources and libraries are being added to SRT (package geant321) at a pretty low priority level (ie it's been in the works for a long time).
- DBIN. dbin is the database/data input utility used for the geometry database. It provides Fortran and C++ programs with common access to an ascii
database, with automatic generation of all read and access code for both languages. It was developed by Torre Wenaus, LLNL. SRT package 'dbin'.
- BEGET. BEGET is an event generator framework for CP violation on the Y(4S) that provides an interface to standard generators (Jetset, KoralB) as well as
special functionality for our physics environment. It was developed by Doug Wright, LLNL. SRT package 'beget'.
- EUCLID. Euclid provides the capability to code Geant geometries in C++. It was developed by Torre Wenaus, LLNL and is used for the muon and magnet system geometries.
SRT package 'euclid'. The application code unique to BBSIM is in gnbase/src/. It is now replaced by the EucG3Intfce package coordinated by John Allison.
- FLUKA. Fluka is a hadronic interaction package, an alternative to Gheisha that is Geant's default. To activate Fluka, activate the _FLUKA_ flag in gnbase/src/Flags.h and remake the program (gmake gnbase.all). Use the card HADR 4
in the FFREAD cards to activate the Fluka option (no HADR card defaults to Gheisha). Wright is expert on its use in BBSIM.
- GMAKE. GNU make is a much improved version of make distributed by the Free Software Foundation, available at prep.ai.mit.edu in pub/gnu. Like all GNU tools that use their splendid new configure procedure, it installs quite easily; just follow
the instructions. Note that the default makefile name (used by BBSIM) for gmake is GNUmakefile, not Makefile.
- LEX. Standard Unix tool to implement parsers, used by dbin. If unavailable or if you have trouble with it, try GNU's flex (see gmake retrieval instructions). Wenaus is expert on its use in BBSIM. Implementing dbin with Lex was a MISTAKE.
(That's why dbio was recoded to be Lex-free). Stay away from Lex.
- GAWK. GNU version of the standard unix string manipulation tool, awk. Used by the makefiles and pam2unix. See gmake retrieval instructions. Wenaus, Wright are experts on its use in BBSIM.
- CPP. The C preprocessor, found on every unix platform. Used in BBSIM for include file handling and conditional compilation in Fortran and C++ sources. Any unix literate person can help you with it.
- CVS Concurrent Versioning System. A GNU product, layered on GNU RCS, with a SLAC-developed layer layered on top of (or integrated with) CVS. Supports concurrent development -- concurrent REMOTE development with rCVS -- of software packages
maintained in one central place, the CVS repository (which is in $BFROOT/repo at SLAC). Provides archiving and version tagging. Used to maintain BBSIM. Terry Hung at SLAC is an expert.
- HBOOK. CERN's histogram and ntuple package, used by BBSIM. Interface to it used by BBSIM is the UNT package ('unt' in SRT).
- PAW. Physics Analysis Workstation, the interactive environment to plot histograms and analyze ntuples. Any developer can help you with HBOOK and PAW.
- UNT. A friendly layer over the nasty HBOOK for defining and filling ntuples (now also Column-Wise ntuples - HP only) and histograms. Developed by Doug Wright and used in many
BBSIM subsystem analysis codes (eg. muon in src/muon/mu_hist.F).
- STDHEP. Generator-level standard event format and particle ID scheme by Lynn Garren, FNAL. The format in which BBSIM reads generator events. SRT package 'stdhep'.
- CLHEP. C++ Class library for high energy physics by Leif Lonnblad and others. Used by euclid, dbin. SRT package 'clhep'.
- the compilation warning 'incompatible lengths for common block GCBANK' (or similar) is normal. It arises from Zebra; the true Zebra array length is declared in only one place. In the GCBANK include file the common does not have the full length
declared, hence the warning. This is also the reason you cannot use array bounds checking in the compiler.
- if you get compilation errors involving undefined variables with names ending in _xxxx, xxxx = subdetector code, suspect immediately that your database files are out of date. Pick up the proper version of the offending package, do 'gmake
gnbase.include', 'gmake gnxxxx.all', and 'gmake gnbase.all' to build first the correct include files, then the subsystem library, then the BBSIM executable.
- if you need to add run-time flags or parameters, geometry parameters, debug flags, or any other run-time variables, use dbin; do not use FFREAD. See, for example, in gnbase/run.db how dbin parameters are used for program control.
- In dbin, if you use a dimensioned char in a structure, include an undimensioned dummy, eg. char '-', before it. On some platforms mysterious C++ compilation errors occur if the first char is dimensioned.
Rule zero is let Torre Wenaus know (wenaus@llnl.gov) what you need help on, so he can help or refer you, and keep tabs on where improvements are needed. Rule one is ask your nearest developer, user, or subsystem coordinator. Rule two is post questions to
the BBSIM or 'unconfirmed bugs' discussion as appropriate.
BBSIM began in January '94. Torre Wenaus integrated work of Saclay (Hamel de Monchenault), LLNL (Wenaus) and SLAC (Eisner) into a complete BaBar simulation, Doug Wright installed it in CVS, and it was adopted as the collaboration standard. A large number
of user/developers evolved it thereafter, with Bill Lockman as coordinator. In 6/95 it was subdivided into SRT modules and package coordinators assigned. In the latter part of '95 the subsystems established subsystem simulation coordinators. In 9/95 Torre
Wenaus became simulation manager, overseeing BBSIM and other simulation activity. Bill Lockman took over again as Simulation coordinator in 7/97, and Peter Kim took on the task of bbsim coordinator shortly thereafter.
These subsystems are maintained in SRT packages of the same name. Note the subsystem names predated the definition of three letter acronyms and BBSIM is not being retrofitted to comply. New code uses the TLAs. Package coordinators are indicated in
parentheses.
Send input and comments to lockman@slac.stanford.edu. Contributors are welcome to modify the file, at SLAC $BFROOT/doc/Computing/Simulation/web/bbsim-guide.html. The document is maintained as a single file for ease of printing, in the absence of
browser/html tools that let you define and print a hierarchical document. This makes it a bit slow to download; sorry. |
