Command-line or notebook?

Once you’ve decided on the language, you next have to decide on your programming environment: the command line as in The Basics, or the notebook as in The Notebook Server.

In favor of notebooks

  • They facilitate rapid code development. You fiddle inside a cell, hit SHIFT-ENTER to execute it, get it to do what you want. Then you move to the next cell.

  • Documentation is easy, as shown here.

  • Notebooks are easy to share. For example, a colleague of yours can copy one of your notebooks to their own area to look at it:

    %cp ~jsmith/energy-calibration/myanalysis.ipynb jsmith-analysis.ipynb
  • The interface to a notebook is through a web browser. You don’t need ssh or an X-Windows emulator.

Against notebooks

  • They’re relatively new in software development. It’s possible your supervisor has never heard of them. If you say you’ve got a .png plot in a Jupyter notebook, they’ll reply “You’ve got a what in a where?”

  • The %jsroot on magic command does not enable every X-Window feature available from within the ROOT command line. There’s no TBrowser, Treeviewer, or FitPanel. You can’t add new elements to a plot and then save the ROOT commands so you can examine how to use them in a .C file.1

  • As you saw in the examples above, your canvases are not automatically drawn or updated for you. You must explicitly issue Draw() commands for your canvases.

Issues with the Nevis notebook server

Most of these points involve technical sysadmin issues. You may want to skip them, and come back later if you have a notebook problem.

  • The Nevis particle-physics JupyterHub notebook server is not something you find at most institutions, at least not for now. Only the REU students and the particle-physics groups have access to it. Your astrophysics or RARAF colleagues won’t be able to view your notebooks. You can install Jupyter on your laptop, but that won’t help anyone else see your work.

  • You can develop software in notebooks, but you can’t run multi-threaded or multi-hour jobs with them on our notebook server.2

  • Some physics software is a “chimera”, a blend of software compiled in two languages. For example, the Neutrino Deep Learning group uses Python to call pre-compiled C++ routines. Our notebook server may not be able to run software that’s been compiled on another machine.3

  • As you get more familiar with the UNIX shell, you may start making changes to your standard shell setup. You do this by editing special shell initialization files such as .profile.4 If you add new variables to your environment, these variables are available in our notebook server as well.5

    However, if you modify certain variables such as $LD_LIBRARY_PATH or run environment-customization scripts (such as module load root) in your default initialization, it can affect the execution of the notebook server. The typical symptoms are a notebook kernel that refuses to start or you get library load errors.

You can get around many of these issues by running Jupyter on your Nevis workgroup server.


Oops, I just lied to you. If you’ve drawn something to my_canvas, you can write its associated ROOT commands to a file with


where filename.C can be any name you want. Don’t forget to use -> if your canvas variable is a C++ pointer instead of an object!


The way to handle such tasks is with a batch system. This is one of the optional topics associated with this course.


I doubt this will be important to your work this summer, but so you can look it up if necessary: In 2022, most of the particle-physics systems are running CentOS 7.


Here’s a list of shell initialization files, at least for the systems at Nevis.

A UNIX survival tip: Never let a well-meaning friend start editing your shell initialization scripts for you. I can’t count the number of times I’ve looked at someone’s shell init scripts and saw they were last edited in the 1990s. A user had either forgotten or never knew that their friend had put any such commands there, and so never kept them updated in the years since. These init scripts were copied from user to user for decades.

If you edit your scripts yourself, at least you have a chance to maintain them.


For reference:

If you define a variable in a shell, e.g.,

export mywork=~/analysis_work_directory

then you can access the variable within your program in ROOT C++:

TString my_location = gSystem->Getenv("mywork");

In Python:

import os
my_location = os.environ["mywork"]