ROOT

Using Root for Application Development at Jefferson Lab. 

Updated Dec 19,  2017



Versions available

If you login to an ifarm computer ("ssh ifarm") you'll get to a CentOS 7.* computer. You can check which version by "cat /etc/redhat-release".  Here, you may look at /apps/root to see the versions available.  Usually the one labelled "PRO" (a link) is the one you want, but there may be newer versions.

Note, versions of ROOT are also maintained on /site is supported, per the CLAS software model. See the section below.

Generally speaking, if you look at the /apps/root/VERSION/README_BOB file you can see how ROOT was compiled for that VERSION, (e.g. /apps/root/6.06.06/README_BOB), i.e. what compiler and whether I used the "configure" script or "cmake".  For the /site/12gev_phys distributions, lately I've put the information about how root was built in a file $ROOTSYS/README_HOW_BUILT.  All the more recent versions like 5.34.36 and 6.10.02 are compiled using cmake.


Compiler

You should compile your applications with the same compiler and same kind of platform (e.g. RedHat 7.2) that was used to build ROOT.   The recommendation is that you login to the same kind of ifarm node where you'll run your application on the batch farm and compile your application there. Make sure your application runs interactively before running in batch.

Detailed notes on how ROOT was compiled is shown in the README_BOB file in the ROOT directory, e.g. /apps/root/5.34.36/README_BOB and in $ROOTSYS/README_HOW_BUILT on /site/12gev_phys.  I sometimes just used the default gcc compiler that was available at the time, but in some cases  I had to use a more recent compiler.  You must ensure that you set up and use the same compiler.   Note, version 6.10.02 was compiled with gcc 4.8.5, which is the default compiler on ifarm as I write this.

One nice thing about the CLAS software model is that the name of the compiler that was used to compile ROOT appears in the name of the path.  This way it is unambiguous.

Environment

The CUE command "use root/5.34.36" will set the appropriate variables in your environment or you may use the command "source /apps/root/5.34.13/setroot_CUE".
You might need to change that script to have "export ROOTSYS=" instead of "setenv ROOTSYS", etc, depending on the shell you use.  I believe the batch farms need the "export ROOTSYS=" scheme.

A typical environment might look like this:

ROOTSYS /apps/root/5.34.36/root
LD_LIBRARY_PATH $ROOTSYS/lib before others
PATH $ROOTSYS/bin before others

Make sure you have 3 environment variables set: $ROOTSYS, $PATH, and $LD_LIBRARY_PATH !

Note about non-default compilers

ROOT 6.10.02 was compiled with the default gcc 4.8.5, but some earlier ROOT 6 versions were compiled with other gcc versions.  E.g. root 6.06.02 was compiled with gcc 4.9.2 and so it is necessary to invoke that gcc version with the command "module load gcc_4.9.2".  Now I am told that I am told that getting gcc 4.9.2 to work on the batch farm is tricky.  Apparently, the "module" command does not work well there.  Instead you have to set the  PATH and LD_LIBRARY_PATH to look for /u/apps/gcc/4.9.2/bin
or /lib first.  This will let root scripts in root-6 be run (and run-time compiled) without error.   There are presumably advantages to the later compilers, but also less confusion using the default compilers.  Compile your app with the same compiler as all the libraries were compiled with; don't mix compilers (unless you know better), see also "Compiler" above.
 

Packages

Presently I have the following list enabled and it's controlled by a script that uses cmake.

   set enablePackages = ("roofit" "minuit2" "python" "gdml" "unuran" "qt" "gtgsi" "mysql" "reflex" "cintex" "fftw3" "soversion" "mathmore" )

If we need any others, please let me know and I'll fix it ASAP. 

I can also add missing packages and I check, as part of the certification process, to see if packages were successfully made.  Sometimes a package fails to build because some system package is missing, e.g. GSL.
 

The setroot_CUE script

The following script is used to setup ROOT :

!/bin/bash
# Setup ROOT -- do this:  "source setroot_CUE"
# For sh family:
#export ROOTSYS=/u/apps/root/5.34.13/root
#export PATH=$ROOTSYS/bin:$PATH
#export LD_LIBRARY_PATH=$ROOTSYS/lib:$LD_LIBRARY_PATH
# for MacOs you must also set DYLD_LIBRARY_PATH

# For csh family
setenv ROOTSYS /u/apps/root/5.34.13/root
setenv PATH ${ROOTSYS}/bin:${PATH}

if (!($?LD_LIBRARY_PATH)) then
  setenv LD_LIBRARY_PATH ${ROOTSYS}/lib
else
  setenv LD_LIBRARY_PATH ${ROOTSYS}/lib:${LD_LIBRARY_PATH}
endif

 

Root on /site -- the CLAS software model

As per the CLAS software model, https://data.jlab.org/drupal/common-environment , ROOT is maintained in /site/12gev_phys, which we try to update every 6 months or so.  Generally, the identical version is on /apps/root/*. To use the version on /site, please use the setup procedure like below.  As always, the three things to control are $ROOTSYS, $LD_LIBRARY_PATH, and $PATH.  Also, you should check that the command "root-config --version" returns an expected result.  See the example below.

Having logged into "ifarm" and suppose you want to use production version 2.1

ifarm1102> source /site/12gev_phys/production.csh 2.1

A subtlety: if you already have $ROOTSYS and root setup in your environment, the above lines will not "override" your defintion.  Avoid hard-coded definitions in your login script, or use the above line in your login script if that's what you intend to do.

The JLAB_VERSION variable will control a 'set' of software versions and associated dependencies.  The 'production' version will point to the recommended defaults, but that variable may be set to '1.0' or newer versions as they are created. 

Root on your PC using CUE level 2 install

Here are some notes on installing ROOT on on RedHat 7, CUE level 2 using cmake.  The other way to build, using "configure", is considered obsolete, but you can ask me if you want to do it that way.

First, I note that you should add /apps/root/cmake to your path, the one in /usr/bin is old.  E.g. setenv PATH /apps/bin:${PATH}. 

As usual you need the environment variables

setenv ROOTSYS /home/rom/root-6.10.08/root
setenv PATH ${ROOTSYS}/bin:${PATH}
setenv LD_LIBRARY_PATH ${ROOTSYS}/lib:${LD_LIBRARY_PATH}

$ROOTSYS is where ROOT will get installed, i.e. /bin and /lib will appear there.

Now, go to the ./build directory that appears after you untar the root tar file and run "cmake"

cmake -DCMAKE_INSTALL_PREFIX=$ROOTSYS $toDisable $toEnable ../

where $toDisable and $toEnable are packages you may want to disable/enable.  For me, I disable nothing and I enable "roofit" "minuit2" "python" "gdml" "unuran" "qt" "gtgsi" "mysql" "reflex" "cintex" "fftw3" "soversion" "mathmore"

After 'cmake" does its build you type "make install" and you are done, exept for the testing (see next section).

On your local PC, there might be some things (i.e. libraries or packages) missing.  For the full list of what you need and may want, see the ROOT pages:

https://root.cern.ch/drupal/content/build-prerequisites

As explained in that ROOT web page, you can use "yum install" to install the missing packages.  An example would be:

yum install libXext-devel

I think that recent RH 7 distributions managed by JLab have most of what you want, but if you do this on your own (e.g. I use Fedora 27 at home) you have a lot of "yumming" to do.

Testing Root -- Certification

Suppose you have succeeded at installing Root.  How do you test it ?  This is what I do:

  • Check that packages were compiled using a script ifarm:/group/halla/analysis/rootbuild/check_pkg.com
  • cd to $ROOTSYS/tutorials and "root .x demos.C" and click on everything
  • Also run benchmarks.C
  • cd to $ROOTSYS/test and "make".  Then execute some of the executibles like "stress".
  • Run some of your favorite macros, ranging from simple to complicated.
  • Compile and run your favorite executible codes.  For example, in Hall A we can run Podd on ifarm.

If some users want to hand me macros or test code to test, I'd be happy to add it to my checklist of tests.  For example, I don't regularly use Python or FFTW, so I wouldn't know if it's installed properly unless someone else tested it, or you give me some test code. 

New Feature Requests

If you want a new feature, I'll be happy to help implement it.  Email me at rom@jlab.org.  This sometimes involves getting the Computer Center to install the libraries and "include" files of the new feature, and then I have to enable it in the building scheme and compile the appropriate ROOT libraries. 

ROOT on Windows or MAC

ROOT works on these platforms, but they are not supported by me or by the computer center.  Only Linux.

 

12000 Jefferson Avenue, Newport News, VA, 23606
Phone:(757)269-7100 Fax: (757)269-7363