Use a new shell for the rest of this tutorial to ensure that any local variables from the MC part are not kept.
For this tutorial, we will provide the basic structure for your work
area as well as a skeleton for the analysis code you will be using.
Begin by copying the
AnalysisTutorial directory to your local area:
cp -rp /cvmfs/atlas.cern.ch/repo/tutorials/asg/cern-nov2022/AnalysisTutorial .
Have a look in
AnalysisTutorial and you will see three directories:
source: This is where all of our source files go. It is already
populated with a top-level
build: This is where all the files created by the build system
go. If you ever want to start over your build process you can just
remove and recreate the directory to start over. As such you shouldn’t
put any of your own files into this directory and it should not be
committed to a git repository. Note that some advanced users also have
several build directories (e.g. one for AthAnalysis and one for AnalysisBase,
or starting a new one whenever you switch releases). If you are unclear
why one would want to have multiple build directories, don’t worry about
it, a lot of people work happily with a single build directory.
run: This is where you actually run your programs, collect your
output files, etc. The organization of this directory can be in any
way you want, you can create multiple directories, subdirectories,
etc. It should not be committed to a git repository.
Note that generally your
sourcedirectory should correspond to a git repository (or at least some version controlled area) or should contain one or more version controlled packages. In this tutorial, we will check out a version controlled package into
Note that the naming of these directories is merely a suggestion, none of these names are actually hard-coded in the atlas software. In particular if the
sourcedirectory is a git repository it is generally preferable to name it after the git repository instead. And if you have multiple
rundirectories you should give them names that describe more clearly their different purposes.
source directory you will find a file called
This is a standard top-level ATLAS
CMakeLists.txt file, which is one
of two types of
CMakeLists.txt files that are used. The other type is
CMakeLists.txt file that is customized for each package
and describes the content of the package. The per-package type will be
introduced later and used extensively throughout this tutorial. Whenever
you are asked to make changes to
CMakeLists.txt, it will be in the
package-level version. You will have exactly one top-level
and we will not go into details about its content in this tutorial, but
you can look through it to try to see what it does.