Category: Method

In the world of modern HEP computing, your data analysis location may be on a computer far removed from your office. What if your analysis produces a bunch of plots that you want to be able to just look at without constantly transferring them to your local machine? What if you need to edit code that lives on a remote system and isn’t in CVS? How do you get interactive with remote files?

Many people do the following: they make a secure shell connection (SSH connection) to the remote machine. They then run applications on the remote machine which may pop up windows over the network. The overhead of showing windows over a network connection is HUGE, and often wastes the user’s time. Mounting remote disks using NFS or AFS is either a pain in the ass, or banned due to security restrictions. What can you do?

My go-to solution is SSHFS. This is part of the much larger FUSE program – the Filesystem in Userspace program. FUSE makes it possible for the user to realize the usage of a number of filesystem types without having to be superuser, and without compromising overall system security by requiring access to the kernel of the operating system. SSHFS is an implementation of a network filesystem using the SSH connection protocol.

The idea is simple. Using sshfs, you log into the remote machine and then the remote directory is locally mounted into a directory. You can then use local commands – window operations, terminal operations, etc. – to access the files across the network. For instance, if I make an sshfs connection to machine in Europe and want to edit a script, I run EMACS on my local machine and give EMACS the path of the file on my local disk, which corresponds to the remote file located in Europe. It’s no less secure than using SSH, and as long as you aren’t editing or loading multi-100-Megabyte files over a low-end broadband connection, the response is pretty snappy.

I use SSHFS routinely for editing and viewing files. Even for small ROOT analysis demands, I can use it. Obviously, if you have to analyze gigabytes or terabytes of data, this is a BAD idea. But for simple routine editing and file viewing, it’s a life-saver.

Here are some implementations of FUSE and SSHFS for different operating systems:

• For Linux/UNIX: http://www.linux.com/archive/feature/49757
• For Mac OS: http://code.google.com/p/macfuse/
• For Windows: http://dokan-dev.net/en/download/

How does a physicist survive in a world where computing resources are spread across the globe? In big ways, we as a community try to address this question every day. In small ways – at the level of a single physicist – there are little tips and tricks that can make survival possible.

One of my favorite tricks is to use a program called “screen”. Screen creates a “shell within a shell”, giving you a prompt when you run it on a Linux or UNIX machine. What’s happened is that the screen program spawns a shell within your login shell which can be detached at any time. Detaching the screen shell leaves any program running inside screen alone, freeing you to logout of the machine and come back hours later to check on your work. This is in contrast to what happens if you were to run from a normal shell and try to logout. Often, this ends the running programs, leaving you to have to start all over again!

This may sound confusing, so the best thing to do is just try it. For instance, start “screen” and then type “ping google.com” when you get a prompt. Now, detach screen by pressing “CTRL+a CTRL+d”. The terminal will change back to your login prompt. Now, logout of the machine and twiddle your thumbs for a few seconds. Then, log back in and type “screen -r” to reattach to the screen session. You’ll see that while you were busy logging out and in, ping just kept running uninterrupted.

Imagine the possibilities. You can start running a program that requires a few hours to run, detach and go home. Meanwhile, the program runs on the machine where you ran screen. Hours later, you can log back in (from home, from a cafe, anywhere!) and reattach to see how your program is doing.

There is extensive information on the web about screen. Of course, there is also the manpage! Enjoy!

When presented with a ROOT file, we are often annoyed that the simple variables are present, but the hard-to-compute ones are not. For instance, as might be popular in my experiment, BaBar, perhaps the reconstructed B momentum and the center-of-mass (CM) energy are provided, but not the energy-substituted mass (mES). In this tip, I’ll show you how to define new complicated variables, give them a simple-to-remember string name, and draw them.

Let’s say that the B momentum (in the CM frame) variable is called “pBCM”, and that the CM collider energy is called “SQRTs”. You want to define “mES”, which is mathematically given by: mES = SQRT( (SQRTs/2.0)^2 – pBCM^2 ) You obviously don’t want to have to type this every time. Let’s define a TFormula for this new variable:

TFormula mES("mES","TMath::Sqrt( TMath::Power( SQRTs/2.0, 2.0 ) - TMath::Power( pBCM, 2.0 ) )");

Now you can make this new variable globally accessible to all ROOT commands that parse equations, like TTree::Draw(), as follows:

gROOT->GetListOfFunctions()->Add(&mES);

Now it’s a cinch to use this formula in your Draw() method:

myTree->Draw("mES");

You can easily imagine defining even more complicated variables, like conditional ones where a variable is drawn in certain ways for values of another variable in your ROOT tree. The possibilities are fairly endless.