Request: Defining `Custom` material properties in the blueprints

When using the custom isotopics within the blueprints file it allows a user to specify number densities or mass fractions with some specified density for defining the initial composition of the material. In this case, a user can choose to use material: Custom or choose to use material: X, where X can be something like SS316 or UO2 as an example.

When specifying material: X, the ARMI framework will initialize the component to have material X and then it will default to using the Python methods for getting different material properties that are implemented (e.g., density, linear expansion coefficient, heat capacity, etc.). Although when a user specifies Custom as the material then there is limited functionality to specify these types of material properties.

blocks:
    inner fuel:
        clad: &component_fuel_clad
            shape: Circle
            material: SS316
            Tinput: 20.0
            Thot: 20.0
            id: 0.64
            od: 0.77
            mult: 271
        fuel:
            shape: Circle
            material: Custom
            isotopics: InnerFuel
            Tinput: 20.0
            Thot: 100.0
            id: 0.0
            mult: clad.mult
            od: clad.id

Sometimes when doing benchmark analyses it is useful to specify the number densities of a material using custom isotopics while still maintaining the use of the Custom material so that the density is not inherited from a given material, but instead use the number densities that are specified by the user. In this case, it would be nice if a user could inherit some methods from an existing material (i.e., linear expansion coefficient), but not all of them.

I could imagine a section in the blueprints that could allow a Custom material object to be built. Maybe this means allowing the user to import custom material definitions from a separate Python script (similar to shuffleLogic.py) or maybe this means just providing something like:

materials:
    CustomFuel:
        isotopics: InnerFuel
        linearExpansion: UZr.linearExpansion
        heatCapacity: SS316.heatCapacity
blocks:
    inner fuel:
        clad: &component_fuel_clad
            shape: Circle
            material: SS316
            Tinput: 20.0
            Thot: 20.0
            id: 0.64
            od: 0.77
            mult: 271
        fuel:
            shape: Circle
            material: CustomFuel
            Tinput: 20.0
            Thot: 100.0
            id: 0.0
            mult: clad.mult
            od: clad.id

In this scenario, the isotopics are now a child of the CustomFuel material that is defined in the materials section (rather than it being its own section on the component definition) and then the linearExpansion and heatCapacity functionalities are tied to the pre-existing UZr and SS316 methods that are already implemented in the code base.

This would allow me as the user to circumvent the warning in https://github.com/terrapower/armi/pull/496 and have more control over this behavior without having to implement a new Material class in the application I am working off of to handle both the correct treatment of a custom number density input along with the allowing the material to thermally expand, etc.

Please let me know what you think about this @ntouran / @john-science. The specific use case for this is when a benchmark specifies the number densities of a component/block and when we would like to have linear expansion defined to support a reactivity coefficient calculation.

[ntouran]

Hmm, while implementing that it occurred to me that plugins don’t really do too much in terms of registering materials that they bring in other than setting the material resolution order to know about them (as @john-science was trying to remind me earlier).

This leads me to the supported path.to.module:MaterialClassName syntax supported by ARMI already. If you specified your material name in blueprints as, e.g. jakesCustomMaterials:Milkshake then the system would try to import jakesCustomMaterials.py and look for the Milkshake material class in there.

This can and does currently provide user-supply-able material classes in the run’s input directory, provided that the input directory is in the module resolution path (e.g. PYTHONPATH).

I tried this out and it works. But it’s kind of a pain to always be updating your PYTHONPATH. One thing we could consider doing to make this happen is having ARMI add the input directory directly to the sys.path variable at runtime. Then imports by name would work no problem.

Thoughts on that?

[jakehader]

Thanks for the feedback @john-science. I definitely think that this warrants further discussion between you, me, and @ntouran. Let’s take it offline and report back here with a proposed solution or maybe alternate way to frame the problem I am looking to solve.