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.
Contents
Branch types
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)
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 % --- Water with 760 ppm boron: mix cool_750B water -0.99925 boron -750E-6
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 have to be defined 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.