Main Data History
Show Index Toggle 0 comments
  •  Quick Edit
  • CAD Based particle transport using DAGMC toolkit


    A required 200-250 word abstract starts on this line. Leave two blank lines before “ABSTRACT” and one after. Use single (10 point) spacing. The abstract is a very brief summary highlighting main accomplishments, what is new, and how it relates to the state-of-the-art.

    Key Words: CAD, MCNP, Geant4, Fluka, Monte Carlo


    CAD based particle transport has several possible impimentations The DAGMC toolkit has been used succesfully on several complex geometries, and has been shown to be very close to native geometries in terms of computational performance. There are a number of updates recently, along with several additions to the supported code base, namely FLUKA [ref] and Geant4 [ref].


    We have implimented a version of DAGMC that interfaces with the Fluka code, this implimentation is known as FluDAG. The Fluka team had previously done work on FluGG [ref], an interface for users to be able to use Geant4 geometry with Fluka physics, this exposed an API from which we could inject DAGMC functions. In terms of code structure the fundmental DAGMC library calls are made through functions callable by the Fortran based Fluka routines.


    A team from Hanyang University in Korea, originally developed DagSolid for MOAB 4.0.1 (Han 2013), their work showed that DagSolid is significantly faster than the native tesellated solid implimentation by at least a factor of \(\sim\) 50-1500. The CNERG team at UW-Madison updated this to the current release version of MOAB and added several improvments. Most notably, the use of the native Geant4 unit system, to properly import DAGMC models as centimeter based models and added significant unit test coverage to the DagSolid class. The unit tests assert all behaviours as specified in the Geant4 Toolkit Developer guide \cite{}.

    The University of Wisconsin Unified Workflow

    Since the first implimentation of DAGMC for MCNP-X there has been a need to define problem metadata; such as which volumes are assgined to be steel at a specific density, which volumes are to be water, in which volumes we would like to determine neutron flux and so on. For earlier version of DAG-MCNP5 an ad-hoc schema was defined which would associate any volumes with a material property and if specified specific tallies. This method was limited to MCNP5/X and supported only a subset of the potential geometric metadata.

    CNERG have developed a new scheme known as “The University of Wisconsin Unified Workflow” - (UW\(^2\)), with this scheme we encode problem metadata as raw text strings which are interpreted downstream by a pre-process tool. Material assignments are specified with the mat:<name> key-value pair. This data is stored in the geometry file and is indelibly associated with the volume. The PyNE (the PyNE Development Team 2014, Bates 2014) MaterialLibrary capabillity is used to look up the association of that material name to the composition as defined in the material library. This PyNE Material object, is then inserted into the geometry file thus a local copy of that which was present and permenantly inserted into the geometry file. This material object is then used at run time to translate the PyNE form into the physics engine specific form.

    Similarly for material metadata, there exists methods to handle the tally specific metadata, for this purpose a specific class was written for PyNE which allows the instanciation of tallies with names, volume id numbers and so on. The syntax for the creation of tallies is tally: particle name \ tally type , using the naming PyNE particle naming scheme. Like with Materials, the Tally objects are stored in the geometry file and translated to physics engine specific form at run time.

    Currently Cubit \cite{} is used to assign this metadata using the group feature, where volumes which have a consistent property are assigned to the same group. The group data are handled by a pre-process code which assigns each volume in the group the property belonging to the group. Ultimately, as input every DAGMC enabled code is capable of recieving an identical description of material compositions and identical descriptions of tallies.

    FluDAG Validation

    Simple Testing

    As part of the development of FluDAG a number of tests were created to assert that the behavior from Fluka and FluDAG are consistent. These tests verify each feature that is tested in turn behaves identically to that in Fluka. The tests assert the following behaviour, USRTRACK scores given the same results in each geometry tested, USRBDX scores give the same result in each geometry tested, that turning on magnetic fields works and does not affect results adversely.

    ATIC Testing

    We validated the FluDAG code by constructing equivalent models in Fluka & FluDAG, the Space Radiation and Analysis group (SRAG) supplied a model of the ATIC detector that flew several times between XXX and XXX. The model was supplied in native Fluka format, we used the “Export as” feature in Flair to translate the Fluka model to MCNP, we then used mcnp2cad to generate the CAD model. The materials used in the FluDAG run were used as directly specified in the Fluka input.

    The calculations were run on the Condor Computing network at UW-Madison, 1000 Fluka simulations each with a different random number seed was submitted each with \(1 \times 10^{6}\) primaries. Similarly, there were 500 FluDAG simulations.