Configure Work Area

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:

cd tutorial
cp -rpL /cvmfs/atlas.cern.ch/repo/tutorials/asg/cern-mar2023/AnalysisTutorial .

Tip

Note that the path includes mar2023. This does not need to be updated to the current tutorial version, but newer versions can be safely used (they are identical).

Note

tutorial/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 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.

Tip

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 into source.

Tip

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. If you have multiple build or run 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. You can think of a project as a collection of packages; in Athena we usually use the word "package" to refer to a directory that includes code for a specific purpose (e.g. reconstruction configuration). We often interchange project names with release names: AnalysisBase is a project, for example. The package-level CMakeLists.txt file 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 tutorial by the HSF covering the basics of using CMake can be found here.