Difference between revisions of "Muse"

From Mu2eWiki
Jump to navigation Jump to search
Line 10: Line 10:
 
   setup mu2e
 
   setup mu2e
 
   setup muse
 
   setup muse
    built-in help:
+
Built-in help:
 
   muse -h
 
   muse -h
 
   muse <command> -h
 
   muse <command> -h
Line 16: Line 16:
 
Muse can only be setup once in a process and can't be unsetup.  To change setup choices, start in a new process.
 
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 [[ComputingLogin#Machines|Machines]].  See [[GitHubWorkflow]] for more details on using git.  See [[#mgit|mgit]] for more information on using partial checkout (building only parts of Offline).
 
When building on mu2egpvm01-06, use "-j 4", when building on mu2ebuild01, use "-j 20", see [[ComputingLogin#Machines|Machines]].  See [[GitHubWorkflow]] for more details on using git.  See [[#mgit|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
 +
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.
 +
 
===Build Offline===
 
===Build Offline===
 
Not expecting to commit files back to the Offline repo:
 
Not expecting to commit files back to the Offline repo:
Line 25: Line 41:
 
   git clone git@github.com:<your GitHub username>/Ana1
 
   git clone git@github.com:<your GitHub username>/Ana1
 
   muse setup
 
   muse setup
 +
    edit files, as needed..
 
   muse build -j 20
 
   muse build -j 20
 +
    run
 +
  mu2e -c ..
  
 
===Returning later===
 
===Returning later===
Line 34: Line 53:
 
   cd AnaDir
 
   cd AnaDir
 
   muse setup WorkDir
 
   muse setup WorkDir
 +
 
===Setup options===
 
===Setup options===
 
In one process/window:
 
In one process/window:
Line 39: Line 59:
 
   muse setup
 
   muse setup
 
   muse build -j 20
 
   muse build -j 20
 +
  muse -c ...
 
In another process:
 
In another process:
 
   cd WorkDir
 
   cd WorkDir
 
   muse setup -q debug
 
   muse setup -q debug
 
   muse build -j 20
 
   muse build -j 20
 +
  gdb --args  mu2e -c ...
 +
 
===Backing build===
 
===Backing build===
 
Before "muse setup", link in a pre-built Offline:
 
Before "muse setup", link in a pre-built Offline:
Line 54: Line 77:
 
   muse setup
 
   muse setup
 
   muse build -j 20
 
   muse build -j 20
 +
 
===Partial checkout with backing build===
 
===Partial checkout with backing build===
 
Before "muse setup", link in a pre-built Offline:
 
Before "muse setup", link in a pre-built Offline:
Line 72: Line 96:
 
   muse setup
 
   muse setup
 
   muse build -j 20
 
   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.
 +
# add $MUSE_DIR/bin to the path
 +
# add MUSE_DIR/python to PYTHONPATH
 +
# add <code>alias=source $MUSE_DIR/bin/muse</code>
 +
# 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>
  
<pre>
 
setup mu2e
 
setup muse
 
  < cd to a working dir >
 
git clone https://github.com/Mu2e/Offline
 
git clone https://github.com/Mu2e/Tutorial
 
muse -h
 
muse setup
 
muse build -j 20 >& b_00.log
 
mu2e -n 10 -c Offline/Validation/fcl/ceSimReco.fcl
 
mu2e -s mcs.owner.val-ceSimReco.dsconf.seq.art \
 
    -c Tutorial/DataExploration/fcl/Ex01.fcl
 
 
  < in the same working dir, but in a second window>
 
muse setup -q debug
 
muse status
 
muse build -j 20 >& d_00.log
 
mu2e -s mcs.owner.val-ceSimReco.dsconf.seq.art \
 
    -c Tutorial/DataExploration/fcl/Ex02.fcl
 
</pre>
 
 
An example of a backing release
 
  
<pre>
 
setup mu2e
 
setup muse
 
  < cd to a working dir that will be the backing build >
 
git clone https://github.com/Mu2e/Offline
 
muse setup
 
muse build -j 20 >& b_00.log
 
  
  < *in a new process* cd to a working dir that will link to the backing build >
+
==Muse setup==
  
setup mu2e
+
The command
setup muse
 
git clone https://github.com/Mu2e/Tutorial
 
muse link /path/backing_working_dir/Offline
 
 
  muse setup
 
  muse setup
muse build -j 20 >& b_00.log
+
must be run at the command line so that the alias is available, causing muse to be sourced so it can alter your environment. All other commands
mu2e -n 10 -c Offline/Validation/fcl/ceSimReco.fcl
 
mu2e -s mcs.owner.val-ceSimReco.dsconf.seq.art \
 
    -c Tutorial/DataExploration/fcl/Ex02.fcl
 
</pre>
 
 
 
 
 
Example of a partial Offline build using "mgit" the muse version of pgit
 
 
 
<pre>
 
setup mu2e
 
setup muse
 
cd <a working dir>
 
  ... establish a backing build
 
muse link
 
 
 
Recent published releases:
 
Recent CI builds
 
2021-03-12 21:45 master/43ebbdfe
 
2021-03-12 12:44 master/c2409d93
 
 
 
muse link master/43ebbdfe
 
  ... establish partial code checkout
 
        include your github username to setup an origin remote (requires authentication)
 
mgit init rlcee
 
cd Offline
 
mgit add HelloWorld
 
sed -i 's/From/From '$USER'/' HelloWorld/src/HelloWorld_module.cc
 
 
 
git remote -v
 
git status
 
 
 
cd ..
 
 
 
muse setup
 
muse build -j 20 --mu2eCompactPrint
 
mu2e -c HelloWorld/test/hello.fcl
 
 
 
</pre>
 
 
 
  
Example of jobs submission
 
<pre>
 
  .. in any Muse build
 
muse tarball
 
Tarball: /mu2e/data/users/rlc/museTarball/tmp.BqvJOks3xI/Code.tar.bz2
 
  
mu2eprodsys ... \
+
==Muse setup==
  --code /mu2e/data/users/rlc/museTarball/tmp.BqvJOks3xI/Code.tar.bz2
 
  
</pre>
 
  
  

Revision as of 19:40, 30 March 2021

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

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.

Build Offline

Not expecting to commit files back to the Offline repo:

 cd WorkDir
 git clone https://github.com/Mu2e/Offline
    or
 git clone git@github.com:<your GitHub username>/Offline
    optionally, add smaller repos:
 git clone git@github.com:<your GitHub username>/Ana1
 muse setup
   edit files, as needed..
 muse build -j 20
   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

must be run at the command line so that the alias is available, causing muse to be sourced so it can alter your environment. All other commands


Muse setup