Add current tallies for bounded surfaces and cells

[massimolarsen]

Summary of changes

This PR adds cell-based current tallies and bounded surface-current tallies, while expanding unit testing coverage for existing tally behavior.

The new cell tally supports:

• net-current
• current-in
• current-out

current-in and current-out are reported as positive partial currents, while net-current carries the sign convention.

Types of changes

• Adds TALLY_CELL and current score constants for current-in and current-out.
• Routes mcdc.Tally(cell=..., scores=[...]) with current scores into a dedicated TallyCell implementation.
• Adds runtime scoring for cell-current tallies during non-reflective surface crossings.
• Computes pre-crossing and post-crossing cell IDs once per crossing and scores tallies attached to the crossed cells.
• Keeps reflective crossings from contributing to cell-current tallies.
• Adds bounded surface-current support for axis-aligned planar surfaces.
• Allows surface current tallies to be restricted with in-plane bounds, for example y=[...] / z=[...] on a PlaneX.
• Preserves existing tally type IDs for surface, collision, and tracklength tallies.
• Adds unit testing coverage for:
  • incoming and outgoing cell-current signs
  • separate current-in / current-out scores
  • vacuum boundary crossings
  • reflective boundary behavior
  • curved boundary crossings
  • bounded and unbounded surface-current scoring
  • bounded surface validation
  • tally factory routing and invalid score combinations
  • existing collision and tracklength tally routing behavior

Developer Checklist

• [ x] I have read the contributing guide.
• [ x] My code follows the code style of this project.
• [ x] I have updated the documentation accordingly.
• [x ] I have added tests to cover my changes.
• [ x] All new and existing tests pass

Associated Issues and PRs

• closes #
• related to #

Associated Developers

• Dev: @massimolarsen

[ilhamv]

Thanks, @massimolarsen. Apologies for just reviewing this.

This is a very good feature. But I think we may need to reorganize it a bit to follow the tally design core idea:

The currently existing proper tally types—surface, tracklength, and collision—correspond to the MC estimators used. The grouping is advantageous as it is directly related to the triggering event and scoring mechanism and thus the code implementation.

The new tally type TallyCell looks like TallySurface with more advanced spatial filtering. I'm wondering if the new tally can be facilitated through TallySurface with a cell filter, where the tally creation is chosen when a cell is given along with the current scores.

What do you think?

[massimolarsen]

Thanks, @massimolarsen. Apologies for just reviewing this.

This is a very good feature. But I think we may need to reorganize it a bit to follow the tally design core idea:

The currently existing proper tally types—surface, tracklength, and collision—correspond to the MC estimators used. The grouping is advantageous as it is directly related to the triggering event and scoring mechanism and thus the code implementation.

The new tally type TallyCell looks like TallySurface with more advanced spatial filtering. I'm wondering if the new tally can be facilitated through TallySurface with a cell filter, where the tally creation is chosen when a cell is given along with the current scores.

What do you think?

Yea, let me fix that. I misread TallySurface as "Surface" meaning the physical surface, so I created a new TallyCell for the physical "Cell" region. In reality "Surface" is referring to the surface crossing estimator, which makes a lot more sense along with tracklength and collision. That is my bad. I'll rewrite the tally as the TallySurface with an extra cell filter.

[massimolarsen]

Modified the previous TallyCell implementation to be a spatial filter within the existing surface crossing tally TallySurface. Updated testing and docs.