ADER - Daniel Wooten

What is ADER?

ADER is a source code extension to a widely used nuclear-energy-industry code, SERPENT 2. ADER, designed and built by myself - Daniel Wooten - adds an entire suite of optimization functionalities to SERPENT 2. ADER, composed of more than 30k lines of C code, is a first-of-its-kind nuclear simulation package allowing for high fidelity simulations of next generation nuclear reactors. Due to national security concerns only a redacted version of the code is available to the public - this is the github to which the link above directs.

At a glance

~30,000 lines of C, integrated directly into the SERPENT 2 source
~15,000 lines of unit and integration tests in C and Python
Complete user manual and API documentation
Chemistry-aware linear optimization engine (CLP)
Presented at the 5th International Serpent User Group Meeting, Knoxville, TN
Primary project of my UC Berkeley doctoral thesis

Test driven development

From the beginning of the project ADER was designed to be a living code. As such, not only are the comments and documentation geared towards future development but ADER started and released as a test-driven project. Test-driven projects are those in which the code to test the product is written before the product is created. While incurring some overhead in the planning stages this approach tends to shed light on future problems long before they arise. Additionally, such an extensive test suite allows for future developers to be assured that their changes have not broken some other part of the product. This concern is particularly important for products which interact with an environment of other platforms.

Why reprocessing

The R in ADER is for Reprocessing, and it is the whole reason the project exists. Conventional depletion tools assume a fuel load: you tell the code what is in the core, and it tells you what happens to it. That assumption quietly breaks for any reactor that moves and reprocesses its fuel. Composition is no longer an input. It becomes a decision variable, coupled to the depletion state, and it has to satisfy physical and chemical constraints at every step.

ADER's core is a chemistry-aware linear optimization engine that operates on the depletion state and solves for fuel-load composition rather than accepting it. I built it because the fuel-cycle tools available for circulating, liquid-fueled systems rested on assumptions I could not defend, and I wanted depletion results I would be willing to put in front of a regulator. Any program pursuing fuel recycling alongside a reactor is working on the same problem.

Building off of legacy code

The ADER code was the primary project of my graduate thesis at UC Berkeley. ADER was developed by myself, Daniel Wooten, and it represents a first-of-its-kind modeling solution for an emerging class of nuclear reactor. ADER exists as more than 30 thousand lines of C code written as a direct integration into the very popular nuclear simulation tool, SERPENT 2 - itself composed of more than 1 million lines of C code which is why ADER was written in C.

I took ADER through every stage of development, from conception and whiteboarding to documentation and distribution. From the beginning ADER was designed with the end-user as the priority and the future developer always in mind. The error messages are plentiful and informative while the code comments are crisp and meaningful just as the code itself is clean and straightforward. ADER's creation as a test-driven development saved myself dozens of hours in terms of debugging and adaptation. The development of ADER spanned many years and of course the design requirements and objectives changed along the way with its comprehensive test suite easing that process.

Just because I built ADER does not mean I worked alone. ADER is an extension to an existing, and massive, nuclear simulation code which itself is in continual development as is the nature of leading research codes. As such the biggest challenge in creating ADER was integrating with and understanding the base code as it was not written cleanly or with future developers in mind. My favorite error message from SERPENT may have been "Error: [****] we shouldn't be here". That said, the development team for SERPENT 2 is very easy to work with.

Working at the source level

There is a meaningful difference between running a Monte Carlo transport code and modifying one. Writing input decks means learning an interface. Extending the source means learning the physics implementation, the data structures the tallies live in, the memory model, and the assumptions the original authors never wrote down. ADER required the second kind of understanding, sustained across several years and several major upstream releases.

I presented ADER to the international Serpent developer and user community at the 5th International Serpent User Group Meeting in Knoxville, Tennessee, and published on it at PHYSOR 2016 and the Molten Salt Reactor Workshop at Oak Ridge. The methodology that came out of it appeared in Annals of Nuclear Energy.

ADER is not my only software project by far, but it is my largest and one that I'm proud of - not because I 'completed' it but because I know I built it such that it would live on past my care of it.