For analysis (including reskimming) this documentation is meant to
be used with analysis-21/analysis-22/analysis-23. (Please make sure you have
all relevant updates from the extra tags page!).
For doing MC production, skimming or
reconstruction you should probably try to match the releases being used in
production. This webpage contains the list of releases used for those purposes.
If you are using 14.x.x series release (e.g. through analysis-23) you
should use cond14boot for both data and MC. If you are using 16.x.x series
releases (e.g. analysis-24) you should use cond16boot.
This message is usually something like:
040508 10:24:42 7268 SysError: TFile::TFile - file /nfs/kan001
/vol6//work/users/elmer/14.1.1/040508-10:23:53/AllEventsKan.01.root can not be o
pened (No such file or directory)
KanEventOutput::KanFileReg.cc(283):Could not open /nfs/kan001/vol6//work/users/e
lmer/14.1.1/040508-10:23:53/AllEventsKan.01.root!! Please check that this file d
oes not already exist, and that you have write access to that location.
The last line of the complaint indicates several possible problems. Others are:
- A collection of the same name has already been written. Try checking with
KanUserAdmin. You should either delete the old collection or change the name of the new collection that you are trying to write.
- One of the directories in "collection space" into which you are trying
to write doesn't exist. Directories were not created by default in analysis-21,
however there is a KanModules tag on the extra tags page which will do this. Make sure you
have that tag and try again.
An example of such a message is:
TUnixSystem::DispatchSignals - segmentation violation
Sometimes the message will contain something other than "segmentation
violation" (e.g. "illegal instruction", etc.). The first thing to note is that
the "TUnixSystem::DispatchSignals" is not the problem itself.
What has happened is that ROOT has noticed that your job is crashing (by
"catching the signal") and it prints this line from its "signal handlers". The
real problem is whatever caused the job to crash in the first place.
If you are going to ask in HN about such a crash, note that it is not
sufficient to post to HN that you saw this "TUnixSystem::DispatchSignals"
message. What you need to obtain is the traceback for the crash. For more
on obtaining the traceback, signals and general debugging tips, see
HOWTO-Basic-Debugging
The advantages of posting all questions to HN over private mail are:
- Many people can help answer the questions. Sometimes it may be the
expert to which you had though to send private mail who answers, but
not always (experts go on vacation sometimes and, despite occasional
evidence to the contrary, may also go to sleep sometimes)
- Others can see both the question and the posted answers and thus
more easily solve their own problems (or even discover that they
had a problem they did not realize that they had)
For all questions as to which datasets to use, you should look at the Data Quality Group (DQG) webpage. For specific information as to which skims
are available at which Tier A sites, you should look at the Tier A
Data Location page. This is also linked from the DQG page.
Often people want to run interactive root. The standard prescription to do
this involves setting the envvars LD_LIBRARY_PATH, ROOTSYS and
PATH to point to the version of ROOT that you would like to run. The primary
problem with this is that if you are using a version of ROOT different from
the one used by BaBar applications the latter risk to get the wrong shared
libraries, etc. whenever you run a BaBar application in the same shell!
(Always remember that envvars are evil...)
To simplify this, BaBar provides a simple wrapper script called 'bbrroot'.
If you run this it will start a ROOT interactive session without
any need to set envvars. By default it will start the version of ROOT which
is being used in the release you are working with (i.e. the one from which
'bbrroot' is taken. If you want bbrroot to start a ROOT version other than
the default one we have provided (in more recent releases) a way to specify
this by putting the version in a ~/.bbrroot file:
noric01> cat ~/.bbrroot
4.00-06a
Bottom line: don't set any envvars to run ROOT. Use bbrroot.
Given an SP "modenum", how do I found out what mode it is, what dec file it corresponds to, etc.?
You should use BbkSPModes for this.