SLAC	PEP-II
BABAR
SLAC<->RAL

HEPIC	E,S & H	Databases	PDG	HEP preprints
Organization	Detector	Computing	Physics	Documentation
Personnel	Glossary	Sitemap	Search	Hypernews

Comp. Search Who's who? Meetings FAQ Homepage Archive Environment Administration New User Info. Web Info/Tools Monitoring Training Tools & Utils Programming C++ Standard SRT, AFS, CVS QA and QC Remedy Histogramming Operations PromptReco Simulation Production Online SW Dataflow Detector Control Evt Processing Run Control Calibration Databases Offline Workbook Coding Standards Simulation Reconstruction Prompt Reco. BaBar Grid Data Distribution Beta & BetaTools Kanga & Root Analysis Tools RooFit Toolkit Data Management Data Quality Event display Event Browser Code releases Databases Check this page for HTML 4.01 Transitional compliance with the W3C Validator (More checks...)

Using Beta The following sections are currently intended to give a flavour of how to use the Beta package. This package is currently under active development and, by definition, the following is not completely up to date. Please consult the Beta web page for this weeks detailed instructions. Beta really consists of five packages: Beta contains the base classes and the candidate classes. BetaUser contains sample code from which you can build your own analysis. BetaTools contains analysis level tools that you might want to use in your program. BetaAslund contains the interface for running with Aslund input. BetaReco contains the interface for running on reconstructed data. Getting started The following instructions may need modification, for example to add specific versions of the listed or other packages. Consult the Beta web page and the Analysis Tools hypernews page for this weeks detailed instructions. To get a running copy of Beta for use with Aslund newrel -t <release number> myBeta cd myBeta addpkg BetaUser addpkg workdir gmake cd workdir gmake setup NB. You should always build the executable (gmake) in myBeta. To run the sample job (after building the executable above): (in workdir) ./betrun ../BetaUser/script.tcl ev begin -nev 100 exit paw his/file 1 framework.hbook (look at plots 1 through 9) To get a running copy for use with bbsim/reconstruction newrel -t <release> myBeta cd myBeta addpkg BetaUser addpkg BetaReco addpkg workdir setenv BetaReco yes (Note: BetaReco=yes is needed for the BetaUser.bin link step only) gmake cd workdir gmake setup You will need to have a ./bbsim.xdr file for the program to read. A link to the one that's shipped with each release will do for a start; it usually contains three events. ln -s PARENT/bbsim.xdr bbsim.xdr NB. You should always build the executable (gmake) in myBeta. To run the sample job: ./betarun ../BetaUser/reco.tcl ev begin -nev 100 exit Files of interest in the package README - similar to this page, perhaps more up-to-date runtime.input - input file for Aslund, copy to workdir to use. Generates $B^0 \rightarrow J/\psi(ll) K^0_s, \bar{B^0}\rightarrow {\rm nothing}$ SampleBetaAnalysis.cc - code for a simple $J/\psi$search script.tcl - framework script to run simple example from the Aslund input module BetaTestModule.cc - boring module for doing specific regression tests, normally disabled by the script Using candidates Pending better documentation, the best way to find the names of available member functions, etc., is to read the BtaCandidate.hh file. Some useful ones are: Accessors to contained information, stated at the primary vertex double charge() const HepLorentzVector vector4() const double mass() const Hep3VectorD p() const double pX() const double pY() const double pZ() const double energy() const The addition operation combines Lorentz vector and charge, but does not maintain mother/daughter information BtaCandidate& operator +=( const BtaCandidate &) BtaCandidate operator +( const BtaCandidate &) const Accessors to values at nearest approach to a point. Note that these can be significantly slower and/or less accurate than accessing the information at the IP. HepLorentzVector vector4(const HepPoint& pt) const Hep3VectorD p(const HepPoint& pt) const double pX(const HepPoint& pt) const double pY(const HepPoint& pt) const double pZ(const HepPoint& pt) const Accessors to specific information, not present in all Candidates const AbsRecoTrack* recoTrk() const const BtaAbsVertex* decayVtx() const Candidates can maintain ``genealogy'' information, which consists of links to ``mothers'' and ``daughters''. The daughters of a candidate C are those candidates that were used by a BtaOperator to create C. C is a mother to each of those daughters. A candidate can have more than one mother. Member functions are provided to navigate those relations. int nMothers() const int nDaughters() const HepAListIterator motherIterator() const HepAListIterator daughterIterator() const bool overlaps(const BtaCandidate&) const Two candidates are said to ``overlap'' if they or at least one of their daughters are the same object. This includes the various form of ``in-law'' relations, but not most form of "cousins". (Shared daughters overlap, but not shared mothers) Service routines: virtual void print(ostream& o) const BtaCandidate& operator =( const BtaCandidate &) Three separate lists of BtaCandidates are kept in each BaBar event: One for Monte Carlo truth information, one for candidates made from reconstructed charged tracks, and one for candidates made from reconstructed neutral objects. These are kept separate to simplify user analysis code; the candidate objects themselves are interchangable. The available operators are: BtaOpAdd4 BtaOpVtx The SampleAnalysisModule.cc and BtaV0Finder.cc files contain examples of the use of these. To combine two BtaCandidates c1 and c2 using vertexing, filling an existing candidate c3: BtaOpVtx op; c3 = op.combine(c1,c2); The operators can also create new'd tracks and directly fill existing tracks, see the header file for details. The + operator is also defined between two candidates. Its intended to be very fast, and the candidate it returns therefore does not have a lot of function. In particular, it does not remember which parent tracks it was made from. c3 = c1+c2;       Hints, tips, pitfalls This only runs from within workdir, due to needed Aslund files. Also, you must have Aslund checked out so that the Aslund geometry files are found (you need not build it, although once you start you must let it build the entire library). Consult the workdir docs for possible ways around this. The 'betarun' script within the workdir package does the setup and execution. The Aslund ``restart'' support is not working, so the program will crash with an "end of file" error if a file named "output" is present in the current working directory. The workdir/betarun script should handle this for you. You need to provide an xdr file to drive the existing input module. The default script expects this to be in the current directory, e.g. workdir under the name ``bbsim.xdr''. The contents don't matter, although you won't be able to run more events in one pass than there are in the file. This is because the existing execution framework requires .xdr I/O to drive events through the pipeline. It will eventually be fixed. Sample code for a simple analysis is provided in the SampleBetaAnalysis files. It's intended as an example of several techniques, not a first step toward a polished analysis. It searches for K0s -> pi+ pi- as an example of a finder routine and vertexing, and then searches for J/psi -> 2 charged tracks using a double loop. (It would be more efficient, though perhaps a less interesting tutorial, to use a finder for both searches, then combine the outputs) It makes various histograms of masses before and after fits, decay lengths, momenta in lab and CM frame, etc. The sample executable also includes the PrintModule (for printing event summary information) and DispModule (for event display). These are by default disabled by the sample script, but can easily be enabled if desired. Because this package continues to evolve, the sample code will be receiving updates. To avoid uncontrolled changes to your code when doing CVS updates in the Beta directory, it would be wise to rename SampleBetaAnalysis.* to something like MyAnalysis.* before you start to use it. (This will require corresponding changes to names in the MyAnalysis.* and AppUserBuild.cc files). An analysis module, like the SampleBetaAnalysis that's provided as an example, is a class. Variables that are needed from event to event can therefore be stored as member variables and directly address. The histograms in the sample are done this way, as they are created in the begin() routine, used in the event() routine, and written out in the end() routine.