Previously very little thought was put into my detector designs. I did what was easy - linearly repeated structures in the simulation because that is what the lattice cards in MCNP are capable of. However, to add a little "flair" to my thesis I went and actually optimized the RPM8 geometry with a genetic algorithm. The basis premis is simple; as the neutrons go through the detector they will be moderated by collisions within the moderator. Slower (neutron with less energy) have a higher probability of being captured. You would then want to build the slow neutron up with a moderator, then wipe them out with a detector layer, build 'em up again, and so forth. The optimization problem is what thickness of moderator, detector, moderator, detector, etc is necessary to have the count rate while still maintaining the detector criteria.
The moderator - detector dichotomy suggest a geometry that can be concisely represented as bit strings (which is why I decided to use a GA). These bit string (representing a geometry and therefore a fitness function of the count rate per mass absorber) can then be evolved toward an optimal solution; the highest count rate per mass absorber while still meeting the criteria. Using the count rate per mass absorber has the benefit of penalizing detectors designs with too much absorber, but doesn't ensure that the minimum mass of absorber to achieve the count rate is used. (It's the most bang for your buck, but there might be a product that cost fifty cents. Make senses?*)
Anyway, the width of the detector is fixed, but the granularity of the search can be determined by the number of bits in a genome (generic solution to a GA). I used the PyEvolve toolkit, writing a bunch of python scripts to create and input deck for MCNPX and submit to the cluster queue. The first image is the rendering (by material) of the optimal detector for a 10 length genome, and the next is for a 26 length genome.
 |
| Optimal Geometry for a 10 length genome |
 |
| Optimal Geometry for a 26 length genome |
Further improvements will be to move away from MCNPX to use a deterministic transport code (probably XSDRN**). This will help speed up performance as MCNPX takes about 1.73 minutes on 16 cores, though interestingly enough the computational time decrease to 1.71 minutres for the more complex geometries. This would make it easy to do different film types without too much trouble.
*Sorry. Not really.
**The old programers had a sense of humor and named some transport codes after pills. And then Battlestar Galatica came out, so most of the modules in SCALE then have names from BSG.
 |
| Vaseline? |
No comments:
Post a Comment