Here are the slides I presented at the Aachen Institute for Advanced Study in Computational Engineering Science of RWTH University Aachen.
Slides for EU Regional School
Leave a reply
Category Archives: Teaching Nuclear Engineering
Using tkz-graph to draw nuclear reaction networks
The other day I was interested in drawing a fairly simple nuclear reaction network in$$\LaTeX$$. I thought that tikz would be a good way of doing this. Basically, tikz is a way to generate vector graphics directly inside the $$\LaTeX$$ source code. I figured that somebody would have an example online of how to draw a simple directed graph with annotations on the connections.
There does exist a fairly new package called tkz-graph that is specifically designed for drawing such a graph. Unfortunately, there are some limitations that affected my final image. One thing I wanted to do was color the nodes of the network with different colors to demonstrate different linear chains in the network, but that seems to be difficult with the current version as coloring nodes differently is not currently supported without defining a node type for each style.
The end result was pretty nice
Transmutation and decay network for uranium-238
This network could be much more involved insofar as there could be higher nuclides plutonium, but the point here is to illustrate how these networks can be draw in $$\LaTeX$$.
The code for this figure is given below, after the jump. Continue reading
Introduction to Python 3 for nuclear engineers
In this lecture, we’ll discuss why python is good language to learn for scientific computing. We’ll also cover the use of strings in Python 3 as well as the topics of branching (if statements) as well as simple iteration with while loops.
Here’s a link to the lecture. For the iPython notebook source, click here.
I just don’t know man (Epistemic Uncertainty)
Yes, epistemic uncertainty (that is, uncertainty due to a lack of knowledge) is likely the biggest thorn in the side of a modeler/computational physicist/ computational engineer (I would make a bolder statement, but, at the risk of being redundant, I just don’t know man). One way of dealing with this is the concept of Probability Boxes. The basic idea is to treat aleatory uncertainties as distributional and epistemic as to be an interval. On the one hand, this is conservative because we have no assumptions about the underlying distribution, but the
Continue reading
Prediction and Calibration
In this post we’ll look at some actual experimental data (crazy, I know) and use simulation data from the code Hyades2D to try and produce calibrated results. The data is the very same used in Stripling, McClarren, et al., and we show how Gaussian process models can be used to make sense of simulation and experimental data.
Markov-Chain Monte Carlo
If you’re in the business of sampling from a distribution that you only know up to a constant normalization, Markov-Chain Monte Carlo (and the Metropolis Algorithm) are for you. The Metropolis algorithm is name after a scientist, and not the adopted hometown of an illegal alien, but it can leap unruly distributions in a (burn-in + n) bound. In particular, Bayes’ Theorem gives us an unnormalized distribution we would like to sample from.
The 2014 Nuclear Engineering Code-a-thon: The Details
The 2014 code-a-thon was a 24 hour exercise where a group of students worked to put together a fully functional Eulerian hydrodynamics code. In particular we were interested in a code that could handle multiple materials. The motivation for the nuclear engineering students is that many of them had experience with Lagrangian hydrodynamics methods in a graduate course on radiation-hydrodynamics, and exposure to Eulerian hydrodynamics was missing from their experience. Also, last year the students had so much fun at the code-a-thon they wanted to do it again. This year our chief code architect was Andrew Till and his vision was the binding force in the organization of the pre-event coordination.
In 2013 we tried to do a straight 24 hour exercise. That experience taught us that this year it should be two 12 hour days. At one point this year, someone asked why not just one 24 block and the unanimous answer was “You must not have been here last year.” The actual reason is that at about 3am in the morning debugging code is more stressful and less effective than we could have imagined.
Like 2013, we are using C++ as the programming language for the code. Most students had experience with C++, though some learned on-the-fly. This year we used the object-oriented paradigm, as opposed to last year where we (overly) used templates. Also this year, test-driven development was a point of emphasis. Our technical expert from Los Alamos National Laboratory, Gabriel Rockefeller introduced this concept to the students, and several were quite enamored with the idea.
Another feature that people assigned themselves to teams before the event. These teams discussed ahead of time the structure of the their code, including designing any classes or functions they would need. Most groups used the class-generator produced by one of the participants, Jonathan Madsen.
The code, named meh (multi-material Eulerian hydrodynamics), was designed to be a 3-D code that could handle an arbitrary number of materials. The code as of now only handles materials that have a gamma-law equation of state. We also base the mixed-material equation of state on pressure-temperature equilibrium in a cell.
In terms of the physics/numerics in the code, we used HLL and HLLC for the Riemann solvers (a good reference, and one we used, is the book by Toro-Riemann Solvers and Numerical Methods for Fluid Dynamics: A Practical Introduction
For development we used subversion for version control (partially because our department already has an svn server set up), Cmake for our build system (thanks again to Jonathan Madsen). The code was also designed to break work into blocks that could be sized to the available cache on a given machine.
For all the best laid plans, we did not get a complete code that solved the Euler equations. However, all was not lost: the code worked in that each piece of the code, boundary conditions, Runge-Kutta time integrator, Riemann solver, EOS, etc. could all talk to each other and run a time step. Each piece was not tested fully in the integrated code, but each could at least talk to each other. Over the next semester, we plan on bringing it all together and I will report on the findings here.
The participants were, in no particular order,
Don Bruss, Andrew Till, Alex Long, Jonathan Madsen, Bruno Turcksin, Damien Lebrun-Grandie, Akansha Kumar, Vischal Patel, Daniel Holladay, Taylor Lane, Michael Hackemack, Marco Delchini, Peter Maginot, Ryan McClarren, and Gabriel Rockefeller.
The 2014 Code-a-thon in pictures
We’re still recovering from the 24 hours of coding that was the 2014 Nuclear engineering code-a-thon. More on what happened and what we did later. For now I wanted to share with everyone the pictures I took of the event. In the panoramic shots you might notice that some people don’t change position much, even when there is food.
First coffee at the code-a-thon
Code-a-thon First Hour
Day 2 – Pizza Time
Day 2 Mid-afternoon malaise
Day 2: Two Hours to go
Code-a-thon Day 1 Kickoff
Here’s what it looked like. More info to come.
High-Impact Learning For Computational Science Education Through A Code-A-Thon
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.