Nuclear Engineering and Design 251 (2012) 400–406

Contents lists available at SciVerse ScienceDirect

Nuclear Engineering and Design

journal homepage: www.elsevier.com/locate/nucengdes

Progress on the development of a fully integrated HTR code package

H.-J. Allelein a,b , St. Kasselmann a,∗ , A. Xhonneux a,b , S.-C. Herber a,b
a
Forschungszentrum Jülich GmbH, Institut für Energieforschung (IEK), Sicherheitsforschung und Reaktortechnik (IEK-6), 52425 Jülich, Germany
b
RWTH Aachen, Lehrstuhl für Reaktorsicherheit und -technik, 52064 Aachen, Germany

a r t i c l e i n f o a b s t r a c t

Article history: A variety of computer codes have been developed, validated and optimized to simulate the different
Received 21 January 2011 safety and operational aspects of HTRs. In order to overcome the present limitations of these codes and
Received in revised form to exploit the advantages of modern computer clusters, a project has been initiated to integrate these
11 September 2011
individual programs into a consistent code package applying state-of-the-art programming techniques
Accepted 12 September 2011
and standards. The HTR code package couples the related and recently applied physics models in a highly
integrated manner. This will allow the steady-state and transient operating conditions of a full 3D reac-
tor model to be simulated including new features such as fission product release calculations for each
core zone or dust production and transport simulations. In this paper we report on the basic software
architecture and the current status of this new integrated code system currently under development.
© 2011 Elsevier B.V. All rights reserved.

1. Introduction The determination of the power and temperature history with

correlated burnup and isotope compositions can then be used to
The history of high-temperature reactor (HTR) prototypes in run fission product release and fuel performance codes such as
Germany is closely related to Forschungszentrum Jülich and its FRESCO-II (Krohn and Finken, 1983) and PANAMA (Verfondern and
‘Institute of Safety Research and Reactor Technology (IEK-6)’. Nabielek, 1985). These codes read calculated temperatures from
Whereas HTR research at IEF-6 formerly focused on the devel- V.S.O.P. and MGT to determine the release rates of important iso-
opment of pebble bed reactor designs, today the key task is the topes. SPATRA (Moormann, 1992) is able to simulate the transport
evaluation and improvement of safety features during normal and position of fission products on metallic surfaces.
operation and accident conditions. For this purpose a variety of
computer codes have been developed, validated, and optimized to 2. Benefits of the new HTR code package
simulate the different safety and operational aspects of HTRs. These
codes are widely used today and have also been applied in recent The heterogeneous infrastructure of computer codes has led to
licensing procedures, such as for the Chinese HTR-PM. some major limitations and drawbacks with respect to functional-
The code infrastructure currently in use is shown in Fig. 1. The ity and flexibility. The new HTR code package (HCP) will overcome
two multi-physics codes V.S.O.P. (Rütten et al., 2005) and MGT these issues. It will consist of a software backbone for program flow
(Druska et al., 2009; Gerwin, 1987, 1989) are applied to simulate control, user I/O, 2D/3D solvers and other program services. Code
the primary loop of an HTR. While V.S.O.P. is used for core design, modules for specific tasks can then be coupled to the HCP back-
fuel cycle, and reactor operation simulation on a long time scale, bone code (see Fig. 3). This allows different physical models to be
MGT is applied to study the dynamical behavior of an HTR on a short included in a very flexible manner. While the coupling between
time scale. Currently a 3D version of MGT is being validated as well. the thermohydraulics and neutronics module, for example, will be
Both codes offer a wide range of physics modules including 2D/3D turned on by default, other models such as the calculation of fis-
coupled neutronics and thermohydraulics, fuel shuffling, burnup, sion product release or dust migration in the core can be included
forced flow and natural convection, gas mixture and gas diffusion, on demand.
as well as graphite corrosion chemistry (e.g. when considering air In the following, some examples are given of how HCP will
or water ingress). As a supplement to these codes, special ques- overcome the current drawbacks and limitations with respect to
tions related to rapid depressurization accidents of an HTR have physical models and code structure.
been addressed with the code DIREKT (Struth et al., 1999).
2.1. Impact on physical models

∗ Corresponding author. Tel.: +49 2461 61 6071. The most important issue is the simulation of long-term reactor
E-mail address: s.kasselmann@fz-juelich.de (St. Kasselmann). operation with V.S.O.P. and short-term reactor transients, as well

0029-5493/$ – see front matter © 2011 Elsevier B.V. All rights reserved.
doi:10.1016/j.nucengdes.2011.09.053
 H.-J. Allelein et al. / Nuclear Engineering and Design 251 (2012) 400–406 401

Fig. 1. Overview of the code infrastructure presently being used in the field of HTR safety research.

as accident scenarios with MGT. This impedes the simulation of Another new feature of the HCP will be the possibility to sim-
alternating operating conditions of an HTR because a huge effort ulate aerosol behavior in the primary circuit. This is especially
is required to create several input files by hand. As the HCP will relevant with respect to carbonous dust, which is seen as an impor-
contain one consistent module for neutronics and one for ther- tant activity carrier at depressurization accident scenarios. The
mohydraulics, any desired sequence of steady-state and transient dust module will constitute a coupling of the following models:
operating conditions can be simulated. relevant deposition models (especially turbulent deposition, ther-
Another issue is the calculation of fission product releases with mophoresis, inertial impaction and gravitational settling), Rock’n
FRESCO-II. At the moment, only one flow channel within the core is Roll resuspension model, particle adhesion for rough surfaces as
taken into account and the distinct temperature profile inside the well as multi-layer deposits and convective dust transport within
fuel pebble is neglected. As the FRESCO-II code will be an integral the primary circuit.
part of the HCP, fission product release calculations can be per- A number of further minor issues such as the different treat-
formed for each core zone and time step including the temperature ment of decay heat calculation in V.S.O.P. and MGT or the different
profiles of the pebbles. Also, the transport of the fission products implementation of SiC-layer corrosion in FRESCO-II and PANAMA,
within the primary loop will be considered by extending the MGT will also be harmonized within HCP.
gas flow model.
A further example is the usage of different spectrum calcula- 2.2. Impact on code structure
tion codes. While MGT is based on the 43-group MUPO library
(Schlösser, 1963), V.S.O.P. uses GAM (Joanou et al., 1961) for the Although V.S.O.P. and MGT are designed to simulate different
fast and THERMOS (Honeck, 1961) for the thermal part of the neu- aspects of the primary loop, similar input data has to be provided
tron energy spectrum. In the first step, all three libraries have for both codes separately (e.g. grid geometry, material definitions,
been updated according to ENDF/B-VII.0 (Nünighoff et al., 2010). and cross sections). This approach almost doubles the amount
In the course of the ongoing code integration process, these spec- of input data necessary to run a single reactor model. Further-
tral codes will be replaced by the new 1D spectrum code TOTMOS more, the existence of different nuclear libraries in the two codes
(Brockmann, 2010). TOTMOS extends the capabilities of THERMOS requires an interface program to mediate between the different
to the epithermal and fast energy range of the neutron spectrum. codes. In the HCP, only one set of nuclear data has to be provided
In HCP, all modules use data from one consistent XML data and will be applied consistently for all the different physical mod-
library. This library can be generated fully automatically by the ules.
new code HCPLibGen. Currently it contains decay data for 3842 As both codes contain some similar physical models and apply
nuclides, cross section data for 393 nuclides and fission yields for similar algorithms, there is a high level of code duplication. Cur-
31 nuclides. rently, decisions are being made as to which parts of each code are
Especially for pebble bed reactors, the simulation of fuel shuf- to be continuously developed and which codes will be ‘frozen’ and
fling is a major task. Therefore a feasibility study has been launched archived appropriately. The fact that V.S.O.P., MGT and DIREKT, for
to investigate a new model which will share the same grid with all example, contain only slightly different thermohydraulics models
other code modules. With this new approach, it will also be possible led to the decision to unify these parts of the code. This will reduce
to simulate azimuthally differing flow profiles as well as stagnant the amount of source code to be maintained in this domain by a
zones. Also fuel piles can be modelled. Fig. 2 illustrates the result factor of up to three, while still providing all the functions. Similar
of a pebble flow simulation for a typical HTR core. arguments hold for large sections of the neutronics part available
402 H.-J. Allelein et al. / Nuclear Engineering and Design 251 (2012) 400–406

3. Technical aspects of HCP development

A number of issues have to be taken into account when setting

up a new code system, especially if it is based on a set of validated
and well-established programs. The process of defining detailed
specifications and selecting suitable programs to fit into the new
code package is almost complete. As the development of HCP also
requires considerable coding work, four different aspects will be
outlined in this chapter from the technical point of view: the refac-
torization and reverse engineering of legacy code, the definition of
a basic software design for a new enclosing framework, the new
data I/O concept and tools to ensure the software quality during
the development process.

3.1. Refactoring and reverse engineering of legacy code

Refactoring is a disciplined technique for restructuring an exist-

ing body of code, thus altering its internal structure without
changing its external behavior (Fowler, 1999). The goals of refac-
torization are to increase readability, to eliminate duplicate code,
and to speed up the implementation of new features due to the new
in-depth knowledge of the implemented algorithms.
Since 2009, a refactoring and reverse engineering process of
all codes involved has been in progress. Here most of the prob-
lems arose due to non-compliant legacy source code when bugs
cannot be automatically detected by the compiler. Consequently,
the refactoring is accompanied by extensive code refurbishment
with respect to recent programming standards. Large parts of the
FRESCO, PANAMA and MGT codes have already been successfully
refactored.
One example is the interface program between V.S.O.P. and MGT
which is necessary due to the different nuclear libraries used in
the two codes. One major issue here was to resolve problems due
to interdependencies as a result of non-sequential reading from
different input files. At the same time, static memory allocation was
replaced by dynamic memory allocation. After having removed all
COMMON blocks in favor of external modules, the whole code was
split up by applying the “ExtractMethod” refactoring strategy.
Fig. 2. Snapshot of a pebble flow simulation (indicated by color markers) for a typical Another part of MGT which has been reviewed is the spectrum
HTR core geometry (left: initial state, right: state after a number of shuffling steps). calculation program. This program calculates the critical spectrum
(For interpretation of the references to color in this figure legend, the reader is of a bare homogeneous reactor in 43 neutron energy groups, which
referred to the web version of the article.)
is then used to evaluate condensed macroscopic cross sections. The
aim of the refactoring here was to separate the data input layer from
the physics code as a prerequisite for the implementation of a new
advanced spectrum code. Most of the problems here occurred due
both in V.S.O.P. and MGT. This issue will be resolved by extracting
to the large number of nested logical structures and goto state-
and adapting only the disjoint code parts leading to a unique set of
ments. Fig. 4 illustrates the code layout after the first iteration of
code within HCP.
refactoring.
The decision to switch to the TOTMOS code is motivated not
As a side effect, the amount of code was reduced by about 15%
only by physical reasons, but also by the fact that for every new
while at the same time providing better usability.
cross section dataset published up to now three different libraries
have to be updated.
Another topic which is becoming more and more significant, 3.2. Aspects of software design
especially with respect to full 3D simulation models, is per-
formance. Recent studies (Druska, 2009) of the matrix solvers While refactoring is clearly a bottom-up process, designing com-
currently used in our codes have shown that the performance pletely new software is generally a top-down approach. The latter
gain when applying more advanced algorithms (e.g. from LAPACK, means forming a high-level structural picture of the code and then
Anderson et al., 1999) seems to be limited. Work has there- moving down from that high-level perspective to the details of
fore started on exploring the advantages of solving the diffusion implementation.
equations on Multi-Core CPUs and parallel computing systems. The development of the HCP is a combination of the two
Unfortunately, the present code structure will not allow parallel approaches. The total sum of FORTRAN source code currently in
computers to run the codes efficiently. Significant modifications use amounts to almost 100k lines of code (LOC) and represents
have to be made here. several thousand person-months of work. Nevertheless, the purely
All these aspects illustrate the need for a major code review and procedural structure of the codes which has evolved over the last
consolidation process. This finally resulted in the development of few decades does not meet the requirements for a modular and
the HTR code package, officially launched in November 2009. future-proof code system.
 H.-J. Allelein et al. / Nuclear Engineering and Design 251 (2012) 400–406 403

Fig. 3. Overview of the modular design of the HTR code package currently being developed.

Therefore the question arose as to the kind of software design thus strives to reduce the amount of coupling between the different
approach that should be chosen in the long run. It is widely objects, which reduces the complexity of the entire program. An OO
accepted that software complexity and code maintenance costs can approach is also mandatory for collaboration with other research
be reduced by choosing an appropriate object-oriented (OO) design facilities with respect to future HCP development work. In the field
approach. The main goal here is to divide the responsibilities of of nuclear reactor codes, objects like Meshes, Batches, FuelElements,
the program among its objects. An object-oriented software design Nuclides, Materials are appropriate, for example.

Fig. 4. A subroutine after the refactoring process where the code has been updated according to Fortran 90.
404 H.-J. Allelein et al. / Nuclear Engineering and Design 251 (2012) 400–406

Fig. 5. XML data representation of a reflector mesh as part of the new nuclear data input model.

While this way of thinking has already manifested itself in the discussion of this new XML input concept and a first feasibility
structure of the new XML input file discussed later in this paper, study can be found in Scholthaus (2009).
it is far more difficult to redesign the complete code. Therefore, a For the systematic analysis of the new binary output data, a
strategy is pursued according to which interfaces hide the procedu- C++-based toolbox called MAVIS (Multiple Data Analysis and Visu-
ral structure of the existing code modules from newer redesigned alization) has been developed. This allows data written by the HCP
object-oriented modules. At the same time, the HTR software back- to be printed and compared in a very flexible manner. MAVIS is
bone is designed using an OO approach right from the beginning. based on ROOT, a widely used analysis framework originally devel-
Finally, the interface of each module is adapted to permit commu- oped for the field of high-energy physics (Brun and Rademakers,
nication via objects in both directions. 1997).
As a first result, a data model has been developed which has
successfully been applied to the new data library generation code.
It offers intrinsic error treatment, automatic unit conversions as 3.4. Software quality assurance
well as problem specific data types.
Also the fission product release code FRESCO and the fuel perfor- There is a large amount of literature on software quality issues.
mance code PANAMA have been successfully redesigned and initial International standards like ISO/IEC 25000 have also been defined.
progress has been made in defining a FuelElement object that serves In the day-to-day work on source code it all comes down to three
as an interface between FRESCO/PANAMA and MGT. This will allow major pillars: version control, regression/unit tests, and project
fission product release rates to be calculated for each core zone and automation.
the whole reactor lifetime, taking into account steady states as well As the HTR code package couples existing codes in a highly inte-
as transients. grated manner, a great deal of presently stand-alone code must
be modified to fit into the new concept. To ensure the software
quality and to minimize the introduction of new bugs, well-known
3.3. Data model and I/O strategies such as version control, regression tests, and automa-
tion tools are applied. With the tool subversion (Collins-Sussman
To run programs such as V.S.O.P. and MGT, a large volume of et al., 2004), every set of code modifications is tagged, documented,
input data has to be provided by the user and a great deal of infor- and uploaded to a repository. So far there are more than 470 docu-
mation is supplied by the codes to the user. The recent approach of mented and tested code revisions of MGT, for example, which are
setting up and printing out huge formatted text files has reached accessible through a file server by every member of the working
its limits with respect to efficiency and usability. group. It needs to be emphasized that the team is strictly subdi-
Therefore, a new object-oriented data model is being developed vided into people developing the software and people running the
based on XML (Extensible Markup Language) and binary data files. software tests and validation scenarios.
Fig. 5 shows a simplified example of the XML data representation of Before a commit, each new revision is cross-checked with the
a reflector mesh as part of the nuclear data input. A more detailed former code revision using a representative set of distinct test cases
 H.-J. Allelein et al. / Nuclear Engineering and Design 251 (2012) 400–406 405

Detailed Detailed Altogether, this approach leads to much lower code maintenance
costs and has already been proven to reduce the implementation
Neutronics Thermohydraulics and validation time of new physics models.

5. Outlook
MCNP(X) CFD HCP will be one of four software tools applied for future safety
DOORS Computational Fluid research activities at IEK-6 (see Fig. 6). While HCP will be a multi-
MC / SN Dynamics physics code system for the simulation of an HTR primary loop,
Transport Codes
CFX (Ansys Inc., 2007) and MCNP (Briesmeister, 1986) will be used
for detailed studies in the field of thermohydraulics and neutron-
ics, respectively. COCOSYS (Allelein et al., 2008) will be applied for
questions related to containment and confinement safety.
HCP will be validated with data from former experiments such
as SANA (Stöcker, 1998) and VELUNA (Fröhling and Roes, 1995),
and also with future data from experiments such as NACOK-II, a test
facility for HTR thermohydraulics, which is currently being built at
Jülich. The neutronics and thermohydraulics code part can also be
COCOSYS HCP validated with data made available within the envisaged HTR-10
Containment Code Coupled Physics of an International Research Framework.
System Safety HTR Primary Loop

Acknowledgements

The authors are indebted to their colleagues C. Druska, S. Jühe,

Containment / Multi-Physics S. Kelm, J. Li, H.-J. Rütten, S. Scholthaus and S. Struth for support
Confinement Code Integration and valuable discussions.

Fig. 6. Overview of the future code infrastructure applied in the field of reactor
References
safety research.

Allelein, H.-J., Arndt, S., Klein-Heßling, W., Schwarz, S., Spengler, C., Weber, G., 2008.
(regression testing). For MGT a special simulation scenario was COCOSYS: status of development and validation of the German containment
code system. Nuclear Engineering and Design 238, 872–889.
defined combining a steady state calculation with a sequence of Anderson, E., Bai, Z., et al., 1999. LAPAck Users’ Guide, 3rd edition. SIAM, Philadelphia,
transients like TWCR, LOFC, DLOFC and air ingress. It can thus be http://www.netlib.org/lapack/lug.
ensured that every code module is invoked and tested. The results Ansys Inc., 2007. ANSYS CFX Version 11: Solver Theory.
Briesmeister, J.F., September 1986. MCNP – A Monte Carlo Code for Neutron and
are than compared to reference data of a former code version which Photon Transport. Los Alamos National Laboratory, LA-7396-M Revision 2.
was extensively benchmarked against experiments. Brockmann, H., 2010. TOTMOS – an integral transport code for calculating neu-
In the near future, these tests will be accompanied by so-called tron spectra and multigroup cross sections, internal report. Forschungszentrum
Jülich.
unit tests checking every subroutine for correct behavior over the
Brun, R., Rademakers, F., 1997. ROOT – an object oriented data analysis frame-
whole input parameter space. work. Proceedings AIHENP’96 Workshop, Lausanne, September 1996. Nuclear
Finally, project automation tools, such as makefiles, batch Instruments & Methods in Physics Research A 389, 81–86, http://root.cern.ch/.
scripts, and integrated development environments (IDE) like Collins-Sussman, B., Fitzpatrick, B.W., Miachel Pilato, C., June 2004. Version Control
with Subversion – Next Generation Open Source Version Control. O’Reilly Media.
Eclipse, are applied to prevent breaking a build and to ensure a Druska, C., January 2009. Analyse direkter und iterativer Lösungsverfahren
standardized working environment. für Gleichungssysteme mit nichtsymmetrischen, dünnbesetzten Matrizen
zur Optimierung neutronenphysikalischer sowie thermodynamischer Simu-
lationsverfahren, Masterarbeit. Aachen University of Applied Sciences (Jülich
4. Conclusions Campus)/Forschungszentrum Jülich.
Druska, C., Kasselmann, St., Lauer, A., 2009. Investigations of space-dependent
This paper describes the progress achieved in developing a fully safety-related parameters of a PBMR-like HTR in transient operating condi-
tions applying a multi-group diffusion code. Nuclear Engineering and Design
integrated HTR code package (HCP). The HCP will consist of a soft- 239 (March (3)), 508–520, ISSN 0029-5493.
ware backbone for program flow control, user I/O, 2D/3D solvers Fowler, M., 1999. Refactoring: Improving the Design of Existing Code. Addison-
and other program services. Code modules for the specific tasks Wesley.
Fröhling, W., Roes, J., 1995. Zur chemischen Stabilität bei innovativen Kernreaktoren,
can then be coupled to the HCP backbone code. This allows differ- JÜL-3118. Forschungszentrum Jülich.
ent physical models to be included in the most flexible manner. Gerwin, H., 1987. Das zweidimensionale Reaktordynamikprogramm TINTE (Teil I),
As HTR reactor systems will be marketable in a medium-term per- JÜL-2167. Kernforschungsanlage Jülich GmbH.
Gerwin, H., 1989. Das zweidimensionale Reaktordynamikprogramm TINTE (Teil II),
spective, the HCP can also be thought of as a repository for storing JÜL-2266. Kernforschungsanlage Juelich GmbH.
recently applied physical models in a transparent way. Honeck, H.C., September 1961. THERMOS – a thermalization transport theory code
The development approach combines the refactoring and for reactor lattice calculations, BNL 5826.
Joanou, G.D., Leshan, E.J., Dudek, J.S., May 1961. GAM-I, a consistent P1 multigroup
reverse engineering of old but validated legacy code with a new
code for the calculation of fast neutron spectra and multigroup constants, GA-
design of an enclosing framework. So far several thousand lines of 1850.
code have been updated according to recent programming stan- Krohn, H., Finken, R., 1983. FRESCO-II – Ein Rechenprogramm zur Berech-
nung der Spaltproduktfreisetzung aus kugelförmigen HTR-Brennelementen in
dards and refactored with respect to the physics tasks. A new data
Bestrahlungs- und Ausheizexperimenten, JÜL-Spez-212.
input concept for HCP based on XML is currently being developed. Moormann, R., 1992. Source term estimation for small sized HTRs, Jül-2669.
The usage of a version control system, as well as a set of test cases Nünighoff, K., Li, J., Druska, C., Allelein, H.-J., 2010. Status of updating the cross sec-
and regression tests, guarantees the stability and the predictive tion library of the juelich reactor dynamics codes TINTE/MGT to ENDF-B-VII. In:
PHYSOR 2010, Pittsburgh, PA, USA, May 9–14.
power of the codes. The HCP will be regularly benchmarked against Rütten, H.-J., Haas, K.A., Brockmann, H., Scherer, W., 2005. V.S.O.P. (99/05) computer
V.S.O.P. and MGT, as these codes still represent the reference. code system, JÜL report 4189. Forschungszentrum Jülich.
406 H.-J. Allelein et al. / Nuclear Engineering and Design 251 (2012) 400–406

Schlösser, J., 1963. MUPO – an IBM-7090 programme to calculate neutron spectra Struth, S., et al., 1999. Component exposure in hypothetical accidents with very fast
and multigroup constants, Dragon report D.P.172. depressurization in a HTR module reactor. Nuclear Engineering and Design 190,
Scholthaus, S., December 2009. Entwicklung eines XML-Schemas für die Eingabe- 297–302.
datei der nuklearen Daten des Fortranprogamms MGT, Seminararbeit. Verfondern, K., Nabielek, H., 1985. PANAMA – Ein Rechenprogramm zur Vorher-
Forschungszentrum Jülich. sage des Partikelbruchanteils von TRISO-Partikeln unter Störfallbedingungen,
Stöcker, B., 1998. Untersuchungen zur selbsttätigen Nachwärmeabfuhr bei Jül-Spez-298. KFA Jülich.
Hochtemperaturreaktoren unter besonderer Berücksichtigung der Naturkon-
vektion, JÜL-3504.