Potential for incorrect material properties upon restart or db load

[keckler]

Whenever a material property is modified by a material modification and that modifier doesn't alter the material in such a way that the change is recorded in the database, the property will likely be wrong when the reactor is loaded from the database. This includes instances of just playing around with the reactor in iPython or in restarts/snapshots.

A concrete example of this is the TD_frac material modifier in either UraniumOxide or B4C. Because TD_frac (and its associated instance variable theoreticalDensityFrac) is not written to the database directly, it is left at its default when the reactor is loaded back up from the database. So if you do a restart run with a case that has either of those materials in it, your material densities will be wrong if your TD_frac entries don't exactly equal the default values in the material class. For UraniumOxide that is 1.0 and for B4C that is 0.90.

There are other materials, including ThoriumOxide and some lesser-used materials that will have a similar issue.

This same type of error is possible for other material modifiers as well. For instance if your thermal properties like thermal conductivity or heat capacity are dependent on composition as specified in the material modifications. I don't see any examples of this in the public framework.

I believe this has the potential to be causing lots of analysis problems, depending on how one is using restart cases in their workflow.

[john-science]

Yes, I believe you correctly understand the current situation.

The Database treats materials as static things.

But people can inject whatever code they want into the materials, of course. Including adding a lot of state to a material object. But all that arbitrary state information will be lost when you translate your run to the database.

This shouldn't affect most ARMI runs, but it would affect restarted runs. Mostly, it could affect post-run analysis.

I think it is infeasible to try to store any arbitrary materials state in the database. But if there is one important variable, it should be stored as a parameter on the component, and not on the material.

[keckler]

To clarify, I do not believe this bug is impacting the number densities stored as a component parameter, at least in the way that we are currently using the material's density() method.

In the current usage, c.material.density() is just used to instantiate the number densities. From that point on (at least in neutronics-type calculations), if we want to know the density ARMI actually looks to the number density parameter, since that is updated with burnup. This means that the number densities going into our neutronics calculations are not adversely impacted by this.

Other use cases may use c.material.density() in broader ways, though, which could be dangerous during restarts/snapshots.

[drewj-tp]

Taking the tact of attempting to make the theoretical density a component parameter, defaulting to one

After some looking, the majority (if not sole) use case for TD is (surprise!) computing the actual density of a material. If we move TD to a component parameter, we'd need to

1. Use this in computing density for things like composition so dens = self.material.density(...) * self.getTheoreticalDensity()
2. Remove usage of Material.getTD when computing material density
3. Consider deprecating Material.getTD and Material.setTD? If the goal is to keep them stateless, removing the theoretical density attribute will go a long way

[keckler]

@drewj-tp Should this ticket have been closed by your recent PR?

[drewj-tp]

@keckler

@drewj-tp Should this ticket have been closed by your recent PR?

I'm very conflicted and unsure.

#1852 fixed a specific instance where the theoretical density stored on a material is not written to / read from the database. If your intent in this ticket was to call out that specific case, then yes we can close this.

I was under the opinion this ticket is focused more generally on the design issue where anything can be stored on a material and it will not be passed to db and back. #1863 is a symptom of that problem in my opinion