ANAPAW


ANAPAW on Gentoo Linux


Although the general outline of installation method will work for any Linux, I give certain specifc details to Gentoo, such as using portage and gcc_config, which other Linux distributions will need to substitute similar functionality, such as apt-get in Debian, but I am not familiar enough to give the exact detail on other distros here, as I am primarily familiar with Gentoo.

Get anapaw_v-2.3.1.tar.gz (or latest version) from Takeuchi san's website, extract this in

/usr/local and make a symlink for /usr/local/anapaw 
to the
/usr/local/anapaw_v-2.3.1 directory.
  

(I assume you get your experimental data with the relevant anapaw source code from your own DAQ & Analys machines)

Get the 3 tarballs for the binaries of cernlib compiled with gcc34 from http://cernlib.web.cern.ch/cernlib/version.html PC Linux Cern i686-slc5-gcc34-opt(Cernlib 2006)

Extract the cernlib cernbin and include .tar.gz files somewhere like

/tmp or ~/downloads
  

Move them to /cern/2006b/i686-slc5-gcc34-opt and make a symlink /cern/pro to that directory

Since they are precompile and assumed to reside in /cern/pro, you must have this filestructure. If you just want the libraries for ANAPAW, you can put them any place you'd like. IF YOU PLAN TO USE THIS ON A SYSTEM WITH CERNLIB COMPILED WITH GCC4 CONCURRENTLY: DO NOT ADD /cern/pro/bin to $PATH, or be sure your PATH order is correct for which cernlib binaries you really want to use. Some details on this below.

First, if you don't have gcc3, install it through portage. Make sure the `fortran' USE flag is enabled, either globally in make.conf for specifically for gcc in /etc/portage/package.use

# emerge =sys-devel/gcc-3.4.6-r2
  

You need to emerge lapack-atlas, but I believe you need to switch to the gcc34 compiler first or you will get errors with ANAPAW. You can do this with

gcc-config
  

I also rebooted after switching to gcc34 but this should not be necessary (reboot was unrelated to ANAPAW install).

I also added a line to /etc/make.conf

F77=g77
  

(You should probably comment this line out after you install lapack-atlas -- see below for an elegant solution)

Using eselect (if you emerge eselect-lapack) then you can switch between lapack-atlas and lapack-reference, where you know that lapack-atlas is compiled using gcc3 and lapack-reference is compiled using gcc4. You could probably reverse the situation and use lapack-reference as the gcc3 compile lapack for use with ANAPAW and lapack-atlas as the gcc4 compiled version for other use, but I did not test this method.

You also need to be careful on things like emerge world because it will rebuild lapack to a newer version when it becomes available, likely using gcc4 (which I assume is your default compiler when not using ANAPAW), and then lapack will need to be re-emerged using g77 before you can makeana again. This is annoying, so I make a solution for it so I can avoid this trouble.

What I do is not officially supported in Gentoo, but it is a very nice hack.

Create this directory and file

daid@flux /etc/portage/env $ ls
sci-libs

daid@flux /etc/portage/env/sci-libs $ more lapack-atlas
export F77=g77
export CFLAGS="-O2 -march=prescott -pipe"
export CXXFLAGS="${CFLAGS}"
  

The CLFAGS are generally not necessary, but as of gcc43 march=core2 is supported, which is the exact correct setting for Intel Core 2 Duo, which is what I have in my laptop. As such, I use this setting in my /etc/make.conf However, gcc34 won't know what to do with a march=core2, so instead prescott is good for my case. This also has the added benefit of making emerges while I am running gcc3 fail, which is good because I don't want to install most things with gcc3 by accident!

This will ensure that any time lapack-atlas is emerged, it will g77 to compile. We can confirm this is the perfect solution by using gcc-config to change to a gcc4 complier and trying to emerge lapack-atlas:


>>> Emerging (1 of 1) sci-libs/lapack-atlas-3.8.0
 * atlas3.8.0.tar.bz2 RMD160 SHA1 SHA256 size  ;-)  ...                          [ ok ]
 * lapack-lite-3.1.1.tgz RMD160 SHA1 SHA256 size  ;-)  ...                       [ ok ]
 * atlas-3.7.39-shared-libs.patch.bz2 RMD160 SHA1 SHA256 size  ;-)  ...          [ ok ]
 * lapack-reference-3.1.1-autotools.patch.bz2 RMD160 SHA1 SHA256 size  ;-)  ...  [ ok ]
 * checking ebuild checksums  ;-)  ...                                           [ ok ]
 * checking auxfile checksums  ;-)  ...                                          [ ok ]
 * checking miscfile checksums  ;-)  ...                                         [ ok ]
 * You need one of these Fortran Compilers: g77 gfortran ifc
 * Installed are:  gfortran
 * Current Fortran Compiler is set to g77, which is not usable with this package !
 *
 * ERROR: sci-libs/lapack-atlas-3.8.0 failed.
  

This is exactly the result we expect: If for any reason portage tries to re-emerge lapack-atlas using a gcc4 compiler, it will fail, saving us the time of TWO compiles of lapack-atlas (one done automatically by portage during an update with gcc4 and one done manually using gcc3 to regain ANAPAW usage.

But, if we switch the compiler and try to emerge it again, we get a working lapack for ANAPAW built with g77!

You can't emerge cernlib from portage using similar tricks outlined above for lapack because it requires gfortran (and portage won't let it use g77 for some reason), which is why I direct to get the pre-compiled binaries above. In principle you may install cernlib from source yourself, but I find this very challenging. Since ANAPAW just needs the libraries anyway, it's fine to have the pre-compiled libraries directly from CERN.

In /usr/local/anapaw/Setup/setupanapaw

setenv CERNLIB             /cern/pro/lib
  

and also set your ANAPAW_WORK directory and so on like a normal anapaw install.

Since I don't use csh or tcsh required for ANAPAW macros (and Gentoo needs bash for many shell scripts such as in /etc/init.d and for portage ebuilds, so switching the default shell is not an option, although with OpenRC (currently only in unstable branch of portage), which is in production, they are moving /etc/init.d to a newer format that doesn't require bash, so maybe in the future one can switch the default shell in Gentoo) , what I do is hack a solution. Because I only use tcsh for ANAPAW, I make ~/.tcshrc read:

daid@flux ~ $ more .tcshrc
#ANAPAW
alias analogin 'source /usr/local/anapaw/Setup/setupanapaw'
#setenv ANAPAW_WORK $HOME/s30_4/users/crib/
#setenv ANAPAW_WORK $HOME/data/s30_may08_anapaw/
setenv ANAPAW_WORK $HOME/data/s30_july09_anapaw/

setenv PATH
/home/daid/scripts:/sbin:/usr/non-portage:
/home/daid/.gentoo/java-config-2/current-user-vm/bin:${PATH}

analogin

And in ~/.bashrc I have the line
alias analogin="tcsh"
  

So then from bash I can enter `analogin' and it changes to tcsh and sets the environment variables and changes the working directory.

Because I need cernlib and paw compiled with gcc4 for other programs (such as mocadi), I have those emerged through portage using gfortran. If you have a similar case, there is a small tweak that needs to be made for the anapaw source code, inside ANAPAW_WORK/src/makefile

The last line is the original line commented out (good practice for modified code). What I do is switch the order of the LFLAGS and PRIVLIB calls. The reason is that if PRIVLIB is called first, it adds -L/usr/X11R6/lib to the library path *before* -L/cern/pro/lib is added to the library path. Since portage installs the pawlib (and associated files) in this directory, we nee

$(PROGRAM):: $(SRC)
        $(FC) $(FFLAGS) -o $(PROGRAM) $(SRC) $(ANAPAW_LIB)/$(OBJ) $(LFLAGS) $(PRIVLIB)
#       $(FC) $(FFLAGS) -o $(PROGRAM) $(SRC) $(ANAPAW_LIB)/$(OBJ) $(PRIVLIB) $(LFLAGS)
  

If you don't have cernlib installed through portage with gfortran, then you can omit the above makefile change.

At this point, we can analogin, makelib, makeana and everything should work just great!!

To /etc/X11/xorg.conf it is also good to add an option under the Screen section:

Option "Backingstore" "Yes"
  

This is for PAW so that if the histogram window (typically called HIGZ__## @ localhost) will preserve it's data if virtual desktops are changed, etc.