Serpent Manual
User Manual:
Open the PDF directly: View PDF .
Page Count: 164
Download | |
Open PDF In Browser | View PDF |
Serpent – a Continuous-energy Monte Carlo Reactor Physics Burnup Calculation Code June 18, 2015 User’s Manual Jaakko Leppänen Preface This documentation is a User’s Manual for the Serpent continuous-energy Monte Carlo reactor physics burnup calculation code.1 Code development started at the VTT Technical Research Centre of Finland in 2004, under the working title “Probabilistic Scattering Game”, or PSG. This name is used in all publications dated before the pre-release of Serpent 1.0.0 in October 2008. The name was changed to due to the various ambiguities related to the acronym. The code is still under development and this manual covers only the main functionality available in June 18. The official Serpent website is found at http://montecarlo.vtt.fi. Support and minor updates in the source code are currently handled via the Serpent mailing list, in which all users are encouraged to join by sending e-mail to: Jaakko.Leppanen@vtt.fi. Any feedback is appreciated, including comments, bug reports, interesting results and ideas and suggestions for future development. A discussion forum for Serpent users is found at http://ttuki.vtt.fi/serpent. For a quick start, experienced Monte Carlo code users are instructed to view the lattice input examples in Chapter 11 starting on page 133. 1 For referencing the code, use either the website: “http://montecarlo.vtt.fi” or this report: “J. Leppänen. Serpent – a Continuous-energy Monte Carlo Reactor Physics Burnup Calculation Code. VTT Technical Research Centre of Finland. (June 18, 2015)” 2 Contents Preface 2 1 Installing and Running Serpent 8 1.1 Compiling Serpent . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 8 1.2 Running the Code . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 9 1.3 Parallel Calculation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 10 1.4 Nuclear Data . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 11 1.4.1 Data Types . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 11 1.4.2 Directory File . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 12 1.4.3 Radioactive Decay and Fission Yield Data . . . . . . . . . . . . . . 13 2 Input 15 2.1 General . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 15 2.2 Input format . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 15 2.2.1 Input cards . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 15 2.2.2 Comment lines and sections . . . . . . . . . . . . . . . . . . . . . 16 2.2.3 Dividing the input into several files . . . . . . . . . . . . . . . . . . 16 2.2.4 Input errors . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 17 Units . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 18 2.3 3 Geometry 19 3.1 The Universe-based Geometry Model in Serpent . . . . . . . . . . . . . . . 19 3.2 Surface Definitions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 19 3.2.1 Surface types . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 20 3.2.2 Positive and negative surface sides . . . . . . . . . . . . . . . . . . 21 3.2.3 Surface examples . . . . . . . . . . . . . . . . . . . . . . . . . . . 22 Cell Definitions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 24 3.3 3 CONTENTS 4 3.3.1 Cell types . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 24 3.3.2 Cell examples . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 25 3.4 Fuel pin definitions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 27 3.5 Nests . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 27 3.6 Universes and Lattices . . . . . . . . . . . . . . . . . . . . . . . . . . . . 28 3.6.1 Universe transformations and rotations . . . . . . . . . . . . . . . . 28 3.6.2 Lattices . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 29 3.6.3 Universe and lattice examples . . . . . . . . . . . . . . . . . . . . 32 3.7 Repeated Boundary Conditions . . . . . . . . . . . . . . . . . . . . . . . . 36 3.8 HTGR geometry types . . . . . . . . . . . . . . . . . . . . . . . . . . . . 39 3.8.1 Implicit particle fuel model . . . . . . . . . . . . . . . . . . . . . . 39 3.8.2 Explicit particle / pebble bed fuel model . . . . . . . . . . . . . . . 40 3.8.3 HTGR geometry examples . . . . . . . . . . . . . . . . . . . . . . 41 Geometry plotter . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 42 3.9 4 Materials 4.1 47 Material definitions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 47 4.1.1 Nuclides . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 47 4.1.2 Material cards . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 48 4.2 Thermal scattering libraries . . . . . . . . . . . . . . . . . . . . . . . . . . 49 4.3 Doppler broadening . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 50 4.4 Material examples . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 50 5 Options 53 5.1 General . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 53 5.2 Neutron Population and Criticality Cycles . . . . . . . . . . . . . . . . . . 53 5.3 Energy grid reconstruction . . . . . . . . . . . . . . . . . . . . . . . . . . 55 5.4 Library File Paths . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 57 5.5 Unresolved resonance data . . . . . . . . . . . . . . . . . . . . . . . . . . 57 5.6 Doppler-Broadening Rejection Correction (DBRC) . . . . . . . . . . . . . 59 5.7 Boundary conditions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 59 5.8 Source rate normalization . . . . . . . . . . . . . . . . . . . . . . . . . . . 61 5.9 Group constant generation . . . . . . . . . . . . . . . . . . . . . . . . . . 64 CONTENTS 5 5.10 Full-core power distributions . . . . . . . . . . . . . . . . . . . . . . . . . 66 5.11 Delta-tracking options . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 66 5.12 Cross section data plotter . . . . . . . . . . . . . . . . . . . . . . . . . . . 68 5.13 Fission source entropy . . . . . . . . . . . . . . . . . . . . . . . . . . . . 68 5.14 Soluble absorber . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 69 5.15 Iteration . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 70 5.16 Fundamental mode calculation . . . . . . . . . . . . . . . . . . . . . . . . 71 5.17 Equilibrium xenon calculation . . . . . . . . . . . . . . . . . . . . . . . . 72 5.18 Miscellaneous parameters . . . . . . . . . . . . . . . . . . . . . . . . . . . 73 6 Output 77 6.1 Main output file . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 77 6.1.1 Version, title and date . . . . . . . . . . . . . . . . . . . . . . . . . 78 6.1.2 Run parameters . . . . . . . . . . . . . . . . . . . . . . . . . . . . 78 6.1.3 File paths . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 79 6.1.4 Delta-tracking parameters . . . . . . . . . . . . . . . . . . . . . . 79 6.1.5 Run statistics . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 80 6.1.6 Energy grid parameters . . . . . . . . . . . . . . . . . . . . . . . . 80 6.1.7 Unresolved resonance data . . . . . . . . . . . . . . . . . . . . . . 81 6.1.8 Nuclides and reaction channels . . . . . . . . . . . . . . . . . . . . 81 6.1.9 Reaction mode counters . . . . . . . . . . . . . . . . . . . . . . . 82 6.1.10 Slowing-down and thermalization . . . . . . . . . . . . . . . . . . 82 6.1.11 Parameters for burnup calculation . . . . . . . . . . . . . . . . . . 83 6.1.12 Fission source entropies . . . . . . . . . . . . . . . . . . . . . . . 83 6.1.13 Fission source center . . . . . . . . . . . . . . . . . . . . . . . . . 84 6.1.14 Soluble absorber . . . . . . . . . . . . . . . . . . . . . . . . . . . 84 6.1.15 Iteration . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 84 6.1.16 Equilibrium Xe-135 calculation . . . . . . . . . . . . . . . . . . . 84 6.1.17 Criticality eigenvalues . . . . . . . . . . . . . . . . . . . . . . . . 85 6.1.18 Normalization . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 86 6.1.19 Point-kinetic parameters . . . . . . . . . . . . . . . . . . . . . . . 87 6.1.20 Six-factor formula . . . . . . . . . . . . . . . . . . . . . . . . . . 87 CONTENTS 6.2 6 6.1.21 Delayed neutron parameters . . . . . . . . . . . . . . . . . . . . . 87 6.1.22 Parameters for group constant generation . . . . . . . . . . . . . . 88 6.1.23 Few-group cross sections . . . . . . . . . . . . . . . . . . . . . . . 88 6.1.24 Fission product poison cross sections . . . . . . . . . . . . . . . . . 89 6.1.25 Fission spectra . . . . . . . . . . . . . . . . . . . . . . . . . . . . 90 6.1.26 Group-transfer probabilities and cross sections . . . . . . . . . . . 90 6.1.27 Diffusion parameters . . . . . . . . . . . . . . . . . . . . . . . . . 90 6.1.28 Pn scattering cross sections . . . . . . . . . . . . . . . . . . . . . . 91 6.1.29 P1 diffusion parameters . . . . . . . . . . . . . . . . . . . . . . . . 91 6.1.30 B1 fundamental mode calculation . . . . . . . . . . . . . . . . . . 92 6.1.31 Assembly discontinuity factors . . . . . . . . . . . . . . . . . . . . 93 6.1.32 Power distributions in lattices . . . . . . . . . . . . . . . . . . . . . 93 History output . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 94 7 Detectors 7.1 95 Detector Input . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 95 7.1.1 Setting the Response Function . . . . . . . . . . . . . . . . . . . . 96 7.1.2 Setting the Energy Domain . . . . . . . . . . . . . . . . . . . . . . 99 7.1.3 Setting the Spatial Domain . . . . . . . . . . . . . . . . . . . . . . 101 7.1.4 Surface Current Detectors . . . . . . . . . . . . . . . . . . . . . . 104 7.2 Detector output . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 105 7.3 Detectors in Burnup Calculation . . . . . . . . . . . . . . . . . . . . . . . 107 8 Burnup calculation 108 8.1 General . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 108 8.2 Depleted materials . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 109 8.3 Irradiation history . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 110 8.4 Options for Burnup Calculation . . . . . . . . . . . . . . . . . . . . . . . . 111 8.4.1 Library File Paths . . . . . . . . . . . . . . . . . . . . . . . . . . . 111 8.4.2 Normalization . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 112 8.4.3 Solution of Depletion Equations . . . . . . . . . . . . . . . . . . . 113 8.4.4 Calculation of Transmutation Cross Sections . . . . . . . . . . . . 113 CONTENTS 7 8.4.5 Cut-offs . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 114 8.4.6 Nuclide Inventory . . . . . . . . . . . . . . . . . . . . . . . . . . . 114 8.4.7 Additional Output . . . . . . . . . . . . . . . . . . . . . . . . . . . 115 8.4.8 Decay heat production in multiple precursor groups . . . . . . . . . 115 8.5 Output in independent mode . . . . . . . . . . . . . . . . . . . . . . . . . 116 8.6 Output in coupled mode . . . . . . . . . . . . . . . . . . . . . . . . . . . . 117 8.7 Burnup calculation examples . . . . . . . . . . . . . . . . . . . . . . . . . 117 8.7.1 Material and lattice examples . . . . . . . . . . . . . . . . . . . . . 117 8.7.2 Irradiation history examples . . . . . . . . . . . . . . . . . . . . . 121 9 External Source Mode 125 9.1 General . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 125 9.2 Source definition . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 126 9.2.1 Setting the Spatial Distribution . . . . . . . . . . . . . . . . . . . . 126 9.2.2 Setting the Directional Distribution . . . . . . . . . . . . . . . . . . 128 9.2.3 Setting the Energy Distribution . . . . . . . . . . . . . . . . . . . . 128 9.2.4 Source files . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 129 Source Examples . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 129 9.3 10 Reaction rate mesh plotter 131 10.1 Mesh input . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 131 10.2 Mesh output . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 132 11 Complete Input Examples 133 11.1 Quick start . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 133 11.1.1 VVER-440 lattice calculation . . . . . . . . . . . . . . . . . . . . . 134 11.1.2 BWR lattice calculation . . . . . . . . . . . . . . . . . . . . . . . . 137 11.1.3 CANDU lattice calculation . . . . . . . . . . . . . . . . . . . . . . 142 11.1.4 Mixed UOX/MOX PWR lattice calculation . . . . . . . . . . . . . 145 11.2 Burnup calculation examples . . . . . . . . . . . . . . . . . . . . . . . . . 150 11.2.1 Pin-cell burnup calculation . . . . . . . . . . . . . . . . . . . . . . 150 11.2.2 PWR assembly burnup calculation . . . . . . . . . . . . . . . . . . 153 Bibliography 162 Chapter 1 Installing and Running Serpent 1.1 Compiling Serpent The Serpent code is written in standard ANSI-C language. The code is mainly developed in the Linux operating system, but it has also been compiled and tested in MAC OS X and some UNIX machines.1 The Monte Carlo method is a computing-intensive calculation technique and raw computing power has a direct impact on the overall calculation time. It should be taken into account that the unionized energy grid format used in Serpent requires more computer memory compared to other continuous-energy Monte Carlo codes. One gigabyte of RAM should be sufficient for steady-state calculations, but a minimum of 3 Gb is recommended for burnup calculation. The source code is compiled simply by running the GNU Make utility.2 The Makefile provides for detailed instructions and various options for different platforms. Serpent uses the GD open source graphics library [1] for producing some graphical output. If this library is not installed in the system, the source code must be compiled with the “NO_GFX_MODE” option. The compilation should not result in any errors or warning messages and it should produce an executable named “sss”. Any problems in installation should be reported by e-mail to: Jaakko.Leppanen@vtt.fi. Code updates are provided to registered users by distributing the updated source files by e-mail. New files replace old ones and the code must be re-compiled for the changes to take effect. 1 The main platforms in PSG/Serpent development have been a 2.6 GHz dual-core AMD Opteron PC with 5 Gb RAM running Fedora Core 4 and an iBook G4 with 1.2 GHz PowerPC processor and 768 Mb RAM running OS X v10.4. 2 For a detailed description of Makefiles, see: http://www.gnu.org/software/make. 8 1.2 Running the Code 1.2 9 Running the Code All interaction between the code and the user is handled through one or several input files and various output files, as described in the following chapters. The code is run from the command line interface. The general syntax is: sss[ ] where is the name of the main input file are the options The input file is a standard text file containing the input description. The input can also be divided into several files which are referred to in the main file. The available options are: print version information and exit run the simulation using random number seed from previous calculation -plot terminate run after geometry plot -testgeom test the geometry using randomly sampled neutron tracks -checkvolumes calculate Monte Carlo estimates for material volumes by sampling random points -mpi run simulation in parallel mode (see Sec. 1.3) -disperse generate random particle or pebble distribution files for HTGR calculations -version -replay The replay option forces the code to use the same random number seed as in a previous run. Without this option, the seed is taken from system time and written in a separate seed file (named .seed) for later use. The seed can also be set manually in the input using the “set seed” option.3 The geometry test option can be used for debugging the geometry in addition to the geometry plotter. The code randomly samples neutron tracks across the geometry and checks that the cells are correctly defined. Some input errors can spotted using this option. The volume checking option can be used to verify that the volumes used in the calculation are correct. The code is able to calculate cell volumes for simple lattice geometries, but some more complicated geometry types require the values to be set by the user. The volumes 3 The results of a Monte Carlo calculation depend on the sequence of pseudo random numbers used during the simulation. This sequence is fixed by the random number seed and the calculation can be repeated using the same seed. The capability to reproduce the same simulation is important, for example, for debugging purposes. Some codes, such as MCNP [2], use a fixed seed value, which results in the same results every time the code is run. The Serpent code uses by default a different seed for each run and hence the results are different as well. This behavior can be overridden by the replay command line option or by setting the seed manually in the input file. 1.3 Parallel Calculation 10 are used for normalizing reaction rates for detectors and burnup calculation. The number of random points should be large (at least 1,000,000) for good statistical accuracy. The random particle / pebble distribution generator works by prompting the user information on the volume type and dimensions, particle data and packing fractions. The code then generates a distribution inside the desired volume without overlapping any particles. The data is written in a file using format that can be directly read into the explicit HTGR geometry model (See Sec. 3.8.2 on page 40). The option is available from code version 1.1.5 on. IMPORTANT NOTES ON RUNNING THE CODE: 1. The seed file is overwritten by a new value each time the code is run without the replay option and the old seed is lost. SEE ALSO: 1. Dividing the input into several files (Sec.2.2.3 on page 16) 2. Setting the random number seed manually (Sec. 5.18 on page 73) 3. Geometry plotter (Sec. 3.9 on page 42) 4. Setting material volumes manually (Sec. 4.1.2 on page 49) 1.3 Parallel Calculation Serpent uses the Message Passing Interface (MPI) [3] for parallel calculation. To activate this capability the code must be compiled with the “PARALLEL_MPI” option (see the Makefile for details) and the MPI libraries must be installed on the system. There are two options for running the code in the parallel calculation mode. The first option is to use the standard MPI tools, such as mpirun: [user@host mpitest]$ mpirun -np 10 sss input This command executes the calculation in 10 hosts as defined in the parallel environment. The second option is to use the built-in MPI runner and define the number of tasks in the command line: [user@host mpitest]$ sss -mpi 10 input In this calculation mode, the code attempts to run mpirun on its own. This may require small modifications in the source code or may not work at all in some systems. The file path for mpirun is defined by the “MPIRUN_PATH” precompiler variable in the “header.h” source file. 1.4 Nuclear Data 11 IMPORTANT NOTES ON PARALLEL CALCULATION: 1. Parallel calculation is available from version 1.0.3 on. 2. When multiple tasks are sharing the same memory space, the size of allocated memory is also multiplied. This should be taken into account when setting the memory size in the compilation. 3. The methodology is still under development. The calculation lacks error tolerance and load sharing and the mode should be used only in systems consisting of identical hosts. Most of the MPI routines were directly adopted from PSG and features exclusively available in Serpent (including burnup calculation) are not thoroughly tested. SEE ALSO: 1. The MPI standard: http://www-unix.mcs.anl.gov/mpi/ 2. The mpirun script: http://www-unix.mcs.anl.gov/mpi/www/www1/mpirun.html 1.4 Nuclear Data The Serpent code reads continuous-energy interaction data from ACE format cross section libraries. The current installation package contains libraries based on JEF-2.2, JEFF-3.1, ENDF/B-VI.8 and ENDF/B-VII evaluated data files. Since the data format is shared with MCNP, alternative data for various isotopes should be readily available to most users. There are also several ACE format data libraries based on different evaluations publicly available through the OECD/NEA Data Bank [4]. New libraries can be produced from raw ENDF format data using the NJOY nuclear data processing system [5]. 1.4.1 Data Types Three types of cross sections are available in the data files. Continuous-energy neutron cross sections (type 1) are used for the actual transport simulation. The data contains all necessary reaction cross sections, together with energy and angular distributions, fission neutron yields and delayed neutron parameters. The second data type is the dosimetry cross section (type 2). Dosimetry cross sections exist for a large variety of materials and may include derived reaction modes not commonly encountered in transport calculation. The data may consist of one or several partial cross sections, but all energy and angular distributions are omitted. The data can be used with detectors but not in physical materials included in the transport calculation. 1.4 Nuclear Data 12 Thermal scattering cross sections (type 3) are used to replace the low-energy free-gas elastic scattering reactions for some important bound moderator nuclides, such as hydrogen in water or carbon in graphite. Thermal systems cannot be modelled using free-atom cross sections without introducing significant errors in the spectrum and the results. 1.4.2 Directory File The cross section data is accessed by using a separate directory file, which differs from the “xsdir” file commonly used with ACE format data. A conversion between the two formats can be made by running the “xsdirconvert” utility script, included in the installation package: [user@host xsdata]$ xsdirconvert.pl data.xsdir >> data.xsdata The Serpent directory file contains the data necessary for the code for locating the cross section libraries and forming the material compositions. Each line in the directory file has the following format: where is the name identifying the nuclide in the input file is the actual nuclide name in the data is the type of the data is the isotope identifier (1000*Z + A) is the isomeric state number (0 = ground state) is the atomic weight is the nuclide temperature (in K) is the binary format flag (0 = ASCII, 1 = binary) is the data path for the library EXAMPLES: 1001.06c H-1.06c 8016.06c O-16.06c 40000.06c Zr-nat.06c 92235.09c U-235.09c 92238.09c U-238.09c 95342.09c Am-242m.09c lwtr.03t Np-237.30y 1001.06c 1001.06c 8016.06c 8016.06c 40000.06c 40000.06c 92235.09c 92235.09c 92238.09c 92238.09c 95342.09c 95342.09c lwtr.03t 93237.30y 1 1 1 1 1 1 1 1 1 1 1 1 3 2 1001 1001 8016 8016 40000 40000 92235 92235 92238 92238 95242 95242 0 93237 0 0 0 0 0 0 0 0 0 0 1 1 0 0 1.00783 1.00783 15.99492 15.99492 91.21963 91.21963 235.04415 235.04415 238.05078 238.05078 242.05942 242.05942 0.00000 239.10201 600.0 600.0 600.0 600.0 600.0 600.0 900.0 900.0 900.0 900.0 900.0 900.0 0.0 0.0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 /xs/1001_06.ace /xs/1001_06.ace /xs/8016_06.ace /xs/8016_06.ace /xs/40000_06.ace /xs/40000_06.ace /xs/92235_09.ace /xs/92235_09.ace /xs/92238_09.ace /xs/92238_09.ace /xs/95342_09.ace /xs/95342_09.ace /xs/tmccs1 /xs/llldos1 1.4 Nuclear Data 93237.30y 93237.30y 2 93237 0 239.10201 13 0.0 0 /xs/llldos1 The alias is the nuclide name used in the input file and it may or may not be the same as the actual isotope name. The xsdirconvert tool writes two entries for each nuclide, one using the original name and another one using the element symbol and the isotope number. The data types are: 1 = continuous-energy, 2 = ACE dosimetry. 3 = thermal scattering, The temperature entry is used with transport data only and the atomic mass with transport and dosimetry cross sections. Isomeric states are identified from the state number4 (see Am-242m in the example). There is no standard convention on how to name these isotopes in the ACE format data, but the xsdirconvert-tool assumes that the mass number of isomeric state nuclides is increased above 300. If another convention is used, the state number must be set manually in the directory file. It is recommended that the isomeric state entries are always carefully checked after running xsdirconvert. 1.4.3 Radioactive Decay and Fission Yield Data Radioactive decay and fission yield data is needed for running the Serpent code in the independent burnup calculation mode. It is recommended that the libraries are included in the coupled mode as well, since it enables the data to be reproduced in the output file, making it directly available to the coupled calculation. The decay constants and fission product distributions are read from standardized ENDF format data files [6]. The format is directly accessible and the data requires no preprocessing. JEF-2.2, JEFF-3.1, ENDF/B-VI.8 and ENDF/B-VII data libraries are included in the installation package. More data can be downloaded from various Internet sources: – OECD/NEA Data Bank: http://www.nea.fr/html/dbdata/ – Los Alamos T2 Nuclear Information Service: http://t2.lanl.gov – US National Nuclear Data Center: http://www.nndc.bnl.gov – US Radiation Safety Information Computational Center: http://www-rsicc.ornl.gov – IAEA Nuclear Data Centre: http://www-nds.iaea.org – JAEA Nuclear Data Center: http://wwwndc.tokai-sc.jaea.go.jp IMPORTANT NOTES ON INTERACTION DATA: 4 The information on isomeric states is needed for burnup calculation only. All nuclides are treated similarly in the transport simulation. 1.4 Nuclear Data 14 1. The weight in the directory file is given as the atomic weight, not the atomic weight ratio as in MCNP xsdir files. 2. The temperature in the directory file is given in Kelvin, not in MeV as in the MCNP xsdir files. 3. Binary data is not supported in the current code version. 4. The data path in the directory file must refer to the absolute, not the relative location of the library file. 5. The code always uses the first matching entry in the directory file. The use of duplicate isotope names may lead to unexpected results. SEE ALSO: 1. Setting up the file paths (Sec.5.4 on page 57) 2. Material definitions (Chapter 4 on page 47) Chapter 2 Input 2.1 General The Serpent code has no interactive user interface. All communication between the code and the user is handled through one or several input files and various output files discussed in Chapter 6. User-defined detectors are discussed as a separate item in Chapter 7 and burnup calculation in Chapter 8. 2.2 Input format The format of the input file is unrestricted. The file consists of white-space (space, tab or newline) separated words, containing alphanumeric characters(’a-z’, ’A-Z’, ’0-9’, ’.’, ’-’). If special characters or white spaces need to be used within the word (file names, etc.), the entire string must be enclosed within quotation marks. 2.2.1 Input cards The input file is divided into separate data blocks, denoted as cards. The file is processed one card at a time and there are no restrictions in what order the cards should be organized. The input cards are listed in Table 2.1 and detailed descriptions are provided in the following chapters. All input cards and special command words are case-insensitive. Each input card is delimited by the beginning of the next card. It is hence important that none of the parameter strings used within the card coincide with the card identifiers in Table 2.1. 15 2.2 Input format 16 Table 2.1: List of commands and input cards Card cell dep det disp ene include lat mat mesh nest particle pbed pin plot set src surf therm trans 2.2.2 Description cell definition irradiation history detector definition implicit HTGR particle fuel model detector energy binning read a new input file lattice definition material definition reaction rate mesh plotter nest definition particle definition explicit HTGR particle / pebble bed fuel model pin definition geometry plotter misc. parameter definition external source definition surface definition thermal scattering data definition universe transformation Chapter / Section 3.3 8.3 7.1 3.8.1 7.1.2 2.2.3 3.6.2 4.1.2 10.1 3.5 3.8 3.8.2 3.4 3.9 5.1 9.2 3.2 4.2 3.6.1 Page 24 110 95 39 99 16 30 48 131 27 39 40 27 42 53 126 20 49 29 Comment lines and sections The Serpent code provides two types of comments for the input files. The percent-sign (%) or hash (#) are used to define a comment line. Anything from this character to the end of the line is omitted when the input file is read. The alternative is to use C-style comment sections beginning with “/*” and ending with “*/”. Everything within these delimiters is omitted, regardless of the number of newlines or special characters between them. 2.2.3 Dividing the input into several files Complicated input descriptions can be simplified by dividing the cards into separate files. This capability may also be useful if different calculation cases share some partial data. Additional input files are recursively read from the main file using the include-command: include " " where is the file path for the input file When this command is encountered, the program will first read the included file before 2.2 Input format 17 continuing with the main file. The number of nested input files is unrestricted. Since file names and paths often include non-alphanumeric characters, it is good practice to always enclose the strings within quotation marks. 2.2.4 Input errors The Serpent code performs some error checking on the input file before proceeding with the calculation. These checks include: – Checking that there are an even number of quotation marks. – Checking the correct number of parameters for some input cards. – Checking the type (string, integer, real) of some parameters. – Checking that the values of some parameters are within a reasonable range. – Checking that all cards that are referred to in other cards are defined. – Checking that all referred files exist. – Checking that the input contains sufficient data for running the simulation. – Various checks related to specific input cards. Failure in any of the checks results in an error message and the termination of the calculation. Most common input errors are caused by missing parameters or mistyped command words. In the former case, the result is often an error message related to parameter type or number. The program does not recognize card names with typing errors, but rather processes the entire card as if was a set of parameters belonging to the previous card. Such errors may stop the calculation later on for entirely different reasons, or in the worst case, run the simulation with a set of parameters totally different from what the user intended. In case of any unexpected behavior, the typing of the card names should the first thing to be checked. IMPORTANT NOTES ON INPUT FORMAT: 1. The input file consists of white-space separated words containing alphanumeric characters. If special characters or white spaces need to be used (file names, etc.), the entire string must be enclosed within quotation marks. 2. Each card is delimited by the beginning of the next card and it is hence important that the card names are not used in for other purposes, for example as cell or material names. If the name of an input card is spelled incorrectly, the previous card is not delimited, which may result in a completely unexpected behavior. 2.3 Units 18 3. Running the Serpent code should never result in crash or termination without an error message. In such case, please report the problem by e-mail to Jaakko.Leppanen@vtt.fi. 2.3 Units Table 2.2 summaries the most essential units used in the code. Table 2.2: Units used in the Serpent code. Quantity Distance Area Volume Time Energy Microscopic cross section Macroscopic cross section Mass Mass density Atomic density Power Power density Neutron flux Reaction rate Burnup Burn time Unit cm cm2 cm3 s MeV b 1/cm g g/cm3 1024 /cm3 W kW/g 1/cm2 s 1/cm3 s MWd/kgU days Notes (depends on the case) (barn = 10−24 cm2 ) ( = 1/barn×cm) (reaction rate density) (per total initial heavy metal) IMPORTANT NOTES ON UNITS: 1. Power, neutron flux, reaction rate and all related quantities depend on how the neutron source rate is normalized. SEE ALSO: 1. Source rate normalization (Sec. 5.8 on page 61) Chapter 3 Geometry 3.1 The Universe-based Geometry Model in Serpent The Serpent code uses a universe-based geometry model for describing complicated structures, very similar to MCNP. This means that the geometry is divided into separate levels, which are all constructed independently and nested one inside the other. This approach allows the complexity of the geometry to be divided into smaller parts, which are much easier to handle. It also enables the use of regular geometry structures, such as square and hexagonal lattices, commonly encountered in reactor applications. Perhaps the best example of a universe-based geometry construction is the reactor core. At the highest level, the geometry consists of fuel pins, in which the fuel pellets are surrounded by cladding and coolant. Each pin type is described independently in its own universe. The next level is the fuel assembly, in which the pin universes are arranged in a regular lattice. The assembly may also comprise flow channel walls, moderator channels or any support structures. In the next geometry level these assembly universes are arranged in another lattice to form the core layout, which can be surrounded by radial and axial reflectors and finally the reactor pressure vessel wall. The basic building block of the geometry is the cell, which is a region of space determined using simple boundary surfaces. Each cell is filled with a homogeneous material composition, void or another universe. 3.2 Surface Definitions Serpent provides for various elementary and derived surface types for geometry construction. A “derived” surface type refers here to a surface comprised of two or more elementary surfaces, such as a cube constructed of six planes. The input format does not make any dif- 19 3.2 Surface Definitions 20 ference between elementary and derived surfaces and the description below applies to both. The syntax of the surface card is: surf ... where ... is the surface identifier is the surface type (see Table 3.1) are the surface parameters The surface identifier is an arbitrarily chosen number identifying the surface in the cell definitions. Surface types and their use is described in the following subsections. 3.2.1 Surface types The present code version contains 20 surface types, listed in Table 3.1. The number of parameters is fixed and depends on the type. Some surface types have parameters that are optional. For the three types of planes, the x0 , y0 and z0 coordinates refer to distances from the origin. For sphere, cube and the cylindrical surfaces these parameters define the coordinates of the surface center. Sphere, cube and cylinder radii are given by r. The square, hexagonal and cruciform cylinders also include an optional parameter r0 , which defines the radius of rounded corners. If this parameter is omitted, it is assumed that the corners are sharp. The optional parameters z1 and z2 are bottom and top planes of truncated cylinder. The cylindrical surfaces are illustrated in Figure 3.1. The cuboid is defined by the minimum and maximum coordinates in each direction. The hexagonal prismatic surfaces are similar to the corresponding cylinders, with the difference that the enclosed space is limited by bottom and top planes at z1 and z2 . The “pad” is a cylindrical surface type that was included in the code in order to model the neutron pad in the VENUS-2 reactor dosimetry benchmark [7]. The surface is defined as a sector between angles θ1 and θ2 cut out from a layer between cylinders of radii r1 and r2 . The “cone” or “conz” surface type (see Fig. 3.2) is determined by the x0 , y0 and z0 coordinates of the base, the base radius r and the height h. The height of the cone also determines the orientation: a positive value for a cone pointing in positive direction and a negative value for a cone pointing in the negative direction of the z-axis. Cones oriented in the x- and y-axes (“conx” and “cony”, respectively) are defined in a similar manner. The “dode” and “octa” surface types (see Fig. 3.3) are determined by the x0 and y0 coordinates of the central axis and two distances r1 and r2 from the center. If the second value is omitted, the surface is a regular octa- or dodecagonal cylinder. The octagonal cylinder basically consists of two intersecting square and the dodecagonal surface of two intersecting 3.2 Surface Definitions 21 Table 3.1: Surface types in the Serpent code. Type inf px py pz sph cylx cyly cylz or cyl sqc cube cuboid hexxc hexyc hexxprism hexyprism cross pad conx cony conz or cone dode octa plane quadratic Description all space plane perpendicular to x-axis plane perpendicular to y-axis plane perpendicular to z-axis sphere circular cylinder parallel to x-axis circular cylinder parallel to y-axis circular cylinder parallel to z-axis square cylinder parallel to z-axis cube cuboid x-type hexagonal cylinder parallel to z-axis y-type hexagonal cylinder parallel to z-axis x-type hexagonal prism parallel to z-axis y-type hexagonal prism parallel to z-axis cruciform cylinder parallel to z-axis (see description below) cone oriented in the x-axis cone oriented in the y-axis cone oriented in the z-axis dodecagonal cylinder parallel to z-axis octagonal cylinder parallel to z-axis general plane general quadratic surface Parameters x0 y0 z0 x0 , y0 , z 0 , r y0 , z0 , r, x1 , x2 x0 , z0 , r, y1 , y2 x0 , y0 , r, z1 , z2 x0 , y0 , r, r0 x0 , y0 , z 0 , r x1 , x2 , y1 , y2 , z 1 , z 2 x0 , y0 , r, r0 x0 , y0 , r, r0 x0 , y0 , r, z1 , z2 x0 , y0 , r, z1 , z2 x0 , y0 , r, d, r0 x 0 , y 0 , r1 , r2 , θ 1 , θ 2 x0 , y0 , z0 , r, h x0 , y0 , z0 , r, h x0 , y0 , z0 , r, h x 0 , y 0 , r1 , r2 x 0 , y 0 , r1 , r2 A, B, C, D A, B, C, D, E, F, G, H, J, K regular hexagons. The general plane is defined by equation Ax + By + Cz = D This is a simplified case of the general quadratic surface, defined by Ax2 + By 2 + Cz 2 + Dxy + Eyz + F zx + Gx + Hy + Jz + K = 0 3.2.2 Positive and negative surface sides The surfaces are used for defining the geometry cells as will be described in the following section. For this purpose, each surface is associated with a positive side and a negative side. It is defined that a point is inside a surface if it is located on the negative side of the surface. 3.2 Surface Definitions 22 cyl sqc hexxc r0 r r r x0 y0 x0 y0 x0 y0 r d r r1 x0 y0 x0 y0 x0 y0 hexyc cross pad r2 Figure 3.1: Basic cylinder types. The surfaces are infinite in the z-direction. The square cylinder illustrates the definition of rounded corners. h x0 y0 z 0 r cone Figure 3.2: The cone surface. For the three types of planes, the positive side is defined in the direction of the positive coordinate axis. The positive sides of the sphere, cube, cone and the cylindrical surfaces are defined outside the perimeter of the surface. 3.2.3 Surface examples A few simple examples of surface definitions are given in the following. 3.2 Surface Definitions 23 r1 r2 r1 r2 r1 r1 x0 y0 x0 y0 r2 r2 octa dode Figure 3.3: The octagonal and dodecagonal cylinder surfaces. % --- plane perpendicular to x-axis, located at x = 4.0 cm: surf 1 px 4.000 % --- sphere centered at (1.0, 0.0, 2.0), radius 5.0: surf 2 sph 1.000 0.000 2.000 5.000 % --- cylinder centered at origin, radius 10.5 cm: surf 3 cyl 0.000 0.000 10.500 % --- cube at origin with diameter 5.0 cm: surf 4 cube 0.000 0.000 0.000 2.500 % --- square cylinder centered at origin, radius 10.0 cm, % rounded corners with radii 0.2 cm: surf 5 sqc 0.000 0.000 10.000 0.200 % --- x-type hexagonal cylinder centered at (1.0, 0.0), % radius 2.0 cm: surf 6 hexxc 1.000 0.000 2.000 % --- cruciform cylinder centered at origin, radius 20.0 cm, % half-thickness 5.0 cm: surf 7 cross 0.000 0.000 20.000 5.000 % --- neutron pad used in the VENUS-2 benchmark: surf 8 pad 0.000 0.000 11.250 54.750 59.073 65.073 % --- cone at origin, base diameter 2.0 cm, height 5.0 cm surf 9 cone 0.000 0.000 0.000 1.000 5.000 IMPORTANT NOTES ON SURFACES: 3.3 Cell Definitions 24 1. In code versions earlier than 1.1.8 the cone surface type may only be used with the full delta-tracking calculation mode (threshold = 1). 2. Reflective and periodic boundary conditions may only be used in geometries where the outermost boundary is defined by a square or hexagonal cylinder or a cube. 3. The dodecagonal cylinder surface type is available from code version 1.1.4 on. 4. The octagonal cylinder and general plane and quadratic surface are available from code version 1.1.9 on. SEE ALSO: 1. Delta-tracking options (Sec. 5.11 on page 66) 2. Boundary conditions (Sec. 5.7 on page 59) 3.3 Cell Definitions The geometry description in the Serpent code consists of two- or three-dimensional regions, denoted as cells. Each cell is defined using a set of positive and negative surface numbers, which correspond to the surface identifiers defined in the surface cards. Unlike MCNP and other Monte Carlo codes, Serpent can only handle intersections of boundary surfaces. This means that the neutron is inside the cell, if and only if it is on the same side of each boundary surface as given in the surface list (see the examples below). The lack of the union operator restricts the generality of the geometry description to some extent. This limitation is compensated for by providing a large collection of derived surface types, which in most cases can be used to replace the unions of the elementary surfaces. The advantage of this approach is that the geometry description remains relatively simple.1 3.3.1 Cell types The syntax of the cell card is: 1 It is known that the use of derived surface types may slow down the neutron tracking routine in some cases when the conventional ray-tracing algorithm is used. Neutron transport in Serpent, however, is primarily based on the delta-tracking method which is not prone to such limitations. The use of derived surface types reduces the total number of surfaces, which may actually speed up the delta-tracking routine in complicated geometries. 3.3 Cell Definitions 25 cell ... where ... is the cell name is the universe number of the cell is the cell material are the boundary surfaces The cell name is a text string that identifies the cell.2 Each cell belongs to a universe, which is determined by the universe number (lattices and universes are thoroughly described in Section 3.6 on page 28). Cell material determines the name of the material that fills the cell (see Chapter 4 for material definitions). There are three exceptions: 1. If the cell is empty, the material name is set to “void”. 2. If the cell describes a region of space that is not part a of the geometry, the material name is set to “outside”. 3. If the cell is filled by another universe, the material name is replaced by command “fill” and the number of the filling universe. The “outside” cells are required for filling the regions of space that are not a part of the actual geometry. When the neutron streams to such a region, the history is terminated or boundary conditions are applied. The cell shape is determined by the list of boundary surfaces. Positive entries refer to positive (“outside”) surface sides and negative entries to negative (“inside”) surface sides. The cell is defined as the intersection of all surfaces in the list. 3.3.2 Cell examples A few simple examples of cell definitions are given in the following. % --- two half-planes separated by a plane in the z-axis at 5.0 cm: surf 1 pz cell 1 1 cell 2 1 5.000 water air -1 1 % lower half-plane filled with "water" % upper half-plane filled with "air" % --- solid uranium sphere ("Godiva") of radius 8.7407 cm: 2 When the number of cells in the geometry is large, it is often easier to replace cell names with numerical constants. This is possible since the code treats cell numbers as any other text strings. This convention is followed in most example cases in this manual. 3.3 Cell Definitions surf 1 sph cell 1 0 cell 2 0 0.0 26 0.0 uranium outside 0.0 -1 1 8.7407 % uranium inside sphere % outside world % --- tungsten-reflected plutonium sphere: surf 1 sph surf 2 sph cell 1 0 cell 2 0 cell 3 0 0.0 0.0 0.0 0.0 plutonium tungsten outside 0.0 0.0 -1 1 -2 2 5.0419 9.7409 % plutonium inside surface 1 % tungsten between surfaces 1 and 2 % outside world % --- a segment of LWR fuel rod in water: surf surf surf surf surf 1 2 3 4 5 cyl 0.0 cyl 0.0 cyl 0.0 pz -50.0 pz 50.0 cell cell cell cell cell cell 1 2 3 4 5 6 1 1 1 1 1 1 UO2 void clad water water water 0.0 0.0 0.0 0.40 0.45 0.60 -1 1 -2 2 -3 3 -4 5 4 4 4 4 -5 -5 -5 -5 % % % % % % UO2 fuel inside surface 1 gap between fuel and cladding cladding water outside cladding water below the segment water above the segment IMPORTANT NOTES ON CELLS: 1. Material names “void”, “outside” and “fill” are reserved for empty cells, cells not belonging to the geometry and cells filled by another universe, respectively. 2. Only the intersection operator is available for cell definitions. This means that a point is inside the cell if and only if it is inside (or outside if defined by a negative surface number) all the boundary surfaces in the list. SEE ALSO: 1. Material definitions (Chapter 4 on page 47) 2. Boundary conditions (Sec. 5.7 on page 59) 3.4 Fuel pin definitions 3.4 27 Fuel pin definitions Since Serpent is primarily a lattice physics code, the geometry has a simplified definition for fuel pins consisting of nested annular material layers. The syntax of the pin card is: pin ... where ... ... is the pin identifier (universe number) are the materials are the outer radii of the material regions The fuel pin is not an actual geometry object, but rather a macro that is used to define a pin universe. The material regions and their outer radii are given in ascending and the code constructs the cells using using cylindrical surfaces. If the radius is negative, it is interpreted as layer thickness instead of absolute radius. The universe number is set by the pin identifier. Pin materials can also be other universes, which are defined using the fill command (See filled cells on page 28). Pin definitions are most commonly used with lattices to define fuel assemblies. Examples are given in the following section. IMPORTANT NOTES ON PIN DEFINITIONS: 1. The pin identifier is a universe number, which must not coincide with another universe. 2. The outermost material regions is given without a radius and it fills the rest of the universe. 3. Layer thickness are available from version 1.1.13 on. SEE ALSO: 1. Filled cells (Sec. 3.6 on page 28) 2. Lattice examples (Sec. 3.6.3 on page 32) 3.5 Nests Fuel pin and particle (see Sec. 3.8 on page 39) are special cases of the nest geometry type, defined as: 3.6 Universes and Lattices nest 1> 2> n> where ... ... is the nest identifier (universe number) is the surface type are the materials are the surface parameters Nested objects consist of materials or sub-universes separated by similar surfaces. Nests can be defined using planar (px, py, pz), cylindrical (cyl, sqc, hexxc, hexyc), spherical (sph) or cubical (cube) surface types. In each case the parameters , , ... define the main dimension, all other parameters are set to zero. 3.6 Universes and Lattices As mentioned above, a universe-based geometry allows the geometry to be divided into separate levels. Each universe is defined independently and must cover all space. Regions of space not belonging to the geometry must be defined using “outside” cells. The universes are defined by the cell universe numbers and the geometry is layered by replacing the material name with the fill command: cell fill ... where ... is the cell name is the universe number of the cell is the universe number of the filling universe are the boundary surfaces Each universe has its own origin, which can be shifted using the universe transformation command (see Sec. 3.6.1) The lowest level of the geometry belongs to universe 0, which must always exist. 3.6.1 Universe transformations and rotations Each universe is by default centered at the origin, which may sometimes cause difficulties with filled cells. The origin can be shifted to another location using the universe transformation card: 3.6 Universes and Lattices 29 trans where is the universe number is the x coordinate of the new origin is the y coordinate of the new origin is the z coordinate of the new origin Universe transformations are also convenient, for example, for positioning control rods in a reactor core. Universes filled in a lattice structure are automatically shifted to the appropriate position and transformations are not needed. Universe rotations were implemented in Version 1.1.14. The syntax of the transformation card with rotations has two alternative formats: trans trans ... where is the universe number is the x coordinate of the new origin is the y coordinate of the new origin is the z coordinate of the new origin is the rotation angle around x-axis is the rotation angle around y-axis is the rotation angle around z-axis are the coefficients of a rotation matrix If three values are entered after the coordinates, they are interpreted as rotation angles around the three coordinate axes. If nine values are entered, they form the rotation matrix, which is used to multiply the position and direction vectors when the rotation is applied. The coordinate translation always precedes the rotation. 3.6.2 Lattices Lattices are special universes, filled with a regular structure of other universes. The Serpent code has eight lattice types: square lattice, two hexagonal lattices, the circular cluster array, three infinite 3D lattices filled with a single universe and the vertical stack. Square and hexagonal lattices The syntax of the lattice card for the square and hexagonal lattices is: 3.6 Universes and Lattices 30 lat where
is the universe number of the lattice is the lattice type (= 1, 2 or 3) is the x coordinate of the lattice origin is the y coordinate of the lattice origin is the number of lattice elements in the x-direction is the number of lattice elements in the y-direction is the lattice pitch The lattice card is followed by a list of universe numbers, which determines the layout. The lattice type numbers are: 1. Square lattice 2. X-type hexagonal lattice (unit cell is the x-type hexagonal cylinder, see Fig. 3.1) 3. Y-type hexagonal lattice (unit cell is the y-type hexagonal cylinder, see Fig. 3.1) Each lattice defines a universe, which must be embedded inside a cell using the fill command. If the bounding cell is larger than the lattice, neutrons may stream to undefined lattice positions, which results in a geometry error. This can be avoided by increasing the lattice size by defining additional positions in the periphery (see examples below). Circular cluster array The circular cluster array (lattice type 4) is defined by: lat
where is the universe number of the lattice is the lattice type (= 4) is the x coordinate of the lattice origin is the y coordinate of the lattice origin is the number of rings in the array The lattice card is followed by a list of rings, which are defined by: ... where ... is the number of sectors in ring is the central radius of the ring is the angle of rotation are the universe numbers filling the sectors 3.6 Universes and Lattices 31 The circular array is needed for constructing some cluster-type fuel assemblies, used in CANDU, MAGNOX, AGR and RBMK reactors. The array is also convenient for determining the fuel rod layout in some small research reactors, such as the TRIGA. Infinite 3D lattices The infinite 3D lattices are used to construct repeated structures of identical cells that fill the entire universe. This type of construction can be used, for example, for describing the microscopic fuel particles inside an HTGR fuel pebble or compact. The syntax is: lat where
is the universe number of the lattice is the lattice type (= 6, 7 or 8) is the x coordinate of the lattice origin is the y coordinate of the lattice origin is the lattice pitch is the filler universe Lattice type 6 is a cubical lattice and types 7 and 8 x- and y-type hexagonal prismatic lattices, respectively. Vertical stack Universes can be vertically stacked, one on top of the other, using lattice type 9: lat
where is the universe number of the lattice is the lattice type (= 9) is the x coordinate of the lattice origin is the y coordinate of the lattice origin is the number of axial layers The lattice card is followed by a list of axial layers, which are defined by: where is the axial position (lower boundary of the layer) is the filler universe The z-values must be given in ascending order. Space below the lowest z-value is not defined and the top layer fills the entire space above the highest value. 3.6 Universes and Lattices 32 Cuboidal 3D lattice The cuboidal lattice is a 3D structure composed of cuboids with different dimensions in the x-, y- and z-directions. The syntax is: lat where is the universe number of the lattice is the lattice type (= 11) is the x coordinate of the lattice origin is the y coordinate of the lattice origin is the z coordinate of the lattice origin is the number of lattice elements in the x-direction is the number of lattice elements in the y-direction is the number of lattice elements in the z-direction is the lattice pitch in x-direction is the lattice pitch in y-direction is the lattice pitch in z-direction The lattice card is followed by a list of universes. This lattice type is available from version 1.1.17 on. 3.6.3 Universe and lattice examples The universe and lattice definitions are best described using a few examples. The fist example is a 17×17 PWR MOX fuel assembly containing three types of fuel pins and empty control rod guide tubes (see Figure 3.4 on page 45). % --- MOX pin 1: pin 1 MOX1 4.36250E-01 void 4.43750E-01 clad 4.75000E-01 water % --- MOX pin 2: pin 2 MOX2 4.36250E-01 void 4.43750E-01 clad 4.75000E-01 water % --- MOX pin 3: pin 3 MOX3 4.36250E-01 3.6 Universes and Lattices void clad water 33 4.43750E-01 4.75000E-01 % --- Empry guide tube: pin 4 water 5.62500E-01 clad 6.12500E-01 water % --- Pin lattice (pitch = 1.26 cm): lat 10 1 1 2 2 2 2 2 2 2 2 2 2 2 2 2 1 1 1 2 3 3 3 2 3 3 2 3 3 2 3 3 3 2 1 2 3 3 3 3 4 3 3 4 3 3 4 3 3 3 3 2 1 0.0 0.0 17 17 1.26 2 3 3 4 3 3 3 3 3 3 3 3 3 4 3 3 2 2 3 3 3 3 3 3 3 3 3 3 3 3 3 3 3 2 2 2 4 3 3 4 3 3 4 3 3 4 3 3 4 2 2 2 3 3 3 3 3 3 3 3 3 3 3 3 3 3 3 2 2 3 3 3 3 3 3 3 3 3 3 3 3 3 3 3 2 2 2 4 3 3 4 3 3 4 3 3 4 3 3 4 2 2 2 3 3 3 3 3 3 3 3 3 3 3 3 3 3 3 2 2 3 3 3 3 3 3 3 3 3 3 3 3 3 3 3 2 2 2 4 3 3 4 3 3 4 3 3 4 3 3 4 2 2 2 3 3 3 3 3 3 3 3 3 3 3 3 3 3 3 2 2 3 3 4 3 3 3 3 3 3 3 3 3 4 3 3 2 2 3 3 3 3 4 3 3 4 3 3 4 3 3 3 3 2 1 2 3 3 3 2 3 3 2 3 3 2 3 3 3 2 1 1 1 2 2 2 2 2 2 2 2 2 2 2 2 2 1 1 The second example is a hexagonal VVER-440 lattice with 126 fuel pins and a central instrumentation tube. Empty lattice positions are filled with water (see Figure 3.5 on page 45). % --- Fuel pin with central hole: pin 1 void fuel void clad water 0.08000 0.37800 0.38800 0.45750 % --- Central instrumentation tube: 3.6 Universes and Lattices pin 2 water clad water 34 0.44000 0.51500 % --- Empty lattice position filled with water: pin 3 water % --- Pin lattice (x-type hexagonal, pitch = 1.23 cm): lat 10 2 0.0 0.0 15 15 1.23 3 3 3 3 3 3 3 3 3 3 3 3 3 3 3 3 3 3 3 3 3 3 1 1 1 1 1 1 1 3 3 3 3 3 3 3 1 1 1 1 1 1 1 1 3 3 3 3 3 3 1 1 1 1 1 1 1 1 1 3 3 3 3 3 1 1 1 1 1 1 1 1 1 1 3 3 3 3 1 1 1 1 1 1 1 1 1 1 1 3 3 3 1 1 1 1 1 1 1 1 1 1 1 1 3 3 1 1 1 1 1 1 2 1 1 1 1 1 1 3 3 1 1 1 1 1 1 1 1 1 1 1 1 3 3 3 1 1 1 1 1 1 1 1 1 1 1 3 3 3 3 1 1 1 1 1 1 1 1 1 1 3 3 3 3 3 1 1 1 1 1 1 1 1 1 3 3 3 3 3 3 1 1 1 1 1 1 1 1 3 3 3 3 3 3 3 1 1 1 1 1 1 1 3 3 3 3 3 3 3 3 3 3 3 3 3 3 3 3 3 3 3 3 3 3 The third example is a CANDU cluster consisting of 37 pins in 4 rings. The third ring is rotated by 15 degrees (see Figure 3.6 on page 46). % --- Fuel pin: pin 1 fuel 0.6122 clad 0.6540 coolant % --- Cluster: lat 1 6 12 18 10 4 0.0 0.0 4 0.0000 0.0 1 1.4885 0.0 1 1 1 1 1 1 2.8755 15.0 1 1 1 1 1 1 1 1 1 1 1 1 4.3305 0.0 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 3.6 Universes and Lattices 35 All three examples are illustrated using the geometry plotter in Section 3.9 on page 42. It should be noted that the plots contain cell structures not included in the above examples. The following example demonstrates the use of the vertical stack: % --- Uranium ball: surf 1 sph 0.0 0.0 2.5 2.5 cell 1 1 uranium cell 2 1 void -1 1 % --- Stack 5 balls: lat 2 9 0.0 0.0 5 0.0 5.0 10.0 15.0 20.0 1 1 1 1 1 Notice that the origin of universe 1 is positioned at the bottom of each layer. IMPORTANT NOTES ON UNIVERSES AND LATTICES: 1. Each universe is defined independently and must cover all space. Regions of space not belonging to the geometry must be defined using “outside” cells. 2. The lowest level of the geometry belongs to universe 0, which must always exist. 3. Each universe has its own origin, which can be shifted using the universe transformation command. 4. Cells in higher geometry levels can only be accessed through filled cells or lattices. 5. Each lattice defines a universe, which must be embedded inside a cell using the fill command. The lattice must fill the container cell completely to avoid neutron streaming to undefined lattice positions. 6. Hexagonal lattices are defined using a square matrix for the universe layout. To position the lattice cells correctly, a number of empty cells must be defined for each row. The definition is best described in the example in Sec. 3.6.3 on page 33. 7. Multi-level hexagonal structures (pin-assembly-core) are defined using both x- and y-type hexagonal lattices with different type at each level. 3.7 Repeated Boundary Conditions 36 8. If the infinite lattice types are is used in burnup calculation, material volumes must be set manually (see Sec. 4.1.2 on page 49). 9. The vertical stack lattice type is available from code version 1.1.8 on. SEE ALSO: 1. Pin definitions (Sec. 3.4 on page 27) 2. Filled cells (Sec. 3.6 on page 28) 3.7 Repeated Boundary Conditions What happens to neutrons that end up in a region defined as being outside the geometry is dictated by the boundary conditions. There are three options: 1. Black boundary - the neutron is killed 2. Reflective boundary - the neutron is reflected back into the geometry 3. Periodic boundary - the neutron is moved to the opposite side of the geometry The condition is set by the “bc” parameter, described in Section 5.7 on page 59. Reflective and periodic boundary conditions can be used to construct infinite and semiinfinite lattice structures. The way these boundary conditions are handled in Serpent is somewhat different from other Monte Carlo codes. Instead of stopping the neutron at the boundary surface, reflections and translations are handled by coordinate transformations. This limits the outermost boundary to a few specific surface types that can be used to define a square or hexagonal lattice structure. There are basically three options: Infinite 2D geometry: The geometry has no dependence on the z-coordinate. The outer boundary is defined by a single square or hexagonal cylinder (“sqc”, “hexxc” or “hexyc”). Radially infinite, axially finite 3D geometry: The outer boundary is defined by a square or hexagonal cylinder (“sqc”, “hexxc” or “hexyc”and two axial planes (“pz”). The boundary condition takes effect in the radial direction only. The axial boundary conditions are black. Infinite 3D geometry: The outer boundary is defined by a single cube, cuboid or hexagonal prism (“cube”, “cuboid”, “hexxprism”or “hexyprism”). The boundary condition takes effect in all directions. 3.7 Repeated Boundary Conditions 37 The following examples illustrate the different geometry types. The details of the geometry are omitted for the sake of simplicity and replaced by a fill command. An infinite 2D hexagonal geometry can be defined as: surf 1 hexyc 0.0 0.0 7.350 % --- Cells: cell 1 cell 99 0 0 fill 10 outside -1 1 set bc 3 Note that the reflective boundary condition is unphysical in a hexagonal geometry. infinite 2D square geometry can be defined as: surf 1 cell 1 cell 99 sqc 0 0 -0.233 -0.233 7.68750 fill 10 outside -1 1 set bc 2 In both cases the outer boundary is defined by a single surface. If the geometry is finite in the axial dimension, the system becomes three-dimensional. A radially infinite square lattice can be defined as: surf surf surf 1 2 3 cell 1 cell 97 cell 98 cell 99 sqc -0.233 -0.233 7.68750 pz -200.0 pz 200.0 0 0 0 0 fill 10 outside outside outside -1 1 -2 3 2 -3 2 -3 set bc 2 It is also possible to define the outside world as: cell 97 cell 98 cell 99 0 0 0 outside outside outside 1 -1 -2 -1 3 3.7 Repeated Boundary Conditions 38 but the code may run slower because the boundary condition will be handled also for some neutrons that end up outside the geometry. As for the infinite 2D geometry, the boundary in an infinite 3D geometry must be defined by a single surface, such as a cube: surf 1 cell 1 cell 99 cube 0.0 0.0 0.0 3.0 0 0 fill 10 outside -1 1 set bc 2 or a hexagonal prism: surf 1 cell 1 cell 99 hexxprism 0.0 0.0 1.880 0.0 4.93 0 0 fill 10 outside -1 1 set bc 3 In both cases the boundary conditions are enforced in both radial and axial directions. IMPORTANT NOTES ON REPEATED BOUNDARY CONDITIONS: 1. The outer boundary must be defined by a single surface in infinite 2D and 3D geometries. The allowed surface types for a 2D geometry are square and hexagonal cylinders. Infinite 3D geometries can be defined using a cube, cuboid or hexagonal prism. 2. Axially infinite, radially finite geometries are defined by a square or hexagonal cylinder and two axial planes. The way the outside world is defined may affect the running time. 3. The hexagonal cylinder and prismatic surfaces are physically reasonable only with periodic boundary conditions (reflective boundary conditions work if the geometry has a 30 degree symmetry). The use of reflective boundary conditions with these types was enabled in update 1.1.18. In earlier code versions the boundary condition is automatically changed into periodic. SEE ALSO: 1. Surface types (Sec. 3.2.1 on page 20) 2. Defining the outside world (Sec. 3.3.1 on page 25) 3. Setting the boundary condition (Sec. 5.7 on page 59) 3.8 HTGR geometry types 3.8 39 HTGR geometry types The fuels in high-temperature gas-cooled reactors (HTGR) consist of microscopic TRISO particles dispersed in a graphite matrix. The multi-layer fuel particles can be defined similar to fuel pins (see Sec. 3.4 on page 27): particle ... where ... ... is the particle identifier (universe number) are the materials are the outer radii of the material regions The simplest approach is to describe the particle distribution as a regular lattice, using lattice types 6, 7 or 8 (See the infinite 3D lattices in Sec. 3.6.2). However, the regular arrangement fails to account for the random distribution of the particles and often leads to a distorted fuel-to-moderator ratio due to cell cut-off at the outer boundary. For this reason the Serpent code has two geometry models specifically designed for HTGR fuels. 3.8.1 Implicit particle fuel model The implicit particle fuel model works by sampling new particles on the neutron flight path during the tracking process. The input syntax is: disp ... where ... ... ... is the universe number of the dispersed medium is the universe filling the space between the particles are the packing fractions of the particle types are the radii of the particle types are the universe numbers of the particle types The number of particle types is not limited, but the sum of the packing fractions must be less than 1.0 (physical factors set the upper limit much lower, although this is not checked by the routine). The implicit particle fuel model was revised in update 1.1.3. It should be noted that the model is not exact and there are statistically significant differences compared to the explicit model described below. The implicit model seems to work best for low packing fractions but no comprehensive validation has been carried out yet. 3.8 HTGR geometry types 3.8.2 40 Explicit particle / pebble bed fuel model A better choice for modeling HTGR geometries is the explicit particle fuel model, which reads the positions of the particles from a separate file. The same model can be used for setting up reactor-scale pebble-bed geometries. The input syntax is: pbed " " [ ] where is the universe number of the dispersed medium is the universe filling the space between the particles / pebbles is the input file containing the particle / pebble coordinates are the options The particle / pebble distribution is handled explicitly, so there are no approximations done in the modeling. Each line in the input file describes the position of a single particle / pebble. The format is: where is the x coordinate of the particle / pebble is the y coordinate of the particle / pebble is the z coordinate of the particle / pebble is the radius of the particle / pebble is the universe number of the particle / pebble The total number of entries is unlimited, although memory or running time may become a limiting factor if the number exceeds several million. The options are used to activate the calculation of various particle / pebble-wise parameters. Currently the only available option is the power distribution, which is requested with option “pow”. The code writes the output in a separate file “ .out”, where “ ” is the file where the distribution was read. The input data is included for convenience. The format of the output is:
where
is the x coordinate of the particle / pebble is the y coordinate of the particle / pebble is the z coordinate of the particle / pebble is the radius of the particle / pebble is the universe number of the particle / pebble is the power produced inside the particle / pebble is the associated relative statistical error All results depend on source normalization (see Sec. 5.8 on page 61). 3.8 HTGR geometry types 3.8.3 41 HTGR geometry examples The following example shows how the particle distribution inside a single PBMR fuel pebble can be modeled using a regular 3D array and the two particle fuel models in the Serpent code. The definition of a fuel particle is very similar to the fuel pin: % --- Definition of a coated fuel particle: particle 1 fuel buffer PyC SiC PyC matrix 0.0250 0.0340 0.0380 0.0415 0.0455 The first option is to describe the particle distribution as a regular cubical lattice: % --- Option 1: regular 3D array: lat 10 6 0.0 0.0 0.16341 1 The implicit particle fuel model is defined using a list of packing fractions and particle types: % --- Filler universe composed of graphite: surf 1 inf cell 1 2 matrix -1 % --- Option 2: implicit particle fuel model: disp 10 2 0.09043 4.55000E-02 1 The explicit particle fuel model reads particle coordinates from a separate input file (can be used for pebble distributions at reactor scale as well): % --- Filler universe composed of graphite: surf 1 inf cell 1 2 matrix -1 % --- Option 3: explicit particle fuel model (read coordinates from file): pbed 10 2 "particles.inp" 3.9 Geometry plotter 42 Finally the pebble description using one of the three options (all assigned with universe number 10): % --- Pebble: surf 10 sph 0.0 0.0 0.0 2.5 surf 20 sph 0.0 0.0 0.0 3.0 surf 30 cube 0.0 0.0 0.0 3.0 cell cell cell cell 10 20 30 40 0 0 0 0 fill 10 matrix helium outside -10 10 -20 20 -30 30 IMPORTANT NOTES ON HTGR GEOMETRY TYPES: 1. The implicit particle fuel model was revised in update 1.1.3. The model is not exact and should be used with caution. Test calculations show that the model works best for low packing fractions. 2. If the implicit particle fuel model is used in burnup calculation, material volumes must be set manually (see Sec. 4.1.2 on page 49). 3. Calculation of particle / pebble-wise power distributions is available from update 1.1.4 on. SEE ALSO: 1. An earlier version of the implicit particle fuel model in Ref. [8] 3.9 Geometry plotter The geometry plotter uses the GD open source graphics library [1] for producing png format output files for visualization. In order to use the plotter, the source code must be compiled with this library included (see the Makefile for detailed instructions). The syntax of the plotter command is: 3.9 Geometry plotter 43 plot