FAQ - Neutron Transport Simulation, Detector Calibration, and Shielding
Posted: Fri Aug 02, 2019 9:05 pm
This FAQ (should it be raised to that status) will discuss neutron transport simulations and their applicability to fusors. This lengthy block of text is not a beginner's FAQ, so one should be well-versed in all topics in the Neutrons and Detection FAQs before continuing. While this is not a "frequently-asked question" per se, I think it deserves discussion.
Carl Willis used MCNP to simulate moderator performance versus material, thickness, etc. back in 2003 (http://fusor.net/board/viewtopic.php?f= ... 84&p=36164) but that was its first and last use on the forums. I highly recommend Carl's paper as it is a good introduction to neutron activation experiments performed in the early 2000s and moderator optimization. The dimensions of moderators used by must fusioneers are based on that study (as well as industry experience, I'm sure), but nearly 16 years-worth of posts have buried it. I, like many others, took the "2-3in of HDPE for 3He and boron tubes" figure for granted, and not until recently did I dig far enough back to find the source. But enough intro.
Neutron Transport Simulation and Monte Carlo:
Radiation transport through matter is a complex process. Instead of solving diffusion and transport equations on complex geometries to find fluences, reaction rates, and any other values of interest, most publicly available codes are based on Monte Carlo (MC) and simulate the paths of many individual particles to accumulate statistically significant counts. Per MC, particles are randomly assigned values within the user-specified parameter space (direction, energy, etc.) and are stepped through the geometry until absorbed, or deleted by a 'vacuum' boundary surface. Absorption, scattering, and various cross-sections are integrated along the paths, resulting in accurate determination of the above values. The accuracy increases by roughly sqrt(N) but the simulation time increases linearly, meaning long simulations are needed for acceptable results. Depending on the speed/core count of your CPU, number of particles, and geometry, simulations could last for minutes, hours or days.
Available Codes:
The aforementioned MCNP, which stands for "Monte Carlo N-Particle Code," is one of the more well-known packages for simulating general radiation transport (not just neutrons). The downside is that it has usage and export restrictions, which could pose challenges for non-US citizens or residents of other countries. Instead of going through the hassle, I opted for.....
OpenMC, which is open source neutron-only code developed at MIT. It is for many intents and purposes identical to MCNP, including in its definition of geometry and tallies, and has thorough documentation for both APIs and the standard distribution. The one downside, which proved somewhat of a stumbling block for me, is that it is made for Linux/MacOS. Using the Python API and the new Linux kernel (actually Ubuntu) included in Windows 10, however, I managed to get it working. Documentation: https://openmc.readthedocs.io/en/stable/
For a more complete list of libraries, see https://en.wikipedia.org/wiki/Neutron_transport
OpenMC Installation
This is easy on Linux and MacOS, and is simply a matter of copy-pasting the commands from the documentation into the terminal. The cross-section data is not included and must be downloaded and converted separately (discussed below). On Windows, this is the method I used:
1. Install Ubuntu from the Microsoft store and follow the basic install procedures from the documentation as you would for a Linux system.
2. If you do not already have one, install a Python IDE. I use Spyder included with Anaconda.
3. Download the Python API, which will allow you to easily generate the input files, and extract it to a folder of your choosing. Depending on your Python version, you may need to use 2to3.py to convert the API to Python 3. My folder structure, which will be used as reference below, is "Simulations-->OpenMC-->..." where the OpenMC libraries files are in said folder. I write the simulation files in "Simulations" and import OpenMC as a Python package. This makes the file structure simple as all generating, input, and output files are in "Simulations" and you don't have to worry about the computer not finding files.
4. Download the ENDF/B-VII.1 cross sections and use the Python API (openmc-ace-to-hdf5.py) to convert the .ACE files to .h5 files and generate cross-sections.xml. Place these .h5 files in a subfolder of "Simulations". Alternatively, if you can get it to work, just run 'openmc-get-nndc-data' and the xml files will appear in the Linux files.
5. In the Ubuntu terminal, set the environment variable OPENMC_CROSS_SECTIONS to the cross-sections.xml file. This can be done with 'export OPENMC_CROSS_SECTIONS=/mnt/d/...' where 'd' is replaced with whatever drive the xml is on.
6. Set the Ubuntu current directory to "Simulations"
7. Once the geometry, materials, settings, plots, and tallies xml files are generated (discussed next) and in the "Simulations" folder, run OpenMC by typing 'openmc' in the Ubuntu terminal. It will automatically utilize all available cores, though manually setting the number is specified in the docs. Alternatively, if the xml files are elsewhere or you have multiple projects, run OpenMC with a path argument or change the current directory.
Specifying Geometry and Simulation Parameters
These inputs are thoroughly discussed in the OpenMC docs so I will refrain from re-typing that here. Take-away points are as follows:
-Geometry is specified using logical operators half-spaces of 2nd order surfaces. For example, +z_plane is everything above the plane z = z0. If I want to make a box, I will use +neg_x & -pos_x & +neg_y & -pos_y & +neg_z & -pos_z.
-Cells are assigned a geometry and material
-Universes are assigned cells and/or sub-universes to form the overall structure.
-Neutron sources can be defined by cell materials (i.e. uranium), or, for our interest case, as a point source of specific energy and angular distribution
-Output data, which comes in the form of tallies, can be defined using various filters. If I want to find the fluence/flux through a specific surface I define a 2D or 3D mesh and tell OpenMC to tally the parameters I want. Cell filters for fluence and reaction rates are also possible, as is energy binning. It is important to note that the units for flux is particle-cm/source particle (a kind of path-length flux), meaning that, for a 3D mesh, the measured value must be divided by the mesh thickness. The units are then particles/source particle, or a dimensionless fraction. Reaction rates are in reactions/source particle.
Optimal Moderator Thickness
Finally we get to the interesting part, which is how neutron transport simulations can be used with fusors. The most immediate use has already been covered by Carl, though it deserves some reiteration here. We want thermal neutrons, and the best (only?) way to obtain those from a fast neutron source is through moderation by light elements. For a fixed center-line distance the thicker the moderator the more neutrons that are thermalized and the higher your detection rate/detector sensitivity will be. For this example the exact geometry is not important, but consider the following plot:
Thermal (0.025eV - 0.5eV) neutron fluence in a cylindrical paraffin moderator
At a glance this appears to contradict Carl's results, but it in fact does not:
There is clearly a peak region in the ~4-7cm range, but this results from the trade-off between moderator thickness and center-line distance and not absorption or other effects. His simulations moved the source further away as the moderator thickness increased, mimicking a real-world scenario where the bulky detector exterior can be placed only so close to the focus. In other words, increase the moderator thickness and the center distance must increase. Interestingly, and for reasons I have not yet discerned, the graphs appear to have the form x^n*e^-x which pops up everywhere from the radial hydrogen wavefunction to factorials. I would expect, from the inverse square law, to have some function f(x)*x^-2, but the moderator geometry must be playing a major role here. Perhaps someone with more physics education than I could provide insights.
Neutron Detector Calibration
I was faced with a problem that many here encounter with their surplus neutron detection gear: calibration. While verifying gamma discrimination using check sources and neutron detection with Am-Be or Po-Be is simple enough, quantifying neutron fluence is much more challenging without a calibrated detector and source. I did (do) not want to spend $150 or $400 on a bubble detector, group buy or not, and have it die within 6 months or a year, so I turned to simulation. Using two somewhat independent methods in OpenMC, I believe that I have accurately calibrated my neutron detector, though only a physical source will guarantee the reliability of the method.
I modeled all major geometries of my neutron detector, including the paraffin moderator, aluminum 3He tube shield, and 3He/Ar gas mix at the appropriate pressure. For reference, I have an SNM-18 tube and the simulation parameters are the following:
tube length: 28.4cm
tube diameter: 3.2cm
fill composition: 97% 3He 3%Ar @ 4atm
quoted sensitivity: 70% (found inaccurate later)
moderator ID: 3.81cm
moderator thickness: 3.05cm
moderator length: 50.8cm (tube shield is much longer than the detector portion)
focus-detector center distance: 13.97cm (because of course I have all those sig. figs...)
Air is light blue, paraffin is grey, aluminum is black, and the 3He/Ar is teal.
The source is isotropic, emits 2.44MeV neutrons, and is located along the perpendicular bisector of the detector. Five batches of 100,000 particles each were simulated, taking about 10s on a 4C/8T 2.6GHz processor. This was plenty of particles to drop the uncertainty well below 5%, though I found that smaller geometries with larger distances require upwards of 1e7-1e8 (and 12GB RAM) for accurate counting. I used two tallies, one flux-based and the other reaction-based, to verify the detector statistics, specifically the claimed 70% efficiency. The flux-based tally used a 3D rectangular mesh placed along the detector midplane and perpendicular to the source, as well as a thermal neutron filter (0eV - 0.5eV). The mesh thickness was 0.001cm, meaning that the resulting flux of n-cm/n was divided by said number to obtain the fractional fluence. The reaction tally was filtered to the 3He/Ar cell and the 3He + n reaction, abbreviated as (n,p). Results, from the tallies.out file, were as follows:
======> TALLY 1: REACTION-BASED 3HE TUBE CALIBRATION TALLY <=======
Cell 8
Total Material
Flux 0.0948652 +/- 0.00110802
Total Reaction Rate 0.00457578 +/- 0.000108379
(n,p) 0.00454996 +/- 0.00010832
========> TALLY 2: FLUX-BASED 3HE TUBE CALIBRATION TALLY <=========
Incoming Energy [0, 0.5)
Mesh Index (1, 1, 1)
Total Material
Flux 4.16969e-06 +/- 1.80819e-07
Adjusting the flux-based tally for the mesh thickness, we obtain 0.00416969 n/src. n and 0.00454996 reactions/src. n, which are remarkably close and differ by only 9%. Much of this likely results from cutting off the flux tally at 0.5eV, so more simulation is in order. It appears as if the SNM-18 tube's sensitivity is closer to 90% than 70%, so again, more simulations are needed. From these results I can conclude that the n/s of my fusor is CPM/60 / 0.00416969 --> n/s = 3.99*CPM
Ultimately, to prove the validity of my methods, I will have to calibrate my detector against a real source. I should be able to do so once the fall semester starts.
Neutron Shielding
Under construction - preliminary results indicate that 10cm of paraffin backed by 10cm of borax reduce fast neutron fluence by ~84x.
Conclusions
Under construction
I should note that, while I am far from a novice, there are many people on these forums with far greater experience than I. Please correct me where wrong and feel free to share experience/wisdom. I will edit this post as necessary.
-Liam David
Carl Willis used MCNP to simulate moderator performance versus material, thickness, etc. back in 2003 (http://fusor.net/board/viewtopic.php?f= ... 84&p=36164) but that was its first and last use on the forums. I highly recommend Carl's paper as it is a good introduction to neutron activation experiments performed in the early 2000s and moderator optimization. The dimensions of moderators used by must fusioneers are based on that study (as well as industry experience, I'm sure), but nearly 16 years-worth of posts have buried it. I, like many others, took the "2-3in of HDPE for 3He and boron tubes" figure for granted, and not until recently did I dig far enough back to find the source. But enough intro.
Neutron Transport Simulation and Monte Carlo:
Radiation transport through matter is a complex process. Instead of solving diffusion and transport equations on complex geometries to find fluences, reaction rates, and any other values of interest, most publicly available codes are based on Monte Carlo (MC) and simulate the paths of many individual particles to accumulate statistically significant counts. Per MC, particles are randomly assigned values within the user-specified parameter space (direction, energy, etc.) and are stepped through the geometry until absorbed, or deleted by a 'vacuum' boundary surface. Absorption, scattering, and various cross-sections are integrated along the paths, resulting in accurate determination of the above values. The accuracy increases by roughly sqrt(N) but the simulation time increases linearly, meaning long simulations are needed for acceptable results. Depending on the speed/core count of your CPU, number of particles, and geometry, simulations could last for minutes, hours or days.
Available Codes:
The aforementioned MCNP, which stands for "Monte Carlo N-Particle Code," is one of the more well-known packages for simulating general radiation transport (not just neutrons). The downside is that it has usage and export restrictions, which could pose challenges for non-US citizens or residents of other countries. Instead of going through the hassle, I opted for.....
OpenMC, which is open source neutron-only code developed at MIT. It is for many intents and purposes identical to MCNP, including in its definition of geometry and tallies, and has thorough documentation for both APIs and the standard distribution. The one downside, which proved somewhat of a stumbling block for me, is that it is made for Linux/MacOS. Using the Python API and the new Linux kernel (actually Ubuntu) included in Windows 10, however, I managed to get it working. Documentation: https://openmc.readthedocs.io/en/stable/
For a more complete list of libraries, see https://en.wikipedia.org/wiki/Neutron_transport
OpenMC Installation
This is easy on Linux and MacOS, and is simply a matter of copy-pasting the commands from the documentation into the terminal. The cross-section data is not included and must be downloaded and converted separately (discussed below). On Windows, this is the method I used:
1. Install Ubuntu from the Microsoft store and follow the basic install procedures from the documentation as you would for a Linux system.
2. If you do not already have one, install a Python IDE. I use Spyder included with Anaconda.
3. Download the Python API, which will allow you to easily generate the input files, and extract it to a folder of your choosing. Depending on your Python version, you may need to use 2to3.py to convert the API to Python 3. My folder structure, which will be used as reference below, is "Simulations-->OpenMC-->..." where the OpenMC libraries files are in said folder. I write the simulation files in "Simulations" and import OpenMC as a Python package. This makes the file structure simple as all generating, input, and output files are in "Simulations" and you don't have to worry about the computer not finding files.
4. Download the ENDF/B-VII.1 cross sections and use the Python API (openmc-ace-to-hdf5.py) to convert the .ACE files to .h5 files and generate cross-sections.xml. Place these .h5 files in a subfolder of "Simulations". Alternatively, if you can get it to work, just run 'openmc-get-nndc-data' and the xml files will appear in the Linux files.
5. In the Ubuntu terminal, set the environment variable OPENMC_CROSS_SECTIONS to the cross-sections.xml file. This can be done with 'export OPENMC_CROSS_SECTIONS=/mnt/d/...' where 'd' is replaced with whatever drive the xml is on.
6. Set the Ubuntu current directory to "Simulations"
7. Once the geometry, materials, settings, plots, and tallies xml files are generated (discussed next) and in the "Simulations" folder, run OpenMC by typing 'openmc' in the Ubuntu terminal. It will automatically utilize all available cores, though manually setting the number is specified in the docs. Alternatively, if the xml files are elsewhere or you have multiple projects, run OpenMC with a path argument or change the current directory.
Specifying Geometry and Simulation Parameters
These inputs are thoroughly discussed in the OpenMC docs so I will refrain from re-typing that here. Take-away points are as follows:
-Geometry is specified using logical operators half-spaces of 2nd order surfaces. For example, +z_plane is everything above the plane z = z0. If I want to make a box, I will use +neg_x & -pos_x & +neg_y & -pos_y & +neg_z & -pos_z.
-Cells are assigned a geometry and material
-Universes are assigned cells and/or sub-universes to form the overall structure.
-Neutron sources can be defined by cell materials (i.e. uranium), or, for our interest case, as a point source of specific energy and angular distribution
-Output data, which comes in the form of tallies, can be defined using various filters. If I want to find the fluence/flux through a specific surface I define a 2D or 3D mesh and tell OpenMC to tally the parameters I want. Cell filters for fluence and reaction rates are also possible, as is energy binning. It is important to note that the units for flux is particle-cm/source particle (a kind of path-length flux), meaning that, for a 3D mesh, the measured value must be divided by the mesh thickness. The units are then particles/source particle, or a dimensionless fraction. Reaction rates are in reactions/source particle.
Optimal Moderator Thickness
Finally we get to the interesting part, which is how neutron transport simulations can be used with fusors. The most immediate use has already been covered by Carl, though it deserves some reiteration here. We want thermal neutrons, and the best (only?) way to obtain those from a fast neutron source is through moderation by light elements. For a fixed center-line distance the thicker the moderator the more neutrons that are thermalized and the higher your detection rate/detector sensitivity will be. For this example the exact geometry is not important, but consider the following plot:
Thermal (0.025eV - 0.5eV) neutron fluence in a cylindrical paraffin moderator
At a glance this appears to contradict Carl's results, but it in fact does not:
There is clearly a peak region in the ~4-7cm range, but this results from the trade-off between moderator thickness and center-line distance and not absorption or other effects. His simulations moved the source further away as the moderator thickness increased, mimicking a real-world scenario where the bulky detector exterior can be placed only so close to the focus. In other words, increase the moderator thickness and the center distance must increase. Interestingly, and for reasons I have not yet discerned, the graphs appear to have the form x^n*e^-x which pops up everywhere from the radial hydrogen wavefunction to factorials. I would expect, from the inverse square law, to have some function f(x)*x^-2, but the moderator geometry must be playing a major role here. Perhaps someone with more physics education than I could provide insights.
Neutron Detector Calibration
I was faced with a problem that many here encounter with their surplus neutron detection gear: calibration. While verifying gamma discrimination using check sources and neutron detection with Am-Be or Po-Be is simple enough, quantifying neutron fluence is much more challenging without a calibrated detector and source. I did (do) not want to spend $150 or $400 on a bubble detector, group buy or not, and have it die within 6 months or a year, so I turned to simulation. Using two somewhat independent methods in OpenMC, I believe that I have accurately calibrated my neutron detector, though only a physical source will guarantee the reliability of the method.
I modeled all major geometries of my neutron detector, including the paraffin moderator, aluminum 3He tube shield, and 3He/Ar gas mix at the appropriate pressure. For reference, I have an SNM-18 tube and the simulation parameters are the following:
tube length: 28.4cm
tube diameter: 3.2cm
fill composition: 97% 3He 3%Ar @ 4atm
quoted sensitivity: 70% (found inaccurate later)
moderator ID: 3.81cm
moderator thickness: 3.05cm
moderator length: 50.8cm (tube shield is much longer than the detector portion)
focus-detector center distance: 13.97cm (because of course I have all those sig. figs...)
Air is light blue, paraffin is grey, aluminum is black, and the 3He/Ar is teal.
The source is isotropic, emits 2.44MeV neutrons, and is located along the perpendicular bisector of the detector. Five batches of 100,000 particles each were simulated, taking about 10s on a 4C/8T 2.6GHz processor. This was plenty of particles to drop the uncertainty well below 5%, though I found that smaller geometries with larger distances require upwards of 1e7-1e8 (and 12GB RAM) for accurate counting. I used two tallies, one flux-based and the other reaction-based, to verify the detector statistics, specifically the claimed 70% efficiency. The flux-based tally used a 3D rectangular mesh placed along the detector midplane and perpendicular to the source, as well as a thermal neutron filter (0eV - 0.5eV). The mesh thickness was 0.001cm, meaning that the resulting flux of n-cm/n was divided by said number to obtain the fractional fluence. The reaction tally was filtered to the 3He/Ar cell and the 3He + n reaction, abbreviated as (n,p). Results, from the tallies.out file, were as follows:
======> TALLY 1: REACTION-BASED 3HE TUBE CALIBRATION TALLY <=======
Cell 8
Total Material
Flux 0.0948652 +/- 0.00110802
Total Reaction Rate 0.00457578 +/- 0.000108379
(n,p) 0.00454996 +/- 0.00010832
========> TALLY 2: FLUX-BASED 3HE TUBE CALIBRATION TALLY <=========
Incoming Energy [0, 0.5)
Mesh Index (1, 1, 1)
Total Material
Flux 4.16969e-06 +/- 1.80819e-07
Adjusting the flux-based tally for the mesh thickness, we obtain 0.00416969 n/src. n and 0.00454996 reactions/src. n, which are remarkably close and differ by only 9%. Much of this likely results from cutting off the flux tally at 0.5eV, so more simulation is in order. It appears as if the SNM-18 tube's sensitivity is closer to 90% than 70%, so again, more simulations are needed. From these results I can conclude that the n/s of my fusor is CPM/60 / 0.00416969 --> n/s = 3.99*CPM
Ultimately, to prove the validity of my methods, I will have to calibrate my detector against a real source. I should be able to do so once the fall semester starts.
Neutron Shielding
Under construction - preliminary results indicate that 10cm of paraffin backed by 10cm of borax reduce fast neutron fluence by ~84x.
Conclusions
Under construction
I should note that, while I am far from a novice, there are many people on these forums with far greater experience than I. Please correct me where wrong and feel free to share experience/wisdom. I will edit this post as necessary.
-Liam David