Materials on a Mesh

[Anthony Scopatz]

This is mostly for Elliott, but, 

How do I tag materials on a Mesh instance?  I thought that there was supposed to some standard way of doing this...  Do you have any examples?

Be Well

Anthony

[Elliott Biondo]

Anthony,

Wearing my CNERG hat--as a customer of PyNE--this question is particularly topical. Wearing my PyNE hat, it is not clear if the CNERG answer should be the PyNE answer.

In CNERG, I believe the only way we use meshes of materials is to discretize a DAGMC geometry. DAGMC geometries are created in CUBIT, so the material names that end up on meshes are the names that are used within CUBIT. Unfortunately, in CUBIT, their is no way of assigning arbitrary attributes to points/edges/surfaces/volumes. Instead CUBIT "groups" are created to designate materials, and volumes are assigned to be members of these groups. These groups have names like "mat<material_number>_rho<density>. The resulting mesh instances will contain tags with these names with values equal to the volume fractions each material.

This scheme is considered to be non-ideal and is queued to be refactored. Ideally, we would be able to have key-value access to materials and densities separately for any DAGMC volume (e.g.: material:SS304, density:8.05). One pathway to achieve this would involve ParaView instead of CUBIT. In this case, mesh representation of the geometry would have similarly simple tags.

I think PyNE/CNERG should come up with a mutually adopted tagging schemes, which is a big project.

Elliott

--
 
---
You received this message because you are subscribed to the Google Groups "PyNE" group.
To unsubscribe from this group and stop receiving emails from it, send an email to pyne-dev+u...@googlegroups.com.
For more options, visit https://groups.google.com/groups/opt_out.

--

Elliott D. Biondo

Nuclear Regulatory Commission Fellow

Computational Nuclear Engineering Research Group (CNERG)

Department of Engineering Physics

University of Wisconsin - Madison

434 Engineering Research Building

1500 Engineering Drive

Madison, WI 53706

[Anthony Scopatz]

Hello Elliott, 

Thanks for your thorough answer.  First let me say that I am happy and willing to work with you on this issue.  I think that it is on our critical path.  I would really like to be able to run a version of the diffusion notebook that incorporates transmuting materials in each cell.  If we had that, we might be the sexiest open source nuclear engineering code ever!

I understand what you are saying with respect to the DAGMC needs and CUBIT.  I think that PyNE should support these use cases but by transforming into some canonical PyNE representation. 

In PyNE's perfect would, I think we would want to be able to tag every mesh entity with a Material instance.  Then the material would be responsible for handling density, etc.  Do you have any idea how to do this with MOAB?  Is this a better question for the MOAB list?

Be Well

Anthony 

[Elliott Biondo]

Tagging a Material instance would be amazing. I am not sure if this is possible in MOAB or iMesh, but I know PyTAPS does not support tagging arbitrary data types. I bet you could store a pointer to a Material instance, for the purpose of coupled transport/burnup as you mentioned, but I imagine writing to disk would be more tricky.

[Paul Wilson]

Hi all

The right answer here may depend on how you want to use it.

I've been throwing around the idea of referencing things the other way: a map/dictionary keyed on the MOAB entity handle and containing a material object.  Since MOAB's format is built on HDF5, I'm interested in writing the material info in some part of the hierarchy next to the MOAB info.  This is a hot topic in the fusion neutronics community with an intense interest in standardizing gamma source files for portability.

This bypasses some of the MOAB tag capabilities, but I fear that a material object is a big changing blob that might stress out those tag capabilities.  That is a question better posed to the MOAB list, though.

Paul

-- ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ --

Paul Wilson ~ UW-Madison ~ 608-263-0807 ~ cal: http://bit.ly/pphw-cal

Professor, Engineering Physics. ~ http://cnerg.engr.wisc.edu

Faculty Director, Advanced Computing Infrastructure

[sent from my iPad]

[Anthony Scopatz]

Paul, 

I am a huge fan of this invert strategy!  In fact, I think that it would be super easy.  We could simply attach a MaterialLibrary instance (called mats?) to PyNE Mesh class keyed in the way you describe.  This is great because all of the pieces are there.  It also adds some umph and impetus to use the PyNE Mesh rather than just the MOAB mesh.  It is no longer a thin wrapper around the MOAB interface.

The other thing that this solves is the persistence problem. The PyNE mesh would have a write_hdf5() method which calls the MOAB mesh HDF5 writer and the MaterialLibrary.write_hdf5() method. 

Of course, we'll have to inform our analysis and viz tools (yt) where the different fields live, but that shouldn't be too hard.  Alternatively, we could expose a PyNE Mesh-level interface for grabbing 'tags' from the appropriate place.  And of course, none of this stops us from dumping everything to MOAB tags if we need to too.

I think that this is the right thing to do.

Be Well

Anthony