FAQ - Neutron Transport Simulation, Detector Calibration, and Shielding

If you have a question about this topic, the answer is probably in here!
User avatar
Liam David
Posts: 146
Joined: Sat Jan 25, 2014 10:30 pm
Real name: Liam David
Location: Arizona

FAQ - Neutron Transport Simulation, Detector Calibration, and Shielding

Post by Liam David » Sat Aug 03, 2019 1:05 am

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:

Image
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:

Image

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...)

Image
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

Robert Dwyer
Posts: 80
Joined: Sun Sep 04, 2016 9:34 pm
Real name: Robert Dwyer
Location: New Mexico

Re: FAQ - Neutron Transport Simulation, Detector Calibration, and Shielding

Post by Robert Dwyer » Tue Aug 06, 2019 8:10 pm

Liam,

Great work! It is good to see someone using Monte-Carlo simulations in the community. This a great example of using a Monte-Carlo for detector work. One can easily poor hours into such software trying to find optimum moderator configurations, mapping the flux of such systems, etc...

I have never used OpenMC but I am a user of MCNP (far from an expert). This post has got me thinking about ways to set up some tallies that would let one do some flux mapping of the neutrons inside the moderator, as well as see how the energy spectra changes over the distance of the moderator. Also of interest would be the use of reflectors. A cool thing about simple calculations with moderators and detectors like this is given a known neutrons source, the simulation can be compared to an experiment rather easily, and efficiencies can be accurately measured.
If we throw more money at it, it will have to work... right?

User avatar
Rich Feldman
Posts: 1119
Joined: Mon Dec 21, 2009 11:59 pm
Real name: Rich Feldman
Location: Santa Clara County, CA, USA

Re: FAQ - Neutron Transport Simulation, Detector Calibration, and Shielding

Post by Rich Feldman » Thu Aug 08, 2019 2:46 am

Thank you, Liam, for a great presentation.

A few months ago I downloaded MCNP and skimmed the manual. Figured it could be an educational complement to my moderator configuration experiments. http://www.fusor.net/board/viewtopic.ph ... =10#p82995 Then had to take a break from fusor play.
Mike echo oscar whisky! I repeat! Mike echo oscar whisky, how do you copy? Over.

Peter Schmelcher
Posts: 164
Joined: Sat Nov 13, 2010 6:56 am
Real name: Peter Schmelcher

Re: FAQ - Neutron Transport Simulation, Detector Calibration, and Shielding

Post by Peter Schmelcher » Sat Aug 31, 2019 6:11 pm

Nice work!

Another arrow in your quiver could be Cosmic ray generated neutrons. For initial testing, does my detector setup work, it’s a no brainier. For calibration it remains an unanswered question.

Previous post with attached papers.
viewtopic.php?t=11307

-Peter

User avatar
Liam David
Posts: 146
Joined: Sat Jan 25, 2014 10:30 pm
Real name: Liam David
Location: Arizona

Re: FAQ - Neutron Transport Simulation, Detector Calibration, and Shielding

Post by Liam David » Sat Aug 31, 2019 11:42 pm

Cosmic neutrons are indeed a "does my detector work?" discriminator, though with the high variability due to probability (~sqrtN), altitude, latitude, the sun doing it's stuff, I doubt it's more useful than that. You'd need a minimum of several hours of data collection, and even then, I doubt you'd get within 50%. The proof, of course, is in doing the experiment. Since my tube is driven by a Ludlum model 12, doing such an experiment with manual datalogging is not very appealing nor worth the time--time better spent running higher fidelity simulations and actually doing fusion.

Alex Aitken
Posts: 228
Joined: Mon Dec 08, 2003 10:33 am
Real name:

Re: FAQ - Neutron Transport Simulation, Detector Calibration, and Shielding

Post by Alex Aitken » Thu Sep 05, 2019 1:35 pm

This is awesome, awesome, awesome. I thought pretty much nobody else was interested in Monte Carlo methods.

I tried to repeat Carl's work in the mid 2000's and had good agreement with the fast neutron flux, but my other results were weirdly off. I exchanged emails with him but couldn't work out the problem. A few years later I revisited and found the wrong number of zeros in the thermal energy binning which was making the thermal and epithermal results wrong.

I used mcnp4c3 and ENDFB6.8 which were on the KTH Transmutation page for students to use. No longer on the original page a copy of the binary remains on the open internet so this is an option for anyone wanting to use mcnp. I cannot find a copy of the original KTH ENDFB6.8 but other versions, including newer versions do not seem hard to find. 4c3 has been considered obsolete for more than a decade now by RSICC but it's fine for anything I can think of, neutronics (which openmc will also do), X-ray/Gamma shielding (which openmc will not do) etc. It's a capable code (it even simulates (gamma,n) reactions) and is the last (most bug fixed) release of mcnp4. To use it in the late 2000's, I had to patch a malloc call in the binary and do some lib tricks to make it work with a then modern linux. The easiest option now is to run an old linux in a VM. Fedora core 4 VM by thoughtpolice is on sourceforge, runs on free VM players and runs the binary without modification.

A few comments on an otherwise excellent start to the FAQ,
The instructions for installing OpenMC are already out of date. The instructions now are to download preprocessed libraries. They seem to make it less MCNP like with every change. Older versions just used ACE files directly, in February even the scripts for processing ACE files into the new format were removed. I'm currently using an old version, v0.7.1.

"There is clearly a peak region in the ~4-7cm range,"
Apologies if this is wrong, but to me this section reads like you are interpreting this peak as the thermal neutron peak. It's the epithermal (resonance peak) in Carl's graph, the thermal peak is around 9 or 10cm.

"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."
Following on from the last point, your geometry has the center of detector to source distance (~14cm) comparable with the optimum for moderation (~10cm). The last few cm significantly increase the angle of the source that interact with the moderator. That (IMHO) is why there is no thermal peak. I've done moderator only (no load) simulations with a 40cm distance, and even with a 20cm distance there is a peak.

User avatar
Liam David
Posts: 146
Joined: Sat Jan 25, 2014 10:30 pm
Real name: Liam David
Location: Arizona

Re: FAQ - Neutron Transport Simulation, Detector Calibration, and Shielding

Post by Liam David » Sat Sep 07, 2019 8:20 pm

Alex, you are absolutely correct in the thermal peak being around 9-10cm. My mistake in reading the graph. If I had editing rights it would be fixed.

I did attempt to follow the latest instructions regarding the cross-section data but for reasons unknown the commands failed. In step 4 I did include "Alternatively, if you can get it to work, just run 'openmc-get-nndc-data' and the xml files will appear" but if that is not what you mean then please let me know. I looked over the install instructions just now and do not see any differences from when I first installed OpenMC (~3 months ago). It was errors likely on my end that resulted in the convoluted install instructions. As I write this I am redoing the installation in an attempt to get a version working without having to manually installing everything. We will see how that goes.

[edit/]
I have reinstalled conda-forge and have successfully run "openmc-get-nndc-data" to obtain all required nuclide cross-section data and generate the cross_sections.xml file. There are still a few errors with my geometry, tallies, etc. generator code as some things seem to have changed since, but the examples run successfully. I will be doing more simulations soon.
[/]

Keeping the front of the moderator at constant distance while increasing its radius does increase the angle across which neutrons can interact. The peak occurs when that increase in solid angle is outpaced by the 1/r^2 of the tube moving farther away. After all, the solid angle approaches 2π as the inverse square distance goes to 0. If the tube is at a constant distance the thermal fluence will only increase with thickness. Here is some math to demonstrate my reasoning:

The solid angle subtended by a rectangular pyramid with its apex at the origin is:
Image

Let β = L, the length of the tube; α = 2r, where r is the moderator radius; d = r + d0, where d0 is the moderator-grid distance. I am essentially finding the solid angle of the detector tube midplane that is perpendicular to the tube-grid vector. While not a perfect measure (the pyramid boundary planes would be tangent to the moderator and never make it to the midplane), it is good enough to illustrate the point. We can now define some quantity, say E, that incorporates the solid angle and the inverse square law like so:
Image

This equation represents the trade-off between incident neutron fluence on the moderator to the distance of the tube. We don't care about any proportionality constants but are interested in the overall shape of the graph. Making the aforementioned substitutions and ignoring scaling, the factor becomes:
Image

When plotting E vs. r, we get something very, very similar to what Carl simulated:
Image

If I remove the changing distance and allow only the moderator thickness to increase, the equation becomes:
Image

The graph is:
Image

which is an increasing function of r but horizontally asymptotic due to Ω->2π. I don't know why the simulated result is concave up while this graph is concave down, but it's clearly something worth investigating. Perhaps it has to do with the increasing range of angles at which neutrons can first interact with the moderator, but that's just a vague guess. There could be a turning point in the simulated results above where I collected data, or I could have made a programming error. Either way, the thicker the moderator for a given distance the better, up until the moderator would have to extend inside your chamber...

Correct me if I'm wrong, but I think we are saying the same thing. Thanks for the advice though! Perhaps an admin will allow me to edit the original post and move this thread into the FAQ section...?

User avatar
Richard Hull
Moderator
Posts: 11409
Joined: Fri Jun 15, 2001 1:44 pm
Real name: Richard Hull

Re: FAQ - Neutron Transport Simulation, Detector Calibration, and Shielding

Post by Richard Hull » Sun Sep 08, 2019 6:51 am

This entire thread should have been started as a FAQ from the get go!! I am not the commander of the FAQ! Anyone here can construct a FAQ! I have for years exhorted others of some stature and knowledge to make up their own FAQs if they see a need for same. Alas, to no avail. Why so many here demur from adding to our knowledge via FAQ creation here, when they feel the need, amazes me.

Before doing a FAQ ask yourself. Does what I am about to impart have a real need related to the particular forum in which it is posted ? Will it make all folks here wiser for having been made a FAQ?
All FAQ titles should begin in the standard format....FAQ - Your subject title.... Dwell on the title and make it searchable with key words as part of it.

Needless to say, do not post a FAQ to the forum, but to the FAQ group related to the forum.

I cannot change this thread to a FAQ or move it. It is an admin thing. I am the garbage man with the power of full deletion and across the board editing of any post. I hope Frank or Andrew reads this and can help out.

Richard Hull
Progress may have been a good thing once, but it just went on too long. - Yogi Berra
Fusion is the energy of the future....and it always will be
Retired now...Doing only what I want and not what I should...every day is a saturday.

User avatar
Liam David
Posts: 146
Joined: Sat Jan 25, 2014 10:30 pm
Real name: Liam David
Location: Arizona

Re: FAQ - Neutron Transport Simulation, Detector Calibration, and Shielding

Post by Liam David » Sun Sep 08, 2019 3:03 pm

Richard, I cannot create a post in the FAQ sections. The button is not there. If I could I would have done so.

User avatar
Frank Sanns
Site Admin
Posts: 1599
Joined: Fri Jun 14, 2002 6:26 pm
Real name: Frank Sanns
Location: Pittsburgh, PA USA

Re: FAQ - Neutron Transport Simulation, Detector Calibration, and Shielding

Post by Frank Sanns » Sun Sep 08, 2019 7:11 pm

I have relocated it to the FAQ section. All should be good now.

Post Reply