Note
You should do all python installation etc as user ‘alma’.
Python modules that are not generally supported (e.g., APLpy) can be manually installed. The source code should be copied into $ALLEGRO_STAFF/src/python2.7.
The source code is generally obtained by downloading it from the internet, or by executing tools like git. After downloading/updating the source files, the general installation procedure is to descend into the module’s directory and compile by
$ python setup.py install --prefix=$ALLEGRO
That was it. The --prefix=$ALLEGRO ensures that the module will be copied into $ALLEGRO/lib/python/site-packages either as a subdirectory or python-egg (a python “zip”-file). The PYTHONPATH is already set when sourcing the rc-files (see General Setup), so that you can start using the new module right away.
It should be mentioned that some packages (e.g., astropy are compiled by using certain versions of numpy or scipy). Therefore, you have to compile them again, once one of these packages are updated.
This is now the default version on all machines but tebinquiche, which runs 2.6. You can run 2.7 on tebinquiche by typing
$ python2.7
There are a few modules/versions available which depend on 2.7. These have mostly been built via the commands
$ export PYTHONPATH=$ALLEGRO/.local/lib/python2.7/site-packages:/software/rhel6/lib/python2.7/site-packages:${PYTHONPATH}
$ python2.7 setup.py install --prefix=$ALLEGRO/.local
In order to use these versions (which may be later than the 2.6 versions), bash users will need to add to their ~/.bashrc the line
pyver='2.7'
whereas for c-shell users the appropriate line in their ~/.cshrc is
set pyver = "2.7"
In both cases, this line should be inserted before the block of code which sources the Allegro login script in $ALLEGRO/bin.
To confirm what module version python is seeing, you can use the python ‘help’ function. As an example, suppose you want to import the 2.7 version of numpy. Do something like
$ python2.7
>>> import numpy as np
>>> help(np)
Help on package numpy:
NAME
numpy
FILE
/software/rhel6/lib/python2.7/site-packages/numpy/__init__.py
etc
You can find the version number by doing
>>> np.__version__
'1.9.0'
>>>
Allegro maintains several versions of CASA compiled for both Red Hat 6 (only on tebinquiche) and Red Hat 7 (all our other machines). You can find which versions are present, and the shorthand commands to invoke them, by typing on any Allegro machine:
ls -l $ALLEGRO_LOCAL_BIN
For example, to run CASA-5.4.0 in the Allegro environment, type:
casapy-54
at the command line (on all machines but tebinquiche, which doesn’t have it). Typing simply:
casapy
will start up the Allegro default version. NOTE however that this is not necessarily the latest version of CASA.
Warning
You have to be user alma to do any of the following.
We use the pre-compiled casa versions that we download from the NRAO webpage. Due to faster access, we store the CASA binaries in /data1/allegro/bin/casa rather than on Lustre.
The default procedure when installing a new version is the following:
Download the gzipped file (in this example Version 4.7.2)
$ cd $ALLEGRO_STAFF/src/casa/rhel7
$ wget https://casa.nrao.edu/download/distro/linux/release/el7/casa-release-4.7.2-el7.tar.gz
Unpack it (unfortunately you have to do this on each machine separately)
$ cd /data1/allegro/bin/casa
$ tar -xvf $ALLEGRO_STAFF/src/casa/rhel7/casa-release-4.7.2-el7.tar.gz
Usually the unpacked files have no group read or execute permissions. Formally one ought not to make all files executable but this is by far the simplest thing to do. Note that there is a script for this now, set_casa_perms, which I wrote mostly because we now also need to set a symlink to make sure that CASA cannot see the system python modules.
Create a symlink to the casapy file in the bin directory
$ cd ..
$ ln -s casa/casa-release-4.7.2-el7/bin/casa casapy-472
Also create a symlink to the appropriate buildmytasks:
$ ln -s casa/casa-release-4.7.2-el7/bin/buildmytasks buildmytasks-47
Note that we only make the buildmytasks symlink for major and minor version number releases, not for patch releases.
Compile the user-provided CASA tasks for the newly installed version (only major releases need new compilations)
$ update_buildmytasks --update
Note
CASA is supposed to be self-contained - in particular, it should not be sourcing any modules from system-installed python. This has turned out to be difficult to implement, since the system python setup is pretty insistent about adding system module directories to the module search path. It has been necessary to add a fix as follows. Each CASA version now on chaxa, tulor and helada (cejar sources tulor’s CASA, and the issue is not present for the older versions on tebinquiche) needs to have a symlink to a central file that controls this. You will already have made this link if you have run the script set_casa_perms as described in point 3 above.
CASA version X.Y can be started with casapy-XY. But there is also a default version, which is the currently used version for manual QA2, that can be started by simply typing casapy.
The default version can be changed by manipulating the symlink /data1/bin/casa/casa-default and pointing it to the new default version
$ ls -lah /data1/bin/casa
total 48K
drwxr-sr-x 12 alma allegro 4.0K Mar 11 13:20 .
drwxr- -lah /data1/bin/casasr-x 4 alma allegro 4.0K Mar 11 15:27 ..
lrwxrwxrwx 1 alma allegro 22 Mar 11 13:20 casa-default -> casa-release-4.3.1-el6
drwxr-sr-x 13 alma allegro 4.0K Nov 3 2011 casapy-33.0.16856-002-64b
drwxr-sr-x 13 alma allegro 4.0K Dec 6 2012 casapy-34.0.19988-002-64b
...
CASA needs to take care of any leap seconds that are introduced. A script takes care of updating the leap seconds table of all installed CASA versions:
$ update_leap_seconds_table
Right now, a cron-job executes that command on the 1st of every month at 2AM. That can be changed by editing the crontab (as user alma):
$ crontab -e
Sterrewacht machines come with pre-installed versions of CASA (used mostly by LOFAR researchers), located in the directory /software/sfinx/bin/. Any user of Allegro machines, provided they source the Allegro-recommended login script (see General Setup), will find that such aliases as casapy, casapy-<version> etc point to Allegro-installed CASA rather than the system ones. You should be aware however that Allegro has not (yet) intercepted other aliases such as casaviewer. These still point to the system versions.
Download the OT from the ALMA Science Portal. New versions of the OT are realeased with every new call for proposals (or also later in case of severe bug fixes).
The tarballs for the ALMA-OT should stored in $ALLEGRO_STAFF/src/alma-ot. Since the OT always comes with the same filename (AlmaOT.tgz), they have to be renamed to actually make a difference between the various cycles and test versions. So the Cycle 2 version for proposal submission should be renamed by adding the Cycle number, e.g., AlmaOT-Cycle2.tgz. Other versions, e.g., the PhaseII-generation version, may have different suffix (AlmaOT-Cycle2-PhaseII.tgz).
In order to install ALMA-OT you have to follow these steps (in this example the AlmaOT-Cycle2.tgz):
Untar the file
$ cd /net/chaxa/data1/bin/ALMA-OT
$ tar -xvf $ALLEGRO_STAFF/src/alma-ot/AlmaOT-Cycle2.tgz
Warning
Some cycles have different versions for the proposal submission (which is available from the Science portal) and the PhaseII generation. But the AlmaOT.tgz might unpack these into the same directory. So unpacking into a temporary location might be necessary to avoid overwriting.
Dive into the newly created directory
$ cd ALMAOT-Cycle2/setup
Run
$ ./Setup-Linux.sh
Create a softlink of the script-file into the bin
$ cd /net/chaxa/data1/bin
$ ln -s ALMA-OT/ALMAOT-Cycle2/ALMA-OT.sh ALMA-OT-Cycle2.sh
Note
It has happened at least once in the past that some files were unpacked with only user read permission. In this case the OT will run for user alma but not for any other. You have to make the files world-readable for everybody to be able to use it.
The Carma version of Miriad is now available on the Allegro machines. After you log in, if your login shell is bash, do
. /net/chaxa/data1/allegro/.local/bin/miriad/miriad_start.sh
or for tcsh, do
source /net/chaxa/data1/allegro/.local/bin/miriad/miriad_start.csh
Your should then be able to see and run miriad as well as the plotting package wip.
Other software packages that are compiled manually are also installed in $ALLEGRO/lib or $ALLEGRO/bin if they are for everybody, or in $ALLEGRO_STAFF/lib or $ALLEGRO_STAFF/bin if they are only for Allegro personnel.
The general practice is to create a directory with the package name, and install the versions in a subdirectory of that package. This subdirectory should then be linked to with a softlink with name current (or something similar). The practice of using softlinks is bascially a maintenance-free solution in terms of updating the rc-files, which always point to the directory current. The softlinks to the current version make sure that always the most recent version is used.