Goodbye Japan | Blog #5

I’m back!

Before I delve into what I spent the final week of my internship doing, I wanted to give a brief summary of the KOTO experiment. If you don’t recall, the KOTO experiment is an international endeavor to measure the rare K-Long -> Pi-zero Nu Nubar particle decay in order to compare experimental measurements with the predictions given by our current understanding of particle physics. A couple times a year, the different groups from around the world meet in person to discuss important developments concerning the project at a three-day event called the Collaboration Meeting. I attended this meeting in order to give a presentation that detailed the upgrades currently happening to the project’s data acquisition system (DAQ). While the development of the DAQ primarily occurs at the University of Michigan (where my internship was located), the actual data taking is done in Japan at the J-PARC facility. As such, the Collaboration Meeting was held in Japan and I received a wonderful opportunity to travel outside the country!


Welcome to Japan


After a long 12-hour flight and a 3-hour bus ride, I finally arrived at my destination, the small village of Tokai-mura. My first impressions? Japan is not America. Painfully simplistic, I’m aware, but there were just so many differences that it’s hard to concisely and accurately describe the variations between the two. The architecture of the houses and the way the roads zigzagged across the land,  the day-to-day interactions with people, and of course the local cuisine were all very different from America (Tokai in particular is by an ocean, so a lot of my meals consisted of fresh fish).

Compared to other places I’ve been, Tokai has an interesting quality to it. Dotted with crop fields and containing various parks and temples, the town feels bustling with nature – which at times can make it easy to forget that it also contains a half mile long particle beam. While it’s standard practice to build facilities that produce radioactive materials far away from highly populated areas, I couldn’t help but think of the weird duality this creates. On one side, Tokai represents some of mankind’s greatest technological and scientific advancements, along with our growing ability to probe the nature of the universe; on the other hand – a few blocks away from J-PARC you might be biking through a rice paddy at sunrise next to a soaring swan (at least it looked like a swan).


One of the various temples in Tokai


Of course, the purpose of my visit wasn’t to see Tokai-mura but to learn more about the KOTO experiment. As such, part of my trip was spent seeing the facility that houses the particle beam. When I entered the building, the first sight that greeted me was a giant chasm filled with all manner of construction equipment and electronic doodads. Maybe I’ve seen one too many James Bond movies but my initial impression was that the facility looked more like a typical villain’s lair than expected.


Anyone else thinks it looks lair?


Seeing the main-barrel didn’t help with my initial impressions either. The main-barrel is a big, blue vacuum-sealed chamber where the K-Long -> Pi-zero Nu Nubar decay occurs. To give a sense of its scale, it has a diameter of about feet 10 and is roughly 20 feet long, so big in fact that I couldn’t get a proper full-body picture of it.


The Main Barrel


The next day, the Collaboration Meeting began. At first I was a little nervous to give my presentation; the entire audience was not only more educated than me but also had more experience with KOTO. Fortunately, my presentation was scheduled for the second day of the conference, giving me time to examine and learn from others. After internalizing my mentor’s famous words, “Remember – you’re the expert,” I was able to shake my initial nervousness and get into the swing things (even managing to a have a few of my jokes land).



That’s me, way in the back


For my final day in Japan, I woke up early in order to bike around Tokai. The morning was quiet and the air nice and crisp, a perfect time to gather my thoughts about the past few months with the KOTO project. Because of this internship – I learned how to code, I learned useful organizational skills, and I learned how to effectively work on a team. Skills that will prove useful as I continue studying physics.

I send my thanks to Myron Campbell, for accepting me onto the team (despite my limited experience in coding) and being my mentor this internship. I thank my various KOTO co-workers for being a pleasure to work with. I thank the LSA Internship Program for allowing me to share my experiences with all of you.



And thank you for reading this blog!


Joshua R.



Working with the Workforce | Blog #4

Hey ya’ll,

As the end of summer approaches, my responsibilities at the KOTO particle experiment have been slowing down. Consequently, this week most of my time has been spent working on (drum roll please) a power point presentation! The presentation is for an upcoming meeting that will be held out of the country; normally, the various groups that comprise KOTO share updates through conference calls, however a couple times a year we all meet in person at an event dubbed the Collaboration Meeting. My presentation at the Collaboration Meeting will be a summary of the progress the Michigan team has made in regard to upgrading the system that collects the project’s experimental data.

Summarizing the work of the Michigan team got me thinking about all the interesting people I’ve had the pleasure of meeting because of my internship. One aspect of the workforce that I enjoy is simply the variety of people that I’m able to get to know. Here, there are grads, undergrads, post-docs, researchers, and professors – people who just recently entered college and people who have had careers longer than the entirety of my life. I enjoy seeing these different personalities, perspectives, and skills complement each other as we solve problems and work toward a goal. For example, there are times when I’m struggling with finding a solution to a problem that to my co-worker seems obvious, and sometimes it’s the reverse.

Another advantage is the wealth of practical career knowledge the older members of the team are able to share with me – tips about giving presentations, what opportunities I should seek to progress my career, and more. Plus, it’s always a thought-provoking day when one of my co-workers tell me about an exciting life-changing experience they went through (ever heard a first hand account about life in Antarctic).

That is one aspect of this internship I thoroughly enjoy.

Joshua R.

Notebooks & Record Keeping | Blog #3

Ever since I’ve gotten my research position at KOTO, my appreciation for finely crafted research notebooks has significantly increased. My affection for research notebooks first grew out of tragedy. It all began when my internship had tasked me with creating code that would take the experiment’s data and prepare it for transmission to a PC. While I had completed the first version of the code relatively quickly, it had simply refused to work.

Coding firmware is a bit different than coding software. “Simply” put, when you produce code for an FPGA you are essentially mapping out a circuit. This is different than software, where your code amounts to a list of instructions that a processor executes. Because you are creating a circuit in firmware, there are physical constraints you have to factor when coding firmware. For example, certain types of signals need to placed in specific locations in the FPGA, and you need to make sure your signals are traveling fast enough from point to point to insure the circuit behaves as expected. If you don’t properly consider these constraints, you can create code that produces different results in a simulation than when it’s running on an actual board.

This was happening to me, and I went through the steps a typical programmer might take to debug code; re-reading through my code to detect logical errors, perusing books on how to transmit data using an FPGA, and of course going to After weeks of trying anything and everything that could have the tiniest iota of a chance towards making my code work, one night my code was finally transmitting data correctly. Man had triumphed over code, and I looked forward to resuming my work the next morning.

Color me surprised when I returned to my code the next day and it didn’t work. Frantically I scrapped my brain to find out what happened. I had faint recollections of making slight alterations to the code before I left the night before – but nothing concrete. Actually, calling my fleeting memory at that moment “faint recollections” might be too generous; they were more like ghost tormenting my mind. Did I change this bit from a zero to a one? Did I swap the order of these two lines? I couldn’t remember.

I considered looking back at my notes from the day before, but my hopes were crushed when I realized my disorganized chicken scratch was a poor excuse for note taking; I never found out what changes I made and I burned weeks before I finally got my code in working condition again.

Lessons were learned, bad habits were broken, and notebooks were bought. Now I’m probably a bit too meticulous and record more things in my research notebook than necessary, but ever since I started keeping better track of my research the quality of my work has improved.

And this is a skill this internship helped me develop.

Joshua R.

The Car Door Syndrome | Blog #2


Since my last post, I’ve delved more and more into the black magic that is modern-day technology.  I believe a lot of people have an image of the chalkboard scientist, a scientist where most of their day is spent by a chalkboard grinding away at some equation. While equational derivation is an important part of the job, an often over looked part of physics is its relationship with technology. If you want to build an experiment, you’re going to need quite a bit of knowledge in electronics in order to make it happen. If you want to analyze data, you will need some programming skills.

This comes as a consequence of every experiment having very specific needs, making it difficult (and probably not very profitable) for companies to manufacture easy-to-implement, universal solutions for experiments. Thus, physicists will often need a lot of technological know-how in order to properly construct their experiments.

Personally, I find this exciting because I get to learn about many interesting (and niche) aspects of technology that are usually hidden from users. As expected however, this lack of commercialization has its downsides. Setting up the system of electronics for the experiment can be complex and convoluted. And because the system can be so difficult to initially create, many new experiments will re-use old, outdated, and inefficient systems from previous experiments.

Enter, the Cluster On Board (COB). The COB is a new piece of hardware made by the folks at the Stanford Linear Accelerator Center and serves as a high-end, long term, flexible direct answer to the technological needs of physics experiments. It combines the fast processing speed of firmware with the high computational power of software (no, Stanford isn’t sponsoring this blog).

Most of my time this past month has been spent learning how to work with and program this board. While this piece of equipment has many cool features, I  think one of its biggest features that stuck in my mind is its cost. This technology is expensive, really expensive – like “If I broke it there goes all the money I made this summer and more” expensive.

Sometimes, I have to remove the COB from the shelf it’s on. Extracting the COB from the shelf wouldn’t be so bad, but the COB contains a pair of latches that grumble whenever you start pulling them hard enough. Every time I hear that sound, I think “Today’s the day I pull with too much strength and actually break something.” It’s somewhat similar to the illogical feeling that you might pull and break your friend’s car door handle.

I know the sharp resistance I encounter means the COB is about to successfully detach from the shelf, but sharp resistance is also generally a precursor that indicates an item’s structural integrity is about to be permanently damaged. I also know – the thing is literally designed to be removed frequently, but what if today’s the day…

Joshua R.

Ya’ don’t know it until you teach it | Blog #1


This summer, I am interning for the KOTO particle experiment at the University of Michigan. The goal of the experiment is to calculate the branching ratio for the KL -> pi0 nu nubar reaction. Scientist are interested in this particular reaction because it allows us to test a theory called the Standard Model (SM). The SM has proven to be an extremely powerful theory in describing the interaction of matter. However, there are still certain areas of the model that need to be tested. If the calculated branching ratio of the reaction deviates from the predictions given by the SM, that would be an indication of new physics occurring beyond the SM.

Naturally, all this science produces tons of data. And if you have tons of data, you also need a system to efficiently sort, process, and store it. My job is to work on the system that processes the experiment’s data by programming devices called FPGAs. As this is my second summer with the project, part of my responsibilities have now been delegated to include training newcomers in order to smooth their introduction into the world of FPGA design and the Verilog programming language.

In this new teaching angle, I had found my first surprise of the internship. In my head, probably like most new teachers, I setup the ideal scenario. “I am the knowledgable teacher. I’m going to say X, Y and Zed – and a lightbulb is going off in the other person’s head.” But things don’t necessarily work out how you planned. Because as much as you can mull over the subject material,  plan out your talking points, and make sure your metaphors are on the mark  – you can’t ever be completely prepared for questions.

Questions are the teacher’s version of the dreaded pop quizzes, able to turn even the most eloquent speakers into bumbling idiots at a moment’s notice. Much of my programming knowledge existed as abstract concepts in my head, based on intuition and powerful enough to program effective code. But you can’t really explain things on the foundation of intuition. Questions forced me to put those rough concepts and ideas in my mind under scrutiny, chop off the bits that didn’t quite withstand a second evaluation, and present what survived in an organized and concise manner.

Sometimes the inquiries would uncover gaps in my own knowledge, and our conversations would evolve (or devolve, depending on your personality) into us learning certain aspects of the material together.

In the end, teaching turned out to be valuable not just to the student – but to me also. And I’m thankful for how it strengthened my understanding of coding.

Joshua R.