Implement surface flux tallies

[GuySten]

Description

This PR enable openmc to calculate surface flux tallies.

Fixes #2.

Theory

https://www.tandfonline.com/doi/pdf/10.13182/NSE09-72

Checklist

• I have performed a self-review of my own code
• I have run clang-format (version 15) on any C++ source files (if applicable)
• I have followed the style guidelines for Python source files (if applicable)
• I have made corresponding changes to the documentation (if applicable)
• I have added tests that prove my fix is effective or that my feature works (if applicable)

[GuySten]

The tests does not pass because of #3743.

[GuySten]

This PR is ready for review.

[pshriwise]

Thanks for the PR @GuySten! I'm wondering what your thoughts are on providing the $\mu$ cutoff and ratio values on SurfaceFitlers themselves. As indicated in the paper linked in the description, different factors may be appropriate for different surfaces (for example, if the surface is interior or a boundary surface). Thus, it might make sense to allow these to be applied to SurfaceFitler's themselves. When scoring, I think it would be pretty clean to look up the SurfaceFitler object using Tally:get_filter and adjust the score as needed depending on the value of $|\mu|$ computed above the tally loop.

Given that the score requires a tally have a SurfaceFilter and that it isn't meaningful to have more than one SurfaceFilter on a tally (though interestingly we do currently allow it).

Let me know what you think!

[GuySten]

If I remember correctly there is a case when there are only CellFrom and Cell filters without surface filters.

I think if there is interest we can add in a subsequent PR attributes to the Surface objects themselves that will override the defaults in the setting object.

[pshriwise]

If I remember correctly there is a case when there are only CellFrom and Cell filters without surface filters.

I think if there is interest we can add in a subsequent PR attributes to the Surface objects themselves that will override the defaults in the setting object.

Ah, yes, right you are. Part of the motivation for my comment was that we avoid additional global settings, but in light of the CellFrom/Cell case you mentioned it seems the best approach.

[pshriwise]

Haven't forgotten about this. Will give it another look tomorrow