Run The Job: How to run BaBar applications
In the previous section, you used the
command to compile and link the C++ source code in your test release.
Compiling and linking the code in the BetaMiniUser
package produced an executable named BetaMiniApp.
In this section, you will learn how to run the BetaMiniApp executable,
and BaBar applications in general. There is a brief overview of
program flow, and an extensive discussion of the
from which all BaBar applications are run.
You will run your new BetaMiniApp from Example 2 and view your new momentum histogram.
All Babar applications must be run from the workdir
directory. The basic command to run any analysis job is:
workdir> XXXApp YYY.tcl
where XXXApp is a BaBar executable, and YYY.tcl is a Tcl file.
It is this Tcl file (along with other Tcl files that it sources) that tell XXXApp what to do.
Here is what happens when you run a BaBar executable:
- The application creates the Framework and an AppUserBuild object.
- The AppUserBuild object gives the Framework a list of modules.
- Tcl files (or you, acting like a Tcl file):
- Set up the analysis path: what modules are on the path, in what order,
and whether they are enabled/disabled.
- Set module run-time parameters.
- Tell the input module where to get data, and how much to analyze.
Tcl files and their role in setting up the analysis path are
discussed in detail in the Tcl files section.
In the previous section, you made a brand new BetaMiniApp.
Now it is time to run the new executable. As in the
Quicktour, you go to workdir,
and issue the run command:
workdir> BetaMiniApp snippet.tcl
At this point (although you can't see it), BetaMiniApp
creates a Framework and an AppUserBuild object, which loads
the Framework with modules. One of these modules is your
QExample module. That is why QExample must be included
in BetaMiniUser's AppUserBuildBase.cc file.
After BetaMiniApp performs these two initial actions it sources
snippet.tcl. snippet.tcl sets some parameters and then sources
MyMiniAnalysis.tcl, which in turn sources a number of secondary tcl files
that set up the analysis path. The role of Tcl files is discussed
extensively in the next section.
After a while, you get a Framework prompt:
While the executable is running, a Framework
prompt is given whenever user input is allowed or required. Then you
get to act like a Tcl file. You can issue any legal Tcl command
at the Framework ('>') prompt. This includes ordinary Tcl
commands, and the special
BaBar Tcl commands.
As before, you input some data and then tell the Framework
to process events:
> mod talk KanEventInput
KanEventInput> input add /store/SP/R18/001237/200309/18.6.0b/SP_001237_013238
> ev beg -nev 40
When you exit the Framework you terminate the BetaMiniApp executable and
are returned to your usual unix shell prompt.
Because you ran your job from workdir, the output ROOT file is
placed in your workdir directory. Its name in snippet.tcl is still
set to "myHistogram.root", so it will have overwritten your older
myHistogram.root from the Quicktour.
You can view your new histogram in ROOT:
workdir> TFile f("myHistogram.root");
You should now see the momentum histogram that you added:
TFile** myHistogram.root Created for you by RooTupleManager
TFile* myHistogram.root Created for you by RooTupleManager
KEY: TH1F h1d1;1 MC reco abs mtm difference
KEY: TH1F h1d2;1 Reco track momentum
KEY: TH1F h1d3;1 Tracks per Event
KEY: TH1F h1d4;1 Momentum
KEY: TH1F h1d5;1 TagInspector Status
This confirms that the your compile and link sucessfully
incorporated your code changes into the new BetaMiniApp.
Go ahead and plot your new momentum histogram:
It should look like this:
Finally, Example 2 is finished. You have successfully
edited BaBar code to add a histogram, recompiled and relinked your
code to make a new executable, run the new executable, and viewed
your new histogram. Congratulations!
workdir is the package used to run all BaBar applications.
So it is a good idea to become very familiar with workdir and how it
works, because no matter what other packages you are using, you will
always need workdir. The remainder of this section is devoted to
workdir has links to all of the library and binary files it needs in both
the test release and the base release. Input and output remain local
to the workdir directory.
workdir package is checked out
it comes with the following files:
Before starting to work from the workdir directory you must
set it up by making the setup target.
- Directory with information about repository the workdir
package was checked out from and which version of workdir was checked
- makefile for the workdir package
- general information file
- Subroutines that are loaded during ROOT
- Initialisation code executed at the
start of a ROOT session
- directory of useful kumac macros (for PAW)
- Default kumac that is executed
when PAW starts up in the workdir
workdir> gmake setup
(This target is defined in the
the workdir package. So from workdir, the command is "gmake setup".
From the RELEASE directory, as in the Quicktour, the command is
A main result of
gmake setup is that several symbolic
links are created. These links are:
- This is a link to the production release directory
BFDIST that corresponds to the base
release with which the new release was created.
- By default this is a link to the directory one level
up in the tree, the release directory:
- This link points to the bin directory of the
- This link points to the shlib directory of the
Currently, if you do a
gmake clean from within the
workdir package itself, several of the soft links get deleted or
reset, including the
bin link which will no longer point
to your own bin area - meaning that you will not be able to directly
access your own executables such as
BetaMiniApp which we used
in the QuickTour. To remake
these links correctly, you simply repeat the
command from your workdir directory.
workdir is designed to run applications. Since
input and output remains local to the workdir directory, the
locations of input and output files must be given with respect
to the workdir directory.
When you use your test release to generate an executable like
BetaMiniApp, it is stored in the
of your test release.
gmake setup generates a link
This is the first place that workdir looks for
applications. If it does not find the application there,
then it will look in
In the Quicktour, this meant that when you issued the
command "BetaMiniApp snippet.tcl", the system
RELEASE/bin/$BFARCH/ for your BetaMiniApp executable.
To run the executable you need a Tcl script
as an argument. The
Tcl script has the responsibility of defining the analysis path of the
For example, the BetaMiniUser package used in the
provides example tcl files for several different possible BetaMiniApp jobs:
Any one of these files can be used as an argument to BetaMiniApp.
- MyMiniAnalysis.tcl: Bare outline of an analysis, suitable for filling in with additional code
- MyDstarMiniAnalysis.tcl: Search for the decay chain D*+ -> pi+ D0, D0->K-pi+
- MyK0MiniAnalysis.tcl: Search for a K0 -> pi+ pi- decay.
- MyTimePointAnalysis.tcl: Fetch a specified FCT (Fast Control and Timing
system) time point from the event.
The command to run an executable from workdir is:
workdir> WhateverApp ../<Package>/<filename>.tcl
The second argument locates filename.tcl with respect to workdir.
There are a few other ways to do this (besides "../").
You could make use of the
workdir> WhateverApp RELEASE/<Package>/<filename>.tcl
or you could copy the tcl file into the workdir directory
(or place a symbolic link in the workdir directory without moving the
existing file - see the Workbook section on Unix) and issue:
workdir> WhateverApp <filename>.tcl
In the Quicktour, you ran the job with the command:
workdir> BetaMiniApp snippet.tcl
snippet.tcl is actually NOT one of BetaMiniUser's tcl files,
but it sources (executes) MyMiniAnalysis.tcl right away after setting a few
parameters. You could just as well have changed the parameters
in MyMiniAnalysis.tcl itself, and issued:
workdir> BetaMiniApp ../BetaMiniUser/MyMiniAnalysis.tcl
However most people prefer to use their own personal
snippet tcl files to set parameters. That way, they avoid modifying
standard BaBar tcl files more than they have to. Among other things,
this makes it easier to describe your analysis when you ask other
BaBar people for help. Snippet tcl files are discussed in
detail in the Tcl files section.
As in the Quicktour, applications often write output .root or .hbook
files. The output files are put in workdir. If you want to put them
in a different directory, you need to specify the name of the
directory with respect to workdir. For example,
set histFileName output/myHistogram.root
in your snippet.tcl file puts the ROOT file in the
workdir/output (which you would then of course
have to create before running the job).
Often when compiling your work you will want to issue a "gmake
clean" command to clear out libraries and binaries from a
previous problem with compiling or linking. This should always be done
from your release directory.
However, if often happens that one accidentally issues a "gmake
clean" command from the workdir directory. The main effect of
this command in workdir is that is removes the symbolic link that
workdir has to your
/bin directory - meaning workdir can
no longer 'see' any binaries you have built. This is easy to
fix... whenever you accidentally do a "gmake clean" command
in your workdir, just issue a
command from workdir to rebuild the link. (Or you can do
workdir.setup from your release directory.)
Missing binaries can catch you out in two ways:
There are two ways in which a missing binary will manifest itself:
- If your gmake bin command fails due to some
compile-time error, the binary won't be made
- If you put your release in your scratch area (as in the Quicktour),
and you haven't used your binary for some time (approximately a
week), it will be deleted, as the scratch disk cleans out unused files
- The binary will simply not be found when you try to execute it
- A binary in the BaBar compiled code (in workdir/PARENT) will run,
and none of your changes will be in it
In the second case, what happens is that the system searches for an
executable in your bin/$BFARCH/ directory, and when it doesn't find
one, it looks in the original analysis-42 release, finds the
central, pre-compiled binary, and uses that one instead.
This problem can be very difficult to spot - the code
appears to run just fine, but none of your changes are in the output
In either case, the way to check things is to look at output from
the compile and link stages and, particularly if it is just the case
that you haven't tried to run your binary for some time, check the
ls -l ana42/bin/$BFARCH/
If this directory does not contain the binary you wanted to run, then
the binary hasn't been built, or has got old and been deleted.
A good way to avoid accidentally using the wrong binary
is to always run your executable with its full path name:
(Note that workdir/bin is a link to the bin directory in your
Of course, running with the full path name will not prevent
binaries from going missing. But this way, if there is no
BetaMiniApp in bin/$BFARCH, the system will give you an error message,
instead of running PARENT/bin/$BFARCH/BetaMiniApp.
Page maintained by Adam Edwards
Last modified: January 2008