The development of the IFFY database began with an interest in molten salt reactors (MSR). MSR circulate molten salt from the reactor core to heat exchangers and back. The salt stream carries fuel, failed fuel, and fission products in this loop. Some of the waste causes problems, but some offers opportunities. The key question is, “What’s in the salt?”
Unlike today’s solid fuel, we can draw off some of the waste from the MSR’s salt stream. And some of this “waste” is valuable! We can also remove some of the problematic elements and isotopes for improved operation.
- We can extract medical isotopes and other radioactive isotopes. Some have no current applications because they have never before be recovered in quantity.
- MSR operators will definitely want to remove isotopes that absorb neutrons. They need the neutrons to keep the chain reaction going. This will allow failed fuel to stay in the reactor longer, increasing the chance they will become fuel rather than waste.
- We can be extract certain isotopes and set them aside to decay. In this manner we might create 238-Pu, now in short supply for space probes, and 233-U, the cleanest nuclear fuel. Moreover, 233-U comes from Thorium, which is 500 times more plentiful than the 235-U burned today. This would have a significant impact on sustainability. The “Thorium economy” would also make the enrichment of 235-U obsolete, which would close one route to nuclear weapons.
On the negative side, the fission process creates insoluble metals such as Palladium and Silver. These might clog the pipes. Some elements can be corrosive as well. We can address many of these issues by answering the question,
What’s in the salt (and when and how much)?
We need a time-dependent table of cumulative yields for fission products. A web search did not produce such a table. Initial yield data was available from Brookhaven, but that covers an instant in time. The isotopes produced by fission change quickly or slowly, depending on their half-lives. Since more are constantly being produced in an operating reactor, the situation is complex. Charting the full evolution of all the fission products demands a simulation.
The search did produce the necessary components for such a simulation. The development effort started with downloads from the web. Half-life data are available from several sources. The TORI 2 data from Lawrence Livermore was conveniently in database form already. It also included the next step in each isotope’s evolutionary path, its immediate daughter (or rather daughters, as some isotopes can decay in more than one way). However, the TORI 2 data does not include the possibility of decaying to an excited state of the daughter (decay modes B-m and EC-m). The JEFF-20 data from the International Atomic Energy Agency does cover these decay modes.
Unfortunately, the JEFF-20 data comes in a PDF format. It can’t be edited, which means hand entry rather than cut and paste. In addition, none of the three main data sources used the same method of naming isotopes. A future page will cover these and other problems encountered in integrating the data.
The TORI 2 database was a natural starting point for the project. But it has some structural flaws.
Weird table names
The first major table we borrowed from TORI 2 is named Parents. This seems specific to the decay process, in which a parent nucleus transmutes to a daughter. More accurately, this is a table of isotope characteristics, and has a more general purpose than just decay. We changed the table name to Isotopes, and eventually the more general term Nuclides.
We patterned our second major table after the TORI 2 Parents2 table. A more appropriate name might be Daughters or Decay_Modes. Eventually we settled on Branches, which emphasizes the fact that some parents decay in more than one way.
The TORI 2 data base uses an integer field called IZA as its primary key. Each isotope or isomer has a unique IZA number to identify it across the several data tables. The number scheme is clumsy, unreadable, and unnecessary.
Someone told the TORI 2 developer that a primary key needs to be an integer. But what it really needs to be is unique and unlikely to change over time. A business database might use Customer_ID as its key rather than the customer’s name. After all, she might get married and all the transactions registered in her name would need to change. But element names (and their 1-2 letter symbols) are very unlikely to change, so we feel safe in using the nuclide’s name as our key. (Note that our names ##[#]-[A-Z][a-z][-#] match none of the naming schemes from our three major data sources.)
From the viewpoint of a database purist, the IFFY database has some flaws of its own.
- The Nuclides table includes a separate field for atomic weight (AtWt). Technically, this is redundant, as it could be parsed from the nuclide’s name.
- The Nuclides table also includes the proton number, which could be derived by parsing the element symbol embedded in the nuclide’s name, and joining that to the Elements table.
- The Branches table contains both the decay mode and the daughter’s name. This is also redundant, but more forgivable as the translation is far more complicated than a simple parse.
We describe each table in the IFFY database in the Downloads page.
The effort to develop the data for the IFFY sim was considerable. We gathered and reformatted data from three major sources, then massaged it into an integrated whole. The results are now available in the flexible form of a relational database. Even if IFFY never gets approved, the raw data has value. Documentation for the data development process is partially completed and will be added later.
To the basic data we have added new data elements derived for quality control or simulation control, or simply to display the data in artistic or instructional ways. One of the first of these was the TimeBin, in which the 1322 nuclides are sorted into nine bins, according to their half-lives. This allows the creation of a nine-color chart that displays fission fragment evolution quite succinctly.
Another derived statistic is the Rung, a numerical expression of the Energy Ladder model.