So Long, Upsilon(3S)

It’s been quite a while since I wrote anything here. Things have changed quite a bit since my shining optimism on shift, back in December. Professionally speaking, this has been one of the most exciting and terrifying times in my life as a physicist. We have all felt the crunch of the omnibus budget passed in December, and since then we have all been trying to find a way to do the most science possible with less money. So many opportunities are ahead of us in physics, and all we have to do is find a way to afford reaching out for them.

BaBar switched to running at the Upsilon(3S) resonance, a big change from the B-meson-centric program at the Upsilon(4S). Here we are exploring largely uncharted territory, a sea of unobserved energy states with the lurking hope of some new physics phenomena hidden somewhere in the vast data sample. We have ten times more Upsilon(3S) mesons than recorded at all previous experiments, taken in the span of just a few months. It’s humbling and exciting.

But now we bid farewell to the Upsilon(3S). As we drop our colliding beam energy yet one more time, we can watch the 3S fade into the distance.

Reflections on Shifts

This weekend, I’ve been taking shifts. Specifically, I’ve filled the position known as “Liaison” during the swing period, from 4 pm to midnight. The Liaison’s job is to facilitate communication between the detector group – BaBar – and the accelerator operators. There is a popular perception in my field, which has some truth, of a historical “rivalry” between these two groups. Accelerator physicists are interested in pushing the machine up in performance, possibly creating a high-background environment not suitable for high-efficiency data-taking. The detector physicists want stable conditions with low backgrounds, so they can keep their data logging rates reasonable and maintain a low-noise environment for easier data analysis. Liaison’s job is to pass concerns between the groups, and settle matters of dispute if they arise.

Shifts are the way you get close to your experiment if, like me, you were an undergrad on a different experiment when this one was built. Combined with my detector role, I have not felt this close to BaBar since my last detector service role. It’s refreshing, not only to be reminded where you data really comes from, but to play a modest role in making it happen.

It’s always a little painful. You have to eat questionable food from Safeway, or Quiznos. You drink some coffee, then too much, so that by the time you get home all you can do is think about are diamond sensor background rates while not sleeping. You’re a little too groggy in the morning, a little too sharp in the afternoon. During the quiet moments, when the operators are engrossed in tune space or bunch patterns, you fill the time with work you should have done during the week or the occasional odd posting in the electronic log.

Above all, however, you’re reminded about what a talented crew of people make it possible to probe the frontier of nature. For a moment, you might even get to be part of that crew.

ROOT Tip: Creating New and Complicated Variables

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.