The general philosophy of the LSST software stack is that some python dependencies are so ubiquitous in scientific computing environments that it is more difficult for users to provide new versions than it is to supply them with the stack. The simulations framework relies on the following dependencies that are not part of the LSST stack:
- python 2.7
The recommended install instructions will provide these dependencies for you through an Anaconda distribution.
The recommended (simplest) approach is to use the newest W14 LSST software stack, and use the LSST-provided version of anaconda python. (See here if you want to use your own python).
1. Start by installing the necessary parts of the LSST software stack and the LSST-installed anaconda.
In these instructions we assume you are installing in ~/lsst, however the install directory can be any place in the file system, including a place visible to all users. To install in another location, replace ~/lsst with the desired path in the following instructions. For multi user stacks, permissions are typically restricted to read only for the main stack so packages are not accidentally installed in the main stack.
Choose yes when prompted to install Anaconda. Choose yes when prompted to install git**. These packages will not interfere with your system installed versions. This step will download about 1 GB of files to your machine.
** Only choose 'yes' to install git if your current version is prior to git 1.7 or you have curl-devel installed on your system.
2. Set up the environment and install the simulations code and data.
This will install all packages currently in the catalogs simulations framework (CatSim) and metrics analysis framework and all dependencies. Currently the complete list of installed packages is:
- base – LSST import utilities
- boost– Third party C++ package
- cfitsio– FITSIO I/O library
- daf_base – LSST data access framework
- doxygen– Documentation suite
- freetds– OpenSource implementation for Tabular Data Streams (needed by pymssql)
- healpy– Python bindings for HealPix
- palpy– Python binidings for PAL (Positional Astronomy Library)
- pex_config – LSST configuration package
- pex_exceptions – LSST exception handling package.
- pex_policy – Another LSST configuration package
- pyephem– Ephemeris generation code
- pyfits– Python bindings for interacting with FITS files
- pykg_config– Pure python implementation of pkg_config needed to install healpy on Mac OSX
- pymssql– Python bindings for talking to MS-SqlServer databases (needed to access UW base catalogs)
- scons– Software construction tool
- sconsUtils – LSST utilities for scons
- sims_catalogs_generation – Code for querying databases for catalog data
- sims_catalogs_measures – Code for constructing observed catalogs
- sims_catUtils – Package containing example code and definitions of base catalogs hosted at UW.
- sims_photUtils – Utilities for calculating photometry including variability
- sims_coordUtils – Utilities for calculating coordinate corrections (proper motion, parallax, refraction, etc.)
- sims_dustmaps – SFD dust maps
- sims_maf – Metrics Analysis Framework
- sims_sed_library – Library of SED data for simulated catalogs
- swig– Library for auto-generating python bindings for C++ code
- throughputs – Nominal throughput curves for SDSS and LSST systems
- utils – LSST utilities package
Any of the above packages and all their dependencies can be installed by replacing lsst_sims with the appropriate package name in the above code snippet (e.g. sims_maf). Installation is now complete. See package specific pages for documentation.
Mixing Installed Stack with Development Repositories
When contributing to development work it is often useful to use most packages from an installed stack and only keep local copies of the repositories that need work. For pure python packages, this is straightforward. The following steps will put a local copy of sims_maf into a pre-existing stack.
All packages may be declared with a version and a tag. The version distinguishes on instance of a particular package from another. The eups tag can be used to define a coherent set of packages. The philosophy is to tag all personal package (packages downloaded via git) with a custom tag using the username. Using this workflow allows packages to be set up with the -t $USER switch which means that custom packages are used if they are declared and main stack packages are used otherwise.
1. Move to a directory to hold the working repository and clone it:
Note that you will need a password on the stash server (or have set up ssh keys) to push to the server.
2. Declare and build the package:
See here for the confluence question dealing with how to be polite in a shared stack.
3. Code, commit and push
Code reviews should be handled by branching the repository and issuing a pull request through stash.