csg2csg: A tool to assist Validation & Verification

The csg2csg tool is a minimal dependency Python3 based program to facilitate the comparison of radiation transport Monte Carlo codes. The csg2csg can currently parse MCNP and OpenMC geometry descriptions, and it can subsequently export MCNP, FLUKA, PHITS, OpenMC and Serpent geometry files. This translation is achieved by reading the input geometry into a class based system of objects corresponding to surfaces, cells, materials and so on. The objects are then translated into a ‘generic’ form. This form once generalised can be converted to any of the supported code formats and then radiation transport calculations can be performed. The code has been tested on several geometries; most notably a complex JET model and a 70k cell ITER C-Model geometry.


INTRODUCTION
For a number of years the fusion community has been investigating alternative Monte Carlo (MC) codes for use in fusion nuclear analysis. An EFDA study [1] considered several codes for use, but the study stopped short of investigating detailed geometries due to the difficulties in model conversion. The process of validating a new MC code for use depends on a number of factors, but availability of benchmarks is a limiting factor, fortunately for fusion a collection of benchmarks exist, Shielding INtegral Benchmark Archive and Database (SINBAD) [2] is the collection of available experiments. However, due the variable level of agreement seen in SINBAD Fusion it is thought that any code suitable for fusion, must also be able to complete the suite of International Criticality Safety Benchmark Evaluation Project (ICSBEP) [3] benchmarks. Thus, the ultimate target for csg2csg is to be able to robustly translate any geometry, however the geometries present in both SINBAD and ICSBEP are the key geometries that must be translatable. The MC codes initially targeted for conversion are: MCNP [4], FLUKA [5], OpenMC [6], PHITS [7] and Serpent2 [8]. The reasons for the set of codes is manifold, but this range of codes is thought to stress the range of geometry and material descriptions possible. It should be noted, that there is no attempt to translate source or tally descriptions, it already known that sources will prove near impossible to translate directly.

csg2csg METHOD
Firstly a survey of the different codes mentioned in section 1 and the number of different surface types were compared to find the common set of supported surfaces amongst the codes, the code by code comparison can be found in Table 1. Most codes support the same sets of basic surfaces, the exceptions are: toroidal surfaces, surface by points and macrobodies. It is clear from the common set of surfaces, that surfaces defined by points (which largely serve as helper functions in MCNP) and macrobodies are the features that must get the most attention. Therefore all surfaces must be expressed as their most basic forms, e.g. an RCC should be converted to a cylinder bounded by two planes.
The concept of cell is common amongst all the codes, all be it with different names (e.g. Region, Cell), they all point to some description of the cell as defined by the surfaces that bound it, that is all that can be described as common between the codes, some codes have the cell indicate material either by name or id, others have no indication on the cell card and hold that information separately. Some MC codes associate their density information with the material description and not the cell description, some include additional information like temperature. In terms of the detail of material description all of the codes are equivalent in the detail of the isotopic description, with the exception of FLUKA which has a multigroup mode wherein only some materials retain their special isotopic descriptions of cross sections as opposed to element averaged. csg2csg takes the information contained within the cell/material description and instantiates a new material for each material/density pair, currently temperature is ignored.

csg2csg CODE STRUCTURE
During the development of csg2csg a strong Object Oriented (OO) focus as taken to ensure that there was the appropriate inheritance between classes. For instance, take for example the relationship between the Card, CellCard, and MCNPCellCard classes as shown in Figure 1. The base class Card defines the access patterns from objects which inherit from it, in this case CellCard. When processing is done CellCard contains the generalised description of cell cards. During read time the process which operates on the MCNPCellCard class populates the text description of Card, and generalises the description of the cell card to Surface objects and Boolean operations.  Similarly the surface cards are processed and sorted in a sequence of classes Card, SurfaceCard, and MCNPSurfaceCard. The surfaces are input initially into their text based description, for example the string "*4 CX 4" in MCNP format refers to a surface with id 4, which is a cylinder lying along the x axis with radius 4 cm also with a reflecting condition. This is stored directly in the Card.text_description member variable. When processed the boundary condition information is stored in generic form Boundary.REFLECTING and the surface type is processed into generic form, in this case Surface.CYLINDER_X. The only special thing of note here is that macrobodies when processed are converted into explicit half space representation, for example a BOX is turned into 6 general planes, with an inside (negative) sense and an outside (positive) sense.
The next stage in programmatic flow is to 'explode nots', this procedure updates the cell descriptions which in MCNP can use the # Boolean operator to negate that cell description. Many MC codes support negation, but not with reference to the cell number, so an explicit description of the negated cell is inserted. In MCNP parlance the description (3:4:5) #4 would be exploded to form (3:4:5) #(7 -9 12), however in csg2csg this is done internally using generic operations and data structures.
The following stage, is to apply explicit surface transformations, MCNP input allows in the surface description an integer representing the translation to apply. All MC codes allow cell transformations but surface transformations are unique to the MCNP taxonomic group (MCNP, PHITS, MARS) . The procedure to allow this feature to be fed into other MC codes is to explicitly transform the surfaces, this is done following [9] but is enumerated here due to some implementation differences. First, the surface is turned explicitly from its simplified form surface.CYLINDER_X into surface.GENERAL_QUADRATIC. Then the rotation matrix as defined by the transform card can be applied.

First, the surface coefficients are instanced into A and the rotation coefficient into
Thus the resultant rotated surface equation can be described as in Equation 2.
The result of Equation 2 is the fully rotated form of the general quadratic form of the surface, however this does not include the appropriate Cartesian shift. We must now factor in the shift and its appropriate rotation, we do this constructing a unitary diagonal matrix, which includes the Cartesian shift and the unit directions.
The final fully rotated and shifted form is described by Equation 4.
Thus the contents of R 3 now contain the fully rotated and translated surface. The reason for the deviation relative to [9] is that it was found that doing the compound rotation and translation in a single stage resulted in the incorrect surface description. The last few remaining core functions are largely book keeping; 1. ensure that there is a unique material object for each material number/density pair -most MC codes do not support MCNP's shorthand 2. define all universe translations as a 3 vector matrix rotation form 3. apply cell based boundary conditions to the surfaces which belong to that cell -e.g. some MC codes associate importance 0 regions with surfaces 4. generate bounding boxes for all the surfaces in the problem -this is to support translation to Serpent2. Serpent2 does not support the union operator in the outermost cell -so csg2csg generates an additional cell bounded by a sphere to ensure the outermost cell is simple

EXAMPLES
Without showing detailed validation of MC codes, which is beyond the scope of this paper, it is difficult to prove the validity or utility of the code. Included are a number of pictorial examples produced by the code, in these cases they were chosen as they either demonstrate complexity in terms of the cell descriptions translated (JET), shear number of cells and surfaces (C-Model) and ESS.

JET Model
The JET model is the work of some 10's of people over the last 20 years. It represents the complete torus hall of the JET experiment, including the full torus, external heating systems, and diagnostics, slices are shown in Figure 2  Due to its varied history its an excellent test case to show the range of combinations of methods of defining cells, universes surfaces containing; mixtures of surfaces and macrobodies, cells defined with large numbers of unions and complements, a number of different universe specifications and an extensive collection of materials. This model is geometrically more complex that the ITER C-Model, in that ITER has strict limits on the number of unions, parentheses and nested universes that are allowed.
As can be seen qualitatively in Figure 2, the geometry can be represented in each of the MC codes demonstrated. This is further confirmed by the diff of Serpent2 and OpenMC geometries, where only single pixel cell boundary differences can be seen, here black indicates no difference and white indicates a difference. This diff plot is enabled by using the same RGB values for each unique material, and the same query resolution for the geometry, then these plots can easily diffed.
Single pixel diffs must be tolerated since the method by which each MC determines what spatial coordinate to query varies, one could either stride through the mesh in some order and the centroid of each mesh element is used to determine the spatial coordinate, alternatively one could start at the boundary of the mesh and ray trace across boundaries and use the centroid of the ray, certainly some codes perform some numerical tolerance 'bumping' to ensure that no queries occur directly on cell boundaries.

C-Model
The C-Model geometry (C-Model V1 R2.1 -15/12/2016) is a large and complex MCNP input that describes the ITER reference analysis geometry, it represents the investment of several person years of effort to produce and involves the work of most of the European fusion laboratories. It has several layers of nested universes, large complex multi-union base level universe descriptions, with some 108454 surfaces and 70374 cells. A model of this complexity has only been possible in the last decade with the progress of CAD translation tools like SuperMC & MCAD.
The same diff method as used in Section cannot be used in this case since the C-Model geometry has more than 256 unique material/density combinations, Serpent2 cannot currently reproduce this many colours and thus the diff becomes meaningless, but the geometry slices are shown in Figure  3. A diff of OpenMC & MCNP was produced and showed similar agreement to the JET model, i.e. differences only on surfaces.

CONCLUSIONS
The csg2csg tool has been developed for the purpose of aiding radiation transport benchmarking, facilitating cross code comparison and helping to reduce monoculture. The sister paper to this, "Validation of OpenMC for a range of fusion benchmarks" made broad use of csg2csg to convert the geometries in question. Furthermore, its ability to translate complex geometry correctly as demonstrated qualitatively in Section 4 for the JET and ITER geometry cases.
In terms of missing features there are a number of near term goals; • Support for hierarchical geometry formats like ROOT [10] or Geant4 [11] would open up the use of Geant4 on routine fusion problems and benchmarks. This feature is not thought to be straightforward or performant due to the key differences between the half space based geometry inherited from MCNP geometry and the hierarchical manifold volume based geometry of ROOT/Geant4.
• Some MC codes do not support the Boolean union operator, but instead do so using some implicit ordering of the cells. In order to support those codes the cell description must be refactored into a form which allows trivial splitting of the unions into many small manifold regions. It is thought that this will be done through expansion of the Boolean expressions and the laws of Boolean arithmetic.