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:

1. 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
2. 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.

Branch types

Each branch card defines one or several variations applied to the basic input. The currently supported variations can be used for:

1. Replacing one material with another (repm
2. Replacing one universe with another (repu)
3. Applying a universe, surface or fill transformation (tra)
4. Changing the density and temperature of a material (stp)

Replacing materials

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

as:

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

Replacing universes

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.

Applying transformations

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/cm³ 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 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.338 1200
repu F1 F1h

assuming that universes F1 and F1h 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 $\times$ 3 $\times$ 3 $\times$ 2 = 54 combinations, of which the first 10 are:

nom	+ nom	+ nom	+ nom	(nominal state)
Blo	+ nom	+ nom	+ nom	(boron at low concentration)
Bhi	+ nom	+ nom	+ nom	(boron at high concentration)
nom	+ Clo	+ nom	+ nom	(coolant at low temperature)
Blo	+ Clo	+ nom	+ nom	(boron at low concentration and coolant at low temperature)
Bhi	+ Clo	+ nom	+ nom	(boron at high concentration and coolant at low temperature)
nom	+ Chi	+ nom	+ nom	(coolant at high temperature)
Blo	+ Chi	+ nom	+ nom	(boron at low concentration and coolant at high temperature)
Bhi	+ Chi	+ nom	+ nom	(boron at high concentration and coolant at high temperature)
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 the input data are run.

Output

The 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 it to value "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.

Output format

The .coe output file is divided into blocks, and each block provides 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:

Itot	:	Run index
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)
Ibu	:	Burnup index
Nbu	:	Total number of burnup points

The common header part is followed by a loop over N_uni universes. The first line in each subsection is:

UNI  Npara

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