Week 4 Update: some things are working now?

This morning, when I checked my email, I saw a new message that began with a sentence I never thought I’d see: “The PREX experiment is running pretty well”. After all of the technical issues we’ve faced over the past few weeks, things finally seem to be going well. At the very least, we managed to collect a lot of data over the weekend, and the beam is still on now! And I had my own small victory last week: I managed to get a GUI (graphical user interface) working!

The grad student and the other undergrad on this project had been working for a while to get the GUI up and running. The idea was to have one screen displayed on one computer so the people taking shifts (aka babysitting the beam) could click through the various windows and make sure everything was working as it should. We wanted to display a series of plots if the beam modulation system was on for that particular run and a simple message if beam modulation was off. To do that, we needed to find and extract the data that signaled if beam mod was on. We found that, for each run, there was a variable called ErrorFlag that indicated what errors affected the run. ErrorFlag was a 32-bit number, meaning it was composed of 32 0’s or 1’s. Each of these digits, or bits, showed whether a particular characteristic of the beam was on or off. With a little digging, we found which bit corresponded to beam mod- it was 0 if beam mod was off, 1 if it was on. So all we had to do was check if that bit was 1 or 0 and then display the appropriate thing to the screen. Seems simple enough, right?

Of course not.

For starters, ErrorFlag was encoded as number in base-16. Once we figured that particular fact out (it wasn’t immediately obvious), we had to convert to binary and then figure out how to pick out the particular bits we wanted. Next, we had to loop over all of the events in a particular run to determine the status of ErrorFlag for each one. It took a few days to figure out how to design and implement it, and then a little more time to troubleshoot some mysterious errors that came up.

For runs with beam mod on, we get two sets of plots that look something like this:

Screen Shot 2019-07-15 at 11.44.12 AM Screen Shot 2019-07-15 at 11.42.18 AM

And for runs with beam mod off, we get this:

Screen Shot 2019-07-15 at 11.44.52 AM

Comments

  1. Hi!
    I really enjoyed reading the process of how you overcame the problem of displaying Beam Mod correctly. I think you explained the logic behind solving the problem in a way easy to understand (Or did you just left out the hard parts haha).
    Just curious, what kind of software/computer language did you use to make the user interface?

  2. Carrington Metts says:

    Thanks for your feedback! It really wasn’t a particularly complicated problem to solve, it just took us a while to identify what the problem was and then find the documentation that we needed. The script was written in ROOT, which is a toolkit that was developed at CERN in Switzerland to handle and manipulate large amounts of particle physics data. It’s mostly written in C++, but it has its own intricacies. The GUI screen itself appeared through something called Panguin- I’d never heard of it before working on this project, but apparently its job is just to take ROOT scripts and put them together into an easy-to-use interface that updates in real time (so in the version that’s run in the beam control room, the plots actually change to reflect incoming data).

Speak Your Mind

*