Embedded - 331: Friendly Tea Kettle

Episode Date: May 21, 2020

Dr. Katy Huff (@katyhuff) spoke with us about nuclear engineering, effective software development, and the apropos command. Katy wrote an O’Reilly book describing Python software development to scientists: Effective Computation in Physics: Field Guide to Research with Python. She has been involved with Software Carpentry. Katy is a professor at University of Illinois, Urbana-Champaign, Department of Nuclear, Plasma, and Radiological Engineering. She uses Bell and Glasstone’s Nuclear Reactor Theory in her Nuclear Reactor Theory class.  Katy’s personal site Stellerator Godiva Device Janelle Shane creates the AI Weirdness blog. (She was also a guest in #275: Don’t Do What the Computer Tells You.)

Welcome to Embedded. I am Elysia White. I'm here with Christopher White. We are joined by Katie Huff, Professor of Nuclear, Plasma, and Radiological Engineering. Cool. Hi, Katie. Thanks for having me. Could you tell us about yourself as if we met at lunch at the Python conference? Sure. Hi, I'm Katie Huff. I'm a nuclear engineering professor at Illinois, and I do a bunch of stuff related to software, software education, scientific computing, the Journal of Open Source Software, and all kinds of other things that have given me opportunities to advocate for best practices in open, reproducible scientific computing. Yes, exactly. That's what we want to talk about. But before we get to it, we want to do lightning round where we ask you short questions and we want short answers. And if we're behaving ourselves, we won't say, are you sure and why? But who knows? Are you ready? Absolutely.

What's your favorite flavor of cork? Oh, up corks. Favorite physical constant? The Boltzmann constant. Always a good one. When somebody finds out what you do, what question do they always ask you? Some people, I would say, ask about the waist. But the most interesting people ask about thorium because they probably

read a vice magazine article once. Must not ask about thorium. Okay. Wait, I had my next question. Least favorite physical constant. I'm going to go with, yeah. Let's say it's a unit, not a constant, but the barn, which is an inconvenient multiple of the centimeter that we have to use for its convenience in my world, but it's inconvenient. Otherwise. All right.

Favorite fictional robot. Oh, there's there are these sentient ships in the Imperial rash novels. The Ann Leckie novels. And they're one of the sentient ships is probably my favorite robot, the Mercy of Collar. That's the Ancillary Justice series? That's it. That's the one. All right. And do you have a tip everyone should know?

In the command line, my favorite command is apropos. And what it does is you type apropos and then the thing you're looking for. So like, let's say you don't know what your PDF viewer is on the command line, or you want something that's going to help you with, you know, remote operation of another terminal, then it searches the man pages of all the other commands within bash. So if you type apropos PDF, it'll give you a list of all the commands that mentioned PDF in the man page of those commands. So it's like the index of all the commands on your machine.

Cool. I'd forgotten about that. I'd forgotten about that too. That really is useful. Probably 25 years ago. Okay, so nuclear engineering. It sounds like a scary big thing. Is it?

It is a big thing. 20% of our electricity here in the United States comes from nuclear reactors. So in that sense, it's very big. Reactors themselves are fairly big. Is it scary? I think for many people, it's scary. For myself, you know, it's mostly a very fancy, well-controlled way of boiling water. And so it's not as scary, perhaps, as many folks have reason to believe and feel. It's just a friendly tea kettle.

Yeah, that's right. It's a friendly tea kettle. Exactly. You taught nuclear reactor theory this last semester, if I read that right. One of the books was from 1970. Is it that this theory doesn't change or that's just a really good book? Both. It is a very good book, the canonical book in this field, Bell and Glassstone, I think is the one you're thinking of. And it is so good that it was sold out and our American Nuclear Society had to start reprinting it in paperback just to satisfy the needs of undergraduate and graduate students. It's a really good book, well-written, extremely clear by two giants in this field. It is also representative of the math behind what we understand to be the reactions

inside a reactor. And that math itself, the real sort of formal theory of what happens inside a reactor has not changed since 1970, because in part, you know, the reactors haven't changed dramatically because of the kind of emphasis on safety and regulation and nuclear engineering. You know, the reactors themselves, the technology, most of the ones that are actually deployed are quite a bit the same as they were for Bell and Glastone. And so the equations, which actually represent more than just those reactors, but certainly emphasize application to those light water reactors, they have not changed. The computational advancements in this area have been truly profound, but the fundamental equations that we have to model computationally have not fundamentally changed. How much of a class like that is learning the equations and how much is learning the safety structure that goes around nuclear reactors?

Gosh, what a phenomenal question. The class itself is focused on the neutron transport equation, as well as some kinetics and dynamics. So let's back up and see what that means. So the class focuses on figuring out the neutron transport equation, which involves how many neutrons are in a reactor? Where are they? Where are they going? What energy do they have? At what angles are they moving? At what velocities, etc. And that is a seven dimensional equation at its most fundamental. And so it takes a while to discuss and understand it. But discussing and understanding that equation allows us to understand the dynamics and kinetics in the reactor. So the way that

accidents proceed or the way that fuel changes over long periods. And understanding those two things and having an intuition for the neutron transport itself gives you all of the context that you need to do safety analysis in reactors and to design new reactors to invent, you know, future technology that might be more passively safe or more efficient or recycle nuclear fuel. So all of those things come into the equation if you teach it right, which I've been trying to do. We shall see. I'm a young professor, so I have only taught this course once, but I will teach it again and again for many, many years. I'm going to ask you a question that I've always wondered since I've got you here. Is there any difference? You said that the fundamentals have not changed since not long after

the reactors were invented, but is there any difference between the kinds of reactors that are in nuclear power plants and the kinds that are in ships and submarines? Because there's tons of them in the Navy for power, a lot of ships and subs and things, but those have to be really compact, right? Yes, absolutely. They are somewhat different. They have the same type of coolant. And I believe generally, a lot of this is classified, but my understanding is the same type of fuel. But the fuel has higher enrichment. All right, what is enrichment? The number of uranium atoms can be divided between the types of atoms that have 235 neutrons and protons versus the types of atoms that have 238 neutrons and protons. Both are uranium, but the 238 has three extra neutrons. 235 is the most helpful in this

atomic fission reaction. And the more 235 in that mixture of uranium isotopes, the more compact you can make your reactor. And so in commercial light water reactors that are deployed throughout the U.S., about 100 of them, there's about 3 to 5% of those uranium atoms are the U-235 type. In a Navy reactor, it's in the 90s. The actual number is not within my scope of allowed knowledge. So that 90% is very important, and it gives you a real compactness, as well as the ability to ramp the power up and down pretty quickly, which is important if you're propelling a submarine with it. Thank you. That was one of my questions is how in vehicular nuclear reactors, you don't have the constant draw, but for power reactors, you have the big and constant draw that probably doesn't do well with going up and down. That's right. There are few constraints in our, particularly United States

reactors that are used for commercial nuclear power. And one is the stresses and strains on the large device itself, the metals and fuel and everything else inside the reactor, as well as the pumps and their ramp rates and the turbine and its ramp rate. All of that has sort of ordinary uninteresting mechanical constraints that mean that it makes it a little bit harder to move the power up and down dramatically when you're dealing with such a large amount of power. So in a normal nuclear reactor, it's about a gigawatt worth of electricity, which is about three gigawatts worth of heat, which drive a situation that if you watch the Chernobyl miniseries, these changes in power can put you in a place of not being able to turn the reactor back on. In their case, they responded to this by continuing to pull out the control rods

until it was in a deeply unsafe state. But we would never do that in the United States. Because the consequences of such decisions are so huge, how do we convince people it's safe? I mean, you must have to answer this question a lot. How do we convince people it's safe? How do we convince people that the spent uranium can be stored or disposed of or sent to the moon properly? Not sent to the moon. That seems like a really bad idea. Fired into the moon. That seems like a really bad idea. Fire into the sun. I do want to bring up that, in fact, the Department of Energy and other nuclear institutions worldwide have considered shooting it into the sun.

Of course. But the first part, where you light a giant rocket next to it. Well, what is a rocket? Yeah. So, I think the way to think about this is actually kind of tied to that question around the moon and the sun and whatnot. The appetite for failure in the nuclear community is practically zero. We look at numbers like 10 to the negative fourth in terms of, you know, the likelihood that an incident will happen. And we say, well, 10 to the negative fourth, that's way too high. You know, we really want everything to be 100% perfectly, perfectly safe. And so we have a strong nuclear regulator in the United States. And what has resulted from that,

in fact, is that, you know, while there have been three major nuclear incidents in the world, Three Mile Island, Chernobyl, and Fukushima, the real impact, the public health impact, as well as sort of the actual danger of a nuclear reactor is incredibly low compared to any other energy source. So other than geothermal energy, nuclear power has the lowest deaths per terawatt hour, even if you include all the, you know, people who died at Chernobyl and people who maybe got latent cancers because of Fukushima or Chernobyl. No one died at Thurman Island and no one got any latent cancers. of Fukushima or Chernobyl. No one died through Mile Island, and no one got any latent cancers. So that's not very interesting. But because we keep those deaths extremely low, our deaths per terawatt hour are lower than any other energy source, including

solar, right? People fall off their roofs, putting in solar like at an alarming rate to anyone in nuclear power. You know, people die installing wind turbines and plenty of people get cancers from fossil fuel emissions, as well as, you know, explosions on oil rigs like the deep water horizon right and if you do the math then look at how many deaths per amount of energy that you produce nuclear winds is that just a psychological thing where like the number of deaths from coal is huge right massive but it's slow you don't see them whereas anything that happens with nuclear is by definition, a disaster focused in a location. And is that just the way we process negative events? Yeah.

What a, what a great question. So there's actually some interesting scholarship around this, and I would direct you to some of the work by folks like Dominique Broussard at Wisconsin and many others who have studied the way that our understanding of a technology, as well as our, like, not just our understanding, but our familiarity with it, whether we understand how a car works or not, we're very familiar with it. And we're comfortable getting in our car every day,

even though it's like one of the most dangerous things that we do. And maybe we would be less comfortable living near a nuclear power plant. But in fact, the radiation is like negligible. You can't detect it of a background, that sort of thing. We have a relationship with dread and things that we don't understand and sort of feeling that the consequences of something might be dreadful, that we don't get on planes, even though, you know, they're actually very safe. Like the FAA regulates planes. Now, nuclear power is regulated much more strictly than the FAA regulates planes. But yeah, it's about dread.

It's about our feelings. It's about our feelings. It's about our psychology. And I think a lot of people see the interpretation of the media and think, oh, well, you know, how many people died at the Fukushima nuclear reactor incident? Well, zero people died from radiation exposure. Zero people got radiation sickness. Um, there's one person who has been awarded some compensation. He was a worker at that plant and later got lung cancer.

Now, the Japanese government assumed that that lung cancer could have been from Fukushima exposure. So they awarded his family a great deal, payment, which I think is appropriate. But the reality is the most likely cause was that he was a smoker. Yeah, it's weird because I grew up a few miles from San Onofre Nuclear Power Station. And it was always really scary as a kid because they made a big deal out of it. There were sirens in all of our towns that they would test every year. And sometimes we'd remember they were supposed to go off and sometimes we wouldn't test. And so, you know, you'd be in school and these air raid sirens would go off, which weren't air raid sirens. They were San Onofre evacuation sirens. And so there was this whole

thing that this is this dangerous thing in your backyard. And it could do something horrible at any moment. And I don't think there was any education back then of like look this is really really safe um there's a lot more big risks every day it was always hey that thing you pass going down i-5 that that looks kind of funny that's really scary yeah so it i think yeah it's weird how we, the communication I think is difficult. Yeah, the SONGS plant, that San Onofre plant did have sort of, you know, there's 100 plants in the US and there are a couple that, you know, have had problems in general. And I think, you know, one of the biggest issues around SONGS was around, you know, the anti-nuclear protests around SONGS started in the 70s, right? But, you know, it wasn't really until somewhat later that, you know, evaluation of their earthquake safety came into question after Fukushima. But the NRC eventually, you know, re-estimated that the likelihood of an earthquake intense

enough to cause any kind of core damage was one in 60,000 or something. And that kind of statistic isn't particularly interesting to the people who live nearby who want it to be one and zero. And I think that's valid. Or like, I guess zero in 60,000. That's what I mean. Right. Yeah. But they also had some, they had a radioactive leak inside the containment shell, which is extremely unusual. And I think it was appropriate to shut down that plant. Okay. Nuclear aside. Yeah.

You mentioned in your introduction that you want to make science easier to document. Yeah. More reproducible, more open, more transparent. You know, I really think that science isn't science unless it's in the open and you can prove to yourself that it was true. in reproducibility crises across many fields and in a field like nuclear engineering where safety and uncertainty have such an important role. You know, scientific computing has to be even more open and reproducible and clear and true and trustable and tested and all of this. And so a lot of my work, starting as a graduate student, but well into my current time, includes work just to educate people in the sciences on how to use computers more effectively, as well as working with the Journal of Open Source Software to publish

computational work more openly. And a lot of that comes from this general philosophy that I have around that. I remember when Chris was thinking about getting a PhD in physics, all of the physicists we knew with PhDs were software engineers now after their degree. And since he was already a software engineer, I asked him why. Not quite how it went. Not quite. There were some steps in there.

But there isn't a big, there's no introduction to software in a physics curriculum. And I know that designing software can be non-trivial. How do you convince people who are really smart and know a lot about things like nuclear engineering to sit down and understand understand the syntax of a language. Yeah. So I think the motivation is the easiest part. You know, physicists are going to physics. They deeply want to get answers and ask questions and come to more questions. And those more questions, that's our career surety right there is, you know, the successful production of science reduced, like increases the need for more science. And in order to do that these days,

it's much easier to get interesting answers in physics, astronomy, geology, biophysics, nuclear engineering, mechanical engineering, all this stuff, if you program. And it is much, much easier to avoid retracted papers, public embarrassment, or just failure, right? Something wrong is a failure in science. And like, I mean, you want to say things that are true and only things that are true. And you can never say something wrong that is untrue, you know, in science. You can't come to some conclusion and state it as if it were true. This is the complete opposite of the idea behind science. So to do that, you have to tell people, well, you can't just throw together a script. You have to test it, just like you would calibrate an experiment.

You have to write unit tests and you need version control, but just like you would have a lab notebook. And so folks who want to be more efficient at their science learn that they want to program. And folks who want to do science right realize eventually, if you kind of give them the knowledge, that when you're trying to learn concepts and computational physics, you need all of these reproducible tools as well. And you wrote a book for O'Reilly. Yeah. Effective Computation in Physics, Field Guide to Research with Python. And I admit, I put off reading it just because my brain's been mush.

And I did, finally. I put off reading it because I really expected it to be about science. And I expected to have to really dig in and remember all those things that I just have to relearn each time. And it turned out not that that wasn't it at all. Could you describe the book? Absolutely. So the book, you know, any modern physicist, no matter how experimental, needs to rely on a computer for some part of their computing workflow.

And because, as we just discussed, some of them are doing it wrong or not being careful or not doing it efficiently, this book intended to sort of give those people the tools to harness that and automate those aspects of research that they don't need to be doing by hand and guiding research that could be simulated better or more clearly. And there was this great need in sort of the physical sciences more broadly to see that just written out as simply as humanly possible. And it includes stuff around sort of just an introduction to the terminal, like how not to be afraid of the terminal, how to use Python sort of in a fundamental way, as well as how to analyze and visualize your work and how to store data and deploy software and do work in parallel and version control your code and do some debugging and testing and documentation and whatnot.

And all of that, I think, you know, is the purpose of this book. And it's because its audience is physicists and physics-related fields. We have this emphasis in the title that is a little bit false. We're false. We're not really teaching physics in it, you know. It's just the computational tools at the level that a physicist is ready to hear them. And that was it. It was a lot of Python. It was a lot of Python. It was a lot of here's how you use a terminal,

why you would want version control with some pretty amusing examples of lost work. How did you learn this? Oh, I really, it took a long time as an undergraduate student in, at the university of Chicago. I was a physics major and I did some research with a telescope for the cosmic microwave background. And we had to simulate the future plans for our validation experiments in the field. And that was my senior thesis. And in order to do this, I had to learn Python.

So I learned Python and I thought this is really fun. I love this. I had some basis for it from earlier internships, like at Los Alamos where I learned Perl. That was actually my first programming language. I don't know. That's a tough one to be the first. Yeah.

I learned a lot of regular expressions. Let me put it that way. But yeah, so that activity made it clear to me like how much more I could get done than my peers if I were programming and learning stuff. And I'm very, I really like problem solving and computing is a series of problems that as soon as you solve them, you get a new problem. You know, you get past that one bug and like, yes, we have a new bug, right? That's how you know you're writing code. And so I loved that. I thought it was great. And I was very self-taught. And then in graduate school in nuclear engineering with my phenomenal PhD advisor, Paul Wilson.

He introduced me to a lot of things around version control and testing and whatnot. And we really, as a group, my graduate student colleagues and I, you know, really took it pretty far and learned a lot and got involved with Greg Wilson in Canada with software carpentry and a whole bunch of other things. And what it really turned out to be was that I just, I really felt like I should dig into this. And it was very self-taught, I guess. Your book reads like a software development manual, as if it could be used to teach that class. Are you planning to use it to teach a class in software development or in physics? Ah, what a great question. So this book reflects a lot of the content that Anthony Skobatz and myself and many other people developed for the Software Carpentry Foundation, for which we were early leaders. And that activity does teach scientists in every field, actually, across the world. This is a cool big foundation that teaches scientists to learn

software. And we, Anthony and I, targeted a few more, much more advanced concepts than what we typically were teaching in these software carpentry workshops. And we added those to the book and created a book around that. But software carpentry itself does have workshops and we help to develop those courses. And they are taught all over the world, all the time to scientists by scientists in these sort of two-day or even week-long boot camp kind of computational workshops. A lot of the same content is covered in Software Carpentry, but you can't get very deep in two days. You can really only cover Python, Git, and maybe some

databases. Beyond that, the book has to take over. And so that's why Anthony and I put the book together is that, you know, we needed to go further to really talk to people in the physical sciences about how to be doing computational simulation related work. So software carpentry, could you, what is that? Yeah, so software carpentry is a non-profit organization that is effectively a very large community of scientists who care about using computers appropriately within science. And that mostly comes to mean having the skills to be efficient and having the skills to be reproducible, where those skills are just the base set of, you know,

get some, well, any version control, really, we have multiple different kinds of version control lessons now, Python or R, and some data handling that's appropriate. And having that formulated into a workshop and training scientists to be workshop instructors, the Software Carpentry Foundation sort of creates a framework for scientists to share those skills. Because as you noted, scientists don't start out, whether it's in physics or engineering or applied math, you know, there needs to be a little bit of software engineering, but not exactly software engineering, just building stuff with software, i.e. software carpentry. That makes a lot of sense. At our school, everybody had to take the intro to CS class, but not everybody had to take the software development class. So, cool.

What part of your book do you think people have the hardest time internalizing? So, there's a chapter on regular expressions that I think a lot of people don't see the value of until they read it because they have to. So until they find, until they have some problem where they suddenly need regular expressions desperately, a lot of people find that chapter, I think pretty dense, you know, covers set grep and set and awk, but then also points out that you can do all of the same things in Python. And I think those tools are so fundamental to my functionality in a programming environment that it seemed important. But I think for a lot of folks, they don't have to do data munging at a high level until they've already got a lot of the other skills that are in the book. So dealing with and cleaning up data is really important, but not until you've maybe covered a

lot of other things. But it's either the first thing you do because you're the intern or the getting ready to work on something. And so you're the one who has to do all the data munging and they pay you so little, you could do it by hand. They don't really care. Or you don't do it until it's after you've gotten it ready. And now you're getting data from a new telescope with a different format or something like that. Exactly. Exactly. That's probably the one people have the most trouble with, but I don't know. That's probably it. The book doesn't cover Jupiter notebooks. Why not? around then. They didn't represent to Anthony and I the kind of work that needed to go into a real distributable package in a testable scientific environment. And we

see a lot of value in Jupyter notebooks for prototyping, communicating, even documentation. But Jupyter notebooks themselves can be problematic if you would like to then distribute them and build on them and extend them in an open source Python package for science kind of a way. The rigor can be lost occasionally in a Jupyter Notebook. Now, all of that said, we actually have distributed Jupyter Notebooks of all of the code in the book at a GitHub repository for the book. So while we don't cover how to use Jupyter Notebooks, I think we maybe mentioned it very briefly, but we don't cover it in the, in the book,

as you noted, we do use Jupiter notebooks to allow people to play with the code that's in the book. So yeah, we see a lot of value in it, but you know, I don't know that we, so I think we,

at the time really didn't want to encourage folks to spend all of their software engineering time for their scientific software in Jupyter Notebooks. Okay. And that makes sense. I mean, I like Jupyter Notebooks, especially if I'm going to talk to somebody about this, if I'm building a case for something or writing a report. But even then, many times it's importing a library that I wrote elsewhere just to show it off. It's a nice front end. It's good to develop stuff in, too, as you work through it,

because then you can document at the same time. But you wouldn't deploy a Jupyter notebook. People do, but yeah, I wouldn't. It would be harder. Yeah. The hacker within. I kept seeing this as I was researching. What is that?

So this actually answers your question about how I learned most of this stuff. The true answer is that when I started as a graduate student in the research group of Paul Philip Hood Wilson at the University of Wisconsin. He encouraged us to, you know, break things and try to program and embrace some part of ourselves that was interested and willing to tinker, even if it felt a little dangerous. And that he described as the hacker within ourselves. And so my graduate mentor encouraged myself and many of my graduate colleagues, Milad Fatnishad, Anthony Skopats, and many others to find the hacker within ourselves. And in order to do that, we created a little student org at the University of Wisconsin where we would meet and eat lunch or pizza or brownies or beer or whatever

we felt like at the time. And we would talk about the newest, coolest thing that we had learned while trying to do our computational research. And it morphed into something that really captured a lot of best practices in reproducible scientific computing. And it was a really intense kind of fun group of people who were interested sometimes in, you know, writing little snippets of goofy code together that did strange things or having, you know, collaborative workshops and setting up lectures by people we thought were really amazing in the scientific

Python community. And that student org kind of proliferated to other institutions. It was at Illinois by the time I got here as a faculty member. And, you know, I brought it to Berkeley. Some other folks brought it to Australia. Actually, there's a whole bunch of places where there's a Hacker Within contingent. The idea is like graduate students don't have a place to learn some of these like little skills like apropos right in the command line. Who's going to tell you about that? It should be some community of other people doing scientific computing. And that's what the hacker within intended to be. It's a little weird, scientific, reproducible scientific sounds, you know, very on one side, on the same side as nuclear engineering and hacking seems and breaking things seems a different thing. Like, don't cross these streams. Yeah, I mean, I generally think of hacking as, you know, using someone's really unique technical

knowledge to creatively overcome some problem, right? And I recognize and many others recognize that, you know, hacking can really evoke a lot of other things, even bad actors. But, you know, maybe think of this as the white hat hackers of science, right? Unless you're ready to try to break your code, you're really not ready to say that it's working. Because the whole activity of unit testing and continuous integration that you need in order to really feel sure that your code isn't rife with bugs, you need, in order to do that, you have to be testing your code. And in order to test, in order to write tests, you have to have this kind of creative hacker within yourself that attempts to break that code.

That's an interesting point of view, that if you aren't ready to try to break it, it's not really done. That's why software development organizations have separate testers, right? Because developers are often so bad at testing their own code because there's that little, I don't want to break it, instinct, right? And the, I know how it works, so I'm going to follow the garden path because that's what's there. And I know what it's supposed to do. So I'm not even going to try to do anything that might be a little out of scope. That's exactly right. And it's sort of like, you know, putting on the white hat and deciding like, how am I going to find the bugs in my code? You have to pretend that you're

trying to break it. So what research are you doing now? Oh man. So I have a bunch of graduate students. They're so phenomenal and they're doing work modeling and simulating some really interesting multiple physics coupling inside fancy molten salt reactors and gas cooled reactors and mini micro reactors. I also have some graduate students applying machine learning and AI to problems that we've historically used people for in nuclear engineering. Wait, I want to hear more about that. Oh, yeah. So here's an example. So there's a job title, spectroscopist. And that individual looks with their eyes at spectra, which is the energy histogram

of what photons are coming out of a particular sample of material. And that histogram, that spectra, is going to give you a notion of what isotopes are in there, because isotopes emit gamma particles, photons, at specific energies. And you can identify what isotopes are there by what energies you see in that histogram. So, the sort of state of the art for a very long time, all the way up till now, is to train a person to look at that spectrum and identify which isotopes are probably in it. Now, there are plenty of computational methods to pull out signals and there's, you know, region of interest methods and library methods and all kinds of sort of uninteresting methods.

But it seemed like the kind of thing that's kin enough to image processing and image recognition that we should try machine learning on it. And to great success, my very first graduated PhD student, Mark Komuda, successfully trained some neural networks that perform as well or better than existing computational methods for this purpose. And you can use this kind of thing to identify an unknown radioactive source in a shipping container or something like that, even if your signal is pretty lousy. And so it's pretty cool stuff, you know, and it, you know, it's just one example. We also are trying out machine learning and AI for designing nuclear reactors, generating flow channels and stuff, you know, thinking pretty blue sky. So there's a lot of cool applications. Are you familiar with janelle shane

i'm not i'll send you a link that it's it's uh uh ai sort of gone wrong but in a humorous way that i suspect you will enjoy she's she uh She came up with, she taught at NeuralNet all the paint colors, you know, this color, this name, and then she had it generate new names for new paint colors. And I think...

And ice cream flavors. And ice cream flavors, and like poopy brown and stuff like that, just really... I look forward to our future nuclear reactors. Yeah, so far, I have to say that that tracks pretty well. Unless you really constrain the kinds of things that you trust the machine to do, it's going to come up with some really wacky stuff, especially this generative kind of machine learning, I think is, can be a little bit unpredictable. Yes, yes. That's funny. I love that. Okay, so you talked a little bit about

molten salt reactors, which just sounds super cool. Not a tea kettle. That's the point. It cools it with molten salt. I don't think you cool things with molten. Yeah, you do. Really? Yeah, I'm right, right? You are right. You are right. It's really, really hot, though. So it doesn't feel very cool. Yeah, exactly. So in a molten salt reactor, there's two kinds. One is a liquid fueled molten salt reactor and one is a solid fueled molten salt reactor. Let's focus on the liquid fueled. This is where you dissolve those uranium atoms into a salt. And then the fission can be, you know, can create enough heat to melt that salt. And the salt is the fuel and the coolant and what's called the moderator. It brings the neutrons to a nice energy that we like. And it flows around the reactor like in a big pot. Usually nuclear reactor fuel is a solid and it's cooled by water. But in this case, the coolant is this molten salt and it's also

the fuel. How can the fuel be the coolant? Well, we talk about a coolant in the sense that it helps to exchange heat with the steam or whatever cycle that's removing energy from the reactor. Okay. My confusion, which is valid, is because solar molten salt reactors don't use the molten salt as a coolant. Right. But as a battery. Right. And the solar salts are actually really similar to the kinds of salts that we are interested in using for molten salt reactors because they have extremely high heat capacity, which means you can heat them up and they hold that heat without like, um, boiling or anything uncool like that.

Sounds really cool. What I'm doing right now is boring. Nah, you guys are awesome. Do you have a reactor at the university that students, I don't want to say play with, but break hack. Yeah, we used to.

To gain experience. Yeah, so the sad story is there's a long history in the United States of universities like ours having research reactors. And the University of Illinois had the second of the most common type ever in the world. And it operated for 38 years. And students played with it. Reactor operators were trained. Neutron and gamma experiments were conducted. Medical isotopes were produced. And then in the 90s, there was a decline in nuclear engineering funding and a somewhat uninterested dean and their license application needed to be renewed, which was going to cost a little bit of money, and they declined to do so. So they instead decommissioned it at our institution. So at Illinois, we don't currently have an operating fission reactor. There, you know, is always

interest in attempting to build such a thing for our students. And so I am certainly involved in activities to get a reactor back on campus. They're expensive, but you could have a cool new one now. So we're working on that. But something I will bring up is that our department does have a pretty sweet fusion device. It's called a Hydra. It is a stellarator. And what that is, is it creates a... Stellarator?

I don't think about fusion. It just has the best names. Stellarator. I know. It about fusion, just has the best names. Stellarator. I know. It becomes a star. That's right. And so it's shaped like a donut and a hot charge dense gas, aka a plasma, kind of moves around inside it when you turn it on.

There's big magnets and all kinds of stuff going on there. And this particular kind of device has a twist in it, which makes it a stellarator. Our device actually can operate both as a toroidal ordinary tokamak or a stellarator. So fusion power is still 20 years out, right? Always will be. Always will be. Why? I mean, it seems like it should work. Why can't it work?

The sun does it just fine. I don't understand the problem. Exactly. Aren't you smarter than the sun? If only. Yeah, so the biggest problem right now is actually a materials science issue. Oh, yeah. Bl blame the materials people that's right so the you know what do you what material do you use to contain the sun right it's yeah so like anything that's sort of anywhere near that fusion reaction is going to see extraordinary radiation heats interesting you know physics that are hard to you know not damage materials with so there's a lot of thoughts about how to manage that but we call this the first wall

which is to say the first wall between that plasma fusion reaction and all of the electronics and whatnot on the other side that that material is currently still in development. So most of your research on reactors involves big simulations. Really big. Yeah, I get to use the Blue Waters supercomputer at the University of Illinois here, and it's a great honor because we burn a lot of CPU hours trying to understand the accidents in potential nuclear reactors that we envision. So when you're running stuff on those supercomputers, what, what are you running Python or?

No, most of it's C++. Yeah. Yeah. And some of it's Fortran. That's all right. Sometimes we use Python. I mean, obviously, Python's a great wrapper.

And so to automate a lot of things at the sort of analysis stages and setup stages, we use Python. Are there physics packages beyond NumPy and SciPy and things that you use? Or is that kind of the basic set? Yeah, absolutely. numpy and scipy and things that you use or does that kind of yeah absolutely so some of my most valuable uh time i i really love working on a couple of python packages for nuclear engineering one is called pine the python for nuclear engineering package and it's you know really useful and it does all the little things that nuclear engineers need that no one else needs, like converting from barns to centimeters. And it also has a lot of sort of fun algorithms that, again, only nuclear engineers need.

Then a package called Perk, which is for reactor kinetics that I built as a postdoc and stuff like that. So nuclear engineers have a few Python packages that are pretty specific to nuclear engineering. Awesome. Yeah. Are there Python packages that you use that maybe aren't for your discipline? You know, sometimes the weather simulator ends up being useful because of its particles for something else. That's a phenomenal example. Yeah. So there's a couple of cool packages. One is YT, Matt Turk, who's also at the University of Illinois here with me as the sort of lead PI on this project. And it's a visualization toolkit for mesh-based simulations. And it was designed initially for astrophysics, but it's very applicable to the kinds of large mesh based simulations that we run in my group. Um, and it's for visual visualization

of those, those things in 3d. Um, and then also, uh, I'll, one of my favorite packages in Python is called Pint, P-I-N-T. And it's a unit library. And I just love it. Why? Because of the Barnes thing? Yeah, kind of that. Yeah. One of the biggest, I don't know.

So I'm not sure what happens to like web developers and other kinds of software engineers. But the most common failure mode of a graduate student doing an analysis is some total screw up of units. And a pint gives you a nice sort of sanity checker, and it can make sure that you aren't misconverting units and, you know, getting answers that are six magnitudes off. Ah, that'd have been useful for some of those Mars rovers that missed.

Although if you're going to call your rover Beagle, I have to tell you I've had a Beagle. It's not going where you want. Certainly not to Mars. Do you do any hacking now? Oh, it depends on what you call it. Um, but you know, the sad story is that I do a lot of oversight of other people's super cool hacking. Being a professor is like partly Peter principle, you know, you do really well at research and write papers really nicely.

And everyone eventually decides that they're going to give you a professorship. And then you watch other people do those things and make sure that they have sufficient funds to do those things. And you make sure that they're doing them right. And you give them ideas for the projects that you would love to do. Give away all your fun ideas. That's right. But, you know, I am really enjoying it. And if you include all the cool work that my students are doing, we do a lot of cool hacking for projects around micro reactor deployments, advanced tiny reactors that could

be really neato and nuclear fuel cycles that could recycle nuclear fuel safely and securely and all kinds of sweet stuff like that what uh what's a micro reactor i mean how how big are we talking drone size uh yeah so they can be as small as like the rectangular container on the back of a 18 wheeler oh so you know that like oh like a shipping container like a shipping container exactly that's what you're calling micro oh heck yeah a normal nuclear reactor is quite large and to sort of yeah yeah i hate to say it it's uh they're pretty big but um yeah that's a tiny reactor in our book you know um the very tiniest reactor in the world would be about the size of a grapefruit.

The Godiva device is an example of this. It's just pure, you know, uranium or plutonium. But you shouldn't touch it. Right. And so to control such a thing, you need a whole bunch of other gadgetry. Definitely shouldn't eat it. Yeah, definitely no eating. It's not chocolate and it's not a grapefruit.'s right and if it's blue run away um yeah so you know you need

all this other gadgetry for the safety aspects and the cooling aspects and the removal of the heat to turn it into energy and that's usable and all those gadgets take up space yeah it's not a great fruit size then is it no i'm afraid not no um so what do you think what what does the future hold for nuclear power because we aren't making a lot of new reactors as you mentioned the regulatory hurdles are very stringent and it doesn't seem like there's a lot of push for that it does seem like a good part of the solution to like carbon emissions and stuff but it doesn't seem like it's moving forward anymore is that true or yeah so in the united states there are two nuclear reactors

under construction um in burke county georgia at the Vogel Electric Generating Plant. There are already reactors there. These would be units three and four. That activity has been, as could be expected because of our regulatory environment, somewhat over budget and somewhat over schedule. However, I would say that this is extremely hopeful for nuclear power because it will represent the confirmation that we still can build new reactors. There is a lot of hope there. And I think, you know, it's important to think about the magnitude of what these devices represent. You know, two nuclear reactors is like, I don't know, you know, it's two gigawatts of electricity and, you know, it's, you know, thousands upon thousands upon thousands of solar panels and whatnot. This is just a really large contribution to our nation's carbon-free infrastructure. And it is happening, and they're very close to completion.

They really probably would have been completed very, very soon, but they've had to reduce their staffing because of the coronavirus in the last few months. Sure. Yeah, so there's that. I would say continuation of that size of reactor being built in the United States is mostly constrained by the capital costs. And after the current changes in our economy, I'd say the likelihood of even more of these would be low. small modular reactors of which at least one is currently in, it's being, being built very soon as a new scale plant that will be built out in Idaho for the Utah generating company. So there's, it's a very new small modular reactor design came out of Oregon.

And I don't know. I think that's the future because it really reduces the capital cost, allows you to build the modules in a factory, you know, rather than custom on-site with thousands of people. I think that's the future is these much smaller devices that can be built in a factory and deployed to where they need to go. Cool. Well, Katie, do you have any thoughts you'd like to leave us with? Well, I just want to say that in this time, we are seeing the importance of science, statistics, and exponential functions. And I am hopeful that although it's a really sad time for many people, that we'll leave this with a better understanding of at the very least exponential growth, which will help people understand

science. So I'm very hopeful right now at the amount of science in the news, even though it's very distressing science. And I hope people gain a literacy and a respect for scientists over this period. I hope so too. Our guest has been Dr. Catherine Hough, an assistant professor in the Department of Nuclear, Plasma, and Radiological Engineering at the University of Illinois at Urbana-Champaign. Thanks, Katie. Thanks very much.

Thank you to Christopher for producing and co-hosting. Thank you to our supporters on Patreon for Katie's mic. And thank you for listening. You can always contact us at show at embedded.fm or at the contact link on the website embedded.fm. And now a quote to leave you with from Paul Dirac. In science, one tries to tell people in such a way as to be understood by everyone, something that no one knew before. But in poetry, it's the opposite. Embedded is an independently produced radio show

that focuses on the many aspects of engineering. It is a production of Logical Elegance, an embedded software consulting company in California. If there are advertisements in the show, we did not put them there and do not receive money from them. At this time, our sponsors are Logical Elegance and listeners like you.