Automated burnup sequence
Homogenized group constants form the input data for core-level fuel cycle and transient simulator calculations. The data is parametrized according to discrete state-points, which are defined by the local thermal hydraulic conditions together with reactivity control. The process of group constant generation must cover the full range of operating states within the reactor core, which often requires repeating the assembly-level calculation thousands of times. Since the local operating conditions inside the fuel assembly also affect how the materials are depleted, the state-points by which the data is parametrized are not completely independent. The calculations are instead divided into:
- Branch variations, taking into account momentary changes in the operating conditions, such as fuel temperature, moderator density and temperature, boron concentration and insertion of control rods
- History variations, taking into account conditions that persist for an extended period of time, such as moderator temperature and density, boron concentration and positioning of control rods
In practice, the procedure involves burnup calculations covering all assembly types and history variations. Branch variations are accounted for by performing restart calculations for each burnup point, varying the local operating conditions accordingly.
Serpent provides an automated burnup sequence, capable of performing branch variations for a single history run. The procedure works by first running a burnup calculation, after which a number of restarts are performed for selected burnup points. For each restart the code invokes a number of user-defined variations in the input, corresponding to the branches to different state-points. The branches are defined using the branch card, and the combination of variations by the coefficient matrix. The group constant data is collected into a separate output file easily read by post-processing scripts. The input and output formats are described below with examples.
For the moment the automated burnup sequence is limited to performing branch variations, and variations in histories must be handled by writing separate input files.
For complete examples, see the collection of example input files.
Each branch card defines one or several variations applied to the basic input. The currently supported variations can be used for:
- Replacing one material with another (repm
- Replacing one universe with another (repu)
- Applying a universe, surface or fill transformation (tra)
- Changing the density and temperature of a material (stp)
The typical use for the material replacement variation is to change the boron concentration in the coolant. Assume, for example, that there are three coolant compositions defined in the input:
- cool_0B without boron
- cool_750B with 750 ppm boron
- cool_1500B with 1500 ppm boron
% --- Coolant without boron: mat cool_0B -0.77028 moder lwtr 1001 1001.06c 3.33330E-01 8016.06c 6.66670E-01 % --- Coolant with 750 ppm boron: mat cool_750B -0.77028 moder lwtr 1001 1001.06c 3.33076E-01 8016.06c 6.66161E-01 5010.06c 1.51847E-04 5011.06c 6.11204E-04 % --- Coolant with 1500 ppm boron: mat cool_1500B -0.77028 moder lwtr 1001 1001.06c 3.32821E-01 8016.06c 6.65653E-01 5010.06c 3.03690E-04 5011.06c 1.22239E-03 % --- Thermal scattering data: therm lwtr lwj3.11t
If the material used to fill the coolant channel in the original geometry is cool_750B, then this is the material used throughout the burnup calculation. Once the depletion history is completed, the code performs the restarts and invokes the branches. The boron concentration can be varied to 0 and 1500 ppm with branches:
% --- Branch to low boron concentration: branch Blo repm cool_750B cool_0B % --- Branch to high boron concentration: branch Bhi repm cool_750B cool_1500B
which simply replace material cool_750B with materials cool_0B and cool_1500B, respectively. Names Blo and Bhi are used to identify the branches in the coefficient matrix. The material replacement variation also works with mixtures, which may be a convenient way to define coolant compositions using water and boron. For, example, cool_750B above could be defined as:
% --- Water: mat water -0.76973 moder lwtr 1001 1001.06c 0.33333 8016.06c 0.66667 therm lwtr lwj3.11t % --- Natural boron: mat boron 1.00000 5010.06c 0.19900 5011.06c 0.80100 % --- Coolant with 750 ppm boron: mix cool_750B water -0.99925 boron -750E-6
The replacing materials or mixtures cannot be used as part of the original geometry.
Universe replacement variations are useful for invoking changes to entire sub-regions of the geometry, for example, for the purpose of control rod insertion in 2D geometries. An empty guide tube and a tube with control rod inserted could be defined as:
% --- Empty guide tube: pin GTU cool 0.56134 zirc4 0.60198 cool % --- Rodded guide tube: pin ROD AIC 0.43310 steel 0.48387 cool 0.56134 zirc4 0.60198 cool
where cool, zirc4, AIC, and steel are the materials for coolant, guide tube, absorber and control rod tube, respectively. Insertion of control rods can then be invoked with branch:
% --- Insertion of control rods: branch CR repu GTU ROD
which simply replaces the empty guide tube with a rodded tube.
When spatial homogenization is performed for a 2D geometry, the insertion of control rods can be accomplished by simply replacing one universe with another. In 3D geometries, however, the rods can be fully withdrawn, fully inserted or anything in between, and the most convenient way to move the rods is to apply a coordinate transformation that sets the position. Different transformations can be invoked at different branches, to account for the various positions.
The applied transformations are defined separately in the input. For example, if a homogenized 3D node has the height of 19.25 cm, transformations corresponding to fully inserted, half-way and fully with withdrawn control rod positions could be defined as:
utrans pos0 0.0 0.0 0.000 utrans pos1 0.0 0.0 9.625 utrans pos2 0.0 0.0 19.250
assuming that without any transformation the bottom of the absorber sits at the bottom of the node. Without branch calculation the first entries in the utrans cards would be interpreted as universe names, and if universes "pos0", "pos1" and "pos2" are not defined, Serpent would simply ignore these entries. Assuming that the universe defining the control rods is called "ROD", the branches invoking the movement could be defined as:
% --- Fully inserted: branch CR0 tra ROD pos0 % --- half-way: branch CR1 tra ROD pos1 % --- Fully withdrawn: branch CR2 tra ROD pos2
The transformation branch works by simply replacing the universe name in the transformation card with the one given in the branch card. For example, when branch "CR1" is invoked, the universe transformation applied for the geometry would become:
utrans ROD 0.0 0.0 9.625
which would lift the rods in the half-way position. Because of the way the variation is implemented, it is important that the names of the invoked transformations do not correspond to any actual universe in the geometry. If this is the case, Serpent will apply the transformations accordingly already during the burnup calculation.
The transformation branch can also be applied to surface and fill transformations. In such case the target in the branch card refers to a surface and cell, respectively. If multiple transformation types are used in the calculation, it is important to pay attention to how the associated universes, surfaces and cells are named. When the branch is invoked, Serpent identifies the transformation based on the name, without checking the type. So a universe transformation applied to universe 1 and surface transformation applied to surface 1, for example, become indistinguishable.
Transformations are not limited translations, but also rotations and any operations defined by transformation matrix can be applied.
Applying state variations
State variations can be used to change material temperatures and densities, for example, for the purpose of fuel or moderator temperature branches. When the material is not associated with thermal scattering data, the input for the branch card consists of the new density and temperature. This is typical for fuel materials, for example, branches:
% --- Branch to low fuel temperature: branch Flo stp fuel -10.338 600 % --- Branch to high fuel temperature: branch Fhi stp fuel -10.338 1200
change the temperature of material "fuel" to 600 and 1200 Kelvin, respectively. The routine works by looking for the cross section data for the nearest temperature below the given value and applying the built-in Doppler-broadening preprocessor routine to adjust the cross sections to the correct temperature.
Changes in materials with associated thermal scattering data require three additional input parameters for each library:
- The name of therm card associated with the material
- Name of a data library at temperature below or equal to the given value
- Name of a data library at temperature above or equal to the given value
For example, if the coolant is defined as:
% --- BWR coolant with 40% void fraction: mat cool -0.443760 moder lwtr 1001 1001.06c 0.66667 8016.06c 0.33333 % --- Thermal scattering data for light water at 600K therm lwtr lwe7.12t
a branch to a lower temperature could be defined as:
branch Clo stp cool -0.739605 560 lwtr lwe7.10t lwe7.12t
This increases the density from 0.443760 to 0.739605 g/cm3 and lowers the temperature from 600 to 550 Kelvin. The change in temperature for free-atom cross sections is handled by replacing the 600K library data with 300K data and broadening the cross sections to 560K. The change in thermal scattering data is handled using tabular interpolation. The provided library names lwe7.10t and lwe7.12t correspond to 550 and 600K temperatures, respectively. If the material is associated with multiple thermal scattering libraries, they must all be included in the branch card.
Multiple simultaneous variations
The number of variations per branch card is not limited. If the geometry consists of more than one fuel type, their temperatures can be varied with a single branch:
branch Fhi stp fuel1 -10.338 1200 stp fuel2 -10.338 1200 stp fuel3 -10.338 1200 stp fuel4 -10.338 1200 stp fuel5 -10.338 1200
Some core simulator codes apply polynomial interpolation between state points, which often does not require the full coefficient matrix with all possible state-point combinations. Instead of a multi-dimensional matrix it is then more convenient to define a one-dimensional list of branches, in which the necessary combinations are defined. For example, the calculation of a cross term involving variation in both coolant boron concentration and fuel temperature could be accomplished with branch:
branch BRA01 repm cool_750B cool_0B stp fuel -10.338 1200
State variations alone cannot be used to handle heat expansion, but the change in density can be accompanied by a universe replacement variation to account for the change in dimensions:
branch Fh stp fuel1 -10.1348 1200 repu FUE FUEH
assuming that universes FUE and FUEH describe the fuel pin at nominal and expanded dimensions, respectively.
Setting up the coefficient matrix
The coef card lists the burnup points at which the restarts are performed. These points must correspond to points in the depletion history (0 for initial composition). The burnup points are followed by the coefficient calculation matrix, which may be one or multi-dimensional. For example:
coef 11 0 0.1 1 3 5 10 15 20 30 40 50 3 nom Blo Bhi 3 nom Clo Chi 3 nom Flo Fhi 2 nom CR
invokes the branch calculation at 11 burnup points at 0, 0.1 1, 3, 5, 10 15, 20 30 40 and 50 MWd/kgU burnup. The coefficient matrix has four dimensions. The first row defines boron concentration branches: nominal, low and high (see the example on material replacement branch above). The second and third row define variations in coolant and fuel temperature (see the examples on state variation branches above). The last row defines insertion of control rods (see the example on universe replacement branch above). The first entry in each row is a branch with no variations at all, which corresponds to the nominal conditions in the burnup calculation.
Since the matrix has four dimensions, each run involves a combination of four branches. In total the matrix defines 3 3 3 2 = 54 combinations, of which the first 10 are:
|1.||nom||+ nom||+ nom||+ nom||(nominal state)|
|2.||Blo||+ nom||+ nom||+ nom||(boron at low concentration)|
|3.||Bhi||+ nom||+ nom||+ nom||(boron at high concentration)|
|4.||nom||+ Clo||+ nom||+ nom||(coolant at low temperature)|
|5.||Blo||+ Clo||+ nom||+ nom||(boron at low concentration and coolant at low temperature)|
|6.||Bhi||+ Clo||+ nom||+ nom||(boron at high concentration and coolant at low temperature)|
|7.||nom||+ Chi||+ nom||+ nom||(coolant at high temperature)|
|8.||Blo||+ Chi||+ nom||+ nom||(boron at low concentration and coolant at high temperature)|
|9.||Bhi||+ Chi||+ nom||+ nom||(boron at high concentration and coolant at high temperature)|
|10.||nom||+ nom||+ Flo||+ nom||(fuel at low temperature)|
As mentioned above, some core simulator codes do not require all combinations of branches. To avoid running unnecessary combinations it is possible to define a one-dimensional list of branches, for example:
coef 11 0 0.1 1 3 5 10 15 20 30 40 50 10 BR01 BR02 BR03 BR04 BR05 BR03 BR07 BR08 BR09 BR10
and set up the combinations in the branch cards. This may complicate the input, but also save a lot of computing time since only branches that are used for forming the parametrized input data for the simulator are run.
Group constant data from the automated burnup sequence is written in a separate output file named "<input>.coe". The structure of the file is intended to be easily read by post-processing scipts, as described below. The parameters included in the output are selected using the set coefpara card (see also the parameter names in group constant generation).
Passing additional information with variables
Additional information useful for the post-processing script can be passed from the input directly into the output using variables. For example:
% --- Branch to low fuel temperature: branch Flo stp fuel -10.338 600 var TFU 600
defines variable "TFU" and sets its value to "600" when the fuel temperature branch is invoked. When the post-processing script reads the the data, it has the information that this is a branch to lower fuel temperature. Variables are also useful for passing history information. This can be done by defining a branch with varibables only:
% --- History variables: branch HIS var BHI 450 % Boron concentration 450 ppm var WHI 550 % Coolant temperature 550K
and including this branch in the coefficient matrix as its own single-valued dimension:
coef 11 0 0.1 1 3 5 10 15 20 30 40 50 10 BR01 BR02 BR03 BR04 BR05 BR03 BR07 BR08 BR09 BR10 1 HIS
The same information is then included in the output at every branch.
The .coe output file is in ASCII format and divided into blocks. Each block provides a complete header and the group constant data from a single run:
(loop over runs) Itot Ntot Icoe Ncoe Nuni Nbra BRA1 BRA2 ... Nvar VAR1 VAL1 VAR2 VAL2 ... BU Ibu Nbu (loop over universes) UNI Npara (loop over group constant data) PARA Nval VAL1 VAL2 ... ... (end loop over group constant data) ... (end loop over universes) ... (end loop over runs)
The block begins with line:
Itot Ntot Icoe Ncoe Nuni
where the values are:
|Ntot||:||Total number of runs (number of branch combinations times number of burnup points)|
|Icoe||:||Coefficient calculation index|
|Ncoe||:||Total number of coeffient calculations (number of branch combinations in the coefficient matrix)|
|Nuni||:||Number of universes in a single run|
The second line provides information on the branches invoked in current run:
Nbra BRA1 BRA2 ...
where the values are:
|Nbra||:||The number of branches invoked (dimension of the coefficient matrix)|
|BRAn||:||The branch names (as provided in the branch card)|
The third line lists the variables:
Nvar VAR1 VAL1 VAR2 VAL2 ...
where the values are:
|Nvar||:||The number of variable name-value pairs that follow|
|VARn||:||The variable names (as defined in the branch cards)|
|VALn||:||The variable values (as assigned in the branch cards)|
Three variables are always printed: VERSION, DATE and TIME, which provide the code version used, and the date and time the calculation was completed. The 4th line provides information on the burnup points:
BU Ibu Nbu
where the values are:
|BU||:||Burnup (as listed in the coef card)|
|Nbu||:||Total number of burnup points|
The common header part is followed by a loop over Nuni universes. The first line in each subsection is:
where the values are:
|UNI||:||The name of the universe where group constant calculation was performed|
|Npara||:||Total number of output parameters that follow|
This is then followed by Npara lines of group constant data. Each line has the format:
PARA Nval VAL1 VAL2 ...
where the values are:
|PARA||:||The name of the output variable (as listed in the "set coefpara" card as well as the _res.m output)|
|Nval||:||Total number of values that follow|
|VALn||:||The output values|
The relative statistical errors are not printed by default, but they can be included with an option in the set coefpara card. In such case the data is provided in mean value - statistical error pairs and N gives the number of pairs.
The order in which the blocks are printed out depends on how the branches are listed in the coefficient matrix. Serpent runs all burnup points for each branch combination before moving on to the next combination, so the loop over burnup points forms the inner and loop over branch combinations the outer loop. The number of output values and the order in which the values are printed depends on the parameters (see the parameter names in group constant generation)