Re-Examining and Optimizing Previous Material Objects

[csdechant]

This issues is inspired by a conversation in PR #265 (comment below for reference). To summarized, due to the ongoing development of Zapdos, previous material objects should be re-examined to see if any declare property are not being utilized in a current test and address the need for a test or the removal of the property.

This object was made during Alex's thesis and I haven't used it except when I was first using Zapdos. After a quick search in Zapdos, it doesn't seem that any of the test files used this exact material property. That being said, I don't think we should remove it for this PR, as this and other material objects (such as Gas.C and GasElectronMoments) should be re-examined to see if any declare property are not being utilized in a current test and address the need for a test or the removal of the property.

Originally posted by @csdechant in https://github.com/shannon-lab/zapdos/pull/265#discussion_r1905941885

[gsgall]

Just to add to this there are also declared material properties in the GasElectronMoments which hard core the name of transport coefficients for mean electron energy such as mumean_en. However, this is not consistent in other objects which request the material properties. Those allow the user to specify the name of the variable they are using and use that to define the name of the material property being requested. We need to be consistent across objects on how to handle the naming of material properties.

Also there are constants which are declared as material properties which really we could extract out of material blocks and just define these constants (Avogadro's number, elemental charge etc.) globally in a header file so we won't need to utilize material properties for constants.

[csdechant]

Just pushed a branch that will address @gsgall's comment about "hard-coding" transport names for electrons and electron mean energy densities (Branch transport-variable-names). Putting a note here that a PR is not make, yet, because this branch relays on several currently active PRs. Once those PRs are merged, I need to carefully rebase this branch to remove any accidental duplicated commits.