Consider how best to test the R2S script as part of CI without actually running MCNP or ALARA. (and if it is worth it)

While it is possible to delete a tag from a mesh using the pymoab interface, this does not honor the cross-referencing between tags and meshes.

A method should be added to the pyne mesh API to delete a tag and cleanup everything properly.

This is necessary to support the r2s script.

Update mesh.py and associated tests to be compatible with python 3. Depending on how much needs updating, this could come in a follow-up PR.

There are a few key differences between the API for the previous PyNE Mesh class and the new PyMOAB based one. E.g. myMesh.mesh.save() vs myMesh.save()

These should be documented somewhere to help other users transition their code that may depend on PyNE. This probably warrants a new page specific to this mesh API transition.

(Similar to #17)

Move the discretize_geom functionality elsewhere and pass it's results into this script. This will both

• remove the dagmc dependency, and
• open the door for generating these results in other ways

There may be various places in the docs that refer to the use of PyNE mesh, and those may need to be updated.

Catalog them in comments here and/or by making additional issues.

... then update those places.

All PyMOAB usage depends on a valid MOAB installation, but some also depnd on a valid DAGMC installation. We need to document which those are, probably by trying to build PyNE without DAGMC and looking for failures to build or test.

There are some lingering places where the 'imesh' tag type is specified - these should all be modified.

The R2S example that is described in the documents includes a link to a tarball with all the files necessary for a "student" to run an R2S problem.

A correct set of output files should also be added so that:

1. we can test the R2S script in CI without running physics codes
2. "students" can compare their answers

Update all dockerfiles in pyne/install_scripts

All new dockerfiles should enable building the website, as well.

Remove 17.04 and add 18.04

Everyone should review this PR for at least two purposes:

• improve everyone's understanding of the changes

• look out for remaining bugs

• @kkiesling

• @gonuke

• @ngranda

• @bam241

• @moatazharb

• @zxkjack123

• @cadangelo

• @pshriwise

• @ljacobson64

Check here once you confirm that it works for you:

• @gonuke
• @bam241
• @ypark234
• @ngranda
• @SamuelStern
• @zxkjack123
• @kkiesling
• @pshriwise
• @ljacobson64
• @cadangelo

Change restrictions on build to allow DAGMC to be optional in addition to MOAB.

I was reviewing #56 and I'm a little confused as to what the mats data structure is intended to be...

By default it looks like an empty tuple, but the documentation states it should be a MaterialLibrary or dict of mats (typo in docstring there) mapping volume element handles to materials. Here we're mapping indices to materials.

I see that the materials object always gets set to a valid dictionary-like object unless mats is None, indicating that the user doesn't want materials on the mesh.

• I think that at some point we should figure out what's up with the keys for the mats property. I'm thinking it's just a docstring update? 🤞

• I'll also advocate for the default of mats to be an empty dictionary (or MaterialLibrary) to reduce confusion about what the data structure ends up being.

Once we have resolved these issues, make a PR of the PyMOAB update to pyne/pyne.

There may be some issues in review of the original pymoab_cleanup branch

There are some places where pymoab is imported and there is no notification of failure.

This should be handled consistently across all invocations

CircleCI currently works for pyne:develop and for pshriwise:pymoab_cleanup but not for cnerg:develop or cnerg:pymoab_cleanup

Need to get this working

As it stands, the line m = pyne.mesh.Mesh() will fail when it cannot find any volume elements to check for tags in the mesh module.

This kind of mesh creation should either succeed - though I'm not sure what use that is or what it would look like - or it should fail with some kind of exception/message with information on how to create a PyNE mesh properly.

IMO the latter is a better choice for now.

The docker images used for CI need to be updated to include the updated dependencies

Make a Python2 dockerfile that builds all the dependencies for the pymoab_cleanup branch

The partisn routines only use dagmc to call discretize_geom. Instead of passing a DAGMC geometry, it could be possible to pass the data array that is the outcome of discretize_geom.

This will both localize the dagmc dependency and open the door for alternative ways of generating this data, and perhaps also different ways of testing partisn

The PyNE website has not been updated since 3/1/2018. We should push an update and document the best way to do this, perhaps using a docker image. The CNERG website may provide guidance for this.

Alternatively, we can implement a system that automatically updates the website on each new merge.... doctr?

The R2S script currently relies on the old PyNE mesh API and needs to be updated.

Once #10 is complete with the merge of svalinn/DAGMC#578, the dockerfile should be updated to refer to DAGMC default branch

Current build process requires using @ljacobson64 branch so that the newest version of MOAB (v5.1) can be used. Once that PR is merged in DAGMC, we can build from svalinn/DAGMC.

Some scripts have been reviewed already and others have not. This issue will review all scripts to see which still need to be updated.