Beta Version of the DOCPAGANSA GUI and Control Module Krešimir Trontl, Mario Matijević, Dubravko Pevec, Ivan Mihaljević
University of Zagreb, Faculty of Electrical Engineering and Computing Unska 3
10000, Zagreb, Croatia
kresimir.trontl@fer.hr, mario.matijevic@fer.hr, dubravko.pevec@fer.hr, ivan.mihaljevic@fer.hr
ABSTRACT
The DOCPAGANSA (“Development of Code Package for Advanced Gamma and Neutron Shielding Analyses”) research project aims to develop an integrated environment that would enable the shielding designer to employ simplified, as well as advanced computational procedures and codes. Appropriate graphical user interface and control module are required to enable efficient shielding project management and interaction between simplified and complex calculations. In this paper we report on the environmental structure draft and preliminary drafts of these two components.
1 INTRODUCTION
One of the objectives of the research project DOCPAGANSA (“Development of Code Package for Advanced Gamma and Neutron Shielding Analyses”) is the development of the integrated environment which would enable the radiation shielding designer to perform preliminary as well as final steps of the design process. It is presumed that preliminary design stage would be performed by simplified calculational tools based on engineering methods, while the final stage would be performed by complex calculational tools based on deterministic approach and Monte Carlo simulations. These presumptions originate from the authors’ experience in shielding research conducted in the past as well as from the educational activities carried out at the faculty. Overall findings are as follows:
Engineering methods – lack in modelling capabilities, accuracy, and precision;
are easily implemented in software solutions; do not require expert knowledge to be successfully used; do not require strong hardware resources; can produce the results relatively fast,
Complex methods – have advanced modelling capabilities: are accurate and precise is calculation; are hard to implement in software solutions; generally require expert knowledge to be successfully used; require strong hardware resources and are time consuming.
There are a number of computer codes for simplified, as well as advanced radiation shielding calculations. Their development started more then fifty years ago. Over the years some were modified to incorporate new methods and nuclear data, some were abandoned, and new ones were designed. There are also a number of auxiliary tools developed in order to help the designers during the input preparation phase (graphical user interfaces for older command prompt codes) or to enhance the analyses of the results (tools for creating graphs or pictures).
However, to the best of our knowledge, an integrated environment that would enable simultaneous usage of both, simplified and complex, approaches with incorporated auxiliary
tools, does not exist. If a designer is using a simplified code there is not an easy way for him to transform the prepared simplified input into an input required to run complex calculations.
In this paper we report on the draft structure of the integrated environment of the DOCPAGANSA code and we present preliminary versions of the main control module and graphical user interface.
The basics of the integrated environment structure are presented in Section 2. The rough sketch of the graphical user interface and the general idea of the control module are presented in Section 3. Conclusions and future work are given in the Section 4.
2 STRUCTURE OF THE DOCPAGANSA INTEGRATED ENVIRONMENT
The DOCPAGANSA integrated environment is supposed to enable the user to conduct all stages of the radiation shielding design process in a fluid manner. For the environment to be fully functional, the following components and corresponding functionalities have been identified:
Graphical User Interface (GUI) and underlying control module– enable the user straightforward link and intuitive interactions with all components of the system,
Front-end component – enable the user preparation of inputs required by different calculational tools,
Back-end component – enable the user to conduct analyses of the results and provide output forms readable by common software applications (MS Office, graphical software, etc.),
Simplified calculational component – enable the user to conduct simplified radiation shielding calculations,
Advanced calculational component – enable the user to conduct advanced (complex) radiation shielding calculations.
The envisioned structure of the DOCPAGANSA integrated environment is depicted in Figure 1.
Figure 1: Structure of DOCPAGANSA integrated environment
The key property of the front-end component should be the ability to automatically transform input data into forms required by either simplified or advanced calculational tools.
To enable that ability the decision on which calculational tools would be used had to be made.
The point kernel method is often used for the preliminary, design stage. It is based on the Green functions. The quantity of interest (flux, or dose rate) is calculated by multiplying the uncollided flux with the parameter called buildup factor which accounts for radiation scattering (i.e. increase or buildup) within the shield. Calculation of the scattered-flux density is, in general, much more complex. The accuracy of the final result is highly influenced by the precision of buildup factors used in the calculation [1]. Traditionally, buildup factors are used for gamma radiation calculations and are either tabulated or calculated by appropriate methods. The existing codes have the ability to calculate dose rates without and with buildup factors using a variety of fit-functions such as linear, quadratic, polynomial, Taylor, Berger, and Capo forms [3]. Dose buildup factors depend on photon energy, the mean free path traveled by a photon in the material of consideration, geometry of the source, and geometry of the attenuating medium. Buildup is calculated automatically by the code for a shielding material specified by the user (closest to the point detector). Recent research indicated that a novel method could be used for gamma as well as neutron buildup factor determination. The method is based on the machine learning technique called Support Vector Regression (SVR) [2]. To be able to incorporate novel method into existing software, like for example QAD- CGGP, modifications of the source code would be required. Past experience with incorporation of multi-layer and multi-source option into QAD-CGGP [reference] suggests that such modifications would be rather time consuming. Therefore, the decision has been made to develop a new simplified calculational tool based on point kernel method with option to easily switch between different buildup factor determination procedures, as well as the capability of selecting the most appropriate value by statistical analyses.
The complexity of software implementations of advanced calculational methods, like Monte Carlo method, as well as the existence of a number of widely used and tested codes discouraged us from developing a new implementation from scratch. Therefore, the selection of the appropriate code had to be made. After careful consideration MCNP has been selected.
The MCNP6.1.1b [4] is a general-purpose Monte Carlo N-Particle code that can be used for neutron, photon, electron, or coupled neutron/photon/electron transport. The MCNP treats an arbitrary three-dimensional configuration of materials in geometric cells bounded by first- and second-degree surfaces and fourth-degree elliptical tori. For neutrons, all reactions given in a particular cross-section evaluation (such as ENDF/B-VI) [5] are accounted for. Thermal neutrons are described by both the free gas and S(α,β) models. Important standard features that make MCNP very versatile and easy to use include a powerful general source, criticality source, and surface source; both geometry and output tally plotters; a rich collection of variance reduction techniques; a flexible tally structure; and an extensive collection of cross- section data. Energy ranges are from 10-11 to 20 MeV for neutrons with data up to 150 MeV for some nuclides, 1 keV to 1 GeV for electrons, and 1 keV to 100 GeV for photons.
Pointwise cross-section data are used within MCNP: auxiliary program MAKXSF which prepares cross-section libraries with Doppler broadening. In general, MCNP input is more complex than the one required by simple point-kernel code. To ease the transformation of user’s input parameters into the form suitable for MCNP run, the generic template of the MCNP input has been prepared and used by the front-end component. Input file begins with one-line problem title card and the rest is divided into a 3 distinct sections (blank line being divisor): cell cards, surface cards and data cards. Input file is terminated with a blank line terminator. Surface cards are defined with mnemonics and coefficients of analytical surfaces and are used to construct cells (volumes) implementing Booles' algebra. Definition of
materials, volumes, temperatures, sources, tally objects, variance reduction parameters, response functions, and problem cut-off cards such as total CPU time or number of histories, are all part of third section of the input file. All input lines are limited to 80 columns. Cell, surface, and data cards must all begin within the first five columns. Entries are separated by one or more blanks. Numbers can be integer or floating point. Blanks filling the first five columns indicate a continuation of the data from the last named card. A dollar sign ($) terminates data entry on a line, and everything hereafter is interpreted as a comment.
Comment cards can be used anywhere in the INP file after the problem title card and before the blank terminator card. Comment lines must have a C character somewhere in columns 1-5 followed by at least one blank. MCNP makes extensive checks of the input file for the user errors by calling the module IMCN. A part of the MCNP template is depicted in Figure 2.
Figure 2: Part of the MCNP generic template
Efforts to develop an integrated radiation shielding design environment have been going on for some time and draft versions of different components have been made separately by DOCPAGANSA team members. However, the attempts to couple existent pieces into a whole proved to be rather inefficient and troublesome. Therefore, one of the key issues for successful development of the DOCPAGANSA environment is the selection of the targeted operating system and the software tools to be used by all team members in the development process.
Mainly due to two reasons, the selected operating system is Windows. All team members extensively use Windows. Also, over the years Windows has maintained a fairly
standard version structure, with updates and versions split into tiers, while Linux is far more complex. As Linux is an open source system, it allows modifications by anyone for their own purposes. As a result there are hundreds of Linux-based operating systems known as distributions, or 'distros'. This makes it incredibly difficult to choose between them, far more complicated than simply picking Windows 7, Windows 8 or Windows 10 [6]. The only out- of-house component to be used in the DOCPAGANSA environment is the MCNP code which can run, among others, under Windows 7 system. The team is successfully using it under Windows 7 64-bit on Intel Core i-5 CPU at 3.4 GHz using 32 GB RAM.
The selection of software development tool is much more complex question. Despite then fact that FORTRAN holds some advantages over other programming languages, especially for extensive numerical procedures, the decision is to use one of the existing C versions as the main programming language. The main reason is that the majority of the team members are familiar with C, rather than with FORTRAN. To stay up to date, the selected Integrated Development Environment is the Microsoft Visual Studio.
3 GRAPHICAL USER INTERFACE AND CONTROL MODULE
To enable the user straightforward link and intuitive interactions with all components of the DOCPAGANSA system the appropriate graphical user interface and underlying control module are required. Our initial effort is focused on these two elements.
After careful analyses of the actions that the DOCPAGANSA environment is supposed to handle, it was concluded that the most challenging task would be the development of the graphical tool that would enable the user visualization of the problem geometry. To avoid any propriety issues and installation problems we decided to develop that auxiliary tool ourselves, rather than to use third-party sources.
The visualization tool is being developed in Microsoft Visual Studio 10 using C# as Windows forms application. At this stage the tool is developed as a standalone application and final incorporation into the DOCPAGANSA environment, with modifications of the data entry procedure is planned in the future. The starting form is depicted in Figure 3.
Figure 3: Starting form of the visualization tool
After the user enters the input data, or the input data are read from the input file (currently in the form of QAD geometry data), the drawing algorithm performs the error check procedure. If the procedure discovers any geometrical inconsistencies the drawing is
abandoned and the user is informed on the error type. The geometry boundaries are determined and testing of the voxels within the boundaries is started. Currently the voxel is set to the dimensions of 1x1x1 mm. For each voxel the affiliation to particular, user defined, geometry zone is determined and the appropriate colour mark is assigned. The 3D impression is enabled by appropriate mathematical transformations of the 3D geometry input data into the 2D image [7]. The final data are stored in the bitmap image file format (*.bmp). The images of a very simple geometry consisted of three concentric cylinders and two detector locations with different visualization options enabled are depicted in Figure 4 (plain view), Figure 5 (initial cut view), Figure 6 (rotational form), and Figure 7 (rotated geometry).
Figure 4: Exemplary geometry in plain view
Figure 5: Exemplary geometry in initial cut view
Figure 6: Exemplary geometry with activated rotational form in plain view
Figure 7: Rotated exemplary geometry in plain view
The input form currently used for the visualization tool will be used as the basis for the development of the general DOCPAGANSA environment input form. Additional options for source and material definition are to be added with underlying algorithm for data transformation into adequate forms for simplified and complex calculations.
4 CONCLUSIONS AND FUTURE WORK
In this paper the basics of the environmental structure draft of the DOCPAGANSA environment and preliminary drafts of incorporated graphical user interface and underlying control module are reported. At this moment we estimate that the structure of the environment is fully defined, while the software implementation of the structure is at 10%-15%. Therefore, the future work regarding finalization of GUI and control module is demanding and time- consuming and would consist of: finalizing the visualization tool, preparation of the final general input form and underlying control algorithm (front-end component), and preparation of the back-end component. For the back-end component in-house solutions are also
envisioned. The work on the simplified calculational tool is ongoing and it is reported elsewhere.
REFERENCES
[1] J.K. Shultis, R.E. Faw, “Radiation shielding technology”, Health Phys.. 88 (6), 2005, pp. 587-612.
[2] N. Cristianini, J. Shawe-Taylor, An Introduction to Support Vector Machines and other Kernel-based Learning Methods, University Press, Cambridge, 2005.
[3] N.M. Schaeffer, "Reactor Shielding for Nuclear Engineers", U.S. Atomic Energy Commission, 1973.
[4] T. Goorley, "MCNP6.1.1-Beta Release Notes", LA-UR-14-24680, 2014.
[5] M. B. Chadwick, et al, "ENDF/B-VII.0: next generation evaluated nuclear data library for nuclear science and technology", Nuclear Data Sheets 107(12), 2006, pp. 2931- 3060.
[6] http://www.itpro.co.uk/operating-systems/24841/windows-vs-linux-whats-the-best- operating-system-4, last accessed on August 29, 2017.
[7] R. Stephens, Visual Basic – Graphic Programming, Wiley & Sons Inc., New York, 1997.
