This is a DRAFT of SP10 Install Instructions, based on the SP9 version from Peter. Comments and suggestions are welcome. Dave Brown Jan. 23, 2008 last update: Jul. 27, 2008 These instruction just use release 24.2.1c as an example. Other releases can be installed in a similar way. 0) You need SL3, SL4, RHEL3, or RHEL 4 (not confirmed), Objectivity 8.0.9, ROOT 5.14-00e, CLHEP 1.9, GEANT 4.8, and mysql 4.1.9. OBJECTIVITY (Just like SP9) SP10 note ---------------------------------------- Even though we use ROOT based Conditions Database, Objectivity IS still needed due to links in shared libraries. There will be one day we will be free of Objectivity... (allegedly, it will be during the era of SP10). --------------------------------------------------------------------- For convenience I would recommend installing Objectivity 8.0.9 in $BFROOT/package/objy8.0.9 (make the directory if it doesn't already exist). If you install it anywhere else, you will need to configure SiteConfig for it. Since I don't do this, I can't really help you with what variables have to be set in which files. - get Objectivity.R8.0.9.linux86gcc3.tar.gz from /afs/slac.stanford.edu/g/babar/package/objy8.0.9/Objectivity_admin/Objectivity_src/ (NOTE: this file has temporarily disappeared. We are working on getting it back. Feb 5, 2008). - extract, cd cdrom, ./install.sh - select option 3 'Custom Installation' - select 5,9,10,12 - select install directory ( highly recommend $BFROOT/package/objy8.0.9 ) - linux86gcc3 C++ include path /usr/lib/gcc-lib/i386-redhat-linux/3.2.3/include /usr/include/c++/3.2.3 /usr/include/c++/3.2.3/backward /usr/include/c++/3.2.3/i386-redhat-linux - use defaults otherwise - copy liboocx.so from SLAC ( into /linux86gcc3/lib ) - copy oolicense.runtime.txt from SLAC ( into ) ROOT (Same as SP9) Please install ROOT 5.14-00e in $BFROOT/package/root/5.14-00e (Create the directory if it doesn't already exist.) Same as for Objectivity, if you install ROOT somewhere else, you will have to configure SiteConfig for it. Gerald Ragghianti created a tar file for 5.14-00e. Thanks, Gerald! Download it from: http://hep.phys.utk.edu/~gragghia/babar/root-5.14-00e.tgz tar -xvpzf root-5.14-00e.tgz into the directory $BFROOT/package/root and this completes installation. (Actually, it looks like you get a bit of extra file system overhead - the full path to root relative to / at UTK - so you have to move the subdirectories appropriately to get 5.14-00e under the $BFROOT/package/root directory). CLHEP (NEW for SP10!) As of release 24.3.3c, (Jul 26, 2008), we have moved from CLHEP 1.9.2.1 to 1.9.2.1-babar-01. Please install CLHEP 1.9.2.1-babar-01 in $BFROOT/package/clhep/1.9.2.1-babar-01 (Create the directory if it doesn't already exist.) I have created a tar file for clhep 1.9.2.1-babar-01. You may download it from: http://www.slac.stanford.edu/~dbrown/clhep1.9.2.1-babar-01.tar.gz Unpack it with tar -xvpzf clhep1.9.2.1-babar-01.tar.gz in the directory $BFROOT/package/clhep/1.9.2.1-babar-01. Note: If you have already installed your 24-series release, you should cd to the release directory and gmake ldlink to ensure that clhep is linked in to your release successfully. If you have not installed the release yet, gmake siteinstall should take care of this automatically. GEANT 4.8 (NEW for SP10!) Please install GEANT version geant4-08-03-ref-00-patch-03 in $BFROOT/simu/geant4/geant4-08-03-ref-00-patch-03 (Create the directory at your site if it doesn't already exist.) I have created a gzipped tar file you can download to your site: http://www.slac.stanford.edu/~dbrown/geant4.8.tar.gz Download it an unpack it in the directory named above: tar -xvpzf geant4.8.tar.gz Note: If you have already installed your 24-series release, you should cd to the release directory and gmake ldlink to ensure that geant is linked in to your releases successfully. If you have not installed the release yet, gmake siteinstall should take care of this automatically. mysql (NEW for SP10!) Please install mysql libs for version 4.1.9 in $BFROOT/package/mysql/4.1.9/Linux24SL3_i386_gcc323/lib (Create the directory if it doesn't already exist.) I have created a tar file you can download to your site: http://www.slac.stanford.edu/~dbrown/mysql-4.1.9.tar.gz Download it to your site and unpack it to the directory named above: tar -xvpzf mysql-4.1.9.tar.gz Note: If you have already installed your 24-series release, you should cd to the release directory and gmake ldlink to ensure that mysql is linked in to your releases successfully. If you have not installed the release yet, gmake siteinstall should take care of this automatically. ========== 1) Install base release 24.2.1 BFARCH is Linux24SL3_i386_gcc323 quick recipe for release installation : get AFS token setenv BFDISTr /afs/slac.stanford.edu/g/babar/dist (if you are in Europe you should probably import from somewhere closer) * Jesko Merkel reports that it is faster for him setting the * BFDISTr variable as * setenv BFDISTr bbrdist@bbr-xfer06.slac.stanford.edu:/afs/slac.stanford.edu/g/babar/dist * This didn't seem to make a big difference from Louisville, but * did from Dortmund! importrel -pa 24.2.1 >& importrel24.2.1.log importarch -p 24.2.1 Linux24SL3_i386_gcc323 >& importarch24.2.1.log * In SP9 instructions, Peter recommended: "remove AFS token, * might not be necessary, I always do it before 'gmake siteinstall'" * I've never noticed this making a difference, but if you know of a * reason to do this, please let me know. srtpath 24.2.1 cd $BFDIST/releases/24.2.1 gmake siteinstall >& siteinstall.log For more details on how to import releases to remote sites, http://www.slac.stanford.edu/BFROOT/www/Computing/Environment/Tools/SRT/SRTuser-node5.html 2) For lettered version install, just replace 24.2.1 with 24.2.1x, for example, and repeat instructions in step 1. 3) Create test release for 24.2.1c a) srtpath 24.2.1c b) newrel -t 24.2.1c 24.2.1c e) cd 24.2.1c f) srtpath; addpkg workdir; gmake installdirs; gmake workdir.setup 4) No .bbobjy is needed in SP10. 5) Download snapshot (ROOT CDB) Here are some potentially useful notes from the SP9 version of this documentation: * The web page for importing conditions and configuration datasets is here: * http://www.slac.stanford.edu/BFROOT/www/Computing/Distributed/DataDist/cdbCfgExport.html * *** Ashok posted in simuprod-hn how he has set ROOT conditions/configurations at uvic *** * http://babar-hn.slac.stanford.edu:5090/HyperNews/get/simuprod/3001/3/1/1/1.html * *** We will update this document with Ashok's examples! *** Here are my updated instructions for SP10 Downloading the conditions snapshot is similar to downloading background trigger events, and requires use of BbkImport. BbkImport uses a package that depends on BaBar::SQL, which only exists at sites that use a MySQL or Oracle database. To get around this dependency at other sites, you can create a dummy BaBar::SQL package. Create a file $BFROOT/lib.shared/perl/BaBar/SQL.pm which looks like this # # dummy module # package SQL; 1; Importing database files to your site (and later exporting data to SLAC) requires that you have passwordless access to the bbrdist account on the bbr-xfer0x machines at SLAC. Test this by trying to login via ssh to bbrdist@bbr-xfer01.slac.stanford.edu. If this doesn't work, you need to have your server's rsa key added to the authorized_keys file in the bbrdist directory at SLAC. To do this, first login to your production account on your head node at your site. ssh-keygen -t rsa Hit when prompted for a passphrase. Send the contents of the resulting public key file to Wilko Kroeger (wilko@slac.stanford.edu) and ask him to put the key in the bbrdist account's authorized_keys file. You should now be ready to import the conditions database: BbkImport --dbsite=slac --dbname bbkr24 --noupdate-sql \ --dataset Nonevent-CDB-cond24boot-full --remote=0 --ftp-type=bbcp \ --nstreams 10 --window 1M --multiple 10 --reverse \ bbrdist@bbr-xferlfi.slac.stanford.edu And to get the configurations db: BbkImport --dbsite=slac --dbname bbkr24 --noupdate-sql \ --dataset Nonevent-CfgDB --remote=0 --ftp-type=bbcp \ --nstreams 10 --window 1M --multiple 10 --reverse \ bbrdist@bbr-xferlfi.slac.stanford.edu After the imports, you can do KanUpdateRulesCDB /store/cdb/cond24boot/full/2008/02/20080206T112915/CDB-20080206T112915-cdb_boot.root KanUpdateRulesCfgDB /store/cfg/2008/01/CfgDB-20080117T232751.root (Using the appropriate file names for your import). This will update the kanga rules files for you. In general To find out what snapshot you will need and where to download it from, go to http://www.slac.stanford.edu/BFROOT/www/Computing/Offline/Production/run_ranges_sp10.html 6) Download new set of background triggers srtpath 24.2.1 get AFS token BbkImport --dbsite=slac --dbname bbkr24 --noupdate-sql \ --dataset BkgTriggers-R24 --remote=0 \ --ftp-type=bbcp --nstreams 10 --window 1M --multiple 10 --reverse \ bbrdist@bbr-xferlfi.slac.stanford.edu The is the directory that contains store/SP/BkgTriggers. The '--nstreams ...' options are all bbcp options, depending on your site setup you might need other options here (especially the reverse might or might not work). The options quoted here worked for me at Louisville. Again, BbkImport uses a package that depends on BaBar::SQL, which only exists at sites that use a MySQL or Oracle database. To get around this dependency at other sites, you can create a dummy BaBar::SQL package. Create a file $BFROOT/lib.shared/perl/BaBar/SQL.pm which looks like this # # dummy module # package SQL; 1; Overall this will import ~10GB of new background collections as of mid-February 2008. This amount will grow as more background becomes available. Make sure you have enough free disk space. Update: The connection to slac is setup in ~/.bbk by the BbkGetConnectInfo script. That script is part of the release, but also part of the bin package and the bin package is first in the search path. The bin package version of the script uses /usr/local/bin/perl, not the site specific configured perl version for BaBar. Make sure /usr/local/bin/perl exists, set a link if it doesn't (or modify the bin version of BbkGetConnectInfo). 7) How to convert to ROOT CDB from Objectivity CDB The default setting for Conditions database is to use Objectivity. To use ROOT CDB, the environment settings should be changed: setenv CDB_ROO_BOOT kanga::/SP10/full/cdb_boot.root setenv CFG_DEFAULT_IMPL ROOT unsetenv OO_FD_BOOT 8) Validation runs for 24.2.1 Make sure to use the correct ProdTools version (currently V00-07-02). The validation runs for each SP10 release are listed at http://www.slac.stanford.edu/BFROOT/www/Computing/Offline/Production/run_ranges_sp10.html Compare your validation runs against the SLAC reference runs for both architectures (amd and intel). A separate run range will be used for each architecture. There is a standard script to make validation easier. I know some sites wrote their own versions, here is how to use the standard: validate.csh \ An example : cd $BFROOT/prod/log/validation/ validate.csh intel 5990265 5990273 slac 01 osu 02 Checking run 5990265 : Number of discrepancies: 0 Checking run 5990266 : Number of discrepancies: 0 Checking run 5990267 : Number of discrepancies: 0 Checking run 5990268 : Number of discrepancies: 0 Checking run 5990269 : Number of discrepancies: 0 Checking run 5990270 : Number of discrepancies: 0 Checking run 5990271 : Number of discrepancies: 0 Checking run 5990272 : Number of discrepancies: 0 Checking run 5990273 : Number of discrepancies: 0 9) First 24.2.1 generic MC allocation For SP10 the dimuon mode 3981 will be part of the generic MC production, so an onpeak generic allocation will from now on contain modes 1235,1237,1005,3429,3981 and 998. Make sure to use the correct ProdTools version (currently V00-07-02). I highly recommend to try the 'spbuild -n ' feature to build runs. It will connect to SLAC, find the runs allocated to your site and build them. Sprite will use this feature, so you don't have to prebuild runs anymore, sprite will do that too. If you use site specific options for spbuild (--local for instance), this is not yet supported (but will be soon trough an option in sprite_rc). If you want to prebuild runs because you need site specific options, you can either use spbuild run1-run2 or spbuild -n 100 I would recommend to use the second command to check that it works. You have to use it repeatedly to get all the runs in the allocation build. If less than 100 runs are left, spbuild will build whatever is available. If no runs are left, spbuild will do nothing. If you use the '-n' option to build runs, also check that you get the runs allocated to your site (compare to email I sent you). The system we envision is to use sprite for a fully automated MC production. Sprite will build the runs that are allocated to your site. When the pool of allocated runs to your site falls below a certain threshold, I get an automatic notification (not in place yet) and allocate more runs to your site. SP production at your site just keeps on going. The current sprite will always build SP8 runs, even if you want to use it to handle SP6 production. For sites that still produce SP6 MC and which want to use sprite for both SP6 and SP8 production this causes a problem since the SP6 sprite will build and submit SP8 runs which will then of course fail because they will run against the wrong database. For now do not use sprite with SP6. To fix this we will add an option to sprite_rc to select the cycle. By creating two sprite_rc versions, one can then run two sprites like this spcontrol -f sprite_rc start This also means two different ALLRUNS directories (and merge directories) will be needed, one for SP6 and the other for SP8. The sites that will probably produce at least some SP6 MC are osu, cu-boulder, infn and maybe uvic. These sites should seperate SP6 and SP8 into different ALLRUNS and merge directories if they want to use sprite. If they don't want to use sprite, SP6 and SP8 production can in principle work in the same ALLRUNS and merge dirs, but I think it's still a good idea to keep them seperate. ==========================================================================