Muse

Introduction

As Mu2e approaches data-taking there will be many more ntuples, calibration procedures, and analysis code developed. Including this user code in the main Offline repo will be unwieldy and hard to maintain. The main Offline repo should remain minimal, including only what is needed for simulation and reconstruction jobs, for simple maintenance and faster builds. Code for calibration, ntuple, and analysis code, maintained and used by individuals and small groups should be stored in a smaller repos controlled by the appropriate group. These smaller repos could be standalone contain modules and utilities that depend on code and functionality in other small repos, or in Offline. To make this work, we need a system to build the smaller repos against an existing Offline build, or together with the Offline, sharing include files, fcl, and cross-linking. The system should support common use cases and be flexible. The Muse system is a set of scripts developed inside Mu2e that provides this functionality. It is a UPS product containing a set of scripts and support for scons code build at the core.

In this page we will use Ana1 and Ana2 as examples of smaller, non-Offline code repos. WorkDir will represent the path to a user project area on /mu2e/app, or possible other disk where you can build code. AnaDir will represent an area where analysis files are kept : scripts, root scripts, ntuples, histograms, and notes. If the user's work is mostly concerned with code development and commits, then it may be conveneient to use WorkDir as AnaDir, or, if the works is mostly using a statis build, then they may be different. Or there may be several versions of AnaDir, or AnaDir's with different goals, all using the same WorkDir.

Quick Start

Always required:

 setup mu2e
 setup muse

Built-in help:

 muse -h
 muse <command> -h
 muse status

Muse can only be setup once in a process and can't be unsetup. To change setup choices, start in a new process. When building on mu2egpvm01-06, use "-j 4", when building on mu2ebuild01, use "-j 20", see Machines. See GitHubWorkflow for more details on using git. See mgit for more information on using partial checkout (building only parts of Offline).

Muse scripts are focused on the workDir which provides the code to be built, a place to build the code, and persistency of what the user is building and using. There can only be one workDir in a process. After muse is UPS setup ("setup muse"), the workdir is usually configured by cd'ing to the workDir, checking out repos

 cd workDir
 git clone ...

or linking in pre-build backing releases.

 cd workDir
 muse link ...

once the code is organized, then muse is setup

 cd workDir
 muse setup

or from any directory:

 muse setup workDir

Once "muse setup" has been run, then the list of repos which will be built, and the build options, are locked in for the process. If you add or delete repos, or change a link to a backing build, then you must run "muse setup" again in a new process. The status report:

 muse status

can be run before or after "muse setup". If run before, it assumes the default directory is the workDir. If run after, it can be run from anywhere.

Builds can be removed:

 muse build -c

or simply remove the build directory content:

 rm -rf workDir/build

nothing is built in the repo git area, and everything built is under the build directory.

Build Offline

Build the Offline repo locally:

 cd WorkDir
 git clone https://github.com/Mu2e/Offline
    or
 git clone git@github.com:<your GitHub username>/Offline
    optionally, add other repos:
 git clone git@github.com:<your GitHub username>/Ana1
 muse setup
   edit files, as needed..
 muse build -j 20 --mu2eCompactPrint
   run
 mu2e -c ..

Returning later

To re-setup, later, in another process

 cd WorkDir
 muse setup

or

 cd AnaDir
 muse setup WorkDir

Setup options

In one process/window:

 cd WorkDir
 muse setup
 muse build -j 20
 muse -c ...

In another process:

 cd WorkDir
 muse setup -q debug
 muse build -j 20
 gdb --args  mu2e -c ...

Backing build

Before "muse setup", link in a pre-built Offline:

 cd WorkDir
    see options for backing builds:
 muse link
    link in a release:
 muse link master/be905d45
    optionally, add smaller repos:
 git clone git@github.com:<your GitHub username>/Ana1
 muse setup
 muse build -j 20

Partial checkout with backing build

Before "muse setup", link in a pre-built Offline:

 cd WorkDir
    see options for backing builds:
 muse link
    link in a release:
 muse link master/be905d45
    optionally, add smaller repos:
 git clone git@github.com:<your GitHub username>/Ana1
    add Offline partial build
 mgit init
 cd Offline
 mgit add HelloWorld
    edits..
 mgit status
 cd ..
 muse setup
 muse build -j 20

The build command can be run from any directory after "muse setup". The developer might find it useful to have two windows open, both setup to the same workDir: one sitting in workDir where code editing is done, and the build command is issued, and a second window sitting an AnaDir where code is run and output is kept.

Tarball

After preparing and testing a build area,

 cd WorkDir
 muse setup (if not already done)
 muse tarball

Tarball location with be printed. This can be sent to the grid with --code=/path/tarball in mu2eprodsys.

Muse product

The Muse UPS product is created out of the Mu2e/Muse repo. When the product is setup,

 setup mu2e
 setup muse

typically using the current version, it will do the following.

1. add $MUSE_DIR/bin to the path
2. add MUSE_DIR/python to PYTHONPATH
3. add alias=source $MUSE_DIR/bin/muse
4. export MUSE_ENVSET_DIR=/cvmfs/mu2e.opensciencegrid.org/DataFiles/Muse

The product can be packaged from a tag by checking out the tag in the repo, then

Muse/bin/museInstall.sh <version> <path to output product area>

muse setup

The command

muse setup

sets link, fhicl, and other paths, and sets up scons and art. Typically, the user would first organize their repos in the wokrDir, or link backing release builds, before running "muse setup". This command is also typically run when returning to work on the code in workDir in a later process.

The command must be run at the bash command line so that the alias is available, causing muse to be sourced so it can alter your environment. All other commands are run in subshells and will not effect the environment.

The setup command has two forms:

 cd workDir
 muse setup

or from anywhere, if workDir is provided:

 muse setup workDir

Options can be provided:

 muse setup <workDir> -q <options>

there is a small set of allowed options, such as prof/debug, the geant visualization build options. See

 muse setup -h

for the list of options. Examples (can only run one in a process)

 muse setup
 muse setup -q debug
 muse setup workDir -q e21
 muse setup workDir -q e21:trigger:debug

The effects of running setup are the following

1. sets environmentals used by Muse, such as the workDir (MUSE_WORK_DIR)
2. uses UPS to find the machine flavor
3. parses the options
4. determines which set of UPS art products to setup, and does the setup
5. analyzes available information and determines a repo link order
6. adds the workDir area to the bin, link, include and other paths
7. for linked backing builds, links in their build to the workDir build area

The resulting environment can be examined with

muse status
muse -v status

The UPS version of art, and all the other associated products, including a few that are not always needed, but ar convenient, like valgrind, are setup as one "environmental set" or "envset". In implementation, an envset is a script to be sourced as part of "muse setup". This script choses some defaults (if the user doesn't force a choice), then does the UPS art setups. envsets are files, where N represents a digit, with name pNNN if published permanently, or uNNN if customized by the user.

The "muse setup" command uses the following priority list to find which envset to use, and therefore which version of art to setup.

1. the user has forced an explicit choice by a qualifier like "-q p000"
2. an Offline repo is a local checkout, a mgit partial checkout, or a link, and has a .muse, then use the recommendation in there, if any
3. any other local package with a .muse file with a recommendation
4. $MUSE_WORK_DIR/uNNN, where N represents a digit, exists, then take highest number there
5. use highest number from $MUSE_ENVSET_DIR

muse link

The "muse link" command is used to link (in the bash soft link sense) a repo, that was built earlier, elsewhere, to the local workDir. This is sometimes called a "backing build".

The linked repo must have been built by Muse, in its own workDir.  The link will allow Muse to include from and link to (in the gcc sense) the other build. Muse will not attempt to build, or alter in any way, the linked repo.

The linked repo can be on a local disk, or on cvmfs. Running "muse link" with no argument gives a list of available cvmfs builds. There are two groups: first, a list of recent tagged and built releases, and second, a list of continuous integration (CI) builds. CI builds are made automatically every time code is merged in the main branches in the Offline repo.

The "muse link" commands, to see available builds and make links, are typically done while the default dir is workDir, while organizing code in that area, before "muse setup" is run.

muse link
  Recent published releases:
  v09_14_00
  v09_13_00
  Recent CI builds
  2021-03-29 11:05 master/be905d45
  2021-03-25 00:05 master/d3cc52b5
  2021-03-24 22:05 master/9fe21bab

The choice is then linked:

  muse link v09_14_00
     or
  muse link master/be905d45 

Some examples follow.

A user has a analysis repo they want to build against a recent Offline build. The user would clone the analysis repo in their workDir then link a backing build.

 cd WorkDir
 muse link
 muse link master/be905d45
 git clone git@github.com:<your GitHub username>/Ana1
 muse setup
 muse build -j 20

A user wants to link a backing build, then do a partial checkout of Offline for a small local change, or a quick-fix development.

 cd WorkDir
 muse link
 muse link master/be905d45
 git clone git@github.com:<your GitHub username>/Ana1
 mgit init
 cd Offline
 mgit add HelloWorld
    edits..
 cd ..
 muse setup
 muse build -j 20

Multiple users are sharing a build of a Offline and an ntuple. In the Offline builder's area, call it workDir0,

 cd WorkDir0
 git clone https://github.com/Mu2e/Offline
 git clone git@github.com:<your GitHub username>/MyNtuple
 muse setup
 muse build -j 20

then in the user's separate workDir

 cd workDir
 muse link workDir0/Offline
 muse link workDir0/MyNtuple
 git clone git@github.com:<your GitHub username>/Ana1
 muse setup
 muse build -j 20

The command makes links in the "link" directory, which is in workDir. When "muse setup" is run, it creates links from the local build area to the linked code build area.

cd workDir
muse link master/d3cc52b5
ls -l link
   Offline -> /cvmfs/mu2e-development.opensciencegrid.org/museCIBuild/master/d3cc52b5/Offline
muse setup
ls -l build/sl7-prof-e20-p000/link
   Offline -> /cvmfs/mu2e-development.opensciencegrid.org/museCIBuild/master/d3cc52b5/build/sl7-prof-e20-p000/Offline

Note the link command does not select prof/debug or other possible qualifier choice - those are set in the "muse setup" command. If the requested linked build area does not exist, you will get a warning during "setup".

If you link a repo name which has already been linked, the link will be updated, and a warning issued. After changing a link, the user must wipe out the current build

 muse build -c -j 20
    or
 rm -rf build

and re-run "muse setup" in a new process to finish the change.

muse build

This command is how the code in workDir is compiled and linked. This command can only be run after "muse setup". All build products go under the build subdirectory in workDir. Repos linked in the link subdirectory by the "muse link" command, will have links to their build products under the build directory, created by "muse setup".

All arguments to "muse build" are passed to the scons command.

 muse setup workDir
 muse build -j 20

scons features should all work. To remove a build:

 muse build -c

to build a target

 muse build -j 20 --mu2eCompactPrint build/sl7-prof-e20-p000/Offline/lib/libmu2e_HelloWorld_HelloWorld_module.so
   scons: Reading SConscript files ...
   Linking build/sl7-prof-e20-p000/Offline/lib/libmu2e_HelloWorld_HelloWorld_module.so

or

 muse build GDML
   scons: Reading SConscript files ...
   ... 
   [Tue Mar 30 16:34:15 CDT 2021] procs.sh starting GDML
 dir build/$MUSE_STUB/Offline/gen/gdml 
   -rw-r--r-- 1 rlc mu2e 5.2M Mar 30 16:34 mu2e.gdml

The python driving the scons build is in $MUSE_DIR/python.

The scons command itself is run in workDir.

muse status

The "muse status" command attempts to tell you useful things about how muse is setup in this process, or what setups are available. If run before "muse setup", then the command will assume the default directory is a workDir. It will analysis what's there and what builds have been created.

cd workDir
muse status
  existing builds:
    sl7-prof-e20-p000
         Build times: 03/28/21 17:24:29 to 17:27:35
    sl7-debug-e20-p000
         Build times: 03/26/21 10:20:19 to scons error 23
muse setup
muse status
  existing builds:
    sl7-prof-e20-p000         ** this is your current setup **
         Build times: 03/28/21 17:24:29 to 17:27:35
    sl7-debug-e20-p000
         Build times: 03/26/21 10:20:19 to scons error 23

 MUSE_WORK_DIR = /mu2e/app/users/rlc/muse/phase2/test4 
 MUSE_REPOS =  Offline link/Offline
 ...

The current setup is flagged. The build command will record its latest start and stop times. If the stop time is not present, then the build is still running or failed.

muse tarball

The "muse tarball" command makes a tarball of the build are, ready to be submitted to the grid.

 muse tarball
  Tarball: /mu2e/data/users/rlc/museTarball/tmp.Sh0737kx1M/Code.tar.bz2

which can be submitted:

 setup mu2egrid
 mu2eprodsys ... --code=/mu2e/data/users/rlc/museTarball/tmp.Sh0737kx1M/Code.tar.bz2

additional files can be included:

 muse tarball *.txt

If workDir contains repos linked from cvmfs, the tarball will contain a link to the cvmfs build. If the linked repo is on a local disk, it will be included in the tarball.

linkOrder

In order to preserve the one-pass linking Mu2e has established by policy, the repos being built in Muse need to have a specified link order. There is a default link order which will be centrally maintained and will include all repos known to the collaboration generally. When you ask Muse to build your personal analysis repos, or anything not in the central link order, Muse will insert the unknown repos in the beginning of the link order by default. If you have multiple local repos which are not being linked in the right order, you can tell Muse the link order. You do this by creating a new "linkOrder" file locally.

cdworkDir
mkdir -p muse
echo "Ana1 Ana2 " > muse/linkOrder
cat $MUSE_ENVSET_DIR/linkOrder >> muse/linkOrder
cat muse/linkOrder
   Ana1 Ana2 Tutorial Offline
muse setup
muse status
     ...
     MUSE_LINK_ORDER =  Ana1 Ana2 Tutorial Offline

and the repo library directories will be searched in that order.

Linked repos come after their local counterparts, i.e. an Offline in workDir will be linked before the backing Offline that link/Offline points to. This is the mechanism that allows mgit to work with a backing build.

Customizing setups

This procedure allows the user to provide their own envset. This might be necessary to test code with a new compiler, or to test a new set of art libraries, or test a new verison of geant. This procedure will generally only be needed by collaborators doing code management.

To create a custom envset, start with the most recent published envset. This is probably most reliably seen in the Offline/.muse file from the head of Offline.

cd workDir
git clone https://github.com/Mu2e/Offline
grep ENVSET Offline/.muse
   ENVSET P000
mkdir -p muse
cp /cvmfs/cvmfs/mu2e.opensciencegrid.org/DataFiles/Muse/P000 muse/u001
   edit muse/u001 as needed
muse setup -q u001
muse build -j 20

The user can build the same code in the same area both with the default envset P000 and the custom envset u001. The two builds will appear in different directories under the build directory. The two setup/builds will need to be done in separate processes. The two processes will produce the appropriate two different tarballs.

All local envsets must be named uNNN, to make sure they are not confused with copies of the published envsets pNNN. The "u" is for "user", the "p" is for "published".

Typically, once the new envset is validated,

1. u001 would be renamed "p001" as the successor to "p000"
2. p001 committed to the Muse repo, config directory, for the record
3. p001 is copied to the cvmfs envset dir
4. when ready, the ENVSET line in Offline/.muse is updated to p001

One of the techniques to devine the envset without user or repo guidance is to accept the pNNN set with the highest NNN. So while it is possible to publish arbitrary envsets or arbitrary reasons, the highest number may be picked up by some inexperienced users, though not for general use.