The skimmer is only usable on linux, and most of its features will not work outside of SLAC network, because it needs the access to intput ROOT data files, and to the metadata database for the pipeline I data files (at least for the step which is preparing the list of input ROOT data files). This is why it is recommended to use the skimmer only on noric machines, where any new release is installed by its developers.
Currently, the user must know which ROOT release was used for the data he wants to skim, and should define $ROOTSYS accordingly before running the skimmer. This ROOT release must be chosen within a subset which is defined by the administrator when installing the skimmer. Currently, for the noric cluster, the valid values for ROOTSYS are :
/afs/slac/g/glast/ground/GLAST_EXT/$CMTCONFIG/5.10.00/root /afs/slac/g/glast/ground/GLAST_EXT/$CMTCONFIG/5.14.00g/root /afs/slac/g/glast/ground/GLAST_EXT/$CMTCONFIG/5.16.00-gl1/root /afs/slac/g/glast/ground/GLAST_EXT/$CMTCONFIG/5.18.00/root
For simple kinds of data, such as merit tuples, using a different recent ROOT release should be ok.
If $ROOTSYS is not defined, the skimmer will search for $GLAST_EXT/ROOT/v5.10.00/root. If $GLAST_EXT is not defined, it will be set to /afs/slac/g/glast/ground/GLAST_EXT/$CMTCONFIG. If $CMTCONFIG is not defined, it will be set to rh9_gcc32.
Thus, once $ROOTSYS is eventually defined, together with the relevant SK_* shell variables (as described in the user guide), one can simply type :
/afs/slac/g/glast/ground/DataServer/v5r10/bin/skimmer
Of course, it is more confortable to define an alias for it in your Unix account setup files, or add the DataServer bin directory to the Unix PATH :
For what concerns the external tools, at runtime, the skimmer depends on :
The kinds of trees which can be skimmed is currently hardcoded, and especially targetted to GLAST needs. For each of those tree, we expect a top main branch. Actually, we distinguish two sets of trees : the ones which only rely on predefined ROOT types and have a single level of branches under the main one (the tuple-like trees), and the others. The latter typically requires the loading of a dedicated data description library before the concrete skimming takes place.
The last release v5r10 should understand the following types :
Worth to be noted, some different kind of trees can be grouped in common files, such as merit
, pointing_history
and jobinfo
. When skimming, the result is split among several files, one for each kind of tree. Also, some kind of trees do not have branches for the run and the event ids, such as pointing_history
and jobinfo
. Those trees are never skimmed, rather always merged.
The skimmer top routine is a perl script which will execute a set of binaries. Those binaries are depending on ROOT libraries. The administrator of a given site, when installing a new skimmer release, must compile its binaries several times, for the different ROOT releases available at the site and supported by the skimmer. Later on, when one run the skimmer, the top perl routine will look at $ROOTSYS so to know if the user require a specific ROOT release, and it will use the corresponding set of binaries.
It is necessary to combine the skimmer with different ROOT release, because many kinds of data sets (such as mc) contains complex data structure and require the loading of the corresponding shared library (such as libmcRootData.so), and the later has been compiled with a specific ROOT release. The skimmer binaries which are used must be ones compiled with the same ROOT release, or the final behavior is undefined. That's the general case. Yet, for some simple kind of data sets (such as merit), typically tuple of predefined ROOT types, there is no need to load a shared library describing the data structure, and one should be able to skim with a recent ROOT release, the data generated with a different older ROOT release.
So, on any site, including noric cluster, the administrator has compiled the skimmer for a subset of possible ROOT releases, and the user must choose within this subset.