[ENH] Material object

[drewejohnson]

Supporting object for storing SERPENT materials

Requirements

1. Be created with a block of data straight from a SERPENT input or burned material file
2. Store nuclides and their densities on the object
3. Remove and/or update nuclides
4. Update material values like temperature, volume, or thermal scattering data

Optional

1. Output the data with some template engine like Jinja2 or Mako

Holding up

#10

[drewejohnson]

I'm going to expand upon my vision for this object.

Usage

This object should be instantiated/created with the parser to which it is connected, the name of the material, a dictionary of nuclide-density pairs, and dictionary of keywords, e.g.

nucDens = {'nuc0.09c': 0.3, 'nuc1.09c': 0.7, ...}

The dictionary of keywords corresponds to any option that can be used in defining a material [Section 4.1.2 of the manual] like temperature, density, volume, burn, etc.

It will be the responsibility of the parser or the end user to produce these dictionaries, e.g. the burned material reader will obtain this data from the bumat files.

These should also be easy to update, either with public methods for updating nuclide mass/atomic fractions, or by updating the keyword arguments.

Example

mat = Material(<parser>, 'demoMaterial', {nuc: dens pairs}, 
                        {'dens': dens, 'tmp': temp, 'vol': volume, ...})
mat.metadata['temp']
# returns temperature
mat.metadata['vol'] = newVol
# update the volume

Discussion

I am not convinced if we should automatically store the nuclide library indicators, .09c, or if those should be inferred from the material temperature.
If the temperature is given, either at creation or updated as above, then the library suffixes when printed must match.
That way, when we do move towards writing objects with the templating engines, we will not run into issues where the materials temperature definition does not align with the library indicators

We may want to subclass this object by having a standalone class and one that is linked to the reader.
Currently, the DepletedMaterial is linked to the DepletionReader, and I believe the Homogenized Universe Object that @sallustius is working on will be linked to the results and branching readers.
All of the main functionality could be written into a base class, and a linked material object, specific to the readers, could have a simple subclass, as

class StandaloneMaterial(object):
    def __init__(self, <arguments>):
        # create
    # add the functionality to this object

class LinkedMaterial(StandaloneMaterial, _SupportingObject):
    def __init__(self, reader, <arguments>):
        StandaloneMaterial.__init__(self, <arguments>)
        _SupportingObject.__init__(self, reader)