Review tallies

[RemDelaporteMathurin]

@shimwell

I did a bit of refactoring of the tallies we have.

It made me realise that for some of them, we were not bringing much convenience.

For instance:

Regular Mesh tally

# OpenMC
my_tally = openmc.Tally()
my_tally.scores = ["(n,Xt)"]
my_mesh = openmc.RegularMesh(name="3d_mesh")
my_mesh.dimension = (100, 100, 100)
my_mesh.lower_left = (0, 0, 0)
my_mesh.upper_right = (10, 10, 10)
my_tally.filters.append(openmc.MeshFilter(my_mesh))

# ODW
my_tally = odw.MeshTally3D(
    tally_type="(n,Xt)",
    bounding_box=[
        (0, 0, 0),
        (10, 10, 10)
        ],
    mesh_resolution=(100, 100, 100)
)

Here odw is not more convenient than OpenMC itself, or at least not enough to justify the maintainance work, the documentation (which would be a doublon of OpenMC's btw).

Unstructured mesh

# OpenMC
my_tally = openmc.Tally()
my_tally.scores = ['(n,Xt)']
filename = "filename.exo"
if filename.endswith(".exo"):
    library = "libmesh"
elif filename.endswith(".h5m"):
    library = "moab"
my_mesh = openmc.UnstructuredMesh(
    filename, library, name="my_custom_name")

# ODW
my_tally = odw.TetMeshTally(
    tally_type='(n,Xt)',
    filename="filename.exo"
)
my_tally.name = "my_custom_name"  # it's not exposed in TetMeshTally

Here there's coveniency in the library choice. Not ground breaking either.

A parsing of openmc.CylindricalMesh would be exactly the same: copying openmc features.

List of things I believe odw adds in no particular order: 1) 2D regular mesh tallies 2) additionnal convenience scores (TBR is just another way of writing (n,Xt))

  flux_scores = [
      "flux",
      "neutron_flux",
      "photon_flux",
      "neutron_fast_flux",
      "photon_fast_flux",
      "neutron_spectra",
      "photon_spectra",
      "neutron_effective_dose",
      "photon_effective_dose",
  ]

3) a convenient correspondence dict where the users can have nmm materials, openmc materials or strings from nmm library 4) a convenient way of creating the geometry with vacuum surfaces, reflective planes etc. Bonus: FusionSettings allow fusion users not to worry about "fixed_source" and inactive_batches. But that's two lines of code 😄

What I propose

1. should not be a tally class but a class inheriting from openmc.RegularMesh() that could be called RegularMesh2D (or even 3 classes: XYRegularMesh, XZRegularMesh, YZRegularMesh) The usage would be:

   my_tally = openmc.Tally()
   my_tally.scores = ["(n,Xt)"]  # note that we can have several scores here, where we can't in odw
   my_mesh = odw.RegularMesh2D(name="my_custom_name", plane="xy")
   my_tally.filters.append(openmc.MeshFilter(my_mesh))

   We could also make a PR to OpenMC.

2. We can either make a PR to openmc to include these scores natively, or leave it as it is (a compute_filters function) while getting rid of odw.Tally. The usage could be

   my_tally = openmc.Tally()
   my_tally.scores = ["flux"]
   my_tally.filters = compute_filters("neutron_flux")

   It's one additionnal line for the users, but the most complicated things are hidden in compute_filters (and so we keep the convenience).

3. I'm happy to keep odw.Materials as is since it provides useful checks

4. Same as 3. , it is very fusion focused as it provides easy ways of having reflective surfaces for segment models

Feel free to completely ignore all that. I'm just trying to minimise our maintainance workload.

I think we should see odw more as an openmc-extension than an openmc-abstraction. We provide fusion cad-based neutronics users with classes that make their life easier, while letting them the native flexibility of openmc.