Creating a Simons Observatory Environment
The install script takes options to specify the location of the base environment (if it is not already activated) and the name (or full path) of the environment to create. It also allows specifying a central location to install the modulefile:
./soconda.sh -h
Usage: ./soconda.sh
[-c <directory in config to use for options>]
[-e <environment, either name or full path>]
[-b <conda base install (if not activated)>]
[-v <version (git version used by default)>]
[-m <modulefile dir (default is <env>/modulefiles)>]
NOTE
Running the soconda.sh script will create log files in the current directory.
Consider running the command from within a temporary build directory to avoid
clutter.
Base Conda Environment
If you already have a conda-forge or micromamba base environment, install
conda-build and conda-verify package to base environment.
conda update -n base --yes --all conda
conda install -n base --yes --all conda-build conda-verify
For a new installation of a conda base environment, run the following script to install miniforge:
./tools/bootstrap_base "$HOME/miniforge3"
This will install the base conda environment to the $HOME/miniforge3
directory. It will set conda-forge as default channel. After the installation
you need to re-login or start a new terminal to initialize conda. You can
manually activate this base environment, but for the example below this is not
needed.
Special Note on mpi4py
By default, the conda package for mpi4py will be installed. This should work
well for stand-alone workstations or single nodes. If you have a cluster with a
customized MPI compiler, then set the MPICC environment variable to the MPI C
compiler before running soconda.sh. That will cause the mpi4py package to
be built using your system MPI compiler.
Install soconda
Example: Local System
This procedure will work to install soconda to your local computer or a basic
cluster. First, clone the soconda repo
git clone git@github.com:simonsobs/soconda.git
cd soconda
Run the soconda.sh script, specifying the location of the base environment
(-b), the name of the configuration to use (-c), and the name of the
environment (-e):
./soconda.sh -b "$HOME/miniforge3" -e soconda -c default
This will create a new environment soconda_xxx.x.x with version number as
suffix using default configuration. More details on
configuration.
You can find out the name of newly created environment with:
conda env list
Then you can now activate the environment with:
conda activate soconda_xxx.x.x
If running on a Linux desktop that uses wayland, you also need to install the
qt-wayland package
conda install qt-wayland
Using Jupyter
If you want to use jupyter first install a kernel for this new soconda environment.
Next just run jupyter-lab from a terminal in your directory containing some
notebooks and jupyter-lab should launch in your default browser:
cd /path/to/project
jupyter-lab
and then ctrl-c the jupyter-lab terminal job when you are done. If you installed jupyter-lab on a local "server" and want to connect from your laptop (for example), you can launch a long-running jupyter session and control what port is used for communication with the browser on your laptop. For example:
(on server): nohup jupyter-lab --no-browser --port=12345 &> jupyter.log &
To list the currently running jupyter servers:
(on server): jupyter server list
To connect to jupyter-lab running on this server, start an SSH tunnel from your laptop:
(on laptop): ssh -N -L 12345:localhost:12345 server_domain_or_ip
Then you can connect to jupyterlab with the link provided by command jupyter
server list. To stop jupyterlab listening on port 12345:
(on server): jupyter server stop 12345
Example: NERSC
At NERSC, the default provided python does not work well for our needs. Instead, we have a conda-forge base environment installed in our project software directory:
source /global/common/software/sobs/perlmutter/conda_base/etc/profile.d/conda.sh
conda activate base
We can either install a shared software environment or use this base environment to build a conda environment in a personal directory. If you are installing to a shared software environment, you should do that as the project account and follow a specific naming convention which is beyond the scope of this document. If you wanted to install these tools to your home directory you could do:
mkdir -p ~/conda_envs
./soconda.sh -e ~/conda_envs/soconda -m ~/conda_envs/modulefiles
And then load the module:
module use ~/conda_envs/modulefiles
module avail
module load soconda/XXXXXX
Running Tests
After loading an soconda environment, you can run some tests with:
./run_tests.sh
Installing a Jupyter Kernel
After loading an soconda module or activating an soconda conda environment the first time, you can run (once) the included script:
soconda_jupyter.sh
This will install a kernel file to
~/.local/share/jupyter/kernels/soconda-xxxxx so that the jupyter server knows
how to launch a kernel using this python stack.
Customizing an Environment
When running soconda.sh, the system configuration to use can be specified
with the -c option. This should be the name of the configuration subdirectory
within the "config" top-level directory. If not specified, the "default" config
is used. If you want to dramatically change the package versions / content of
an soconda stack, just load the existing base conda environment, copy one
of the configs to a new name and edit the three lists of packages
(packages_[conda|pip|local].txt) to exclude certain packages or add extras.
Then install it as usual.
Deleting an Environment
The soconda environments are self contained and you can delete them by running
command conda remove --name <envname> --all or conda remove -p
/base_dir/envs/name --all. Or directly removing the <base dir>/envs/<name of
env> directory. You can optionally delete the modulefile and the versioned pip
local directory in your home directory. If you installed a jupyter kernel,
remove kernel file in ~/.local/share/jupyter/kernels/ with matching soconda
version.
If you have multiple soconda environments and deleted the wrong kernel file, you can always recreate it.
Advanced Details
The compiled packages assume the use of the conda compilers for consistency with
the libraries installed through conda. If you want to change those compilers you
can remove the compilers conda package and manually set the CC, CXX, and FC
environment variables. Full warning that this may cause problems with threading
interfaces, thread pinning, etc, when building packages that use OpenMP.
Libactpol / Moby2
There are three conda recipes for libactpol_deps, libactpol, and moby2.
These are using git hashes that are either the latest or a branch / version
recommended for S.O. use.
So3g
This package has a local conda recipe. There is a branch being tested that remove dependences on boost and compile-time linking to spt3g. Once that is merged, so3g can migrate upstream to conda-forge.