Use b.core instead of b.r.core.

[mgjarrett]

Description

Blocks have an r property and a core property. Both functions just look up the chain of ancestors of the block to find the core and reactor. It's unnecessary to go all the way up to the reactor just to then grab the core off of it.

---

Checklist

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

• 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 bug fixes or new features.
• The documentation is still up-to-date in the doc folder.
• The dependencies are still up-to-date in setup.py.

[mgjarrett]

Basically acting on the note in this docstring:

armi/armi/reactor/blocks.py

Lines 173 to 181 in 646f23d

	It may make sense to try to factor out usage of ``b.r``.
	For now, this is presumptive of the structure of the composite hierarchy; i.e.
	the parent of a CORE must be the reactor. Fortunately, we probably don't
	ultimately want to return the reactor in the first place. Rather, we probably want the core
	anyways, since practically all `b.r` calls are historically `b.r.core`. It may be
	prefereable to remove this property, replace with `self.core`, which can return the core.
	Then refactor all of the b.r.cores, to b.core.
	"""

Can't completely remove b.r yet because it's used to get active nuclides from reactor blueprints here:

armi/armi/reactor/blocks.py

Line 737 in 646f23d

if any(nuc in self.r.blueprints.activeNuclides for nuc in adjustList):

[john-science]

I love it!

Can we remove the comment you link on line ~173 now?

[mgjarrett]

Can we remove the comment you link on line ~173 now?

I would like to remove that entire function, but we still have one case of b.r.blueprints so we can't remove this property altogether. I think we can trim some of the docstring and make it better. I'll push a commit with a new docstring.

[keckler]

I think these are good changes.

With regards to your comment:

Can't completely remove b.r yet because it's used to get active nuclides from reactor blueprints here:

Is there a reason why we want to remove b.r completely? I agree that, in the cases you changed b.r.core -> b.core, it makes sense because it avoids unnecessary computation. But I think that b.r could still be useful in the API.

Plus, if we're trying to avoid changes to the API, I would view that as an unnecessary change to the API.

Just a thought.

[mgjarrett]

I agree that removing b.r would be an unnecessary change to the API. The docstring had this comment:

It may make sense to try to factor out the usage of ``b.r``

So that's why I thought it might be desirable to remove it. But as long as it's being used, and it's not hurting anything, it makes more sense to leave it in for continuity.