Missing material modifications in docs

[keckler]

There is a table in section 2.2.4 of the documentation that describes the material modifications available across all the material classes in the framework:

This table is missing entries for the following material classes:

• lithium
• mox
• uraniumOxide
• uZr

The entries are drawn programmatically in blueprints.rst by looking at all subclasses of Material:

The problem appears to be that it does not recursively look into all subclasses of Material. For instance, the classes above are subclassed from:

• lithium -- material.Fluid
• mox -- UraniumOxide
• uraniumOxide -- material.FuelMaterial
• uZr -- material.FuelMaterial

This piece of the documentation should be updated to draw the entries recursively.

[john-science]

Nice find!

Thankfully, that's an easy fix.

[john-science]

I haven't forgotten about this ticket. It appears that inside the if numArgs > 1: condition, we can do something like:

for subM in m.__subclasses__():

And do the same if numArgs > 1: checking again. I just haven't decided the cleanest way to write the resultant two loops (or the final table) yet.

It'll happen this week.

[john-science]

The PR for this issue is here: #432

And the table this new code generates looks like:

Material Name	Available Modifications
B4C	B10_wt_frac, theoretical_density, TD_frac
FuelMaterial	class1_custom_isotopics, class2_custom_isotopics, class1_wt_frac, customIsotopics
Lithium	LI_wt_frac
Sulfur	sulfur_density_frac, TD_frac
ThU	U233_wt_frac
UThZr	U235_wt_frac, ZR_wt_frac, TH_wt_frac
UZr	U235_wt_frac, ZR_wt_frac
UraniumOxide	U235_wt_frac, TD_frac

[keckler]

Thanks John. My only issue is that the modifications that we just deprecated in #430 are showing up in this table (i.e. theoretical_density and sulful_density_frac). I don't really see a way around this, so I guess I'll live with it.

[john-science]

Thanks John. My only issue is that the modifications that we just deprecated in #430 are showing up in this table (i.e. theoretical_density and sulful_density_frac). I don't really see a way around this, so I guess I'll live with it.

Yeah, at some point we will have to move the API along, and fully deprecate those method signatures. When that happens the code (and the docs) will be cleaner.

Set your watches for deprecation day.