No component matched warning for non-pin type fuel

[macatillo]

When using non-pin type fuel, the user is warned on "No component matched" for Flags.WIRE and Flags.CLAD. It is not clear where the warning is originating from or what can be done to fix it.

This is occurring in a non-standard fast reactor benchmark (BFS-73-1), where there are no pins/clad defined and the core uses a stack up of "disks" or "plates".

[info] Will expand CR, FE, H, NI, SI, TI, O, NA, AL, MN elementals to have natural isotopics
[info] Constructing assembly `Inner Fuel 0 Rods`
[warn] No component matched Flags.WIRE in <Homogenized UO2 Aluminum Can Reflector Pellet: 0 SS Bars block-bol-000 at ExCore XS: B BU GP: A>. Returning None
[warn] No component matched Flags.CLAD in <Homogenized UO2 Aluminum Can Reflector Pellet: 0 SS Bars block-bol-000 at ExCore XS: B BU GP: A>. Returning None
[info] Constructing assembly `Inner Fuel 1 Rods`
[info] Constructing assembly `Inner Fuel 2 Rods`

[ntouran]

Oof sorry about that. That is most likely coming from a residual call to b.getSmearDensity, probably at armi/reactor/blocks.py:813:40: self.p.smearDensity = self.getSmearDensity().

We've modeled BFS-73-1 before too and surely got the same warning. That shouldn't happen at the framework level so I'll see what we can do to move that call into a more specific pin-type fuel plugin.

For the time being, I can at least assure you that you can safely ignore the warning. The code just won't have a meaningful value set to the block-level smearDensity param.

Thanks for the report.

[jakehader]

I wonder if these types of reports for calculating design-specific information, like smear density, should be the responsibility of the reports plugin where the API could expose certain functions to call based on the design(s) being analyzed.

Things like smear density, hydraulic diameter, wetted perimeter, etc. are design type specific but also depend on user modeling choices. Providing a warning indicates that there is a problem with the input, but maybe this is a choice by the user to not model a grid for a block and just to treat it as a homogenized blob.

I think we should discern between real warnings and input suggestions in the logging. This is somewhat related to how we handle the settings validation too. It's probably worth considering a separate log for this information rather than the stdout log or a different message verbosity (i.e., note) especially since warnings can be easily overlooked if there are too many that don't have actionable feedback to the user.

[john-science]

I had never seen this ticket before, so sorry I'm late to the party.

First off, Nick was correct, the error happens in Block.completeInitialLoading() on this line:

https://github.com/terrapower/armi/blob/15e313850c6f71d47f3fde5ec1d047a9fadb7c43/armi/reactor/blocks.py#L790

The real problem here is that this is a method on the Block base class that assumes the Block is pinned. As @drewj-tp recently pointed out, there should be another layer of abstraction here, like PinnedBlock that could have the pin logic here moved into it.

A stop-gap measure would be to insert a check in getSmearDensity() to see if the Block in question is pinned:

if self.getNumPins() == 0:
    return 0.0