DON'T PANIC

A note on key notation: Keys sequences follow the "emacs" style for notating keys. Therefore "C-c" means hold down the control key, while pressing the c key. "M-a" would mean hold down the "Meta" key and press the a key. On most keyboards the Meta key is the key labeled "Alt". There is also the "Super" key, on most PC keyboards this key has the "Windows icon" on it. The function keys 1-12 are notated as F1 etc. The escape key is usually notated ESC, and the enter key is notated RET for Return. A sequence is denoted by a series of keys and spaces or dashes. A dash means hold the two keys at the same time, a space means release the previous keys and continue with the next instruction. Some examples:

• "C-c C-a" Control-C release Control-A
• "C-c a" Control-c release A
• "C-M-f" Press Control, then Meta, then F without releasing

The online version of the guide includes a Table of Contents; simply mouse over it and a full list of topics will pop up. You can click any topic to jump to that section. If you read this in org-mode, the file will open folded. It will look like:

#+TITLE: DON'T PANIC
#+AUTHOR: David Bjergaard
#+EMAIL:  hhg-svc@ccbar.us
#+OPTIONS:   H:5 num:nil toc:t \n:nil @:t ::t |:t ^:t -:t f:t *:t <:t
#+OPTIONS:   TeX:t LaTeX:t skip:nil d:nil todo:t pri:nil tags:not-in-toc
#+STYLE:    <link rel="stylesheet" type="text/css" href="./css/style.css" />
#+LaTeX_CLASS: article

 * A Hitchhiker's guide to High Energy Physics...

Place your cursor at the beginning of * A Hitchhiker's... and hit TAB, this will expand the topics allowing you to see and over-view of the document. Move to whichever topic you're interested in and hit TAB again to expand that section.

If you are reading this in Vim without Vim-OrgMode, then you will have no folding and the whole document will be expanded. Jump to various headlines by searching for "**" (two levels deep), "***" (three levels deep), "****" (four levels deep), etc.

If you are reading this as a PDF, there is no Table of Contents. Just scroll to the section you are interested in.

NOTE If you are reading this on GitHub, a link to another section will probably be broken due to a bug in how GitHub parses org-flavored markdown.

All bottles of donated Old Janx Spirit are redirected to our lawyers, who are out enjoying them now. They insisted that we include this disclaimer:

The Hitchhiker's Guide to High Energy Physics is a set of documents and software herein referred to as "The Guide"

The Guide is free software; you can redistribute it and/or modify it under the terms of the GNU General Public License as published by the Free Software Foundation; either version 3, or (at your option) any later version.

The Guide is distributed in the hope that it will be useful, but WITHOUT ANY WARRANTY; without even the implied warranty of MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the GNU General Public License for more details.

You should have received a copy of the GNU General Public License along with this software. If not, see http://www.gnu.org/licenses/.

Also, note that the content of this guide is satirical in nature, and is intended to be sarcastic. If you have a weak heart or are easily offended, it may be better to seek out other sources of information.

All of the sources for the guide are hosted on GitHub.

Here are some quick-links:

• The Guide the online version of the guide
• PDF of The Guide if you prefer that sort of thing, though it's of limited use in printed form.
• Org source of the online version
• GitHub Repo where source code is hosted
• Compiled Macros for Level 2 of ROOT enlightenment
• Compiled Programs for Level 3 of ROOT enlightenment
• Bug Reports/Feature Requests
• Pull Requests for submitting patches

To get a local copy:

git clone https://github.com/dmb2/hitchhikers-guide-to-hep.git

Then you'll have a copy of the org file, as well as the compiled macros and compiled programs.

• For Linux Hitchhikers
• PuTTY (ssh client for Windows): Secure SHell is the standard way of accessing *nix machines remotely. PuTTY is the Windows client for this.
• ROOT: The industry standard for High Energy Physics analysis. Beware: this program uses an Infinite Improbability Drive to perform analysis.
• Xming an X11 server for Windows: This allows you to tunnel X11 applications (ROOT's histogram interface) to your Windows desktop, this way your data (and ROOT) can live on a remote machine, but you can still interact with them as if they were on your desktop. (You need a fast internet connection to do this). Xming comes in two flavors: the "web" version, which is locked behind a paywall for people who donate to the project, and a slightly less up-to-date public version available for free. Choose the public version. See Getting Started and Trouble shooting for tips on getting set up.
• WSL: Windows 10 released a Linux subsystem that allows a unix-like environment in Windows.
• Cygwin: Adds a substrate of the GNU system to Windows (in addition to an X11 server), you can use this to create a more Unix-like environment to work from.
• VirtualBox: Allows you to boot operating systems within operating systems (useful if you don't want to dual boot Ubuntu) see For Linux Hitchhikers after you've setup a working distro.

See here for a nice picture-book tutorial on installing Ubuntu through VirtualBox on Windows.

• Screen: This lets you pick up where you left off if your ssh connection drops, here is a good conceptual introduction. If you use screen on lxplus, you'll have to re-initialize your kerberos tokens after logging in with kinit -5, otherwise you won't have read access to your files.
• tmux: Offers the same features as screen.
• ROOT: The industry standard for High Energy Physics analysis. Beware: this program uses an Infinite Improbability Drive to perform analysis.
• BASH: The command shell of choice for ATLAS Physicists. You may think you could use ZSH, but it's better just to stick with what everyone else uses. CMS Physicists prefer TCSH for some weird reason.
• Editor: Choose you're religion wisely, it will eventually permeate your being and change the way you approach life in general.

You will, regardless of which operating system you use, be typing commands into a terminal. It's inevitable, powerful, and intimidating to new users. HEP hitchhikers should feel at home. Proficiency with the command line is essential to being a functioning HEP researcher.

The terminal is like the Galaxy Hitchhiker's utility towel. Every hitchhiker needs a terminal, and each hitchhiker customizes his or her towel to their needs.

If you've never touched a terminal before, and don't know what the command line is, there are two options:

1. The great pedagogical introduction (12 page PDF) by Carl Mason
2. "An Introduction to Unix" (a comprehensive, modern take on the unix ecosystem) by Oliver Elliott

You should read both, Carl Mason's tutorial should be read "cover-to-cover", where as Oliver's is written very much in the spirit of this guide, so bookmark it and refer to it after you've read Carl Mason's tutorial.

Many of these tips are lifted from here. Put this in your ~/.ssh/config file:

ControlMaster auto
ControlPath /tmp/ssh_mux_%h_%p_%r
ControlPersist yes
ServerAliveInterval 30
ServerAliveCountMax 1

It is possible to setup ssh shorthand to route you to remote machines. The syntax (in ~/.ssh/config) is:

Host shortname
  #expands to shortname.remote.location.edu
  HostName %h.remote.location.edu 
  User username
  ForwardX11 yes #this is equivalient to ssh -Y
  IdentityFile ~/.ssh/id_rsa #path to your pubkey

The major version control systems in HEP is Git. Git is a series of tools and utilities to allow collaboration on large pieces of software.

Git also provides programmers with a convenient "paper trail" through the course of developing a piece of software. It allows them to revert the source code they are working on to any state that they've previously checked in.

Git is a software that was written by Linus Torvalds, the hacker behind Linux. It was written to manage the Linux kernel, a massive piece of software. Git's model for managing source code is slightly different. In Git, you maintain the entire repository in your local copy. This makes committing, managing, and branching very fast. It also means you can work with all of the advantages of a version control system without internet access. Simultaneously there is a copy of the repository on a remote server. Git handles syncing these two repositories when instructed. This can lead to confusion if you've used other versioning systems, but shouldn't be a problem if you have no expectations.

Some good Git tutorials:

• type "man gittutorial" in the command line
• Pro Git (an online book, modular and comprehensive in scope)
• Git Immersion
• Visual tutorial on branching
• Git Concepts Simplified (slide show, click to advance)

Intermediate or advanced topics:

• Undoing, fixing, or removing commits in Git
• Simple Git workflow is simple
• Git tips from the trenches

*rc files are special files that are executed every time a program starts. They almost exclusively live in the user's home directory, and can be shadowed by the system. Sometimes they have a special syntax for setting options, sometimes they are written in a scripting language. The most relevant rc files for a new hitchhiker are:

.rootrc

the file that sets root options

.bashrc

this is executed every time you open a terminal in bash

.tcshrc

as above but for tcsh (hopefully you aren't using this!)

.zshrc

as above for the zsh shell

.vimrc

configuration options for the venerable vim editor

.screenrc

options for gnu screen

.emacs

written in emacs lisp, is executed on startup, breaks the rc naming scheme. Advanced emacs users have multi-thousand line rc files

There are other files, if you want to know about them you can do:

ls .*rc

And google the ones that look interesting. Alternatively you can look at the system defaults:

ls /etc/*rc

Sometimes its useful to copy the system file to your home directory and then edit it there in order to add your customizations. Some programs document their options that way.

In recent years programs have begun migrating to putting their configuration files and options the .config subdirectory in a user's $HOME directory.

• XQuartz: Like XMing for Windows, XQuartz runs a local X11 server for tunneling X11 applications over SSH, unlike Windows, you don't need a separate SSH program, ssh is built in.
• Terminal.app: This is Mac OS's default terminal emulator. It comes with Mac OS, so you shouldn't need to install it. You should be aware of it though.
• ROOT: The industry standard for High Energy Physics analysis. Beware: this program uses an Infinite Improbability Drive to perform analysis.
• Aquamacs: A port of Emacs that uses Aqua as a standard OS X application. This integrates Emacs with the Mac OS UI. In the long history of corporate acquisitions a lot of Emacs hackers (from NeXTSTEP) ended up at apple, you will find that Mac OS integrates the Emacs experience much more fundamentally than any other OS in existance. (This doesn't mean you need to use Emacs if you use Mac OS, just that your muscle memory will thank you subconsciously.)
• MacPorts: A system for compiling and installing open source software on the Mac
• Home Brew: A package manager for Mac OS, allowing you to install various utilities that don't necessarily come pre-installed with Mac OS.

After you have finished the tutorial for your editor of choice, then it's time to find a guru. Guru's are best located by asking around. If you are talking with someone and notice they use your editor, don't be afraid to ask them how they did something. Most of the time the Guru will be flattered and may even volunteer to help you with any other editor related questions.

The end goal of any student of the Church of Emacs is to obtain proficiency reprogramming the editor to solve the task at hand. This is ultimately stems from the philosophy of lisp (this gift was given to us by St. IGNUcious an AI hacker from MIT where Emacs was born). In lisp, the flexibility of the language allows it to be re-written to solve the problem as clearly as possible. In Emacs, an enlightened user will write a substrate of elisp (Emacs' dialect of lisp) in order to solve the editing problem at hand.

While customizing and writing your .emacs (the initialization file loaded by Emacs in your home directory) is a spiritual journey, there are those who have done their best to illuminate the path. A brief guide to customization philosophies here.

The Editor finds the following packages essential:

• tramp: If your reading this in Emacs, you can follow the link with "C-c C-o". It is the most important aspect of Emacs for HEP users. It allows you to "visit" files on remote machines from the Emacs running on your desktop. It does this through ssh. To visit a remote file, type "C-x C-f" and then type '/ssh:user@remote.host:~/remote/path', note that tab completion works remotely just the same as visiting a file locally! Tramp is also aware of ssh aliases in ~/.ssh/config, see Configuring SSH.
• Calc - ""Calc" is an advanced desk calculator and mathematical tool written by Dave Gillespie that runs as part of the GNU Emacs environment." It handles barns and electron volts out of the box!
• filladapt: a mode for more intelligently filling text in paragraphs
• flyspell: a spell checker that highlights mispelled words (will check in comments if in a programming mode)
• rect-mark: Adds facilities for marking yanking and otherwise editing columnar formatted text.
• dired (another info link): a directory editor for manipulating files in the Emacs way
• solarized-theme: A theme by Ethan Schoonover, comes in dark and light variants that actually complement each other well, another good one is zenburn or gruvbox
• ibuffer: changes the buffer interface and allows you to group buffers based on various buffer attributes
• paredit: Enhances Emacs's awareness of parenthetic structure
• smartparens: Electrically pairs and deletes delimeters when appropriate (never miss a closing brace again!)
• auto-complete: When setup properly, tab completes anything at any point depending on past input or names in other buffers.
• auctex: LaTeX editing facilities (for when org-mode doesn't quite cut it)
• org-mode: This guide is written in org-mode. Org-mode can manage todo lists, write websites, serve as a lab notebook, execute code for literate programming and many other things. More relevant for physicists is the org-mode cookbook. People switch to Emacs just to get org-mode!

Init files of famous Emacs hackers are (in no order of awesomeness) Magnar Sveen, Technomancy, John Wiegley. There are also software packages that intend to comprehensively change the Emacs out of the box to a better user experience. The two most famous are Prelude and Emacs Live. An example (slightly annotated) init file can be found here.

Finally, there are some Emacs gurus who post blogs on the internet. Some particularly useful ones are Emacs Redux, Mastering Emacs, and Emacs Fu.

Various religious texts granting Emacs users various powers (such as reading email, chatting, tweeting, playing games, listening to music) can be found at the Emacs Wiki.

If Emacs is like Catholicism, then Vim is like Buddhism. Vim is the modern incarnation of vi, a modal text editor that descended from ed. The modal way of editing is by expressing in a few keystrokes how the text should be manipulated. This is in contrast to Emacs, where text is manipulated directly. This fundamental difference is the source of much confusion for new users, and is also why many people recommend Emacs as "being easier to learn." This should not deter new users from learning vi(m), as its editing facilities are substantial.

A functional .vimrc looks like:

syntax on
set cursorline
set hlsearch
set ic
set incsearch
set ruler
set shiftwidth=4
set tabstop=4
set wrap

To learn Vim, type vimtutor at the command lime and follow the instructions. Take your time, and repeat the tutorial once or twice over a few days. In the mean time editors such as gedit or nano offer a more traditional experience. As your Vim skills improve, you will feel more comfortable with Vim and can stop using the less powerful editors.

Some useful links include:

• Vim Videos Tutorial videos by Derek Wyatt, the novice videos are must see if you are new to vi(m)
• Vim Genius a drill website for learning Vim commands
• New user Vim Tutorial
• Vim Koans tidbits of wisdom to ponder
• A collection of extensions and plugins for Vim
• YouCompleteMe A Vim autocompletion engine for editing.

Followers of the Unix way realize that there are situations where a using a set of shell commands piped together may fit the task at hand more efficiently than either of the other two editors. Tools you should be familiar with are:

• sed and one-liners
• awk and one-liners
• perl (and its poetry)
• grep
• Heretics exist which exhort the use of pico or even nano.

Always keep in mind

Some people, when confronted with a problem, think "I know, I'll use regular expressions." Now they have two problems. – Jaimie Zawinski

Required Reading: The Descent to C

As C++ has evolved from C, it retains parts of C's low level nature. Part of this is the need to be explicit about managing memory manually. This is in stark contrast to languages such as Java or Python where memory management is handled for the programmer.

A consequence of this is the ability to address specific cells of memory (the smallest accessible unit, typically a byte). An object (int, double, float, char, string, etc) may span several memory cells. A pointer is the computer's representation of a memory cell's location in memory, ie a memory address. Ultimately the programmer is interested in the data contained in the set of memory cells "pointed to" by the pointer. The act of retrieving this data is called "dereferencing a pointer".

As in physics, facility with manipulating pointers is best gained through experience, however many analogies have been developed to ease confusion. One analogy is street addresses, A street address is a sequence of numbers (the pointer) which instructs someone, a mailman say, (the computer), how to find a specific location. Once at that location, it is possible to manipulate objects located at that address (deliver mail if your the mailman, break the mailbox if your a bored teenager, knock on the door if you are a vacuum salesman etc).

Now some syntax:

Foo* bar = new Foo("Baz",42,"What is the question?");
std::cout << "object bar lives at memory address:"<<bar<<std::endl;
std::cout << "bar calculated a question to the answer to \"The Ultimate Question\" as "<<bar->TheAnswer()<<std::endl;
std::cout <<"Another way to get the answer is: "<<(*bar).TheAnswer()<<std::endl;

Lots of interesting things have been introduced here. Let's look at a possible output of this program:

object bar lives at memory address: 0xd29ad0
bar calculated a question to the answer to "The Ultimate Question" as "What is 6x9?"
Another way to get the answer is: "What is 6x9?"

What happened? Let's look at the first line

Foo* bar = new Foo("Baz",42,"What is the question?");

Foo* is a pointer of type Foo. It's an address to a chunk of memory that contains an instance of Foo.

Question: Why does the compiler need to know that it's a Foo type object at that address?

Answer: Foo might fall across several memory cells, in which case the compiler must know how many memory cells to move if you ask for the bar+1 spot. In fact, in C there is a concept called the void*, a type-less pointer that is an address to anything. It is the programmer's responsibility to cast the void* to the correct type.

OK, so we have a pointer to an object of type Foo called bar.

Question: What happens on the right hand side of the assignment operator (=)?

Answer: C++ reserves the keyword "new" for memory allocation. The "new" keyword takes a class constructor on the right hand side, and returns a memory address on the left hand side. This address gets stored in the variable bar.

Operationally, the "new" keyword allocates a chunk of memory to hold the object on the right hand side, and returns a pointer to the beginning of the chunk.

What happens when we want to access the memory that the pointer points to? There is another operation called "dereferencing" which goes to the address pointed to and returns the object contained at that point in memory. Consider the following snippet:

double* foo = new double(3.14159);
double pi = *foo;
std::cout <<"Pi is: "<<pi<<std::endl;

Here, a chunk of memory has the value 3.14159 written to it, then that value is retrieved and stored in another location of memory called pi. That data is the written out the terminal by std::cout and std::endl.

Now we can understand this line:

std::cout <<"Another way to get the answer is: "<<(*bar).TheAnswer()<<std::endl;

It means, retrieve the object pointed to by bar, and call the method "TheAnswer()" on it. Programmers abhor syntax that can easily get them into trouble, so the language designers (of c) added a shorthand for this kind of operation (the -> operator):

Foo* bar=new Foo();
if(bar->Value()==(*bar).Value()){
  std::cout<<"They're the same!"<<std::endl;
}

Quiz: What will the output of this snippet be?

Methods, or functions are defined as:

return_type function_name(arg1_type arg1, arg2_type arg2, ...){
  //statements that define function_name
}

It is possible to "forward declare" functions, these are "promises to the compiler" that you have a function with a particular signature:

double foo(double,double);
// important other stuff
double foo(double theta, double phi){
  return sin(theta)*sin(theta) + cos(phi)*cos(phi);
}

Notice that the compiler doesn't need to know the names of the arguments in the forward declaration.

Before we move onto the next topic, a note on methods. Most of the time during development, you only have a few helper functions. This is fine! Just write your helper functions in a header file, and include them. Write the main function and move on with your life. There are many examples in HEP, where methods have been pigeon-holed into classes. The result is a cumbersome interface for the user (YOU!) or more importantly your supervisor. With that in mind, lets move on to classes.

STOP! Read the last paragraph of the previous section.

Now, ask yourself: Do I really need a class? No. Ok, great!

Yes. Are you sure? Maybe your needs are better served with a few functions and a well defined interface.

Do you have complicated data structures that need to be operated on by many methods? No? Maybe your needs are better served with a few functions and a well defined interface.

Yes? Maybe you should rethink your design.

You've rethought it and realized that you have to use a class because the person before you did, now there isn't a clean way to do it any other way. OK, classes.

Editor's Note: Our dear reader may have been studying this guide and thought to themselves: "Gee wiz, there is a lot of great advice here, I should follow this exactly or dragons might eat my analysis program!" While this may be a possibility, the previous advice on classes may be a little, well, misguided.

More sound advice may sound like this: When beginning development, make your first (and maybe second) drafts of the program without classes. This will force you to recognize which parts of your program fit together (data+methods) and which are separate. Then, revise your program to include classes with the appropriate encapsulation of data and methods. This will ensure that you write a clean interface, and that you don't end up with 20 methods that all take the same four arguments.

The basic syntax is:

class A{
public:
  A():a(0),b(0){};
  A(int _a):a(_a),b(0){};
  ~A(){};
  void SetA(int new_a){a=new_a;};
  void GetA(){return a;};
  void SetB(int new_b){b=new_b;};
  void GetB(){return b;};
private:
  int a;
protected:
  int b;
};

This is a trivial example, and it breaks many rules about naming conventions and clarity. It is not a good example. It should not be used as a good example to win arguments about concise code. In fact, you probably shouldn't have read it.

Important features of the code: Anything after the public keyword is accessible to the outside world, ie:

A myObj;
myObj.SetA(10);
myObj.GetA();
myObj.SetB(42);
myObj.GetB();

Is all valid code, anything that is written after private, is just that. You cannot access it outside of the class:

myObj.a; //Compiler error
myObj.b; //protected is a special form of private

The protected keyword is for class inheritance. It says that these variables and methods are private for users of the class, but if another class inherits from this one, they inherit these symbols.

Normally in class inheritance, you only inherit the public members of the class. The private members are not inherited. Protected offers a way to encapsulate data, but also share data among inheritance diagrams.

In case you haven't picked up on it, classes are one of the hairier aspects of C++. It's better if you refer to some other resource for a tutorial on classes, as their subtleties are beyond the scope of The Guide.

Mostly Harmless.

The ROOT devs have done a great job of documenting how to install pre-compiled versions on various OS's. Sadly its not straightforward on Debian-based (aka Ubuntu) systems. Windows binaries are available but they're beta-use.

These instructions are for *nix based systems (ie it was written for Ubuntu, but MacOS shouldn't be much different and Windows is out of the question).

When choosing a version of ROOT, always pick the 'pro' (pro for production) version. It's the latest, stable, version recommended by the ROOT Devs.

Nota Bene If you're doing this on Mac OS, you'll need to use brew install blah instead of apt-get install blah, and the package names will probably be different.

If you haven't yet, read the section of the guide relevant to your OS.

For our install of ROOT, we'll be compiling and running it locally. This has a few advantages:

• "Uninstalling" is easy, either unset the environment variables pointing to ROOT, or completely delete the folder that root lives in (in this example ~/root)
• Having multiple versions side-by-side is possible, you could have:
  • ~/root-clang a version of root compiled with clang
  • ~/root-5.34 a stable version of ROOT
  • ~/root-5.99 the beta version of ROOT 6
  • To use any of them you would just have to source ~/root-ver/bin/thisroot.sh
• You don't need root (administrative) access on the machine (as long as the pre-req's are installed). This is generally nice since it decouples ROOT from the hosting OS.

It appears that xrootd is built with root by default. If you want to be able to access files hosted at CERN, you'll have to have a kerberos client installed (either krb5-user or heimdal-clients on debian or ubuntu systems). Then before connecting, run kinit -5 ${CERN_USER}@CERN.CH to generate a kerberos certificate.

This might be a little in the weeds, but if your event processing bandwidth is smaller than the network bandwidth you can achieve the same performance as a local file-system without needing to copy large data sets locally. Of course there are lots of considerations, not least of which where your machine is relative to the data on the network.

There are three methods of running code through ROOT to produce results. These methods are listed below, each more sophisticated than the last. They also include example code intended as a starting point for hacking.

As a reminder, see Obtaining a copy and supporting material for instructions on obtaining and running the example code.

PyROOT are a set of python bindings to ROOT. It works fairly well out of the box, but there are some things to keep in mind.

• Idiomatic python avoids "from ROOT import *", prefer "from ROOT import blah"
• the ROOT devs know you aren't going to be idiomatic, so instead they've implemented a lazy loading system (ROOT is huge, so "from ROOT import *" would take forever). This may be confusing if your a python expert and expect exploration commands like dir() to work with ROOT.
• If performance matters, try to stay in C++ land (ie call C++ functions from python) as much as possible
  • If performance really matters, write it in python and then port it to C++. This is fairly advanced, but not impossible. You'll have to generate CINT dictionaries for your source files.

If you're looking for a more "pythonic" (not my word) experience, maybe give rootpy a shot. See also An even briefer introduction to Python for resources to learn python itself.

RooFit is a shiny penny compared to the rest of the ROOT ecosystem. It has its own quirks and idioms, but the interfaces are fairly reasonable and the manual is well written. The latest version of the manual and quickstart can always be found here:

• ROOT User's guide, Roofit Manual

Direct links are here, though they aren't guaranteed to be current:

• RooFit Manual (PDF) 2.91-33
• RooFit Quick Start Guide (PDF) 3.00

A well designed graph is truly a work of art. The path from paltry graphics spit out by ROOT to something worthy of framing (and yes, truly amazing data visualizations are routinely framed) is long and fraught with naysayers who will insist that you are doing it wrong. Ignore them, and do what needs to be done to communicate your hard won data clearly and concisely. To get you started, give "Principles of Information Display for Visualization Practitioners" a read. It is an executive summary of Edward Tufte's works on visualizing information. If what you read resonates with you, then please read Tufte's books. They make for delightful coffee time distractions. After reading his books you will start to see his influence in particularly nice graphics. You will also see many sins committed by other practitioners. Choose your role-models wisely.

Sage advice (passed down from The Editor's first mentor):

When you make a plot, take the time to make it publication quality and reproducible.

This means two things:

1. Make it good enough to go into a paper
2. Prefer generating it with C++/Python over any other format (data inputs will frequently change at the last minute, and being able to "hit a button" and get the plot is very useful unless you have a room full of Mechanical Turks lying around)

This also means it's probably a good idea to keep *.root files containing your histograms for last minute style changes if you are writing a presentation.

Producing a publication quality plot can be challenging, however ROOT includes the concept of a "Style" which can be applied. These are global rules for how plots should be printed. In previous versions of ROOT, the default style was notoriously bad. In The Editor's humble opinion, this was done to simultaneously encourage each physicist to set their own standard, and to immediately identify ROOT newbies from seasoned ROOT hackers.

Now, things are better, though the idea that "each physicist set their own standard" has stuck, and so there are many styles floating around.

Sometimes it is useful to add your own developed classes to ROOT (so they can be used in ROOT macros/PyROOT scripts or so they can be stored in a ROOT file). For example you may have a class of the form (in a file called CustomEvent.h, for example):

#ifndef CustomEvent_h
#define CustomEvent_h

#include "TObject.h"

class CustomEvent : public TObject {
  ClassDef(CustomEvent,1);
private:
  int    _eventID;
  double _eventEnergy;
public:
  CustomEvent() {}
  virtual ~CustomEvent() {}

  void set_eventID(const int eid);
  void set_eventEnergy(const double e);

  int eventID() const { return _eventID; }
  double eventEnergy() const { return _eventEnergy; }
};

#endif

It is a good idea to inherit from TObject if you require reading or writing objects to disk. Official documentation of the ins and outs of adding classes can be found in Chapter 15 of the User's Guide, as well as information here: cint and ClassDef. We also need CustomEvent.cxx:

#include "CustomEvent.h"

CustomEvent::CustomEvent() {}
CustomEvent::~CustomEvent() {}

void CustomEvent::set_eventID(const int eid) { _eventID = eid; }
void CustomEvent::set_eventEnergy(const double e) { _eventEnergy = e; }

To make this class accessible within (Py)ROOT you must create a LinkDef.h file of the form:

#ifdef __CINT__
#pragma link off all globals;
#pragma link off all classes;
#pragma link off all functions;

#pragma link C++ class CustomEvent+;

#endif

Now you must generate a dictionary for the class:

rootcint -f CustomEventDictionary.cxx -c CustomEvent.h LinkDef.h

This generates CustomEventDictionary.cxx and CustomEventDictionary.h. Now you can compile the source for your class and the new dictionary source. Then finally link them together in a library:

g++ -fPIC -c CustomEvent.cxx `root-config --cflags`
g++ -fPIC -c CustomEventDictionary.cxx `root-config --cflags`
g++ -shared -o libCustomEvent.so CustomEvent.o CustomEventDictionary.o `root-config --glibs`

Now by loading the library libCustomEvent.so you can use your class within ROOT. For example, the macro:

{
  gSystem->Load("libCustomEvent");
  CustomEvent a;
  a.set_eventID(42);
  std::cout << a.eventID() << std::endl;
}

At some point you'll get stuck. Hopefully you'll be stuck on a good problem, but more often than not you'll be stuck on some quirk that ROOT has. Remember ROOT's mantra: "It's not a bug, it's a feature!"

ROOT's object protocol is very strange. The naming schema is based on an industry standard for C programs where it's not possible to use namespaces. The result is very confusing for new users (very good for HEP). Every object in root that can be written to disk (ie saved in a ROOT file) derives from a TObject base class. This base class defines a protocol for objects. (All objects can print themselves, have a name, have a title, have a class name, etc). This makes it possible to have a list of disparate objects (as long as it's a list of TObject*). As you gain more experience with ROOT, this becomes a power tool. Like any power tool (as Tim Taylor can attest), this can be abused to no end.

Eventually you'll encounter a segmentation fault or segfault in ROOT. (They can also go under the name core dump). This happens when you try to read, write, or otherwise abuse a part of memory that doesn't belong to you. The result is that the program (ROOT usually) crashes. ROOT has gotten pretty good at realizing that this has happened, and printing information about what was going on when the crash happened.

If you've never touched HEP or heard of Particle Physics, read chapter 1 and 2. Otherwise here's a rough path through the book (with suggested exercises to work):

• Chapter 3 (Problems 3.4, 3.14 (for fun), 3.15, 3.16, 3.25, 3.26 (last two cover Mandelstam variables, which are very useful tools))
• Chapter 6 (Problems 6.8 or 6.9, 6.12, 6.13, 6.14, 6.15)
• Chapter 7 (Problems 7.6, 7.8 (optional), 7.14, 7.23, 7.30, 7.36, 7.37, 7.39, 7.51)
• Chapter 8 (Problems 8.14, 8.15, 8.16, 8.19, 8.23, 8.28)
• Chapter 9 (Problems 9.2, 9.3, 9.6, 9.14, 9.17, 9.20, 9.23, 9.25, 9.31, 9.32)
• Chapter 10 (Problems 10.4 10.5, 10.6, 10.15, 10.16, 10.21, 10.23)

Halzen and Martin has a better treatment of Quantum Chromodynamics, but that just adds another book to your library.

This assumes the reader has covered the material in chapter 4 in a undergraduate quantum course (at the level of Griffiths). Chapter 4 is too much of a review to be useful as a primary source. Griffith's quantum book covers it, but Townsend's "A Modern Approach to Quantum Mechanics" is a better text to have on your bookshelf.

HEP uses cylindrical coordinates (well, a combination of cylindrical and spherical really) with the z axis oriented along the beam line, R radially "up" and the φ curling right-handed around the beam axis.

In addition, HEP physicists think in terms of a variable called "pseudorapidity" denoted η. This is defined as \[ \eta = - \log\left(\tan\frac{\theta}{2}\right) \] Where θ is the polar angle from the beam azis. Why use this crazy coordinate system? Well, it's related to rapidity, the relativistic counterpart to speed. More important to HEP experiments, differences in pseudorapidity are Lorentz invariant along the beam axis.

If you want to keep a mental map of angles (from wikipedia):

This is taken from The Editor's Lab Notebook (which is locked by a password, and hence will only be read by one person):

Someone generates gobs of MC for use in any analysis for some process ( \(W\rightarrow \mu\nu+p\) where \(p\) is a parton). I want to study what a variable will look like in data, so I run my analysis over the MC and get a plot out. Then I run the same code over data and plot the two on top of each other. The trouble is that the number of MC events I ran over is not the same as the amount of data I ran over. Now the problem becomes how to appropriately scale the Monte Carlo prediction to match the data (the result of the experiment).

As experimental high energy physicists, we define variables so that we can relate the cross sections predicted by theory to what we measure out of the beam. To this end, we can get the number of expected events from

Here \(\sigma\) is the cross section in barns (typically pico-barns) and \(\mathcal{L}\) is the integrated luminosity collected by the experiment. How do we compare this to the Monte Carlo prediction? There, the computer counts up the number of events that were generated for a specific process, what we want is

Here \(N_{exp}\) is the expected number of events we get from Data. In order to compare data to MC we need to scale \(N_{exp}\) to the same order as \(N_{D}\). Remember, there is a cross section calculated from theory that the MC prediction used, therefore we can write

It is possible that \(\sigma_{MC}\) is corrected to the next order. In order to avoid recalculating everything, a \(k\) factor is reported as the ratio of \(\sigma_{NLO}/\sigma_{MC}\). Then all you have to do is multiply \(\sigma_{MC}\) by the \(k\) factor, and the calculation is updated to the newest NLO prediction.

We're interested in the weight, so

Now, when each bin in the Monte Carlo histogram is scaled by W, it will be equal to the theoretically expected yield calculated by \(\sigma_{MC}k\).

There are many possibilities. The most "user friendly" is probably JaxoDraw. It's even got a name reminiscent of Douglas Adams!

JaxoDraw comes as a jar file, you may want to make it more command line friendly by making a script to invoke it (put this in ${HOME}/local/bin/jaxodraw):

#!/bin/bash
java -jar ${HOME}/local/lib/java/jaxodraw-2.1-0.jar $@

Now make it executable:

chmod +x ${HOME}/local/bin/jaxodraw

And add it to your PATH. I have my path set up to search this path from my .bashrc:

export PATH=${HOME}/local/bin:$PATH

Now to test it out by typing jaxodraw at the command prompt, it should just launch. If it doesn't try again.

Someday you may be working on a presentation and want the figures exported by jaxodraw to have a transparent background. Some kind soul has hacked the conversion steps to do this for you. You can grab the scripts here: http://personal.psu.edu/jcc8//jd-conversions/

If you have jaxodraw setup as above you can just dump the scripts in $HOME/local/bin and run them on the xml file produced by jaxodraw.

Calm down, take a deep breath and read the first line of The Guide. Then come back here. Somewhere a fellow grad student has a copy of "Introduction to Elementary Particles (2nd Edition)" by David Griffiths. Read Chapter 6 in entirety paying special note to the footnote on page 205.

When keeping a lab notebook, it is important to make the barrier for writing something down as small as possible. If it's difficult or inconvenient, you will not be inclined to document as well as you should.