The web hosting service does not accept Access database files. Therefore, we can only offer text versions of the individual components of the IFFY database. These are comma-separated values (.csv) files, so Excel will open them handily. We have tested Office Calc on only a few of these.
- Documentation tables
- Nuclear data (input) tables
- Simulation components
- Temporary tables (which need to be created if testing the code)
- SQL_Queries (some for post-production)
- Simulation output tables
The Source of the data is generally a web page from a reputable nuclear agency or lab. However, some entries give the reasons those sources are insufficient. The field definitions offer a quickie introduction to the database. In addition, this page has more detail.
Fission fragment decay requires data for half-lives (from the Nuclides table), branching, and initial yields. In addition, neutron capture needs cross-section data. The Elements table is the least important “raw” data, used only for a few charts.
We found it convenient during debugging to process fission fragment evolution in two phases. The first phase processed the fission event and 1/2 second of decay. We stored the results in Primer0, aka Snapshot0 or Snap0. The remainder of the processing used Primer0 as the restart point.
- Older versions of Yields table have a Timestep value of -1. Two to the power -1 is 0.5 (seconds), which is when the fission event happens. While consistent mathematically, this was confusing programmatically. Snap-1 was too easy to confuse with Snap1. It was also the only timestep with no Old_Inventory to decay. Once we got the first second of reactor operation nailed down (in Snap0), we never went back to Snap-1.
- Snap0 has no neutron capture! Neutron capture code was created later, and we considered 1/2 second of capture/transmutation too minor to redo the entire output.
The buffer tables store intermediate results for faster processing and debugging.
The code references two Form objects, which we cannot easily pass on. First, the simulation has a “start “button named Run_1. Second is a counter that displays the atomic weight, which counts down as the simulation progresses. In addition, the Immediate window displays the combo and the timestep. These are in lieu of a progress bar.
The SQL queries are not normally stored in a table. Rather, validators should transfer them to the Queries section of the database.
- The code needs only some of the queries (see the Use field).
- Others create the output subsets or perform QC checks.
- EmptySnapshots and two other queries “prime” the sim for a new run.
- LoadElement0 and Get_Fuel-Speed_Pairs need the same LIKE clause!
The output tables describe cumulative yields. The complete output is EvolveAll, which is large enough to slow down any analysis process significantly. Therefore, we provide smaller subsets for faster analysis. Go to this page for more detail.
- All slow data includes neutron capture (except in CaptureQC).
- No fast data includes neutron capture.
Level of detail
The basic output tables have no “frills”. The output fields are TimeStep, Fuel, Speed, Nuclide, and Yield.
In contrast, the View235 and Capture QC tables add several fields (mainly from Nuclides) for analytic slicing and dicing:
- AtWt, Protons, Level : Nuclide identifiers
- Norm: Cumulative yield normalized so all timesteps sum to two atoms
- TimeBin, BarnClass, Rung, ID: IFFY derived data
The View235 query combines 235-U slow and 235-U fast cumulative yield data. The data sets are distinguished by the value of the Speed field; “Fast” or “Slow”.
The CaptureQC table highlights the difference with and without neutron capture. It uses two sets of 235-U Slow data. Therefore, we gave it an extra field called Capture (values Yes or No) to distinguish between the data sets.