Set Up Work Area

Last update: 20 Oct 2023 [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 tutorial directory:

cp -rp /cvmfs/atlas.cern.ch/repo/tutorials/asg/cern-nov2022/AnalysisTutorial .

tip Note that the path includes nov2022. This does not need to be updated to the current tutorial version as was done with the setMeUp script in the account setup session.

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