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 tutorial
directory:
cp -rp /cvmfs/atlas.cern.ch/repo/tutorials/asg/cern-mar2023/AnalysisTutorial .
Note that the path includes
mar2023
. This does not need to be updated to the current tutorial version.
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 CMakeLists.txt
file.
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
source
directory 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 intosource
.
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
source
directory is a git repository it is generally preferable to name it after the git repository instead. And if you have multiplebuild
orrun
directories you should give them names that describe more clearly their different purposes.
Inside the source
directory you will find a file called CMakeLists.txt
.
This is a standard ATLAS project-level CMakeLists.txt
file, which
is one of two types of CMakeLists.txt
files that are used. The other
type is a package-level CMakeLists.txt
file that lives within a package
and is customized to describes the content of the package. The package-level
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 CMakeLists.txt
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. A relevant tutorial by HSF covering basics of using CMake can be found here.