svalinn / dagmc Goto Github PK

There are a number of fronts on which we are not prepared to produce an OpenMP version of DAG-MCNP5. Those should be documented here.

We can extract the Cubit ID number for each volume and then use that to define a string based name for each region. The advantage to this over using the ordinal number is that a user can find it in their cubit model by this ID

Confirm that the update to the the README (200a83) now contains correct instructions for building documentation. The best way to do this is to replicate the Makefile instructions one at a time from the command-line, as much as possible.

See also: svalinn/r2s-act#44

In order to compile DAG-MCNP with the custom source.F90 for reading source data from a MOAB mesh, a few additions to the config flags are necessary. Specifically, in DAG-MCNP/config/Linux.gcf:

• add -fcray-pointer to FFLAGS
• add -liMesh to DAGMC_LIBS
• add -I/filespace/groups/cnerg/users/relson/MOAB/opt-cubit-c12/include to FPPFLAGS
• add $(MOAB_INCLUDES) to FPPFLAGS

The last of those is obviously CAE-specific. I don't know enough about MCNP's build/config process, but I suspect that that path can be passed in some other way, e.g. in the build script. If others have ideas along these lines, I can test them...

For reference, in the actual build script (I am still using build_dagmc from the old SVN repo for DAG-MCNP), I only make the following change:

-CONFIG="gfortran dagmc seq"
+CONFIG="gfortran dagmc seq -fcray-pointer -liMesh -L/filespace/groups/cnerg/opt/MOAB/opt-nocgm/lib -I/filespace/groups/cnerg/users/relson/MOAB/opt-cubit-c12/include -lMOAB -lhdf5 -lnetcdf -lstdc++ "

For the time being, we can generate a new material group naming convention. At some point in the future, we may want to streamline these to be common across different physics packages. To avoid namespace collision with DAG-MCNP, I recommend something that is not starting with "mat_". Perhaps "fmat_" instead...

Based on results of #17 we should document that we only support MCNP5 v1.51 and newer.

One of the warnings that can arise from the tetrahedral mesh tallies is the "Negative Track Length" warning. This appears to happen when a ray passes through triangular faces of a tetrahedron in the "wrong order". That is, a ray identifies an exit point from a tetrahedron that is behind the entry point.

We need to better understand when this happens, and what we can do to prevent it.

The single surface version of DagMC::surface_sense() should reuse the multi-surface version with just a single surface (unless we find a good reason not to).

If there is a good reason not to, this should be documented in the code.

Prepare a build script that allows an external user on a "typical" linux distribution to build DAG-MCNP5. They'll have to indicate the path to certain libraries or source code (e.g. MCNP5) on the command line.

In preparation for FLUDAG, a full review of the handling of different use cases of the ray_firing wrapper for DAG-MCNP is necessary.

This review should consider the following:

• minimize the introduction of state variables that may lead to state confusion
• accommodate all the use cases anticipated in other charged particle transport schemes in a common way

In particular, the following SVN revisions are of interest:

• r303 (2011-06-23)
• r307 (2011-07-06)

Create a general tally interface via refactoring of the MeshTally base class:

• Determine a set of methods and variables needed for all types of tallies
• Check current implementations of KDE and TrackLength mesh tallies for redundancy and common functionality that can be moved to MeshTally #43
• Change the fmesh_card struct to be more general and remove dependency on MCNP5
• Remove MOAB dependency from MeshTally base class

This should be a simple follow on to #33 but applied to KDE tallies.

Now that the svalinnDAGMC repo is up-to-date with the fludag work done on a separate collaboration branch, create a fludag branch of svalinn/DAGMC and use it as a collaboration branch.

Implement this FluGG wrapper function in the FluDAG code.

Definition of done: pass a full set of tests for this capability

• define tests
• write method
• test method

Based on the FluGG interface description (geomg4.ps), write a method that implements the G1FLU interface to perform the ray-tracing operation for a typical simple neutral particle.

A model for this method is the dagmctrack_ method in 5.1.60/trunk/Source/dagmc/mcnp_funcs.cpp of the DAG-MCNP internal repository.

This should be simplest first step because this kind of tally depends only on the track length information originally passed to the mesh tally. It does not need an interface to callback into the physics code for physics data.

Repeat #9 with a model built in DAG-MCNP5. This geometric model will be the basis for the first test with FLUDAG.

Beginning with SVN r322 (2011-08-15), the handling of the distance limit changed and may be unstable. Review the consequences of this SVN revision under all use cases.

There may be some data from the old web site that @gonuke can scrape up.

Next step: @gonuke will search for prior documentation

The FluDAG/FluGG interface has a method that may be called under different circumstances to accomplish ray firing. Tests are necessary for each of these circumstances using the simple driver (#21) to demonstrate ray firing on a DAG geometry.

Need a suite of tools that can take 3d/2d data from standard fluka output and convert to an appropriate storage /visualisation format. This can be done simply with a direct to vtk conversion or by creating and tagging and appropriate moab mesh and then using the existent suite of tools.

DagMC::boundary_case contains a barrier tests for all the actions that are intended to ensure a meaningful value for (u,v,w). This test only tests that each of u,v,w are less than 1, but that is probably not sufficient.

The FluGG developers "gave up" on figuring out how to have a FORTRAN main and still link in the C++ code successfully. We tackled that for MCNP5 successfully, so might be able to contribute this back to the FluGG/FLUKA developers.

Add methods to track on arbitrary hexahedra as well as tetrahedra

Develop routines to appropriately parse and thereby create appropriate handles to the FLUKA scoring routines, i.e. by parsing metadata found within the h5m created via Cubit group names

With MCNP6 supporting the use of unstructured mesh from ABAQUS, it will be useful to understand how those capabilities compare with the ones developed as part of the DAGMC effort.

• usability
• performance
• features
• mesh generation options

The hypothesis is that small features in a model have a small impact on ray tracing performance thanks to the OBB Tree.

This stand along project includes a number of numerical experiments to test/validate/disprove this hypothesis.

Experiment 1-A: Start with a cube, modeled in both native MCNP and DAG-MCNP. Add a "notch" to that cube at the corner, such as removing a rectangular prism from an edge. The edge length of the notch is d. Repeat this with more notches of the same edge length.

Experiment 1-B: Similar to (1-A) but keep the total size of the detail fixed and the edge length shrinks as more notches are added.

Experiment 2-A,2-B: Repeat the above starting with a sphere and rectangular notches.

Experiment 3-A,3-B: Repeat experiment 2-(A,B) with other shaped details.

Determine which metrics will be compared, including at least the ray-firing time per ray. Some experiment design will be necessary to determine fair measures of these quantities.

While the primary task to convert our SVN repository to a Git repository, there are a number of related tasks.

We currently have a number of related repositories:

DAG-MCNP

This private CAE-hosted repository is the primary repository for development of DAG-MCNP. It contains all of the MCNP source code as well as the modifications for DAG-MCNP5. The current layout of this repository should be redesigned as part of a transition to Git. It currently contains a "vendor" directory which in turn contains a directory for each of three versions of MCNP5, as delivered by RSICC. Parallel to "vendor" is a directory for each of those same versions, but modified by UW to generate DAG-MCNP5. Those folders, in some cases, also contain the test for DAG-MCNP5, which can be quite large.

DAGMC

This public Github-hosted repository is intended as the primary repository for distribution of public DAGMC code and patches. It should become the new home of the majority of our code.

fusion_n_tools

This private CAE-hosted repository contains many pieces, including the DAGMC_build directory. This directory is historical place for the patch and other files we distribute publicly for DAG-MCNP5.

Redesign

A new repository design will result in the following repositories:

MCNP

This will be a private CAE-hosted Git repository. It will contain the MCNP source code only. It will have one branch for each version of MCNP, and each branch will be populated initially with the as-delivered source code from LANL/RSICC. From their, we will add our modifications and patches. This repo will only contain modified MCNP source code and will not contain any of the glue/wrapper code. This code will be in the public DAGMC repository. These branches will be derived from the different directories currently in the SVN repo.

DAGMC

This will be a public Github-hosted repository. It will contain a different directory for each physics code. Each of those directories will include a patch file (if available/appropriate) derived from a diff of the private physics code repository. Each directory will also include the necessary glue/wrapper code and other additional files that we are free to distribute publicly. This repository will be the primary development repository for those files.

DAG-MCNP Testing

This will be a public Github-hosted repository. It will contain all the files necessary for testing of DAG-MCNP, including input files, reference output files and those scripts necessary to run all the tests.

Preserving History

The goal of this redesign will be to preserve the development history that is currently built into the private DAG-MCNP repository.

Using the region naming convention (#28) and material naming convention (#29) create a material assignment input snippet for FLUKA from the data in the file.

Check current implementations of KDE and TrackLength mesh tallies for redundancy and common functionality that can be moved to MeshTally.

Add documentation (to gh-pages?) to identify detailed plan for FluDAG implementation, including:

• files
• functions
• library dependencies

Where appropriate, a block diagram may also be illustrative.

Develop tutorial information and sample problems to help people learn how to use DAGMC.

• Godiva
• shielded source

Use a new branch "dagmc_v2" to communicate changes to ORNL.

Confirm that DagMC::point_in_volume_slow() is never called from code outside of DagMC (it is not called internally) and remove from file if no longer needed.

The current code appears to always assign a value (possibly the previous value) even if there is no value in the key value pair. DagMC::parse_group_name()

Write FluDAG interface methods to load a DAG file using the simple driver in #21

The FluDAG/FluGG interface includes a query to determine the current volume from a point. The DAGMC interface only includes a Boolean point inclusion test for a given volume. A simple search will be necessary, using the simple driver (#21) on the geometry loaded in (#22).

Future tasks can be generated for a more advanced search algorithm using MOAB technology.

For applications of the KDE tally to structured mesh, there may be alternate methods for determining the neighborhood that are more efficient that KD-tree searches. By abstracting this interface, we can allow any mesh representation to return a "bag of points" within any neighborhood.

To allow unstructured mesh tallies to be sufficiently flexible in their response, a mechanism is necessary to request physic data from the underlying physics code. Current code simply calls the MCNP5 methods for this data, but a more abstract interface should be generated to allow use in other physics codes.

• Determine what physics data may be needed for all possible tally types
• Create a TallyEvent interface defining this data that can be passed to any mesh tally type
• Modify KDE and TrackLength mesh tallies to accept this new object as a parameter when tallying events
• Move mcnp_weight_calculation to meshtal_funcs and make score weight a parameter when tallying events
• Consider moving ebin selection from MCNP to MeshTally

Currently, the unstructured meshtally capability in DagMCNP stores results on the MOAB mesh with tag names of the form TALLY_TAG_erglow-erghigh (and ERROR_TAG_erglow-erghigh), as well as totals TALLY_TAG and ERROR_TAG.

One potential problem with this is when both neutron and photon transport are done with the same mesh (e.g. the R2S-ACT workflow). It would be a good idea to include particle type in the tag name. TALLY_TAG_TYPE_erglow-erghigh would be the most straight-forward to parse. Single letter types should be fine (n and p).

Develop a simple driver to issue the calls that we expect FLUKA to make into the FluDAG (FluGG) for use in testing and development.

Using the same methodology as the DAG tracking processes we should be able to score physics quantities on a surface mesh, eg, surface triangle, polyhedral mesh. This would help overcome the challenge in using an SD card to segment a surface for scoring in DAG. Would be possible to score any quantity that can otherwise be scored, such as flux, current, heating etc

Suggest the following naming scheme for groups within a Cubit model for use within FluDAG.

MAT_ or MAT_<material_name>DEN

Be aware <material_name> will need to be truncated to a string of length 8 characters.

This should then be parsed to create a FLUKA "MATERIAL" card, e.g.
eg
group "MAT_TUNGSTA"
*...+....1....+....2....+....3....+....4....+....5....+....6....+....7....+....
MATERIAL 28. TUNGSTA

Please note the number "28", should be incremented for each subsequent MATERIAL card.

To be consistent with FLUKA, suggest that groupnames that coincide with FLUKA predefined materials, should not produce a MATERIAL card.

The ASSIGNMA cards can then use the appropriate material names.

Implement Fludag version of g1 tracking routine. Using dag->ray_fire as starting point. Determine the merit/benefit of retaining some history information for future comparison in order to speed up tracking. Take inspiration from dagmctrack and possibly nextvol from mcnp_funcs.cpp

As a first problem for comparison, create a simple 1-D slab problem in FLUKA's native geometry that we can use for testing.

The simplest problem will have an isotropic point source on one side of a single slab and somehow score/tally the results on the other side.

Using photons will ensure a reasonably simple physics.

Perhaps this software gives us a route to a simple cross platform installation http://0install.net/, when we work out any issues with OSX

Given that we are now using a public repository, it will be preferable for users to be able to browse the code that we have permission to distribute rather than only extracting the patch. We should rearrange the data in the MCNP folder and distribute a patch file with the changed MCNP5 code in addition to folders of code we cand istribute.

Using the same problem as #8, create this in the native MCNP5 geometry. This will provide an additional comparison point.

Experience with translating models from the native CAD format to the ultimate ACIS format used for DAGMC is varied. Different import/export opportunities are available at various steps of the process, and with more translations, more paths through different tools are possible.

A systematic assessment will take a series of models, with increasing complexity, through a variety of different paths from the original model to the ultimate ACIS format.

Metrics will be defined to allow for the comparison of these pathways, in terms of accuracy, quality and/or performance in ray tracing.

(was CVSTrac Ticket 440)

Investigate MCNP5 file sourcb.F90 for compatibility with DagMC. Some features of MCNP's source specifications may be unsupported by DAG-MCNP, and these unsupported features need to be added or their absence documented.