Difference between revisions of "Spack"

From Mu2eWiki
Jump to navigation Jump to search
 
(13 intermediate revisions by 3 users not shown)
Line 6: Line 6:
 
spack is designed to manage your code from github repo, to build, to installation in the final location. However, for a few reasons, we are adopting spack in two phases.  For historical reasons, they are phase 2 and 3.  In phase 2, we build our Offline repos locally, driven by the muse scripts, and link to the art suite libraries which are delivered in spack format.  This has the primary advantage that all muse commands and functionality stay the same.
 
spack is designed to manage your code from github repo, to build, to installation in the final location. However, for a few reasons, we are adopting spack in two phases.  For historical reasons, they are phase 2 and 3.  In phase 2, we build our Offline repos locally, driven by the muse scripts, and link to the art suite libraries which are delivered in spack format.  This has the primary advantage that all muse commands and functionality stay the same.
  
−
Phase 3, which is full spack adoption, we expect will come in two forms.  The first is "bare spack" for experts who are comfortable working with spack directly, and a "wrapped' version with Muse-like script which will hide most details for beginners and casual code users. A basic build in bare spack is being used in the [[https://mu2ewiki.fnal.gov/wiki/Building_Offline_with_cmake DAQ setting]].
+
Phase 3, which is full spack adoption, we expect will come in two forms.  The first is "bare spack" for experts who are comfortable working with spack directly, and a "wrapped' version with Muse-like script which will hide most details for beginners and casual code users. A basic build in bare spack is being used in the [[Building_Offline_with_cmake| online setting]].
  
 
==Phase 2 Usage==
 
==Phase 2 Usage==
 
The initial setup, which works for sl7 (with UPS) and al9 (with spack) is
 
The initial setup, which works for sl7 (with UPS) and al9 (with spack) is
 
  source /cvmfs/mu2e.opensciencegrid.org/setupmu2e-art.sh
 
  source /cvmfs/mu2e.opensciencegrid.org/setupmu2e-art.sh
−
Since we can't use UPS, we can't "setup mu2e".  After this, muse will be in your path and will work normally.  You can "muse setup" and "muse build" [[Muse as usual]].
+
Since we can't use UPS, we can't "setup mu2e".  After this, muse will be in your path and will work normally.  You can "muse setup" and "muse build" [[Muse| as usual]].  You can also make tarballs, and submit to the grid, or access musings, like "muse setup SimJob".
 +
 
 +
To access the data-handling tools, both SAM and the new (metacat) tools, you can
 +
muse setup ops
 +
which can be run with or without setting up a Muse Offline build.
 +
 
 +
We are preparing
 +
muse setup ana
 +
to provide access to a python analysis tool suite, like pyana.
 +
 
 +
== Minimal Commands ==
 +
 
 +
* locate a package
 +
spack location -i art
 +
/cvmfs/mu2e.opensciencegrid.org/packages/art/3.14.03/linux-almalinux9-x86_64_v2-gcc-13.1.0-c6fjht65rpw7ctr6ivsn2bbscjbvh5x3
 +
 
 +
 
 +
== Local Offline build ==
 +
Generally on al9, we can build Offline, TrkAna and other repos using muse, which drives the build via Scons and will link to art and root provided in the spack format on cvmfs.  For repos which do not have Scons capability, and can only be made with cmake, then we must use the full spack machinery.  The most common situation is when a user need to build KinKal or artdaq-core-mu2e locally with Offline, in order to develop new code in these repos together.  The following will create a spack working area, check out repos locally, and build them locally using spack driving cmake. To first order, no muse command will work here.
 +
 
 +
This procedure is all together here to allow cut-and-past and will be explained a bit more below.  It assumes you are in the build area, such as your app directory.
 +
 
 +
<pre>
 +
export MYSS=kk
 +
export MYENV=dev
 +
 
 +
mu2einit
 +
 
 +
smack subspack $MYSS
 +
cd $MYSS
 +
 
 +
smack subenv $MYENV
 +
source ./setup-env.sh
 +
spack env activate $MYENV
 +
 
 +
spack rm kinkal
 +
spack add kinkal@main
 +
spack develop kinkal@main
 +
spack add Offline@main +g4
 +
spack develop Offline@main
 +
spack add production@main
 +
spack develop production@main
 +
spack add mu2e-trig-config@main
 +
spack develop mu2e-trig-config@main
 +
 
 +
spack concretize -f 2>&1 | tee c_$(date +%F-%H-%M-%S).log
 +
spack install      2>&1 | tee i_$(date +%F-%H-%M-%S).log
 +
 
 +
spack env deactivate
 +
spack env activate $MYENV
 +
 
 +
</pre>
 +
The "develop" repos are checked out in <code>$MYENV</code>. After editing code, you can simply
 +
spack install  | tee i_$(date +%F-%H-%M-%S).log
 +
The code is installed in <code>$SPACK_LOCAL</code>
 +
 
 +
This build area has a "view" which gathers your bin and includes together in one directory to simplify your paths.  This is supposed to get checked with every install command, but sometimes it isn't.  So if the build ran and it doesn't look like all your changes are there, you can try to refresh the view.
 +
<pre>
 +
rm -rf $SPACK_ENV/.spack-env/view $SPACK_ENV/.spack-env/._view
 +
spack env view regenerate $MYENV
 +
</pre>
 +
 
 +
 
 +
returning to the area in a new process
 +
<pre>
 +
cd $MYSS
 +
source ./setup-env.sh
 +
spack env activate $MYENV
 +
</pre>
 +
 
 +
* smack is a script which simply runs some common combinations of commands, it has a help
 +
** subspack creates a local spack build area backed by builds on cvmfs
 +
** subenv creates a a local environment based on the current complete set of built mu2e code equivalent to a muse envset - art, root, KinKal, BTrk and artdaq-core-mu2e
 +
* an environment limits you to a selected set of code packages and versions
 +
* ''rm'', ''add'', and ''develop'' removes the package from the env, adds it to the env, and checks it out locally
 +
* ''@main'' means the head of the main branch
 +
* ''+g4'' means build with geant (do not skip it like we do for the trigger, which would be ''~g4'')
 +
* concretize means find a set of packages and versions which meet all demands, you only need to do it after changing the packages involved
 +
* install means compile and install as needed
 +
 
 +
Spack is doing a rather large number of operations behind each command, and it is trying to figure it all out for you, so sometimes it will produce strange errors. Probably best to post on slack help-bug.
  
 
==Notes==
 
==Notes==
−
show what spack knows about architectures
 
−
spack arch --known-targets
 
−
 
−
full listing of dependencies
 
−
spack find --long --show-flags --deps --variants ifdhc
 
  
−
diff between two hashes
+
listing packages
−
  spack diff art-root-io/jrcjyn4 art-root-io/h43e5rd
+
  spack find -lv <packagename>
 +
or with the dependencies (things it depends on)
 +
spack find -lvd <packagename>
 +
just print the version
 +
spack find --format "{version}" root
 +
what environment is active
 +
spack env status
  
−
How to group sets of setups into one. You can make a spack environment, like
 
−
spack env create uboone_analysis_current_sl7_x86_64
 
−
then
 
−
spack activate uboone_analysis_current_sl7_x86_64
 
−
and "spack install" packages into it; then if you
 
−
spack env activate uboone_analysis_current_sl7_x86_64
 
−
those will be the packages you see, and they're all spack loaded at once.
 
−
Marc stills need to add support for that to the cvmfs scripts though...
 
  
 
===geant names===
 
===geant names===

Latest revision as of 00:44, 8 June 2024

Introduction

Spack is a software package setup and build system. It can replace UPS, MRB (Multi-Repo Build) and Muse "package managers". Spack was developed for the supercomputer environment and is common use there today. The driving force that inspired spack is the need to install many packages while coordinating their dependencies.

The computing division will provide their software (art, ifdhc) within the spack framework. They have requested that we adopt spack as far as possible, so that the lab can converge to one package manager which will simplify maintenance and support. It will also prepare us to be more efficient in our use of supercomputers in the future. The lab has decided to end support for UPS and only provide software in the spack framework starting with he adoption of the AlmaLinux operating system, which will fully adopted by the hard deadline of 6/30/2024.

spack is designed to manage your code from github repo, to build, to installation in the final location. However, for a few reasons, we are adopting spack in two phases. For historical reasons, they are phase 2 and 3. In phase 2, we build our Offline repos locally, driven by the muse scripts, and link to the art suite libraries which are delivered in spack format. This has the primary advantage that all muse commands and functionality stay the same.

Phase 3, which is full spack adoption, we expect will come in two forms. The first is "bare spack" for experts who are comfortable working with spack directly, and a "wrapped' version with Muse-like script which will hide most details for beginners and casual code users. A basic build in bare spack is being used in the online setting.

Phase 2 Usage

The initial setup, which works for sl7 (with UPS) and al9 (with spack) is 

source /cvmfs/mu2e.opensciencegrid.org/setupmu2e-art.sh

Since we can't use UPS, we can't "setup mu2e". After this, muse will be in your path and will work normally. You can "muse setup" and "muse build" as usual. You can also make tarballs, and submit to the grid, or access musings, like "muse setup SimJob".

To access the data-handling tools, both SAM and the new (metacat) tools, you can 

muse setup ops

which can be run with or without setting up a Muse Offline build.

We are preparing 

muse setup ana

to provide access to a python analysis tool suite, like pyana.

Minimal Commands

  • locate a package
spack location -i art
/cvmfs/mu2e.opensciencegrid.org/packages/art/3.14.03/linux-almalinux9-x86_64_v2-gcc-13.1.0-c6fjht65rpw7ctr6ivsn2bbscjbvh5x3


Local Offline build

Generally on al9, we can build Offline, TrkAna and other repos using muse, which drives the build via Scons and will link to art and root provided in the spack format on cvmfs. For repos which do not have Scons capability, and can only be made with cmake, then we must use the full spack machinery. The most common situation is when a user need to build KinKal or artdaq-core-mu2e locally with Offline, in order to develop new code in these repos together. The following will create a spack working area, check out repos locally, and build them locally using spack driving cmake. To first order, no muse command will work here.

This procedure is all together here to allow cut-and-past and will be explained a bit more below. It assumes you are in the build area, such as your app directory. 

export MYSS=kk
export MYENV=dev

mu2einit

smack subspack $MYSS
cd $MYSS

smack subenv $MYENV
source ./setup-env.sh
spack env activate $MYENV

spack rm kinkal
spack add kinkal@main
spack develop kinkal@main
spack add Offline@main +g4
spack develop Offline@main
spack add production@main
spack develop production@main
spack add mu2e-trig-config@main
spack develop mu2e-trig-config@main

spack concretize -f 2>&1 | tee c_$(date +%F-%H-%M-%S).log
spack install       2>&1 | tee i_$(date +%F-%H-%M-%S).log

spack env deactivate
spack env activate $MYENV

The "develop" repos are checked out in $MYENV. After editing code, you can simply 

spack install  | tee i_$(date +%F-%H-%M-%S).log

The code is installed in $SPACK_LOCAL

This build area has a "view" which gathers your bin and includes together in one directory to simplify your paths. This is supposed to get checked with every install command, but sometimes it isn't. So if the build ran and it doesn't look like all your changes are there, you can try to refresh the view. 

rm -rf $SPACK_ENV/.spack-env/view $SPACK_ENV/.spack-env/._view
spack env view regenerate $MYENV


returning to the area in a new process 

cd $MYSS
source ./setup-env.sh
spack env activate $MYENV
  • smack is a script which simply runs some common combinations of commands, it has a help
    • subspack creates a local spack build area backed by builds on cvmfs
    • subenv creates a a local environment based on the current complete set of built mu2e code equivalent to a muse envset - art, root, KinKal, BTrk and artdaq-core-mu2e
  • an environment limits you to a selected set of code packages and versions
  • rm, add, and develop removes the package from the env, adds it to the env, and checks it out locally
  • @main means the head of the main branch
  • +g4 means build with geant (do not skip it like we do for the trigger, which would be ~g4)
  • concretize means find a set of packages and versions which meet all demands, you only need to do it after changing the packages involved
  • install means compile and install as needed

Spack is doing a rather large number of operations behind each command, and it is trying to figure it all out for you, so sometimes it will produce strange errors. Probably best to post on slack help-bug.

Notes

listing packages 

spack find -lv <packagename>

or with the dependencies (things it depends on) 

spack find -lvd <packagename>

just print the version 

spack find --format "{version}" root

what environment is active 

spack env status


geant names

geant data packages have different names in spack. From Julia: 

g4able is G4ABLA
g4emlow is G4EMLOW
g4neutron is G4NDL
g4nucleonsxs is G4SAIDDATA
g4nuclide is G4ENSDFSTATE 
g4photon is PhotonEvaporation
g4pii is G4PII
g4radiative is RadioactiveDecay
g4tendl is G4TENDL
g4particlexs is G4PARTICLEXS
g4incl is G4INCL

G4NEUTRONXS appears to be obsolete.

References

Retrieved from "http://mu2ewiki.fnal.gov/w/index.php?title=Spack&oldid=24746"