- Email: [email protected]
Progress on the development of a fully integrated HTR code package
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 b
Forschungszentrum Jülich GmbH, Institut für Energieforschung (IEK), Sicherheitsforschung und Reaktortechnik (IEK-6), 52425 Jülich, Germany RWTH Aachen, Lehrstuhl für Reaktorsicherheit und -technik, 52064 Aachen, Germany
a r t i c l e
i n f o
Article history: Received 21 January 2011 Received in revised form 11 September 2011 Accepted 12 September 2011
a b s t r a c t A variety of computer codes have been developed, validated and optimized to simulate the different safety and operational aspects of HTRs. In order to overcome the present limitations of these codes and to exploit the advantages of modern computer clusters, a project has been initiated to integrate these individual programs into a consistent code package applying state-of-the-art programming techniques 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 reactor 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 history of high-temperature reactor (HTR) prototypes in Germany is closely related to Forschungszentrum Jülich and its ‘Institute of Safety Research and Reactor Technology (IEK-6)’. Whereas HTR research at IEF-6 formerly focused on the development of pebble bed reactor designs, today the key task is the evaluation and improvement of safety features during normal operation and accident conditions. For this purpose a variety of computer codes have been developed, validated, and optimized to simulate the different safety and operational aspects of HTRs. These codes are widely used today and have also been applied in recent licensing procedures, such as for the Chinese HTR-PM. The code infrastructure currently in use is shown in Fig. 1. The two multi-physics codes V.S.O.P. (Rütten et al., 2005) and MGT (Druska et al., 2009; Gerwin, 1987, 1989) are applied to simulate the primary loop of an HTR. While V.S.O.P. is used for core design, fuel cycle, and reactor operation simulation on a long time scale, MGT is applied to study the dynamical behavior of an HTR on a short time scale. Currently a 3D version of MGT is being validated as well. Both codes offer a wide range of physics modules including 2D/3D coupled neutronics and thermohydraulics, fuel shuffling, burnup, forced flow and natural convection, gas mixture and gas diffusion, as well as graphite corrosion chemistry (e.g. when considering air or water ingress). As a supplement to these codes, special questions related to rapid depressurization accidents of an HTR have been addressed with the code DIREKT (Struth et al., 1999).
The determination of the power and temperature history with correlated burnup and isotope compositions can then be used to run fission product release and fuel performance codes such as FRESCO-II (Krohn and Finken, 1983) and PANAMA (Verfondern and Nabielek, 1985). These codes read calculated temperatures from V.S.O.P. and MGT to determine the release rates of important isotopes. SPATRA (Moormann, 1992) is able to simulate the transport and position of fission products on metallic surfaces. 2. Benefits of the new HTR code package The heterogeneous infrastructure of computer codes has led to some major limitations and drawbacks with respect to functionality and flexibility. The new HTR code package (HCP) will overcome these issues. It will consist of a software backbone for program flow control, user I/O, 2D/3D solvers and other program services. Code modules for specific tasks can then be coupled to the HCP backbone code (see Fig. 3). This allows different physical models to be included in a very flexible manner. While the coupling between the thermohydraulics and neutronics module, for example, will be turned on by default, other models such as the calculation of fission product release or dust migration in the core can be included on demand. In the following, some examples are given of how HCP will overcome the current drawbacks and limitations with respect to physical models and code structure. 2.1. Impact on physical models
∗ Corresponding author. Tel.: +49 2461 61 6071. E-mail address: [email protected] (St. Kasselmann). 0029-5493/$ – see front matter © 2011 Elsevier B.V. All rights reserved. doi:10.1016/j.nucengdes.2011.09.053
The most important issue is the simulation of long-term reactor operation with V.S.O.P. and short-term reactor transients, as well
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 alternating operating conditions of an HTR because a huge effort is required to create several input files by hand. As the HCP will contain one consistent module for neutronics and one for thermohydraulics, any desired sequence of steady-state and transient operating conditions can be simulated. Another issue is the calculation of fission product releases with FRESCO-II. At the moment, only one flow channel within the core is taken into account and the distinct temperature profile inside the fuel pebble is neglected. As the FRESCO-II code will be an integral part of the HCP, fission product release calculations can be performed for each core zone and time step including the temperature profiles of the pebbles. Also, the transport of the fission products within the primary loop will be considered by extending the MGT gas flow model. A further example is the usage of different spectrum calculation 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 fast and THERMOS (Honeck, 1961) for the thermal part of the neutron energy spectrum. In the first step, all three libraries have been updated according to ENDF/B-VII.0 (Nünighoff et al., 2010). In the course of the ongoing code integration process, these spectral codes will be replaced by the new 1D spectrum code TOTMOS (Brockmann, 2010). TOTMOS extends the capabilities of THERMOS to the epithermal and fast energy range of the neutron spectrum. In HCP, all modules use data from one consistent XML data library. This library can be generated fully automatically by the new code HCPLibGen. Currently it contains decay data for 3842 nuclides, cross section data for 393 nuclides and fission yields for 31 nuclides. Especially for pebble bed reactors, the simulation of fuel shuffling is a major task. Therefore a feasibility study has been launched to investigate a new model which will share the same grid with all other code modules. With this new approach, it will also be possible to simulate azimuthally differing flow profiles as well as stagnant zones. Also fuel piles can be modelled. Fig. 2 illustrates the result of a pebble flow simulation for a typical HTR core.
Another new feature of the HCP will be the possibility to simulate aerosol behavior in the primary circuit. This is especially relevant with respect to carbonous dust, which is seen as an important activity carrier at depressurization accident scenarios. The dust module will constitute a coupling of the following models: relevant deposition models (especially turbulent deposition, thermophoresis, inertial impaction and gravitational settling), Rock’n Roll resuspension model, particle adhesion for rough surfaces as well as multi-layer deposits and convective dust transport within the primary circuit. A number of further minor issues such as the different treatment of decay heat calculation in V.S.O.P. and MGT or the different implementation of SiC-layer corrosion in FRESCO-II and PANAMA, will also be harmonized within HCP. 2.2. Impact on code structure Although V.S.O.P. and MGT are designed to simulate different aspects of the primary loop, similar input data has to be provided for both codes separately (e.g. grid geometry, material definitions, and cross sections). This approach almost doubles the amount of input data necessary to run a single reactor model. Furthermore, the existence of different nuclear libraries in the two codes requires an interface program to mediate between the different codes. In the HCP, only one set of nuclear data has to be provided and will be applied consistently for all the different physical modules. As both codes contain some similar physical models and apply similar algorithms, there is a high level of code duplication. Currently, decisions are being made as to which parts of each code are to be continuously developed and which codes will be ‘frozen’ and archived appropriately. The fact that V.S.O.P., MGT and DIREKT, for example, contain only slightly different thermohydraulics models led to the decision to unify these parts of the code. This will reduce the amount of source code to be maintained in this domain by a factor of up to three, while still providing all the functions. Similar 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 refactorization 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
Fig. 2. Snapshot of a pebble flow simulation (indicated by color markers) for a typical HTR core geometry (left: initial state, right: state after a number of shuffling steps). (For interpretation of the references to color in this figure legend, the reader is referred to the web version of the article.)
both in V.S.O.P. and MGT. This issue will be resolved by extracting and adapting only the disjoint code parts leading to a unique set of code within HCP. The decision to switch to the TOTMOS code is motivated not only by physical reasons, but also by the fact that for every new cross section dataset published up to now three different libraries have to be updated. Another topic which is becoming more and more significant, especially with respect to full 3D simulation models, is performance. Recent studies (Druska, 2009) of the matrix solvers currently used in our codes have shown that the performance gain when applying more advanced algorithms (e.g. from LAPACK, Anderson et al., 1999) seems to be limited. Work has therefore started on exploring the advantages of solving the diffusion equations on Multi-Core CPUs and parallel computing systems. Unfortunately, the present code structure will not allow parallel computers to run the codes efficiently. Significant modifications have to be made here. All these aspects illustrate the need for a major code review and consolidation process. This finally resulted in the development of the HTR code package, officially launched in November 2009.
Refactoring is a disciplined technique for restructuring an existing body of code, thus altering its internal structure without changing its external behavior (Fowler, 1999). The goals of refactorization 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 problems 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. Another part of MGT which has been reviewed is the spectrum calculation program. This program calculates the critical spectrum of a bare homogeneous reactor in 43 neutron energy groups, which 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 to the large number of nested logical structures and goto statements. Fig. 4 illustrates the code layout after the first iteration of refactoring. As a side effect, the amount of code was reduced by about 15% while at the same time providing better usability. 3.2. Aspects of software design While refactoring is clearly a bottom-up process, designing completely new software is generally a top-down approach. The latter means forming a high-level structural picture of the code and then moving down from that high-level perspective to the details of implementation. The development of the HCP is a combination of the two approaches. The total sum of FORTRAN source code currently in use amounts to almost 100k lines of code (LOC) and represents several thousand person-months of work. Nevertheless, the purely procedural structure of the codes which has evolved over the last few decades does not meet the requirements for a modular and 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 approach that should be chosen in the long run. It is widely accepted that software complexity and code maintenance costs can be reduced by choosing an appropriate object-oriented (OO) design approach. The main goal here is to divide the responsibilities of the program among its objects. An object-oriented software design
thus strives to reduce the amount of coupling between the different objects, which reduces the complexity of the entire program. An OO approach is also mandatory for collaboration with other research facilities with respect to future HCP development work. In the field of nuclear reactor codes, objects like Meshes, Batches, FuelElements, 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 structure of the new XML input file discussed later in this paper, it is far more difficult to redesign the complete code. Therefore, a strategy is pursued according to which interfaces hide the procedural structure of the existing code modules from newer redesigned object-oriented modules. At the same time, the HTR software backbone is designed using an OO approach right from the beginning. Finally, the interface of each module is adapted to permit communication via objects in both directions. 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 well as problem specific data types. Also the fission product release code FRESCO and the fuel performance code PANAMA have been successfully redesigned and initial progress has been made in defining a FuelElement object that serves as an interface between FRESCO/PANAMA and MGT. This will allow fission product release rates to be calculated for each core zone and the whole reactor lifetime, taking into account steady states as well as transients.
3.3. Data model and I/O To run programs such as V.S.O.P. and MGT, a large volume of input data has to be provided by the user and a great deal of information is supplied by the codes to the user. The recent approach of setting up and printing out huge formatted text files has reached its limits with respect to efficiency and usability. Therefore, a new object-oriented data model is being developed based on XML (Extensible Markup Language) and binary data files. Fig. 5 shows a simplified example of the XML data representation of a reflector mesh as part of the nuclear data input. A more detailed
discussion of this new XML input concept and a first feasibility study can be found in Scholthaus (2009). For the systematic analysis of the new binary output data, a C++-based toolbox called MAVIS (Multiple Data Analysis and Visualization) has been developed. This allows data written by the HCP to be printed and compared in a very flexible manner. MAVIS is based on ROOT, a widely used analysis framework originally developed for the field of high-energy physics (Brun and Rademakers, 1997).
3.4. Software quality assurance There is a large amount of literature on software quality issues. International standards like ISO/IEC 25000 have also been defined. In the day-to-day work on source code it all comes down to three major pillars: version control, regression/unit tests, and project automation. As the HTR code package couples existing codes in a highly integrated 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 strategies such as version control, regression tests, and automation tools are applied. With the tool subversion (Collins-Sussman et al., 2004), every set of code modifications is tagged, documented, and uploaded to a repository. So far there are more than 470 documented and tested code revisions of MGT, for example, which are accessible through a file server by every member of the working group. It needs to be emphasized that the team is strictly subdivided into people developing the software and people running the software tests and validation scenarios. Before a commit, each new revision is cross-checked with the former code revision using a representative set of distinct test cases
H.-J. Allelein et al. / Nuclear Engineering and Design 251 (2012) 400–406
Detailed Neutronics
Detailed Thermohydraulics
405
Altogether, this approach leads to much lower code maintenance costs and has already been proven to reduce the implementation and validation time of new physics models. 5. Outlook
MCNP(X) DOORS MC / SN Transport Codes
CFD Computational Fluid Dynamics
COCOSYS
HCP
Containment Code System Safety
Coupled Physics of an HTR Primary Loop
HCP will be one of four software tools applied for future safety research activities at IEK-6 (see Fig. 6). While HCP will be a multiphysics code system for the simulation of an HTR primary loop, CFX (Ansys Inc., 2007) and MCNP (Briesmeister, 1986) will be used for detailed studies in the field of thermohydraulics and neutronics, 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 validated with data made available within the envisaged HTR-10 International Research Framework. Acknowledgements
Containment / Confinement
Multi-Physics Code Integration
Fig. 6. Overview of the future code infrastructure applied in the field of reactor safety research.
(regression testing). For MGT a special simulation scenario was defined combining a steady state calculation with a sequence of transients like TWCR, LOFC, DLOFC and air ingress. It can thus be ensured that every code module is invoked and tested. The results are than compared to reference data of a former code version which was extensively benchmarked against experiments. In the near future, these tests will be accompanied by so-called unit tests checking every subroutine for correct behavior over the whole input parameter space. Finally, project automation tools, such as makefiles, batch scripts, and integrated development environments (IDE) like Eclipse, are applied to prevent breaking a build and to ensure a standardized working environment. 4. Conclusions This paper describes the progress achieved in developing a fully integrated HTR code package (HCP). The HCP will consist of a software backbone for program flow control, user I/O, 2D/3D solvers and other program services. Code modules for the specific tasks can then be coupled to the HCP backbone code. This allows different physical models to be included in the most flexible manner. As HTR reactor systems will be marketable in a medium-term perspective, the HCP can also be thought of as a repository for storing recently applied physical models in a transparent way. The development approach combines the refactoring and reverse engineering of old but validated legacy code with a new design of an enclosing framework. So far several thousand lines of code have been updated according to recent programming standards and refactored with respect to the physics tasks. A new data input concept for HCP based on XML is currently being developed. The usage of a version control system, as well as a set of test cases and regression tests, guarantees the stability and the predictive power of the codes. The HCP will be regularly benchmarked against V.S.O.P. and MGT, as these codes still represent the reference.
The authors are indebted to their colleagues C. Druska, S. Jühe, S. Kelm, J. Li, H.-J. Rütten, S. Scholthaus and S. Struth for support and valuable discussions. References Allelein, H.-J., Arndt, S., Klein-Heßling, W., Schwarz, S., Spengler, C., Weber, G., 2008. COCOSYS: status of development and validation of the German containment code system. Nuclear Engineering and Design 238, 872–889. Anderson, E., Bai, Z., et al., 1999. LAPAck Users’ Guide, 3rd edition. SIAM, Philadelphia, http://www.netlib.org/lapack/lug. Ansys Inc., 2007. ANSYS CFX Version 11: Solver Theory. Briesmeister, J.F., September 1986. MCNP – A Monte Carlo Code for Neutron and Photon Transport. Los Alamos National Laboratory, LA-7396-M Revision 2. Brockmann, H., 2010. TOTMOS – an integral transport code for calculating neutron spectra and multigroup cross sections, internal report. Forschungszentrum Jülich. Brun, R., Rademakers, F., 1997. ROOT – an object oriented data analysis framework. Proceedings AIHENP’96 Workshop, Lausanne, September 1996. Nuclear Instruments & Methods in Physics Research A 389, 81–86, http://root.cern.ch/. Collins-Sussman, B., Fitzpatrick, B.W., Miachel Pilato, C., June 2004. Version Control with Subversion – Next Generation Open Source Version Control. O’Reilly Media. Druska, C., January 2009. Analyse direkter und iterativer Lösungsverfahren für Gleichungssysteme mit nichtsymmetrischen, dünnbesetzten Matrizen zur Optimierung neutronenphysikalischer sowie thermodynamischer Simulationsverfahren, Masterarbeit. Aachen University of Applied Sciences (Jülich Campus)/Forschungszentrum Jülich. Druska, C., Kasselmann, St., Lauer, A., 2009. Investigations of space-dependent safety-related parameters of a PBMR-like HTR in transient operating conditions applying a multi-group diffusion code. Nuclear Engineering and Design 239 (March (3)), 508–520, ISSN 0029-5493. Fowler, M., 1999. Refactoring: Improving the Design of Existing Code. AddisonWesley. Fröhling, W., Roes, J., 1995. Zur chemischen Stabilität bei innovativen Kernreaktoren, JÜL-3118. Forschungszentrum Jülich. Gerwin, H., 1987. Das zweidimensionale Reaktordynamikprogramm TINTE (Teil I), JÜL-2167. Kernforschungsanlage Jülich GmbH. Gerwin, H., 1989. Das zweidimensionale Reaktordynamikprogramm TINTE (Teil II), JÜL-2266. Kernforschungsanlage Juelich GmbH. Honeck, H.C., September 1961. THERMOS – a thermalization transport theory code for reactor lattice calculations, BNL 5826. Joanou, G.D., Leshan, E.J., Dudek, J.S., May 1961. GAM-I, a consistent P1 multigroup code for the calculation of fast neutron spectra and multigroup constants, GA1850. Krohn, H., Finken, R., 1983. FRESCO-II – Ein Rechenprogramm zur Berechnung der Spaltproduktfreisetzung aus kugelförmigen HTR-Brennelementen in Bestrahlungs- und Ausheizexperimenten, JÜL-Spez-212. Moormann, R., 1992. Source term estimation for small sized HTRs, Jül-2669. Nünighoff, K., Li, J., Druska, C., Allelein, H.-J., 2010. Status of updating the cross section library of the juelich reactor dynamics codes TINTE/MGT to ENDF-B-VII. In: PHYSOR 2010, Pittsburgh, PA, USA, May 9–14. Rütten, H.-J., Haas, K.A., Brockmann, H., Scherer, W., 2005. V.S.O.P. (99/05) computer 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 and multigroup constants, Dragon report D.P.172. Scholthaus, S., December 2009. Entwicklung eines XML-Schemas für die Eingabedatei der nuklearen Daten des Fortranprogamms MGT, Seminararbeit. Forschungszentrum Jülich. Stöcker, B., 1998. Untersuchungen zur selbsttätigen Nachwärmeabfuhr bei Hochtemperaturreaktoren unter besonderer Berücksichtigung der Naturkonvektion, JÜL-3504.
Struth, S., et al., 1999. Component exposure in hypothetical accidents with very fast depressurization in a HTR module reactor. Nuclear Engineering and Design 190, 297–302. Verfondern, K., Nabielek, H., 1985. PANAMA – Ein Rechenprogramm zur Vorhersage des Partikelbruchanteils von TRISO-Partikeln unter Störfallbedingungen, Jül-Spez-298. KFA Jülich.
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 b
Forschungszentrum Jülich GmbH, Institut für Energieforschung (IEK), Sicherheitsforschung und Reaktortechnik (IEK-6), 52425 Jülich, Germany RWTH Aachen, Lehrstuhl für Reaktorsicherheit und -technik, 52064 Aachen, Germany
a r t i c l e
i n f o
Article history: Received 21 January 2011 Received in revised form 11 September 2011 Accepted 12 September 2011
a b s t r a c t A variety of computer codes have been developed, validated and optimized to simulate the different safety and operational aspects of HTRs. In order to overcome the present limitations of these codes and to exploit the advantages of modern computer clusters, a project has been initiated to integrate these individual programs into a consistent code package applying state-of-the-art programming techniques 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 reactor 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 history of high-temperature reactor (HTR) prototypes in Germany is closely related to Forschungszentrum Jülich and its ‘Institute of Safety Research and Reactor Technology (IEK-6)’. Whereas HTR research at IEF-6 formerly focused on the development of pebble bed reactor designs, today the key task is the evaluation and improvement of safety features during normal operation and accident conditions. For this purpose a variety of computer codes have been developed, validated, and optimized to simulate the different safety and operational aspects of HTRs. These codes are widely used today and have also been applied in recent licensing procedures, such as for the Chinese HTR-PM. The code infrastructure currently in use is shown in Fig. 1. The two multi-physics codes V.S.O.P. (Rütten et al., 2005) and MGT (Druska et al., 2009; Gerwin, 1987, 1989) are applied to simulate the primary loop of an HTR. While V.S.O.P. is used for core design, fuel cycle, and reactor operation simulation on a long time scale, MGT is applied to study the dynamical behavior of an HTR on a short time scale. Currently a 3D version of MGT is being validated as well. Both codes offer a wide range of physics modules including 2D/3D coupled neutronics and thermohydraulics, fuel shuffling, burnup, forced flow and natural convection, gas mixture and gas diffusion, as well as graphite corrosion chemistry (e.g. when considering air or water ingress). As a supplement to these codes, special questions related to rapid depressurization accidents of an HTR have been addressed with the code DIREKT (Struth et al., 1999).
The determination of the power and temperature history with correlated burnup and isotope compositions can then be used to run fission product release and fuel performance codes such as FRESCO-II (Krohn and Finken, 1983) and PANAMA (Verfondern and Nabielek, 1985). These codes read calculated temperatures from V.S.O.P. and MGT to determine the release rates of important isotopes. SPATRA (Moormann, 1992) is able to simulate the transport and position of fission products on metallic surfaces. 2. Benefits of the new HTR code package The heterogeneous infrastructure of computer codes has led to some major limitations and drawbacks with respect to functionality and flexibility. The new HTR code package (HCP) will overcome these issues. It will consist of a software backbone for program flow control, user I/O, 2D/3D solvers and other program services. Code modules for specific tasks can then be coupled to the HCP backbone code (see Fig. 3). This allows different physical models to be included in a very flexible manner. While the coupling between the thermohydraulics and neutronics module, for example, will be turned on by default, other models such as the calculation of fission product release or dust migration in the core can be included on demand. In the following, some examples are given of how HCP will overcome the current drawbacks and limitations with respect to physical models and code structure. 2.1. Impact on physical models
∗ Corresponding author. Tel.: +49 2461 61 6071. E-mail address: [email protected] (St. Kasselmann). 0029-5493/$ – see front matter © 2011 Elsevier B.V. All rights reserved. doi:10.1016/j.nucengdes.2011.09.053
The most important issue is the simulation of long-term reactor operation with V.S.O.P. and short-term reactor transients, as well
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 alternating operating conditions of an HTR because a huge effort is required to create several input files by hand. As the HCP will contain one consistent module for neutronics and one for thermohydraulics, any desired sequence of steady-state and transient operating conditions can be simulated. Another issue is the calculation of fission product releases with FRESCO-II. At the moment, only one flow channel within the core is taken into account and the distinct temperature profile inside the fuel pebble is neglected. As the FRESCO-II code will be an integral part of the HCP, fission product release calculations can be performed for each core zone and time step including the temperature profiles of the pebbles. Also, the transport of the fission products within the primary loop will be considered by extending the MGT gas flow model. A further example is the usage of different spectrum calculation 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 fast and THERMOS (Honeck, 1961) for the thermal part of the neutron energy spectrum. In the first step, all three libraries have been updated according to ENDF/B-VII.0 (Nünighoff et al., 2010). In the course of the ongoing code integration process, these spectral codes will be replaced by the new 1D spectrum code TOTMOS (Brockmann, 2010). TOTMOS extends the capabilities of THERMOS to the epithermal and fast energy range of the neutron spectrum. In HCP, all modules use data from one consistent XML data library. This library can be generated fully automatically by the new code HCPLibGen. Currently it contains decay data for 3842 nuclides, cross section data for 393 nuclides and fission yields for 31 nuclides. Especially for pebble bed reactors, the simulation of fuel shuffling is a major task. Therefore a feasibility study has been launched to investigate a new model which will share the same grid with all other code modules. With this new approach, it will also be possible to simulate azimuthally differing flow profiles as well as stagnant zones. Also fuel piles can be modelled. Fig. 2 illustrates the result of a pebble flow simulation for a typical HTR core.
Another new feature of the HCP will be the possibility to simulate aerosol behavior in the primary circuit. This is especially relevant with respect to carbonous dust, which is seen as an important activity carrier at depressurization accident scenarios. The dust module will constitute a coupling of the following models: relevant deposition models (especially turbulent deposition, thermophoresis, inertial impaction and gravitational settling), Rock’n Roll resuspension model, particle adhesion for rough surfaces as well as multi-layer deposits and convective dust transport within the primary circuit. A number of further minor issues such as the different treatment of decay heat calculation in V.S.O.P. and MGT or the different implementation of SiC-layer corrosion in FRESCO-II and PANAMA, will also be harmonized within HCP. 2.2. Impact on code structure Although V.S.O.P. and MGT are designed to simulate different aspects of the primary loop, similar input data has to be provided for both codes separately (e.g. grid geometry, material definitions, and cross sections). This approach almost doubles the amount of input data necessary to run a single reactor model. Furthermore, the existence of different nuclear libraries in the two codes requires an interface program to mediate between the different codes. In the HCP, only one set of nuclear data has to be provided and will be applied consistently for all the different physical modules. As both codes contain some similar physical models and apply similar algorithms, there is a high level of code duplication. Currently, decisions are being made as to which parts of each code are to be continuously developed and which codes will be ‘frozen’ and archived appropriately. The fact that V.S.O.P., MGT and DIREKT, for example, contain only slightly different thermohydraulics models led to the decision to unify these parts of the code. This will reduce the amount of source code to be maintained in this domain by a factor of up to three, while still providing all the functions. Similar 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 refactorization 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
Fig. 2. Snapshot of a pebble flow simulation (indicated by color markers) for a typical HTR core geometry (left: initial state, right: state after a number of shuffling steps). (For interpretation of the references to color in this figure legend, the reader is referred to the web version of the article.)
both in V.S.O.P. and MGT. This issue will be resolved by extracting and adapting only the disjoint code parts leading to a unique set of code within HCP. The decision to switch to the TOTMOS code is motivated not only by physical reasons, but also by the fact that for every new cross section dataset published up to now three different libraries have to be updated. Another topic which is becoming more and more significant, especially with respect to full 3D simulation models, is performance. Recent studies (Druska, 2009) of the matrix solvers currently used in our codes have shown that the performance gain when applying more advanced algorithms (e.g. from LAPACK, Anderson et al., 1999) seems to be limited. Work has therefore started on exploring the advantages of solving the diffusion equations on Multi-Core CPUs and parallel computing systems. Unfortunately, the present code structure will not allow parallel computers to run the codes efficiently. Significant modifications have to be made here. All these aspects illustrate the need for a major code review and consolidation process. This finally resulted in the development of the HTR code package, officially launched in November 2009.
Refactoring is a disciplined technique for restructuring an existing body of code, thus altering its internal structure without changing its external behavior (Fowler, 1999). The goals of refactorization 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 problems 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. Another part of MGT which has been reviewed is the spectrum calculation program. This program calculates the critical spectrum of a bare homogeneous reactor in 43 neutron energy groups, which 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 to the large number of nested logical structures and goto statements. Fig. 4 illustrates the code layout after the first iteration of refactoring. As a side effect, the amount of code was reduced by about 15% while at the same time providing better usability. 3.2. Aspects of software design While refactoring is clearly a bottom-up process, designing completely new software is generally a top-down approach. The latter means forming a high-level structural picture of the code and then moving down from that high-level perspective to the details of implementation. The development of the HCP is a combination of the two approaches. The total sum of FORTRAN source code currently in use amounts to almost 100k lines of code (LOC) and represents several thousand person-months of work. Nevertheless, the purely procedural structure of the codes which has evolved over the last few decades does not meet the requirements for a modular and 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 approach that should be chosen in the long run. It is widely accepted that software complexity and code maintenance costs can be reduced by choosing an appropriate object-oriented (OO) design approach. The main goal here is to divide the responsibilities of the program among its objects. An object-oriented software design
thus strives to reduce the amount of coupling between the different objects, which reduces the complexity of the entire program. An OO approach is also mandatory for collaboration with other research facilities with respect to future HCP development work. In the field of nuclear reactor codes, objects like Meshes, Batches, FuelElements, 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 structure of the new XML input file discussed later in this paper, it is far more difficult to redesign the complete code. Therefore, a strategy is pursued according to which interfaces hide the procedural structure of the existing code modules from newer redesigned object-oriented modules. At the same time, the HTR software backbone is designed using an OO approach right from the beginning. Finally, the interface of each module is adapted to permit communication via objects in both directions. 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 well as problem specific data types. Also the fission product release code FRESCO and the fuel performance code PANAMA have been successfully redesigned and initial progress has been made in defining a FuelElement object that serves as an interface between FRESCO/PANAMA and MGT. This will allow fission product release rates to be calculated for each core zone and the whole reactor lifetime, taking into account steady states as well as transients.
3.3. Data model and I/O To run programs such as V.S.O.P. and MGT, a large volume of input data has to be provided by the user and a great deal of information is supplied by the codes to the user. The recent approach of setting up and printing out huge formatted text files has reached its limits with respect to efficiency and usability. Therefore, a new object-oriented data model is being developed based on XML (Extensible Markup Language) and binary data files. Fig. 5 shows a simplified example of the XML data representation of a reflector mesh as part of the nuclear data input. A more detailed
discussion of this new XML input concept and a first feasibility study can be found in Scholthaus (2009). For the systematic analysis of the new binary output data, a C++-based toolbox called MAVIS (Multiple Data Analysis and Visualization) has been developed. This allows data written by the HCP to be printed and compared in a very flexible manner. MAVIS is based on ROOT, a widely used analysis framework originally developed for the field of high-energy physics (Brun and Rademakers, 1997).
3.4. Software quality assurance There is a large amount of literature on software quality issues. International standards like ISO/IEC 25000 have also been defined. In the day-to-day work on source code it all comes down to three major pillars: version control, regression/unit tests, and project automation. As the HTR code package couples existing codes in a highly integrated 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 strategies such as version control, regression tests, and automation tools are applied. With the tool subversion (Collins-Sussman et al., 2004), every set of code modifications is tagged, documented, and uploaded to a repository. So far there are more than 470 documented and tested code revisions of MGT, for example, which are accessible through a file server by every member of the working group. It needs to be emphasized that the team is strictly subdivided into people developing the software and people running the software tests and validation scenarios. Before a commit, each new revision is cross-checked with the former code revision using a representative set of distinct test cases
H.-J. Allelein et al. / Nuclear Engineering and Design 251 (2012) 400–406
Detailed Neutronics
Detailed Thermohydraulics
405
Altogether, this approach leads to much lower code maintenance costs and has already been proven to reduce the implementation and validation time of new physics models. 5. Outlook
MCNP(X) DOORS MC / SN Transport Codes
CFD Computational Fluid Dynamics
COCOSYS
HCP
Containment Code System Safety
Coupled Physics of an HTR Primary Loop
HCP will be one of four software tools applied for future safety research activities at IEK-6 (see Fig. 6). While HCP will be a multiphysics code system for the simulation of an HTR primary loop, CFX (Ansys Inc., 2007) and MCNP (Briesmeister, 1986) will be used for detailed studies in the field of thermohydraulics and neutronics, 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 validated with data made available within the envisaged HTR-10 International Research Framework. Acknowledgements
Containment / Confinement
Multi-Physics Code Integration
Fig. 6. Overview of the future code infrastructure applied in the field of reactor safety research.
(regression testing). For MGT a special simulation scenario was defined combining a steady state calculation with a sequence of transients like TWCR, LOFC, DLOFC and air ingress. It can thus be ensured that every code module is invoked and tested. The results are than compared to reference data of a former code version which was extensively benchmarked against experiments. In the near future, these tests will be accompanied by so-called unit tests checking every subroutine for correct behavior over the whole input parameter space. Finally, project automation tools, such as makefiles, batch scripts, and integrated development environments (IDE) like Eclipse, are applied to prevent breaking a build and to ensure a standardized working environment. 4. Conclusions This paper describes the progress achieved in developing a fully integrated HTR code package (HCP). The HCP will consist of a software backbone for program flow control, user I/O, 2D/3D solvers and other program services. Code modules for the specific tasks can then be coupled to the HCP backbone code. This allows different physical models to be included in the most flexible manner. As HTR reactor systems will be marketable in a medium-term perspective, the HCP can also be thought of as a repository for storing recently applied physical models in a transparent way. The development approach combines the refactoring and reverse engineering of old but validated legacy code with a new design of an enclosing framework. So far several thousand lines of code have been updated according to recent programming standards and refactored with respect to the physics tasks. A new data input concept for HCP based on XML is currently being developed. The usage of a version control system, as well as a set of test cases and regression tests, guarantees the stability and the predictive power of the codes. The HCP will be regularly benchmarked against V.S.O.P. and MGT, as these codes still represent the reference.
The authors are indebted to their colleagues C. Druska, S. Jühe, S. Kelm, J. Li, H.-J. Rütten, S. Scholthaus and S. Struth for support and valuable discussions. References Allelein, H.-J., Arndt, S., Klein-Heßling, W., Schwarz, S., Spengler, C., Weber, G., 2008. COCOSYS: status of development and validation of the German containment code system. Nuclear Engineering and Design 238, 872–889. Anderson, E., Bai, Z., et al., 1999. LAPAck Users’ Guide, 3rd edition. SIAM, Philadelphia, http://www.netlib.org/lapack/lug. Ansys Inc., 2007. ANSYS CFX Version 11: Solver Theory. Briesmeister, J.F., September 1986. MCNP – A Monte Carlo Code for Neutron and Photon Transport. Los Alamos National Laboratory, LA-7396-M Revision 2. Brockmann, H., 2010. TOTMOS – an integral transport code for calculating neutron spectra and multigroup cross sections, internal report. Forschungszentrum Jülich. Brun, R., Rademakers, F., 1997. ROOT – an object oriented data analysis framework. Proceedings AIHENP’96 Workshop, Lausanne, September 1996. Nuclear Instruments & Methods in Physics Research A 389, 81–86, http://root.cern.ch/. Collins-Sussman, B., Fitzpatrick, B.W., Miachel Pilato, C., June 2004. Version Control with Subversion – Next Generation Open Source Version Control. O’Reilly Media. Druska, C., January 2009. Analyse direkter und iterativer Lösungsverfahren für Gleichungssysteme mit nichtsymmetrischen, dünnbesetzten Matrizen zur Optimierung neutronenphysikalischer sowie thermodynamischer Simulationsverfahren, Masterarbeit. Aachen University of Applied Sciences (Jülich Campus)/Forschungszentrum Jülich. Druska, C., Kasselmann, St., Lauer, A., 2009. Investigations of space-dependent safety-related parameters of a PBMR-like HTR in transient operating conditions applying a multi-group diffusion code. Nuclear Engineering and Design 239 (March (3)), 508–520, ISSN 0029-5493. Fowler, M., 1999. Refactoring: Improving the Design of Existing Code. AddisonWesley. Fröhling, W., Roes, J., 1995. Zur chemischen Stabilität bei innovativen Kernreaktoren, JÜL-3118. Forschungszentrum Jülich. Gerwin, H., 1987. Das zweidimensionale Reaktordynamikprogramm TINTE (Teil I), JÜL-2167. Kernforschungsanlage Jülich GmbH. Gerwin, H., 1989. Das zweidimensionale Reaktordynamikprogramm TINTE (Teil II), JÜL-2266. Kernforschungsanlage Juelich GmbH. Honeck, H.C., September 1961. THERMOS – a thermalization transport theory code for reactor lattice calculations, BNL 5826. Joanou, G.D., Leshan, E.J., Dudek, J.S., May 1961. GAM-I, a consistent P1 multigroup code for the calculation of fast neutron spectra and multigroup constants, GA1850. Krohn, H., Finken, R., 1983. FRESCO-II – Ein Rechenprogramm zur Berechnung der Spaltproduktfreisetzung aus kugelförmigen HTR-Brennelementen in Bestrahlungs- und Ausheizexperimenten, JÜL-Spez-212. Moormann, R., 1992. Source term estimation for small sized HTRs, Jül-2669. Nünighoff, K., Li, J., Druska, C., Allelein, H.-J., 2010. Status of updating the cross section library of the juelich reactor dynamics codes TINTE/MGT to ENDF-B-VII. In: PHYSOR 2010, Pittsburgh, PA, USA, May 9–14. Rütten, H.-J., Haas, K.A., Brockmann, H., Scherer, W., 2005. V.S.O.P. (99/05) computer 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 and multigroup constants, Dragon report D.P.172. Scholthaus, S., December 2009. Entwicklung eines XML-Schemas für die Eingabedatei der nuklearen Daten des Fortranprogamms MGT, Seminararbeit. Forschungszentrum Jülich. Stöcker, B., 1998. Untersuchungen zur selbsttätigen Nachwärmeabfuhr bei Hochtemperaturreaktoren unter besonderer Berücksichtigung der Naturkonvektion, JÜL-3504.
Struth, S., et al., 1999. Component exposure in hypothetical accidents with very fast depressurization in a HTR module reactor. Nuclear Engineering and Design 190, 297–302. Verfondern, K., Nabielek, H., 1985. PANAMA – Ein Rechenprogramm zur Vorhersage des Partikelbruchanteils von TRISO-Partikeln unter Störfallbedingungen, Jül-Spez-298. KFA Jülich.