Set up work area

Last update: 14 Nov 2022 [History] [Edit]

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

tip 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 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 top-level ATLAS CMakeLists.txt file, which is one of two types of CMakeLists.txt files that are used. The other type is a per-package 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 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.