SCIENTIFIC WORKFLOWS FOR MCNP6 AND PROTEUS WITHIN THE NEAMS WORKBENCH

,


INTRODUCTION
The Nuclear Energy Advanced Modeling and Simulation (NEAMS) Workbench [1] seeks to empower reactor physicists with versatile, comprehensive, and intuitive interfaces to and between scientific software used to simulate nuclear reactors. Primary among these tools are neutron transport solvers, which compute the distribution of neutron flux within a reactor, as well as the multiplication factor. For this purpose, we here integrate MCNP6.2 [2] and PROTEUS [3] (two high-fidelity neutron transport solvers) into the NEAMS Workbench (expanding on previous work [4]). Doing so, we equip Workbench users with powerful neutronics solvers, enhance the productivity of MCNP6 and PROTEUS users, and facilitate novel hybrid Monte Carlo and deterministic analyses.
This integration entails firstly to refactor the user interface (input specification) of both codes, for improved ease-of-use and versatility. Next, we facilitate post-processing and visualization of both codes by standardizing output formats and leveraging previously-established utilities. Thirdly, we explore the compatible use of MCNP6.2 and PROTEUS as independent analysis tools. Finally, we examine cooperative use, typified here by a hybrid Monte Carlo and deterministic variance reduction scheme known as Consistent Adjoint-Driven Importance Sampling (CADIS) [5].

MCNP Decks
To specify input for Monte Carlo simulations, MCNP6.2 employs a Domain-Specific (Modeling) Language, or DS(M)L. However, despite the ubiquitous use of MCNP among nuclear engineers, no text editors support this custom DSML. Accordingly, users are deprived of common code editing features, such as content-assist, input validation, and reference resolving. Analysts must rely solely on trial-and-error, which can render MCNP input preparation time-consuming and error-prone.
To rectify this hardship, we have developed comprehensive editor services using a language workbench known as Xtext [6]. We show a subset of these features in Figure 1a (content-assistance) and Figure 2 (reference-resolving). Crucially, these editor services enforce DSML syntax and validate MCNP constraints with immediate visual feedback, dramatically enhancing productivity. To implement these editor services in Workbench, we adopt the Language Server Protocol (LSP) developed by Microsoft, allowing us to encapsulate our software (the "language server") separately from the NEAMS Workbench (the text editor or "language client"). Owing to this generic approach, these editor services could also be deployed in any other editor supporting the LSP.

PROTEUS Input Files
Correspondingly, the user's primary interface with PROTEUS is the "driver" input file, which details runtime and output options for the solver. These options are specified in an ad hoc textual format, not recognized or supported by text editors. However, as the semantic data consists almost exclusively of key-value pairs, we simply redefine the PROTEUS input file using a new syntax.
Specifically, we employ the YAML (recursively, "YAML Ain't Markup Language") data serialization format, given the similar (yet standardized) syntax and widespread popularity. * An exemplary driver file specified in each format is given in Listing 1. Notably, the YAML format is nearly identical to the native format, such that established users should find no difficulty adopting the former.
! Specify quadrature sn_type LEG-TCHEBY skipsolve NO bc_alias side_set_0000010 VOID bc_alias side_set_0000020 VOID To validate PROTEUS driver files, we have developed an input schema, written in accordance with JSON Schema 7. This schema encodes documentation, default settings, and valid options, as specified in the PROTEUS user manual. As a benefit of YAML's popularity, we leverage an existing language server (supporting JSON Schema) developed by Red Hat [10] to provide editor services, as exemplified in Figures 1b and 3. Again, these editor services provide immediate validation (and assistance) in the text editor, at immense benefit to the productivity of end-users.

MCNP Textual Outputs
With the exception of unstructured mesh tallies, all MCNP results are output as plaintext files.
To the detriment of end-users, all formats are custom, often forcing users to write ad hoc "text However, despite the tremendous utility of MCNPTools, it does not offer an alternative serialization format. Therefore, the results themselves are not rendered any easier to parse in the absence of MCNPTools. This is problematic, as it forces users to introduce a dependency on MCNPTools (an unfamiliar and restricted-distribution package) in all MCNP projects, in perpetuity.
To remedy this, we have defined Hierarchical Data Format 5 (HDF5) serialization formats for all MCNP outputs supported by MCNPTools. Unlike text files, HDF5 files are simple to access and manipulate, natively supporting metadata, hierarchical data, and multi-dimensional arrays. These files eliminate both the need for text files and purpose-built parsers (like MCNPTools) beyond the initial conversion to HDF5. Moreover, users may employ a familiar HDF5 API, rather than learning the specifics of MCNPTools (if they so choose). From Listings 2 and 3, we find the h5py (HDF5) interface at least as intuitive as that provided by MCNPTools.

MCNP Output Standardization
While comprehensive HDF5 output files for MCNP are advantageous (effectively replacing the textual formats), we now turn to a further goal: standardizing output formats across multiple Monte Carlo neutron solvers. Notably, OpenMC [12], an open-source Monte Carlo neutron transport solver, provides similar functionality to MCNP and already defines HDF5 output file formats. Therefore, we adopt (a subset of) these formats as initial "standard" formats, summarized in Table  1. † Beyond the convenience of standardization, by coercing (all available) MCNP output to the OpenMC formats, we enable the use of the OpenMC Python API for common post-processing. This is especially valuable for OpenMC "statepoints," which provide comprehensive facilities for tally arithmetic, and mesh tallies, which can be interrogated via a simple GUI provided by OpenMC.
To demonstrate this progress, we have converted a MCNP mesh tally from its native MESHTAL format (to a "MESHTAL.h5" file) into an OpenMC Voxel Plot file. With a utility included with OpenMC, the Voxel Plot can then be converted into a Visualization Toolkit (VTK) file which can be plotted in a variety of programs such as ParaView or VisIt. This provides the user with much more powerful viewing and post-processing capabilities than with the native MCNP utility (MCPLOT). Figure 4 shows a comparision of a MESHTAL file plot using MCPLOT (for the native MCNP file) and ParaView (for the VTK version).

PROTEUS Post-Processing and Visualization
Nearly all PROTEUS output information is contained in "UNIC-"formatted HDF5 files describing the multi-group scalar flux distribution (over an unstructured mesh). As these files are already encoded in HDF5 (as was the goal for MCNP in Section 3.1) and supported by both VisIt and ParaView, we consider the established post-processing capabilities mature. To detail the current state of PROTEUS post-processing, we show in Figure 5 a graphical representation of the HDF5 output file (from HDFView) and a pseudocolor plot of scalar neutron flux rendered by VisIt. † We expect more appropriate standard formats could be devised by comparing the common capabilities and output quantities of different solvers (such as MCNP, OpenMC, and Serpent). However, such a comparison is beyond the scope of this work.  Naturally, users may want to employ multiple levels of fidelity for different tasks. For instance, Monte Carlo calculations may prove useful for validation or to collapse multi-group cross-sections, while determinstic methods would be preferred for transients, design studies, and uncertainty quantification. Therefore, the user should be empowered to compatibly simulate the same model (geometry, sources, and materials) in both MCNP6.2 and PROTEUS. Fortunately, both software support unstructured mesh geometry, suggesting a natural avenue for model unification. Specifically, we accomplish this by developing a utility which converts PROTEUS-compatible to MCNPcompatible meshes and templates a corresponding MCNP deck, depicted in Figure 6 [13].

. Unstructured Mesh Conversion
While MCNP6.2 and PROTEUS can both transport particles over an unstructured mesh, MCNP requires meshes to be specified in a subset of the Abaqus ".inp" format, while PROTEUS mesh converters are only available for EXODUS-II meshes. Therefore, we have developed a mesh conversion utility which converts EXODUS-II meshes to an MCNP-intelligible format. Users may also here impose boundary conditions, to be encoded in the corresponding MCNP deck template.

Templating the MCNP Input Deck
As MCNP requires unstructured mesh geometry to be embedded within a Constructive Solid Geometry (CSG) cell, we additionally create a void region to encompass the user-provided mesh. Moreover, to impose reflecting boundaries on the meshed geometry (as MCNP does not permit explicitly setting boundary conditions on meshed surfaces) we establish a reflecting CSG boundary at a minuscule offset from each reflective mesh boundary. Finally, we populate the MCNP deck with "pseudocells" corresponding to each element set of the Abaqus (originally EXODUS-II) mesh, such that the users may manually assign cell properties. If provided in the original mesh, pseudocell densities are also set.
Ultimately, this template defines an MCNP model accepting a mesh originally specified in a PROTEUS-compatible format. As such, this utility allows simulations in MCNP and PROTEUS on identical geometries, immensely streamlining hybrid Monte Carlo and deterministic workflows.

Variance Reduction via Consistent Adjoint-Driven Importance Sampling
Monte Carlo simulations are stymied by stochastic uncertainty. Namely, the convergence of the simulation in a region of interest is inversely proportional to the square root of number of histories N contributing to the response in that region. In analog Monte Carlo simulations (where a simulated particle is considered the literal analog of a physical particle) this presents an issue: stochastic uncertainty will be high in all regions where the (relative) neutron population is low.
We can remedy this by employing variance-reduction (VR) techniques. Specifically, our aim is to accelerate the convergence of a response of interest by maximizing the number of histories in that region. However, to do so, we must know whether or not a given particle is likely to contribute to our response of interest (e.g. by streaming to a given location or scattering to a specific energy group). Conveniently, this can be modeled via the adjoint neutron transport equation. While the forward transport equation models a neutron population arising from a given source, the adjoint solves the inverse problem; namely the contribution of a neutron population to a given response.
That being said, simulating the adjoint transport problem at the same fidelity as in the forward problem (that is, Monte Carlo) is likely to increase, rather than decrease, the computational effort. What would be advantageous is to approximate the solution of an adjoint problem, which can be used to cheaply accelerate the convergence of the high-fidelity forward problem. Thus, we find another virtue of having two compatible neutron transport simulators of differing fidelity.

Implementation in MCNP and PROTEUS(-SN)
Consistent Adjoint-Driven Importance Sampling (CADIS) is the means by which we use the adjoint flux to assign importances to the Monte Carlo phase space. To enact this strategy, we must first define an adjoint source, q † (r, Ω, E) which represents the response we seek to maximize. In the simplest case, this could be a delta function q † = δ(r −r p , Ω−Ω p , E −E p ), such that we minimize the variance at some point detector p. More generally, we often aim to obtain uniform convergence over the entire phase space. We can represent this using the response function q † = 1/ψ (where ψ is the forward flux). This is referred to as Forward-Weighted-(FW-)CADIS, which requires an estimate of the forward flux (and is necessarily dependent on the forward problem definition).
Notably, while CADIS has previously been realized and implemented, the use of PROTEUS affords a unique opportunity to compute these low-order solutions on an unstructured mesh repre-Proceedings of the PHYSOR 2020, Cambridge, United Kingdom Physics of Reactors Transition to a Scalable Nuclear Future sentative of the true Monte Carlo geometry. This is a departure from implementations such as AutomateD VAriaNce reducTion Generator (ADVANTG) which homogenize materials within a Cartesian grid for use in structured mesh solvers. To avoid homogenization, importances are assigned for each MCNP cell of the model. This guarantees that each distinct material region of the model has its own importance. A single importance value is never assigned across portions of different cells as would occur with mesh-based importances. Using cells as the basis to assign importances also avoids introducing extra boundary crossings into the problem since cell boundaries will exist regardless of applying CADIS to the problem. The use of unstructured meshes can be further leveraged via our unstructured mesh conversion utility. This allows the user to create a single model that is used by both the deterministic and Monte Carlo parts of the simulation. Doing so simplifies model creation and ensures consistence between model features. Our example CADIS case utilizes the unstructured mesh workflow described previously.

Numerical Results
As a test case, we applied our CADIS implementation to a simple neutron shielding problem. The problem is defined within a 80 × 80 × 155 cm bounding box with vacuum boundary conditions on all sides. The quantity of interest is defined as the response in a 10 × 10 × 10 cm detector region (comprised of helium) on the opposite side of the shield from the source. For the forward source, a 1 MeV isotropic point neutron source is defined at the center of a 50 × 50 × 50 cm aluminum source container with a 25 × 25 × 25 cm cutout facing the shield. The shield is 80 × 80 × 10 cm and made of water. To provide PROTEUS with the necessary cross sections, this model was recreated and run in Serpent2 collapsing to a two-group structure (using a thermal neutron cutoff energy of 1 eV). Due to the shield being fairly substantial, very few particles will reach the detector and consequently variance will be high. This situation makes the problem a natural choice for variance reduction methods such as CADIS.
This geometry (as plotted by Cubit) is shown in Figure 7. In order to assign importances spatially, the problem is subdivided into many smaller cells rather than leaving large material regions as single cells. The individual cells are indicated by the colored blocks in the model. Using uniform blocks to construct the model was done for simplicity, but is not a constraint for MCNP or PROTEUS. Cells can be structured however the user chooses. The model also includes cells in the empty spaces (filled with helium), but these have been made invisible in order to view the important problem features.
The detector shielding problem was run using 1.0E+08 particle histories for both the analog and CADIS implementations and the response was measured using a F4 (flux) tally in the detector cell. Results from the simulations are given in Table 2 where the relative tally uncertainty and Figure of Merit (FOM) are given. Decreasing the tally uncertainty indicates a decreased variance and a higher confidence in the solution. However, it is more important to assess the competing metrics of variance (σ 2 ) reduction and increased runtime T as a FOM 1/(σ 2 T ). If the FOM increases, it means that the tally uncertainty is reduced more efficiently by CADIS than by simply running the analog problem for more particle histories. Table 2 clearly shows the desired trends of decreased tally uncertainty and increased FOM. This shows that the CADIS implementation was successful with 121% of the FOM from the analog problem. The tally uncertainty decreased by 44%.

CONCLUSIONS
In conclusion, we have comprehensively integrated MCNP6.2 and PROTEUS into the NEAMS Workbench, offering Workbench users powerful reactor physics capabilities and MCNP and PRO-TEUS users an enhanced user interface through full-featured editor services. Meanwhile, by defining HDF5 formats for textual MCNP outputs, we relieve the user's dependence both on inscrutable text files and unfamiliar, purpose-built parsers, beyond an initial conversion to HDF5. We further coerce these MCNP outputs to "standard" formats described by OpenMC, granting users access to OpenMC utilities and facilitating common, comprehensive post-processing workflows.
For the compatible use of MCNP and PROTEUS, we have also developed a model unification utility capable of translating PROTEUS-to MCNP-compatible meshes, as well as generating a template MCNP deck to accept the mesh. Finally, we enact a hybrid Monte Carlo and deterministic workflow for CADIS which (novelly) computes the adjoint flux on unstructured meshes. For a neutron shielding problem, we find our implementation to be effective in applying cell-based weight windows to the MCNP model.
Overall, we find this effort dramatically empowers users of MCNP, PROTEUS, and Workbench, both with new compatible and cooperative modeling capabilities and intuitive, streamlined interfaces for input preparation and post-processing. Moreover, we expect the relevance of this work will only increase as additional simulation tools are "integrated" into the NEAMS Workbench.