Introduction

Package management of the analysis software that LCLS maintains for users is being transitions to conda, from RPM's. This software includes psana (the software LCLS develops for working with experiment data), hdf5, openmpi, and many python packages such as numpy, scipy, ipython and scikit-beam. Advantages of this transition include

• easier for LCLS to integrate and update new software for users
• easier for offsite users to install psana

User Documentation

Users need to do the following

• use bash as your shell, not tcsh or csh (conda doesn't support csh)
• run the command: source /reg/g/psdm/etc/ana_env.sh as usual (explained in the psana python setup example)
• run the command: source conda_setup

 Sourcing the conda_setup script does a few things

• modifies certain linux environment variables that can affect conda
• identifies the most recent conda environment built for the LCLS Data analysis group
• activates that conda environment

At this point your linux prompt should change to something that starts with the name of the conda environment. For example,

(ana-1.0.7)

Python 3

The LCLS Data Analysis group will maintain conda environments with python 3. To activate the latest python 3 environment, pass the --py3 flag to conda_setup. That is run

source conda_setup --py3

Note - psana has not been ported to python 3. The python 3 environments do not include software to work with LCLS experiment data files recorded by the data acquisition system.

Notes on Provided Conda Environments

• source conda_setup -h for full help on the script
• after sourcing conda_setup, you can execute the undo_conda command to restore your environment
• see conda ana release notes for release notes on these environments
• to switch to an older environment called name, you can use conda_setup with the --env name arguments, or use the standard conda source activate name command.

Newer Package Versions

The conda environments will keep up with the latest versions for many standard python packages. Some notable version changes from the RPM based releases

• ipython, version 2.3 -> 5.1
• matplotlib, version 1.4.3 -> 1.5.1
• openmpi, version 1.8.3 -> 1.10.2
• mpi4py, version 1.3.1 -> 2.0.0
• numpy, version 1.9.2 -> 1.11.2 also conda version is based on the intel MK

New package versions means newer features, bug fixes, but it can also mean old interfaces are deprecated, and new bugs crop in. Some users may need to update their code to run with later versions of packages.

Red Hat 5, 6, 7 Issues

Most users will run on rhel7 machines - anyone doing analysis on the interactive machines or submitting batch jobs to the usual queues will use rhel7 machines. There are some rhel6 and rhel5 machines in the experiment hutch control rooms. In particular users running from shared memory may have to run on a rhel6 or rhel5 host.

Continuum (which produced conda) suggests linux packages be built once in a way that runs on any linux operating system - rhel5, rhel6, rhel7, ubuntu, etc. In practice, for large packages like openmpi that the LCLS Data Analysis group must build local versions of, this can get very technical and lead to a brittle system. Similarly, conda-forge, a primary source of conda packages, decided to not support rhel5 for technical reasons.

The LCLS Data Analysis group is presently maintaining 3 separate conda installations, one for rhel5, rhel6, and rhel7. Locally built packages, like openmpi, hdf5, and psana, will be built natively on each platform. The conda_setup script will automatically detect rhel5 vs rhel6 vs rhel7 and activate an environment in the appropriate installation. Use conda_setup to get into a conda environment.

However since conda-forge does not support rhel5, certain packages will not function on rhel5 (for example, opencv, which we obtain from conda-forge). In general, our support for rhel5 is more limited with the conda releases than the RPM releases. Rhel5 users may not be able to use a conda environment.

Moreover it is possible that we install a package that is limited to rhel7. Today - the only such package is tensorflow.

User Conda Environments

A great way to experiment with a new package is to create your own conda environment and install it there (this is similar to using virtualenv). This will work fine for environments with a small number of pure python packages. However if you want to create your own environment that looks like a clone of a LCLS environment like ana-1.0.7, that you then extend, there are some issues

• If you will use these environments across rhel5, rhel6, and rhel7 - All user conda envs live in one place, so you will have to name your environments based on the os and manage it (ie, myenv-rhel6, myenv-rhel7, if you will be putting psana in your myenv)
• There are issues with the conda create --clone command, for instance, mpirun does not seem to be installed properly in the cloned environment
• The biggest issue, is that all 3GB of software in the LCLS environment will get copied into your home directory.

Supporting softlinks from user home directories to a central package repository is a feature under development at continuum, and the LCLS Data Analysis group could add better support for user conda environments if this is an important feature.

Old Notes - to be removed - revised

 Conda based Psana in LCLS central install

Not recommended, and out of date, but here are notes on maintaining your own miniconda install that psana:

Adding Conda Packages to Self Managed Installation - for use outside LCLS or managing your own conda stack at LCLS
 

Internal Notes

There are a lot of JIRA issues that come off of this main ticket: PSRT-78 - Getting issue details... STATUS

There are two related github repositories:

test an installed conda environment: https://github.com/davidslac/test-lcls-conda-build-system

manage the conda installations and environments: https://github.com/davidslac/manage-lcls-conda-build-system

Try to keep content in this master page small and create new child pages for topics.