More flexible handling of MCNP materials in mats2ALARA

[gonuke]

The current version of mats2ALARA assumes that all materials are defined in MCNP with a single isotope per line. MCNP allows more flexibility. We should probably support this. The addition of MCNP material reader to PyNE may supersede this issue.

[elliottbiondo]

I am hoping I can just do away with mats2ALARA and replace it with some sort of R2S wrapper script for PyNE. However (as apparent from discussion in my most recent PyNE issue, #78) it appears that the scope of the code I am writing for PyNE is becoming increasingly general and therefore more difficult to implement. If there is a short-term need for this particular functionality of mat2ALARA (e.g. Ales needs it), I will fix it. It is a fairly easy fix. Otherwise I will just focus my efforts on PyNE.

[gonuke]

Let's stick with the PyNE path and update documentation to clarify that MCNP materials must be specified with one isotope entry per line.

[gonuke]

Do you think it would be possible to use pytaps (or something) to get the group names from the geometry as part of the mat2ALARA process? Most importantly, this would allow that script to know the densities and fill that information in so that the user doesn't have to do it manually (and with great tedium).

[elliottbiondo]

Do you think it would be possible to use pytaps (or something) to get the group names from the geometry as part of the mat2ALARA process?

Yes. This would be a solution to the R2S use case where the user has a DAG-MCNP style input file, where all the densities are only in the h5m file. As you know my current plan is to write all the generalized material stuff in PyNE and then make R2S wrappers. Reading densities from h5m could be one of these wrappers.

That being said, I think a better work flow would be the one we previously discussed where only "engineering names" (e.g. SS304) appear on the h5m file (and not MCNP material numbers and densities), coupled with a standalone library of PyNE materials to read from.

[gonuke]

I agree with the last point on only using "engineering names", but we WILL need to separately specify density if we do this. A full material assignment will need both a material and density assignment. The problem for a mat2ALARA-like step is then the same, just with a different syntax.

[elliottbiondo]

The problem for a mat2ALARA-like step is then the same, just with a different syntax.

I am not sure I understand. Using the "engineering names" work flow I think the matsALARA step would be eliminated entirely. There would be a standalone library of materials in PyNE format (density include). This is something that would be maintained in repo somewhere. The mats2ALARA step would be replaced by a step that would simply print out MCNP and ALARA material definitions for all the engineering materials specified on the h5m using the write_alara() and write_mcnp() methods that I am planning on adding to the PyNE material class.

[elliottbiondo]

I have all the PyNE framework for this complete, now it's just a matter of making an R2S wrapper. I think it may be good to make a quick version with identical I/O to mats2ALARA, then work towards the engineering materials workflow (which will require modification to DAG-MCNP).

Regardless, moving forward will introduce a PyNE dependency to R2S.

[elliottbiondo]

I just pushed a PyNE version of mat2alara.py that should fix all the issues of the previous version and add a lot more features. It requires the latest version of PyNE.

You can close this issue, or leave it open until the engineering materials stuff is done (though that may be more of a DAG-MCNP issue).