The old UPS code management system
Overview
Teaching: 30 min
Exercises: 0 minQuestions
How are different software versions handled?
Objectives
Understand the roles of the tools UPS (and Spack)
What is UPS and why do we need it?
Note
UPS is going away and only works on SL7 but we do not yet have a fully functional replacement. You need to be in the Apptainer to use it. UPS is being replaced by a new [spack][Spack Documentation] system for Alma9. We will be adding a Spack tutorial soon but for now, you need to use SL7/UPS to use the full DUNE code stack.
Go back and look at the SL7/Apptainer instructions to get an SL7 container for this section.
An important requirement for making valid physics results is computational reproducibility. You need to be able to repeat the same calculations on the data and MC and get the same answers every time. You may be asked to produce a slightly different version of a plot for example, and the data that goes into it has to be the same every time you run the program.
This requirement is in tension with a rapidly-developing software environment, where many collaborators are constantly improving software and adding new features. We therefore require strict version control; the workflows must be stable and not constantly changing due to updates.
DUNE must provide installed binaries and associated files for every version of the software that anyone could be using. Users must then specify which version they want to run before they run it. All software dependencies must be set up with consistent versions in order for the whole stack to run and run reproducibly.
The Unix Product Setup (UPS) is a tool to handle the software product setup operation.
UPS is set up when you setup DUNE:
Launch the Apptainer and then:
export UPS_OVERRIDE="-H Linux64bit+3.10-2.17"
source /cvmfs/dune.opensciencegrid.org/products/dune/setup_dune.sh
export DUNELAR_VERSION=v09_90_01d00
export DUNELAR_QUALIFIER=e26:prof
setup dunesw $DUNELAR_VERSION -q $DUNELAR_QUALIFIER
dunesw
: product name
$DUNELAR_VERSION
version tag
$DUNELAR_QUALIFIER
are “qualifiers”. Qualifiers are separated with colons and may be specified in any order. The e26
qualifier refers to a specific version of the gcc compiler suite, and prof
means select the installed product that has been compiled with optimizations turned on. An alternative to prof
is the debug
qualifier. All builds of LArSoft and dunesw are compiled with debug symbols turned on, but the “debug” builds are made with optimizations turned off. Both kinds of software can be debugged, but it is easier to debug the debug builds (code executes in the proper order and variables aren’t optimized away so they can be inspected).
Another specifier of a product install is the “flavor”. This refers to the operating system the program was compiled for. These days we only support SL7, but in the past we used to also support SL6 and various versions of macOS. The flavor is automatically selected when you set up a product using setup (unless you override it which is usually a bad idea). Some product are “unflavored” because they do not contain anything that depends on the operating system. Examples are products that only contain data files or text files.
Setting up a UPS product defines many environment variables. Most products have an environment variable of the form <productname>_DIR
, where <productname>
is the name of the UPS product in all capital letters. This is the top-level directory and can be used when searching for installed source code or fcl files for example. <productname>_FQ_DIR
is the one that specifies a particular qualifier and flavor.
Exercise 3
- show all the versions of dunesw that are currently available by using the
ups list -aK+ dunesw
command- pick one version and substitute that for DUNELAR_VERSION and DUNELAR_QUALIFIER above and set up dunesw
Many products modify the following search path variables, prepending their pieces when set up. These search paths are needed by art jobs.
PATH
: colon-separated list of directories the shell uses when searching for programs to execute when you type their names at the command line. The command which
tells you which version of a program is found first in the PATH search list. Example:
which lar
will tell you where the lar command you would execute is if you were to type lar
at the command prompt.
The other paths are needed by art for finding plug-in libraries, fcl files, and other components, like gdml files.
CET_PLUGIN_PATH
LD_LIBRARY_PATH
FHICL_FILE_PATH
FW_SEARCH_PATH
Also the PYTHONPATH describes where Python modules will be loaded from.
Try
which root
to see the version of root that dunesw sets up. Try it out!
UPS basic commands
Command | Action |
---|---|
ups list -aK+ dunesw |
List the versions and flavors of dunesw that exist on this node |
ups active |
Displays what has been setup |
ups depend dunesw v09_48_01d00 -q e20:prof |
Displays the dependencies for this version of dunesw |
Exercise 4
- show all the dependencies of dunesw by using “ups depend dunesw $DUNELAR_VERSION -q $DUNELAR_QUALIFIER”
UPS Documentation Links
Key Points
The Unix Product Setup (UPS) is a tool to ensure consistency between different software versions and reproducibility.
CVMFS distributes software and related files without installing them on the target computer (using a VM, Virtual Machine).