It is almost the one-year anniversary of the first Code-a-thon I helped organize for Texas A&M nuclear engineering students. It is a good time to reflect on what we did last year. A code-a-thon is an event where a group of people gathers, usually in one location, for a defined period of time to solve a particular problem. In our code-a-thon the students were tasked with developing a Monte Carlo code for thermal x-ray transport that was parallel using C++.

After the jump we go into a lot more detail.

Portions of this post derive from a document co-authored by Todd J. Urbatsch of Los Alamos National Lab.  That document is LA-UR-13-20571.

In my view a code-a-thon is a unique enrichment exercise for nuclear engineering students who work in computation. In this context a code-a-thon is an event where software developers participate in an intensive session of collaboration to produce a working application.  A code-a-thon is some times called a hackathon, or hackfest. The vagaries of spelling these portmanteau words can be maddening; we have decided on the hyphenated spelling. Also, we prefer “code” to “hack” because to the uninitiated the word hack is redolent with nefarious behavior.

In many cases a code-a-thons are set up as a contest between teams to develop the best app for a particular platform. Other times these sessions are hosted by a particular company (Facebook and Foursquare are two notable examples) has its engineers develop new features that are often innovative and not part of standard application development roadmaps; Facebook’s “like” button was conceived at such an event. Next we present some motivation behind using a code-a-thon for computational students in nuclear engineering, beyond the obvious connection that these students do write code in some form.

The research demands of graduate students requires a certain degree of specialization. In the field of computation for nuclear engineering this can be seen in the natural divisions that develop during graduate school: Monte Carlo vs.~ deterministic transport, neutrons vs.~x-rays, C++ vs.~ Fortran, \dots In many ways these divisions are necessary in that to complete a PhD.~thesis the student needs a set of specialized knowledge on a very narrow problem scope. Nevertheless, a scientist with a broad knowledge of the field will produce a more productive researcher. The old platitude about hallucinations of nails when all one has is a hammer is particularly relevant here. The question of balancing the needs of a student’s research, and the goal to graduate in a timely manner, with the necessity to instill a love of learning and removing any fear of the “other” aspects of computational science for nuclear engineering.

At the same time there has been a recent interest in enrichment activities outside of the classroom, often called high-impact learning or active learning (see for instance here or here-paywalled). These practices include undergraduate research, internships, learning communities: basically learning techniques that are outside the traditional lecture-based modality for education. In many respects these kinds of activities could be ideal for expanding the knowledge base of computational students. Rather than taking a class in Monte Carlo methods, a deterministic transport student could be a part of an enrichment exercise that has an aspect of Monte Carlo to it.

The work of a graduate student in computational science also takes place in greater isolation than in many other disciplines. Although, some students work on a part of a code team, often this work only focuses on a circumscribed aspect of the code. Furthermore, there are few inter-generational connections between graduate students, especially between advisors/research groups. In many cases, one cohort of graduate students knows each other due to being in classes together, but have not interacted with the younger/older students. Graduate students interacting with undergraduate students is beyond the pale.

Given this situation, a code-a-thon seemed like an ideal high-impact enrichment activity for the students in nuclear engineering at Texas A&M. It would be an opportunity to expand the technical knowledge of the students and forge connections between students who had never met before. The code-a-thon was held on January 10, 2013, with a planned duration of 24 hours. The end result of the project was a Monte Carlo code for the transport of thermal x-rays, based on the Fleck and Cummings implicit Monte Carlo (IMC) method (article-paywalled). The code is designed to work in parallel using a domain replicated model.

Pre-Event Planning

The bulk of the planning for the code-a-thon took place less than one month prior. McClarren pitched the idea to a few students in early December. The reception to the idea was overwhelmingly positive, and McClarren then invited approximately 25 students to participate in the event on January 10. There was then a planning meeting on Dec 7. At that meeting it was decided that the goal of the code-a-thon would be to write a Monte Carlo code for thermal x-ray transport, using MPI and C++. This was chosen by the students because 1) most of the students at A\&M work on discrete ordinates, deterministic transport (or other deterministic methods), 2) some students had only a passing familiarity with C++ and wanted hands-on experience. At this point, about 15 students said they would participate*.

*One of these students was an undergraduate. Holding the meeting over a semester break depressed undergraduate participation.

At this meeting it was also determined that given the varied skills of the team, pair programming, where two people code together: one with the keyboard and one watching and reviewing the code in real time. This approach allows one of the pair to not be an expert in the syntax and tactics of coding in the particular language, but allows that person to contribute to the overall structure and flow of the code. The goal for pair programming is for the pair to be greater than the sum of the parts (see this article for more on pair programming).

After this meeting, I then went out to invite Todd Urbatsch to be the technical expert for the code-a-thon. His experience in developing Monte Carlo codes for x-ray transport would be particularly helpful for the compressed time line of the exercise. During the event his role would not be to write code, but rather to give advice about code architecture and details. In particular he could help the team avoid the small traps that are easy to fall into when working on a code such as this.

About one week later, December 13, the team assembled in another planning meeting. At this meeting the students began planning the interfaces between elements. That is, laying out the data requirements and what are the dependencies between different parts of the code. In this meeting it was decided that templates would be preferred over inheritance in the code design. There were also some lively discussions between the students at this point as to the degree of generality that would be present in the code. Some students had the idea that the code should be designed to eventually have the functionality to integrate particle tracks against finite element basis functions. The opposite camp felt that degree of generality would be too onerous for a 24 hour project. These discussions largely led to a consensus amongst the students, without any intervention.

The last stage of preparation for the code-a-thon involved setting up a code repository and populating some initial classes with source code. Several of the basic tools needed for the code-a-thon were implemented: basic opacities (cross-sections), physical constants, and stubs representing the mesh class. A final meeting for the code-a-thon was held two days before the event that dealt primarily with practical matters, food being the primary focus of the discussion.

An important outcome of the preliminary meeting, in the eyes of the students, was the name of the code project. The team decided that the name of the code would be FINMCOOL for Fully Implicit Monte Carlo Object Oriented Library.

Timeline of the Event

The event took place in a large meeting room on the Texas A&M campus. Before the kickoff of the coding, we rearranged the room to promote collaboration between teams that would need to communicate. The plan was to divide the day into iterations where at the end of each iteration we would have working code with capability increasing with each iteration. The teams were set based on perceived skills and interest of the students. There were teams tasked with developing the classes for the mesh, materials, random number generator, particle/census, and input.

The goal was to spend the first iteration (10am to noon), to get a code that solved a single-cell, 3-D Cartesian, one-group problem with no material coupling. At noon many of the pieces were developed in isolation. There was an unexpected slowdown in development of the mesh class. In particular that team had no C++ expert. After fixing this problem, several teams moved onto tasks for later iterations. After lunch, we had a status meeting to decide how to flex team members onto new parts of the project. A small effort was put in place to document the code using doxygen, the random number generator added some planned improvements to allow for caching of a bank of random numbers, and the functionality to read in tabular data.

Before dinner break, the code was finally in a state when we could call iteration 1 complete. During dinner another status meeting was held to set the priorities for the next iteration. One team was formed to stand up the parallel capability in the code, another took on the task of integrating the input reading capability into the main branch of the code, and another was set up to put the finishing touches on the material interaction/particle sourcing algorithms. Boundary conditions were assigned to another team. The goal for this iteration was to complete a parallel, multi-cell calculation using one-group physics and reflecting boundaries.

This iteration was completed in about 4 hours, close to 11pm.

In the morning hours of Friday, January 11, 2013, the code was running multi-cell problems. We defined simple integral test problems that exposed some subtle \Cpp\ class interface bugs by heating non-uniformly heating cells that should have been uniformly heated. Furious debugging ensued until 6:30am, when we reached a tipping point, figuratively and literally, and the code-a-thon was declared over.