Warning | ||
---|---|---|
| ||
The skimming tool has been generalized and externalized. The information below is obsolete and related to an old release. If possible, use a more recent release and get the corresponding documentation from the new TRAC server. |
The skimmer is only usable on linux.
The release v4r0 At run time, the release v5r0 depends on :
...
...
...
...
...
...
...
When one wants a given <release> of the skimmer, he must check out the package "DataServer" with the tag <release> from the GLAST CVS repository. Then he just needs to make "bin/skimmer" a reachable executable. For example, if one store stores all the release within under a single <SKIMMER_DIR> directory :
No Format |
---|
prompt> export CVSROOT=:ext:<user>@centaurusa.slac.stanford.edu:/nfs/slac/g/glast/ground/cvs
prompt> cd <SKIMMER_DIR>
prompt> cvs co -r <release> -d <release> DataServer
prompt> export PATH=<SKIMMER_DIR>/<release>/bin/skimmer:${PATH}
|
The list of kinds of input data files which can be skimmed is currently hardcoded, and especially targetted to GLAST needs. For each of those kinds, we expect to have a main ROOT tree, with a main ROOT branch. Actually, we distinguish two sets of files : the ones which only rely on predefined ROOT types and have a single level of branches under the main one (the tuple-like files), and the others. The latter typically requires the loading of a dedicated data description library before the skimming.
The last release v3r10 should understand the following types :
Worth to be noted, in the specific case of merit
input files, the skimmer will also systematically merge the pointing_history
and jobinfo
trees and write them to separate output files.
...
The skimmer top routine is a perl script which will execute a set of binaries. Those binaries are depending on ROOT libraries. When installing a new skimmer release, the administrator must compile the source code several times, one for each ROOT release available at the site and supported by the skimmer. Later on, when a user 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.
Thus, for each ROOT release which is supported by the skimmer (from 5.10 to 5.18) and available on the site, the administrator must :
For the privileged noric cluster, there is a single script "make_skimmer_glast" which is doing this task for all the ROOT releases officially supported by GLAST and the skimmer.
At last, the administrator should make the main access routine "bin/skimmer" a reachable executable. For example, if one stores all the release under a single <SKIMMER_DIR> directory, he can add a software link to "bin/skimmer" in one of the standard directiry declared in $PATH, or extend the definition of $PATH in the site setup files :
No Format |
---|
sh> export PATH=<SKIMMER_DIR>/<release>/bin/skimmer:${PATH}
csh> setenv PATH <SKIMMER_DIR>/<release>/bin/skimmer:${PATH}
|
If you want to skim a kind of data which is not tuple-like, remember the skimmer will need to load the corresponding libraries (such as libmcRootData.so for mc data). So you the site administrator and/or user must ensure those libraries are reachable from the machine where the skimmer will be running, for all the releases which were used when generating the data to be skimmedof interest. If you recompile those libraries locally or copy them from SLAC, remember you must mimic the directory structure used at SLAC (as expected by the skimmer). Especially, for a given <main_package> and a given <release> (for example GlastRelease and v9r3) the path of the directory containing the libraries should end with "/<main_package>/<main_package>-<release>/lib/" ("for the example : /GlastRelease/GlastRelease-v9r3/lib/")). The top directories of those libraries should be declared in shell variable SK_LIBRARY_DIRS.