Should component volume consider symmetryFactor?

[albeanth]

In #1954, we are starting to store more information at the component level. One of those things is the decay power (powerDecay). While looking at some downstream test results with these changes, we noticed that the center-most assembly block-wise decay power was not properly accounting for the symmetry factor. After some discussion, we found that it was due to the fact that we were calculating the block-wise decay power from component-level decay power; and the latter was getting calculated without consideration to the symmetry factor.

E.g., we typically calculate block-wise power by doing something like:

b.decayPower = b.decayPowerDensity * b.getVolume()

where b.getVolume() accounts for the symmetry factor. However, a block-wise decay power derived from component-level decay power looks something like:

for c in b:
    c.decayPower = c.decayPowerDensity * c.getVolume()

b.decayPower = sum(c.decayPower for c in b)

where c.getVolume() does not respect the symmetry factor.

So all this said, should c.getVolume() respect the symmetry factor? This could look something like:

[john-science]

@albeanth "decayPower" is not a parameter in ARMI. That sounds like some MCNP value.

should c.getVolume() respect the symmetry factor?

For your situation, it seems like a clear "yes". But Component.computeVolume() is used in just SO MANY place, so.... can I say for sure, right now, that making the suggested change is correct everywhere? No, I can't say that.

But:

1. We can just test your idea, and see if a million things break.
2. EVEN IF a bunch of other things break, we could add a parameter to that method:

def computeVolume(self, respectSymmetry=False):

So, it seems fixable either way.

[albeanth]

"decayPower" is not a parameter in ARMI.

It was until #1954. Either way, that's not the important part here.

I agree, component.getVolume() is used an a gazillion places - and is why I wanted to open this Issue first and see what others thoughts were. Just changing it will likely have quite the ripple effect.

We could do the optional param, that would be easy. But if it is indeed a bug, then maybe the optional param isn't the "right" option and really it should just be hardcoded in. That's the part I don't know and wanted to get the opinion of others on.

[jakehader]

"decayPower" is not a parameter in ARMI.

It was until #1954. Either way, that's not the important part here.

I agree, component.getVolume() is used an a gazillion places - and is why I wanted to open this Issue first and see what others thoughts were. Just changing it will likely have quite the ripple effect.

We could do the optional param, that would be easy. But if it is indeed a bug, then maybe the optional param isn't the "right" option and really it should just be hardcoded in. That's the part I don't know and wanted to get the opinion of others on.

I'm not sure I agree with a keyword argument here. To me it seems like the multiplicity should be scaled back with the symmetry so that this would be captured on self.getArea(). This seems like it could be a bug in the pin level parameters if we don't account for this in the spatial grid and number of components in the block.