If you are looking for the legacy cvs-based LArSoft site that was previously hosted on this site, note that all content has been moved to LArSoft cvs (legacy site).
If you are looking for the legacy svn-based LArSoft site, go here.
---------------------------------------------------------------

• Table of contents
• LArSoftWiki (beta)
• Preliminaries
  • Where to find the software
    • Re-factoring of experiment-specific software
• Release notes
• Documentation
  • Overview of the user and developer environment
    • The LArSoft developer environment
  • Links to the tools used in working with the software
• How-to's
  • Advanced technical how-to's
  • Release procedures
• Walk-through exercises
• LArSoft code management and distribution procedures
• Working areas

This is the beta LArSoft redmine project and the future home of the LArSoft redmine project.

LArSoftWiki (beta)¶

This page is in beta and content is still under construction. Will go live when the migration to git/cmake is completed.

The LArSoft software is designed to work for all planned and running liquid argon experiments at Fermilab. It is written in C++ and built on the ROOT data analysis software, and the art analysis framework supported by the Fermilab Scientific Computing Division for intensity frontier experiments.

To join the LArSoft mailing list, please follow these instructions using the list name LARSOFT.

Preliminaries¶

• Fermilab computing accounts: see the instructions on the [[larsoftsvn:Fermilab Computing Access]] page if you need an account.
• See [[larsoftsvn:Load Balanced Access to General Purpose VMs]] for information on accessing experiment VMs at Fermilab (e.g., lbnegpvm0X, uboonegpvm0X, etc., collectively known as GPCF.).
• See the documentation section for information on working with/developing LArSoft code, and using git, git flow, mrb and other tools you will need.
• The procedures and tools for building and developing software with this system are completely different from those of the previous system based on svn repositories and the SoftRelTools build system. See the documentation section for details.

Where to find the software¶

In a standard LArSoft installation, the software is accessed via a set of re-locatable ups products, each of which corresponds to the code within a git repository. Each product and the associated repository contain LArSoft software components (i.e., SoftRelTool "packages") that are within the same layer of functionality. The products and repository read-write urls are the following (read-only access is available via http://cdcvs.fnal.gov/projects/<repo_name>):

Product repository name	repository url (all in Redmine)	lxr link (not yet avail)	Redmine browser
larcore	ssh://p-larcore@cdcvs.fnal.gov/cvs/projects/larcore	--	redmine
lardata	ssh://p-lardata@cdcvs.fnal.gov/cvs/projects/lardata	--	redmine
larevt	ssh://p-larevt@cdcvs.fnal.gov/cvs/projects/larevt	--	redmine
larsim	ssh://p-larsim@cdcvs.fnal.gov/cvs/projects/larsim	--	redmine
larreco	ssh://p-larreco@cdcvs.fnal.gov/cvs/projects/larreco	--	redmine
larana	ssh://p-larana@cdcvs.fnal.gov/cvs/projects/larana	--	redmine
lareventdisplay	ssh://p-lareventdisplay@cdcvs.fnal.gov/cvs/projects/lareventdisplay	--	redmine
larexamples	ssh://p-larexamples@cdcvs.fnal.gov/cvs/projects/larexamples	--	redmine
larpandora	ssh://p-larpandora@cdcvs.fnal.gov/cvs/projects/larpandora	--	"redmine:https://cdcvs.fnal.gov/redmine/projects/larpandora/repository
larsoft	ssh://p-larsoft@cdcvs.fnal.gov/cvs/projects/larsoft (A product used to set up the others with a single command. Contains the "setup" package.)	--	redmine

(The SoftRelTools-based packages in each product/repository can be found here along with the approximate order of dependency.)

You can use the git clone <repository url> command to download a copy of each repository to your local area. Additional steps are needed to use, build or develop the software. See the documentation section below for details.

Re-factoring of experiment-specific software¶

Most experiment-specific code, fcl and gdml files have been removed from the above larcore, lardata, larevt and larsim repositories and moved into beta versions of experiment-specific git repositories. (One exception to this statement is that the DetId_t enum type, which effectively maps detector name strings to integers, remains in core LArSoft, pending migration to a new, string-based mechanism for storing and using this information. Other exceptions include fcl files that were not identified during the initial migration.) The beta versions of experiment-specific repositories are the following:

Product repository name	repository url (all in Redmine)	lxr link (not yet avail)	Redmine browser
lbnecode	ssh://p-lbnecode@cdcvs.fnal.gov/cvs/projects/lbnecode	--	redmine
uboonecode	ssh://p-uboonecode@cdcvs.fnal.gov/cvs/projects/lardata	--	redmine

Release notes¶

Release	Date	Purpose	Changes / notes	Full release notes
v1.00.00	Jan 2014	First production release	Replica of final svn-based release. Future LArSoft development proceeds from this release.	xxx
v0.0x.yy	12/09/2013	"beta" public release	Beta suitable for general user testing	N/A
v0.01.01	12/02/2013	"beta" limited release	Beta suitable for expert testing	N/A
v0.00.09	11/25/2013	"beta" pre-release	Second full release under new system. First full re-factoring of experiment-specific and core LArSoft code in the larcore, lardata, larevt, and larsim products. Preparation for expert user testing of beta release.	N/A
v0.00.04	9/15/2013	"alpha" release	First release of git/cmake/ups-based LArSoft products Used for mrb, configuration and re-factoring development and testing	N/A

Documentation¶

• LArSoft

• Quick-start guide to using and develop LArSoft code

• Detailed documentation on using and developing LArSoft code

• Special instructions for beta testers

Overview of the user and developer environment¶

LArSoft releases are distributed via "re-locatable" ups products. People interested in using the core LArSoft software, but who have no need to modify or develop that software can in principle simply perform the appropriate ups setup <product> <version> -q <qualifier> commands, then build their code against those products by reference to the corresponding $<PRODUCT_NAME>_INC and $<PRODUCT_NAME>_LIB environment variables. In addition to the individual products, there is a "larsoft" product that can be used to set up all other products with a single command:

setup larsoft <version> -q <qualifiers>

The versions and qualifiers available can be obtained by using the following command:

ups list -aK+ larsoft

The qualifiers will be one of the following: "debug:e2", "prof:e2", "opt:e2", where:

• debug = debugging symbols available
• opt = compiler optimizations enabled, no debug symbols
• prof = compiler optimizations enabled, profiling code generated
• e2 = built with gcc 4.7.1 and -std=c++0x

In general, only debug and prof versions will be provided, since there is no run-time performance penalty for code that has the profiling code present.

The recommended way to work with LArSoft is to use mrb, the multi-repository build tool, to check out and build your own code. This build system is based upon cmake and a toolkit of cmake macros in the cetbuildtools product -- the same set of tools that are used to build the art framework that underpins LArSoft. mrb operates above cmake and drives the build procedure across (possibly) multiple repositories within one's working area. Using mrb ensures the integrity and structure of the working.

One's working directory within this system has the following structure: a source code sub-directory where all development takes place; a build sub-directory where all build activities take place; and a local products area, where all successfully built software is installed, and from which it can be run.

All software packages built and installed by mrb / cmake / cetbuildtools are in the form of a re-locatable ups products. (A "re-locatable" ups product has a simplified structure compared to that of legacy ups products, and does not require that it be "declared" to a ups database. These features simplify distribution, installation and maintenance of re-locatable products.) mrb provides a simple product template that includes two files that must be modified by the user: a top-level CMakeLists.txt file, that specifies which sub-directories will be included in the build along with any global configuration needed to build the product; and a product_deps file that specifies the dependencies for the package. The product template can otherwise be customized for an experiment. Although this scheme may sound cumbersome and arcane, it is essentially no different than following the package structure conventions imposed by SRT, using a GNUmakefile to configure the build, and a global release setup script to configure the global environment. With cmake, the GNUmakefiles are replaced by CMakeLists.txt files, while the "global environment" for the product is managed locally with the product_deps and top-level CMakeLists.txt files for the product. mrb then manages all the details of utilizing ups to configure the build environment, driving the build, and packaging and installing the ups product in the local products area.

The LArSoft developer environment¶

As previously mentioned, all LArSoft code is archived in a set of repositories based on the git version control system. There are numerous resources on the web on how to use git, starting with the authoritative Pro Git Book and git reference manual provided on the official git website. A search on "git documentation" yields many more.

The LArSoft project has adopted the git branching model described at nvie.com to assist with managing the development workflow and maintaining a stable development environment. Within this framework, the git repositories have the following branch structure:

• A "main" branch that will have only tagged releases. Used only by the software manager.
• A "develop" branch that will have the working head of the repository. Used by all developers.
• One or more "release" branches for the integration of specific tagged releases. Used or authorized only by the software manager.
• An arbitrary set of "feature" branches on which all on-going work takes place. In most cases, these branches will be in local repositories, although publishing them to the reference repository is useful in many cases. Developers can create as many feature branches as needed.
• One or more "hotfix" branches that is used to develop patches to tagged releases. Used or authorized only by the software manager.

The git flow tool is a set of git extension that provide high-level operations for working within this branching model. We recommend that developers utilize git flow when developing LArSoft code. Developers who choose not to use git flow should nonetheless adhere to the branching model.

Links to the tools used in working with the software¶

• git
• git flow
• mrb : the multi-repository build tool
• Re-locatable ups
• cmake

How-to's¶

Advanced technical how-to's¶

Release procedures¶

Walk-through exercises¶

LArSoft code management and distribution procedures¶

Working areas¶

Beta re-factoring