List view
Current support for material assignment and some boundary conditions. This should be expanded to larger set of geometry annotations.
Overdue by 9 year(s)•Due by December 30, 2016•1/3 issues closedThe final implementation of UWUW will also include a final/formal separation of model preparation tasks and model analysis tasks. Model Preparation ============= Ideally, these tasks will be fully supported on all platforms: Linux (multiple flavors), Windows, Mac OS * build a material library from MCNP file or scratch: depends on PyNE * import a geometry to Trelis: depends on Trelis * apply metadata in Trelis: no additional dependency * export dagmc geometry: depends on Trelis plugin, which depends on MOAB (HDF5) * UWUW preproc: depends on DAGMC, which depends on amalgamated PyNE and MOAB Model Analysis =============== These tasks will be targeted at linux environments. * copy UWUW model to computing environment: no additional dependencies * run MC with UWUW: depends on DAGMC, which depends on amalgamated PyNE and MOAB (HDF5)
Overdue by 9 year(s)•Due by August 30, 2016•1/1 issues closedA collaboration with Tech-X, funded by NASA/Wyle, to provide a graphical front end for manipulation and preparation of DAGMC geometry under the UW Unified Workflow (UW)<sup>2</sup> Workflow assumptions =================== The high level user interaction can be described as: 1. User begins with an faceted (h5m) representation of the geometry that has been imprinted, merged and includes a "graveyard" volume 2. User will use graphical interface to: a. assign materials to volumes b. define tally objects and assign volumes or surfaces to those objects 3. User will save a version of the faceted geometry file with additional metadata defined in 2. 4. User will run physics package P using this annotated geometry file Material assignment --------------------------- Material assignment is governed by the following: 1. A library of available materials will be provided to populate a list of materials available to the user, based on human readable material names 2. Each non-vacuum volume will be assigned a material using the PyNE material assignment conventions adopted by DAGMC: a. tagging the meshset for the volume with a string containing the material name b. creating a new meshset for each unique material that is used in a problem and adding the volume meshset for each volume that contains said material to that material's meshet 3. The user may assign a material density to any volume, thus overriding the default material density as defined in the material library. Tally Object Creation ---------------------------- Only "raw" tallies will be supported at this time: e.g. tallies based on the particle tracks directly without multiplying by physical quantities. To be clear, current/fluence/flux will be supported and dose/energy deposition/etc will not be supported at this time. 1. Each region of interest (volume or surface) will be assigned a tally object identified by the type of particle being scored in that object Source definition ------------------------- Particle source characteristics will be defined using a finite set of parameters that users can define using a graphical interface. Those parameters can be attached to the geometry file (h5m) using some tagging convention.
No due date•2/5 issues closedWe will need to analyze and implement DAGMC into MCNP6.
Overdue by 9 year(s)•Due by July 30, 2016•2/2 issues closedThese are ideas that we would like to see implemented in the future
No due date•1/7 issues closedThis milestone is comprised of the addition of remaining functionality that was absent in the alpha release. It requires the addition of processing of the following group names, which can be split into physics based and scoring based. Physics Based * BIASING * CORRFACT * EMF-BIAS * EMFRAY * EXPTRANS * LOW-BIAS * LOW-DOWN * STEPSIZE * WW-FACTOr Detector Based * DETECT * RESNUCLE * USRBDX * USRCOLL * USRTRACK * USRYIELD They all to some extent require way more additional information that can possibly be parsed in group names, but at the very least we should output the required card with the appropriate scoring/physics volume as needed as this is the most difficult to transfer. All of the processing improvements that should be included require that we conform to the standard 8 column, 10 width FLUKA input standard, which does not view well on Github.
No due date•13/13 issues closedWhen we have released the alpha version for NASA to play with, we should perform some improvements to the pre-processing part of FluDAG, current functionality is sufficient however, the following would be useful; * Warn when the material BLCKHOLE is not defined in the model * Ability to tag the implicit compliment as any material * Warn when material names are truncated (may be made redundant by other work) * Auto-capitalize the material tags
No due date•2/2 issues closed- No due date•2/3 issues closed
By creating groups in cubit in an appropriate model create groups of particle scorers (eg. USRTRACK and USRBDX) and propagate these through to Fluka compatable scoring information, by using a similar methodology to the group names for materials. The group names for scoring should be <score type>_<particle type>, e.g. USRTRACK_PROTON |- Volume 1 |- Volume 2 |- Volume 3 +- Volume 4 USRTRACK_NEUTRON |- Volume 1 |- Volume 2 |- Volume 3 +- Volume 4 Should create * 4 USRTRACK score entries for volumes 1 though 4 in unit 21 scoring protons * 4 USRTRACK scores entries for volumes 1 though 4 in unit 22 scoring neutrons NOTE: units cannot be reused, it seems logical to group same score and particle types together in these units.
No due date•3/3 issues closed**This has been overcome by plans to merge tally infrastructure with FRENSIE** Current infrastructure for unstructured mesh tallies is closely tied to MCNP5 capabilities. This should be refactored to abstract those interfaces and allow these tallies to apply to a variety of physics packages. Also need to consider reducing requirement of MOAB capabilities so that other mesh representations can be used, particularly for the KDE mesh tallies.
No due date•20/22 issues closedDemonstrate that we can calculate uncollided flux moments for use in Sn calculations using combinatorial geometry.
No due dateImplement KDE for use as a typical SHIFT tally.
No due dateImplement version of KDE tallies that use track information generated by KBA ray traversal for flux moments. ORNL responsibility: launch rays, truncate rays that move in wrong dimension UW responsibility: for a given subset of points (perhaps domain decomposed) and an increment of track, tally KDE contributions on the points in that neighborhood.
No due dateCurrent unstructured mesh tallies are only valid for tetrahedra. We should add hexahedra and other types of elements.
No due dateConfirm that DAG-MCNP5 builds against Cubt13.x using the current head of CGM.
No due dateOpenMP (and variations) support seems to be a growing priority in the MCNP community. This makes a lot of sense, given the proliferation of multicore computers on which OpenMP-style parallelism is natural and MPI-style is awkward. Previous parallel processing support in DAGMC has focused on an MPI implementation. Effort is now needed to support OpenMP. 1: Ensure we know how to build an OpenMP version of mcnp5. 2: Evaluate where OpenMP-parallelized functions will call into dagmc. 3: Ensure that all such functions call only read-only functions of DagMC. If not, determine a synchronization strategy. 4: Add OpenMP V&V to the test suite. (Derived from CVSTrac ticket 327)
Overdue by 9 year(s)•Due by August 30, 2016•0/1 issues closed