Home
Legacy Redmine wiki for dunetpc (login required)
Building the dunesw software stack
New repository locations for old dunetpc directories
dunesw is the overarching package of the DUNE software suite. It ultimately depends on LArSoft (through its dependencies on the rest of the software suite). This is an event-processing package which itself is based on art. LArSoft usually has a weekly release, and the DUNE software suite will have a new release built on each weekly release.
dunesw is the top of the DUNE software stack as shown below. The rest of the software suite includes duneexamples, dunedataprep, protoduneana, duneprototypes, duneana, dunesim, dunecalib, duneopdet, dunereco, dunecore, and duneutil. Their relations/dependencies are shown within the figure below.
DUNE software is packaged with ups. To configure your environment to access the software, source the DUNE setup script, e.g. if cvmfs is available:
source /cvmfs/dune.opensciencegrid.org/products/dune/setup_dune.sh
A version of dunesw can be quickly set up using ups commands. This is useful if you do not need to make any developments to code within any of the sub-repositories. To list the available versions of dunesw, use:
ups list -aK+ dunesw
To set up a version of dunesw use
setup dunesw <version> -q <quals>
In order to develop/edit any of the software stack, a LArSoft development area is required. This area will be located in a subdirectory within a larger workspace directory (i.e. /dune/app/users/ on a dunegpvm). Create a new directory in your workspace with a name of your choosing (i.e. larsoft) and enter it
mkdir larsoft
cd larsoft
Now it is time to configure this directory as a development area:
mrb newDev -v <version> -q <qual>
where <version> and <qual> are your choice. Normally, <version> will correspond to the LArSoft version found within dunecore's current product dependency file. Note that if you intend to work on a different commit of one of the repositories, the LArSoft version will change accordingly.
At this point, the following directories will be found in your larsoft area:
srcs/
localProducts_larsoft_<version>_<qual>/
build_slf7.x86_64/
srcs/ will be mostly empty except for a barebones CMake file, localProducts*/ will have a single script called setup, and build_slf7.x86_64 will be empty.
This will only need to be done once for the given development area.
Now that you have a development area in larsoft, it is time to set some environment variables defining where the source code is, where it will be built, and where it will finally be installed (localProducts).
source /path/to/larsoft/localProducts_<version>_<qual>/setup
This will need to be done every time you want to work/build code in this development area
Now that the environment is configured, you can start getting the code from git using commands from mrb.
You can clone the entire software suite by simply using the following
mrb g dune_suite
Note, however, that this is generally not recommended for normal development. One motivation behind the deprecation of dunetpc and the creation of the DUNE suite was to reduce the amount of code that a developer needs to build at once. Instead, it is recommended that developers checkout subsets of the suite.
In order to reduce build times, it is possible to build only a subset of the dune suite at a time. This becomes slightly complicated if building more than one product, so the first example will be using a single repository.
This case is very simple, and can be achieved by just using mrb g <product> to get the product you want in your development area and then building it per the instructions below. Once the build is complete, you should setup dunesw <version> <qual> with corresponding versions and qualifiers to load the rest of the packages.
In this case, a little more care must be taken as a continuous (dependency-wise) subset of the software suite must be built. For example, if you would like to build protoduneana and dunecalib, duneprototypes must also be built because it lies between the two. One should consult the dependency graph to determine which products are necessary and run mrb g <product> for each necessary product.
After getting code in your development area, it is time to set up your environment variables to build it
mrbsetenv
This will look through the various ups and cmake files found within any source code in your development area and attempt to set up packages depended upon between the products. If there are any mismatches between versions defined in these, there could be errors and the output of this command will try to let you know that.
Once you've sourced localProducts and ran mrbsetenv (after making sure the code you want is in srcs/), the build can commence.
With a newly created area or after a "zap" of your build area, you should run the following command
mrb i -jN [--generator=ninja]
where N is the number of cores you'd like to build with. On gpvms, this can be 4. However, build machines are available, and on these, up to 16 cores can be requested to speed up the build. --generator=ninja is an optional command that switches make with ninja.
Note that this step performs cmake steps to configure the build, then compiles code, and installs libraries/objects/fcl files/scripts to your localProducts area.
The previous build option is only necessary with a newly created development area or after wiping out your build area. During normal development, a simple compilation and installation is all that's required. To do this use either of the following commands (depending on if you chose make or ninja as your build system).
make install -jN
ninja install -jN
The dunesw stack is meant to be set up in its entirety in order for software to run. Global and shared configuration files are in the dunesw product, for example, and plugins that are dynamically loaded may be in products that are not dependent on the ones you have checked out and built.
From a fresh login, you must:
source /cvmfs/dune.opensciencegrid.org/products/dune/setup_dune.sh
setup dunesw <version> -q <quals>
source /path/to/larsoft/localProducts_<version>_<qual>/setup
mrbslp
The version tag of the precompiled products must match the version tag of the product(s) you have built. The mrbslp command sets up local products and gives you a different environment from what mrbsetenv gives, which is useful for building but some programs may not run with the build environment set. You can type
ups active
to find out what products you have set up and what their locations are on disk.
As of this writing, members of the DUNE orgnanization can push to dunesw and dependent repositories. We will transition to a pull-request-only model, in which reviewers look at each contribution, iterate with the authors, and merge the pull requests when all parties are satisfied. DUNE members have already been submitting pull requests and this is encouraged as review helps keep the software in good shape.
For information and links to how to use pull requests in GitHub, see this page in the LArSoft wiki:
https://cdcvs.fnal.gov/redmine/projects/larsoft/wiki/Working_with_Github
(Fermilab Services login required). It has a description of the CMS bot functionality, which we do not yet use on for DUNE software, but it has the good feature of running the CI tests before submitting pull requests for review.
How to Trigger CI builds and Update Reference Files
This one's not part of dune_suite (yet) but it's a dependency:
dunetpc directory repository in the split structure: 3x1x1dp duneprototypes APAIO do not migrate AnaTree duneana AnaUtils dunereco ArtSupport dunecore BeamData duneprototypes CAFMaker duneana CFilter do not migrate CVN dunereco CalData dunedataprep Calib dunecalib CalibServices dunecalib ClusterFinderDUNE dunereco Coldbox duneprototypes DAQSimAna duneana DAQTriggerSim dunecore DUNEPandora dunereco DUNEWireCell dunereco Daq do not migrate DataPrep dunedataprep DetSim dunesim DetectorVariations dunesim DuneCommon dunecore DuneExample duneexamples DuneInterface dunecore DuneObj dunecore DuneObjDumpers dunecore DuneServiceAccess dunecore EnergyStudies duneana EventFilters duneana EventGenerator dunesim FDSensOpt dunereco GalleryScripts duneexamples Geometry dunecore HitAnalysis duneana HitFinderDUNE dunereco HDF5Utils dunecore Iceberg duneprototypes InfillChannels dunereco LArG4 dunesim OpticalDetector duneopdet PandoraAnalysis duneana PhotonPropagation dunesim ProductFilters duneana Protodune duneprototypes RecoAlgDUNE dunereco RegCNN dunereco SNSlicer dunereco -- but not built (as per dunetpc) SNUtils dunereco -- but not built (as per dunetpc) ShowerAna duneana SimFilter dunesim Simulation dunesim SpaceCharge dunesim SpaceChargeServices dunesim SupernovaAna duneana TrackFinderDUNE dunereco TrackPID dunereco TrackingAna duneana Utilities dunecore VLNets dunereco