The concepts below are notional. We hope for suggestions from experts in nuclear matters as to the approach we should take. Currently, there are three major evolution decisions we need to reexamine.
- Do we really need the early days (time-steps 0-20)?
- Do we need to treat time exponentially?
- Is the order of processing as important as with fission fragments?
Additionally, users will have input to the simulation, which was not the case for fission fragment evolution. How do we present the options to them?
Differences between fuel and fission fragments
A number of factors make the evolution of fuel different from that of fission fragments.
- Nuclides on the higher rungs decay quickly. As the sim progresses, the exponential treatment of time treats more and more of these as if their half-lives were zero: we simply push their population down the chain.
- Fission fragments on the higher rungs are less popular than those in the middle. (The most popular rungs are 2, 3, and 4 ~ evenly split.) Nuclides on the lower rungs owe more of their population to inheritance than native births.
- Exponential time works well because short-lived nuclides quickly become less relevant.
- There is a chain of fuels from 232-Th to 245-Cm, but their half-lives (and half-life equivalents) are not related. Random short/long lives are not a natural fit with an exponential treatment of time.
- The problem space is smaller, with only 14 nuclides to consider instead of 1322.
- We can easily ignore the first Kilosec (20 tmesteps), by assuming a “standard” startup fuel for the first twelve days of reactor operation.
- In addition to decay and neutron absorption, fuels can change due to fission.
- There is less justification for ordered processing when there are three separate and unrelated processes.
These factors make the exponential treatment of time less appropriate when the subject is fuel evolution rather than fission fragment evolution. As the problem space is far smaller, a “natural” clock might be possible.
If we don’t care about the order of processing, we can use an SQL query, which is both simpler and faster than a recordset.
There is no need to process fission in any particular order. Once the fuel atom has been split, it is gone (with respect to fuel evolution! We already track the evolution of the resulting fission fragments.) In essence, we assume each fission event is independent. This includes different fuels and/or different neutron energies. Independent and simultaneous fissions can be done with a weighted SQL query.
Fuel atoms can capture neutrons. We handle fission fragment captures with an SQL query, which does not control the order of processing. This means that a chain/cascade of captures is not properly represented. There are a few consecutive neutron poisons, but we decided not to trace the “cascade”. The situation for fuel is only slightly different, in that neutron capture more often leads to a short-lived daughter. This is even more incentive to ignore the cascade.
The decay process for fission fragments does have a cascade. Starting at the top, we push the nuclides downward as far as we can. Alternately, we could have restricted decay to one decay per time-step. Neither strategy is perfect, but we contend that a cascade is proper for fission fragments, but not for fuel. The decay of fuels – or daughters of fuels – does not have the regular pattern that fission fragments exhibit. The half-lives of fuels do not regularly get longer as the fuel evolves. A fuel atom that decays once, then waits, can be reasonably represented with a one-decay-per-timestep approach. There are a few cases of two highly unstable daughters in sequence. We might aggregate these, which effectively skips over the 233-Th or 239-U phases in the lives of some fuels.
The arguments above refer to processing within the three main nuclear reactions: fission, capture, and decay. For fuels, we propose to forego an internal cascade for all three functions. However, there is still choice in sequencing these three processes.
- We prefer is to do decay first, because the eight fastest reactions are B- decays. We want to get those out of the way.
- Six of the next seven fastest reactions are fissions, so we will process them next.
- Capture will be processed last.
There is no user involvement in fission fragment evolution. The results are “in the can”. The user queries the data base to obtain the mix of fission fragments for a particular fuel/speed/age. The next phase of the project will cover fuel evolution, which is a way of determining fuel/speed/age.
The primary difference we wish to represent is between fast and slow reactors. Eventually, we wish to balance expensive, waste-consuming (and somewhat “touchy”) fast reactors with cheaper slow reactors. Our approach is to assume that any “speed” reactor is achievable. The user should be allowed to choose any percentage contribution of fast neutrons. Our first thought is of a slider that allows a range of 0-100% for “effective” fast neutrons. In this context, an effective neutron is one that doesn’t just bounce off the target nucleus. This includes fission or capture, but not inelastic collisions.
Inelastic collisions are one way to slow down (moderate) neutrons. The problem is that we don’t know how the neutrons will decelerate in any given reactor design. Therefore, we place this requirement on the user. They must choose a single number to represent the relative contributions of fast and slow neutrons.
The user will also be able to select a fuel or a combination of fuels. These can vary over time. There might be a few “starter” sets, using only 233-U or 235-U, each at a fixed enrichment. As mentioned above, the first twelve days of reactor operation are not terribly critical. These starting conditions “prime the pump” for the simulation of fuel evolution. In addition, the user will be able to change the fuel mix manually.
Both “natural” and man-made changes in the fuel input might be referenced from a library of fuel choices. The obvious entries follow the evolution of the starter fuels. Users will need to tailor special entries for each waste-burning scheme. Some combinations may not be possible in reality due to neutron economy restrictions. For instance, 239-Pu in a slow reactor does not produce enough excess neutrons to allow breeding. Our model does not count neutrons, so the user will responsible for providing realistic fuel mixes.