Don't validate material modifications if they are None

[drewj-usnctech]

What is the change?

Material modifiers are not validated if the corresponding value is None

Why is the change being made?

During block construction, an error can be raised if a material modifier does not apply to any components in the block. This is great, and has already caught some errors. However, if a material modifier applies to some components in other blocks, and it not applied to a block without components that support that modifier, an error is raised.

Consider two blocks in an assembly, one fuel and the other axial reflector. The enrichment could be set in the fueled block with U235_wt_frac, but setting a U235 enrichment in an the axial reflector does not make sense. The following YAML input

U235_wt_frac:
  - 0.05
  -

would support this case, but the material validation fails because no component in the axial reflector supports the U235_wt_frac modifier.

Closes #1367

Checklist

• This PR has only one purpose or idea.
• Tests have been added/updated to verify that the new/changed code works.
  • Open to talking testing

• The code style follows good practices.
• The commit message(s) follow good practices.

• The release notes (location doc/release/0.X.rst) are up-to-date with any important changes.
  • Maybe not necessary?
• The documentation is still up-to-date in the doc folder.
• The dependencies are still up-to-date in setup.py.

[john-science]

Is None something we want to support?

Why not throw an error here and force people to set it to 0.0?

What is the benefit of supporting None? It isn't even a valid YAML file any more.

[drewj-usnctech]

Is None something we want to support?

Why not throw an error here and force people to set it to 0.0?

I'm inclined to agree w/ @keckler with

Forcing a zero value just doesn't really make sense when that particular modifier doesn't apply to a given material. I would say that is less desirable than a None value or empty string.

(from #1367 (comment))

There are some cases where you may want to pass a literal 0.0 as a modifier and it actually be applied. 0% enrichment isn't a great example, but maybe a mixing fraction?

What is the benefit of supporting None? It isn't even a valid YAML file any more.

It's loadable with ruamel at least (see #1367 (comment))

I will close by saying this is probably something that should first be discussed as a proposed change in #1367: supporting either empty strings and/or None as a signal that a modifier should not be applied. In the general trend of there should be one way to do things, and current ARMI inertia for relying on empty strings for this capability, that feels like the simplest solution

[john-science]

Okay, I can jive with the high-level idea for this PR. Let's do it.

But this might be an invalid YAML file that ruamel.yaml isn't fighting us on. But even if that's so, I bet the rumael.yaml team won't change their opinion on this, and they will support it forever.

IF they do drop support for it, I won't be able to fight that. We would then just lose this feature. But I am betting the chances of that are low.

[john-science]

Can we fix black for this PR? Sorry, it's a forked repo, I would do it myself.

[john-science]

@drewj-usnctech Looks good! I know I technically made a bunch of comments. But they're all small.

Looks suuuper close to me.

[john-science]

@drewj-usnctech This PR is super close. Just FYI.

[drewj-usnctech]

@drewj-usnctech This PR is super close. Just FYI.

Thanks @john-science. I'll try to get back to it by end of the week