SLAC PEP-II
BABAR
SLAC<->RAL
Babar logo CM2 logo
HEPIC E,S & H Databases PDG HEP preprints
Organization Detector Computing Physics Documentation
Personnel Glossary Sitemap Search Hypernews

CM2 - FAQ


To which release does this documentation refer?

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.


What conditions database should I be using with CM2?

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.


When trying to write output I see an error message about opening a file. What does it mean?

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:


Sometime my job crashes with a complaint from TUnixSystem::DispatchSignals. What does that mean?

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


I sent a private mail to an expert to ask for help and he or she told me to post questions to HN rather than send private mail to experts. Why is that?

The advantages of posting all questions to HN over private mail are:


Which skims are available and at which sites?

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.


Why is it a bad idea to set LD_LIBRARY_PATH, ROOTSYS or PATH myself in order to run ROOT?

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.




Last modified 31-Jul-2004, Peter Elmer