Redesign ARMI Materials to be based on YAML data files

[john-science]

After much discussion, we have determined the ARMI materials are hard to use well and they do not sufficiently separate data from code.

The best solution seems to be to store ARMI material data in data files, next to the code.

ARMI will still need to support fully in-code, special case materials. But we do not expect that will be the usual case.

Side Notes

1. This is a good time for ARMI to transition to measurable density data. "density" and "linear expansion" are things people measure in the real world, and good data can be found. But "pseudo-density" should be moved to be the second-class citizen it is.
2. ARMI's current materials should be moved into YAML files in armi/testing/materials/, to further cement that ARMI's materials are not production-worthy.
3. The design should allow for people to put references in every line of the data file.
4. The design should allow for a set collection of curves / properties: density, linear expansion, heat capacity, and so on. But ARMI Plugins should allow people to add to that list.
5. Each curve / property for a material should be able to take an arbitrary number of independent variables.
6. Curves / Properties should be able to be defined based on look up tables, if desired.

[keckler]

I do not disagree in any way that the ARMI materials are a mess. However I don't think that moving them into the testing/ directory is sensical or helps to fix the issue.

[partofthething]

Lots of properties have a few measured points and recommended continuous functional representations published in the literature, so it'd be nice to maintain some ability to input arbitrary expressions e.g. of temperature, burnup, and other things like pressure. I'm not sure that YAML is ideal for functions because you end up writing your own expression parsing language. I think there's a lot of value in having something like Python, C++, or Rust still involved here.

Furthermore, in a vast number of reactors (i.e. 90%+ of the ones in operation and under construction today), the coolants can be two-phase. Having lookup tables and/or functions that can be a function of both pressure and internal energy has been used before to give complete representations of such properties. If we're doing a big redesign, it may make sense to enable native representation of such fluids. See https://doi.org/10.2172/5437631 for example:

I know people have made independent material property tools as well, particularly in languages that can be readily linked to physics codes written in compiled languages. I think there is a lot of value to that as well since it enables C-speed consistent lookups. Might be a good opportunity for another repo!

As for pseudodensity, yeah it's a dumb name, but the fact that measured linear expansion coeffs and densities almost always disagree in a way that doesn't conserve mass (i.e. because expansion isn't always perfectly isotropic) is a real issue that must be reconciled in code if you're going to maintain conservation of mass, which I have always argued is much more important in nuclear calcs than conservation of density.

Anyway just a few thoughts. 👋

[john-science]

• @keckler - "I don't think that moving them into the testing/ directory is sensical" - The materials stored in the ARMI repository can only use open-source, public ally-available information. And they are, by and large, not trustworthy data sets. I have said this every day for four years, and people still insist on using ARMI materials in production. This is just an idea I have so that people will take the hint. Thoughts?
• @partofthething - " it'd be nice to maintain some ability to input arbitrary expressions" - Definitely. I stated in my description of the solution both that each curve/property should have an arbitrary set of independent variables. We already have code downstream from ARMI that does this, it will definitely be included.
• @partofthething - look-up tables - Ah! Yes! Look up tables are a great idea. We already have code downstream from ARMI that does that. That will definitely be included.

[drewj-tp]

Is yaml really the best format for lookup tables? I can see it handling fine for maybe 1D properties, where you could have two lists, one for independent and one for dependent variables.

But if you had some property that depends on multiple parameters (e.g., temperature and pressure, temperature and burnup), I think YAML would get unwieldy fast.

I would encourage us to think about H5. You could envision one main file that contains groups for each material.

[john-science]

I can see wanting to pick something other than YAML, sure. But since 99% of these materials have very little information in them, I think a human-readable data format would be best. And, if it helps, we HAVE several look-up table materials in YAML format that we've been using for the past year. No one has had a problem with them yet.

[drewj-tp]

@bsculac may have some insight on using something like xarray for labeled axis on lookup tables. So you could have an N-D array for your lookup table data, and each axis contains information not just on the points but also the "name" (e.g., temperature, pressure)

Think like a pandas.DataFrame with an index that contains not just the values but small metadata indicating what the values in the index represent