Versions Compared

Key

  • This line was added.
  • This line was removed.
  • Formatting was changed.
Comment: Migration of unmigrated content due to installation of a new plugin
Warning
titleWarning

The tool has been generalized and externalized. The last releases of source code, documentation and pending issues are now available at the new TRAC server. The specific issues and features for FERMI are in the documentation guide called TSkim for FERMI, which should be more complete than information below.

Use of the skimmer on Noric machines

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 :

No Format

/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.00c-gl1/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.14.00g/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_* If one want to use the last release v3r10, he can simply set the relevant shell variables (as described in the user guide) and , one can simply type :

No Format
/afs/slac/g/glast/ground/DataServer/v3r10v6r1/bin/skimmer

Of course, it is sane more confortable to define an alias for it in your Unix account setup files, or add the DataServer bin directory to the Unix PATH .:

No Format

sh> export PATH=<SKIMMER_DIR>/<release>/bin/skimmer:${PATH}
csh> setenv PATH <SKIMMER_DIR>/<release>/bin/skimmer:${PATH}

For what concerns the external tools, at runtime, the skimmer v3r10 depends on :

  1. Perl 5, which should be found with "/usr/bin/env perl".ROOT 5.10.00 to 5.16.00 : the user can specify $ROOTSYS to any ROOT release, and it will be used as is by the skimmer, but the only validated releases are 5.10.00, 5.14.00g and 5.16.00 ; if 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 /nfs/farm/g/glast/u05/GLAST_EXT/rh9
  2. _gcc32One of the supported ROOT releases (see above), specified wirh $ROOTSYS.

The predefined data kinds

The list of kinds of input data files trees which can be skimmed is currently hardcoded, and especially targetted to GLAST needs. For each of those kindstree, we expect to have a top main ROOT tree, with a main ROOT branch. Actually, we distinguish two sets of files trees : the ones which only rely on predefined ROOT types and have a single level of branches under the main one (the tuple-like filestrees), and the others. The latter typically requires the loading of a dedicated data description library before the concrete skimming takes place. The last release v3r10 v7r0 should understand the following types :

  • merit (tuple-like)
  • pointing (tuple-like)
  • jobinfo (tuple-like)
  • cal (tuple-like)
  • svac (tuple-like)
  • mc (requires libmcRootData.so)
  • digi (requires libdigiRootData.so)
  • recon (requires libreconRootData.so)

...

  • gcr (requires libgcrSelectRootData.so)

Worth to be noted, some different kind of trees can be grouped in the specific case of merit input files, the skimmer will also systematically merge the 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 trees and write them to separate output files. Those trees are never skimmed, rather always merged.