internlm/SWE-Fixer-Train-110K huggingface dataset:
Repository: openmc-dev/openmc

Issue:
Add method to get total material density
For multiphysics coupling, convergence between successive iterations of OpenMC with a T/H solver may be based on the densities, in which case we will need to make the initial density used in OpenMC available to a multiphysics driver. 

There is an `openmc_material_get_densities()` method to get the density of each nuclide in a material, but it would be cleaner for a multiphysics driver to avoid doing a summation on this density and instead directly get the density in g/cm^3.


Discussion:

Resolving patch:
diff --git a/openmc/capi/material.py b/openmc/capi/material.py
--- a/openmc/capi/material.py
+++ b/openmc/capi/material.py
@@ -32,6 +32,9 @@
     POINTER(c_int)]
 _dll.openmc_material_get_densities.restype = c_int
 _dll.openmc_material_get_densities.errcheck = _error_handler
+_dll.openmc_material_get_density.argtypes = [c_int32, POINTER(c_double)]
+_dll.openmc_material_get_density.restype = c_int
+_dll.openmc_material_get_density.errcheck = _error_handler
 _dll.openmc_material_get_volume.argtypes = [c_int32, POINTER(c_double)]
 _dll.openmc_material_get_volume.restype = c_int
 _dll.openmc_material_get_volume.errcheck = _error_handler
@@ -139,6 +142,15 @@ def nuclides(self):
         return self._get_densities()[0]
         return nuclides
 
+    @property
+    def density(self):
+      density = c_double()
+      try:
+          _dll.openmc_material_get_density(self._index, density)
+      except OpenMCError:
+          return None
+      return density.value
+
     @property
     def densities(self):
         return self._get_densities()[1]


Test patch:
diff --git a/tests/unit_tests/test_capi.py b/tests/unit_tests/test_capi.py
--- a/tests/unit_tests/test_capi.py
+++ b/tests/unit_tests/test_capi.py
@@ -120,6 +120,9 @@ def test_material(capi_init):
     m.set_density(rho)
     assert sum(m.densities) == pytest.approx(rho)
 
+    m.set_density(0.1, 'g/cm3')
+    assert m.density == pytest.approx(0.1)
+
 
 def test_new_material(capi_init):
     with pytest.raises(exc.AllocationError):
Repository: openmc-dev/openmc

Issue:
Issues reading in fission heating from hdf5
openmc crashes due to misshapen fission heating and total cross section
```
 Reading U235 from U235.h5
terminate called after throwing an instance of 'xt::broadcast_error'
  what():  Incompatible dimension of arrays:
 LHS shape = (76514, )
 RHS shape = (76515, )
```
The issue comes in ``Nuclide::create_derived`` when the fission heating is added to the total cross section
```
302           // Skip redundant reactions
303           if (rx->redundant_) continue;
304
305           // Add contribution to total cross section
306           auto total = xt::view(xs_[t], xt::range(j,j+n), XS_TOTAL);
307           total += xs;
```

Two things are wrong here. First, fission heating does not contribute to total cross section so it should be marked as redundant. Second, the size of the cross section vector is one too large. All libraries for this test problem, U235, U238, O16, H1, and Zr96, were generated using `from_njoy` on their respective endf files.


Discussion:

Resolving patch:
diff --git a/openmc/data/neutron.py b/openmc/data/neutron.py
--- a/openmc/data/neutron.py
+++ b/openmc/data/neutron.py
@@ -834,6 +834,7 @@ def from_njoy(cls, filename, temperatures=None, evaluation=None, **kwargs):
                 non_fission_heating = Reaction(999)
                 non_fission_heating.redundant = True
                 fission_heating = Reaction(318)
+                fission_heating.redundant = True
 
                 heatr_evals = get_evaluations(kwargs["heatr"])
                 for heatr in heatr_evals:
@@ -841,15 +842,17 @@ def from_njoy(cls, filename, temperatures=None, evaluation=None, **kwargs):
                     f318 = StringIO(heatr.section[3, 318])
                     get_head_record(f318)
                     _params, fission_kerma = get_tab1_record(f318)
-                    fission_heating.xs[temp] = fission_kerma
                     total_heating_xs = data.reactions[301].xs.get(temp)
                     if total_heating_xs is None:
+                        fission_heating.xs[temp] = fission_kerma
                         continue
+                    # Cast fission heating to same grid as total heating
+                    new_fission_heat_xs = fission_kerma(total_heating_xs.x)
+                    fission_heating.xs[temp] = Tabulated1D(
+                        total_heating_xs.x, new_fission_heat_xs)
                     non_fission_heating.xs[temp] = Tabulated1D(
-                        fission_kerma.x,
-                        total_heating_xs(fission_kerma.x) - fission_kerma.y,
-                        breakpoints=fission_kerma.breakpoints,
-                        interpolation=fission_kerma.interpolation)
+                        total_heating_xs.x,
+                        total_heating_xs.y - new_fission_heat_xs)
 
                 data.reactions[318] = fission_heating
                 data.reactions[999] = non_fission_heating


Test patch:
Repository: openmc-dev/openmc

Issue:
Depletion and photon transport don't work together
When the openmc.deplete module loads new cross sections, it apparently is only loading incident neutron data but not photoatomic data which is needed for photon transport. This causes a segfault at transport-time because of missing data.


Discussion:

Resolving patch:
diff --git a/openmc/deplete/chain.py b/openmc/deplete/chain.py
--- a/openmc/deplete/chain.py
+++ b/openmc/deplete/chain.py
@@ -965,6 +965,8 @@ def reduce(self, initial_isotopes, level=None):
             new_nuclide = Nuclide(previous.name)
             new_nuclide.half_life = previous.half_life
             new_nuclide.decay_energy = previous.decay_energy
+            if hasattr(previous, '_fpy'):
+                new_nuclide._fpy = previous._fpy
 
             new_decay = []
             for mode in previous.decay_modes:
diff --git a/openmc/lib/nuclide.py b/openmc/lib/nuclide.py
--- a/openmc/lib/nuclide.py
+++ b/openmc/lib/nuclide.py
@@ -1,5 +1,5 @@
 from collections.abc import Mapping
-from ctypes import c_int, c_char_p, POINTER, c_size_t
+from ctypes import c_int, c_double, c_char_p, POINTER, c_size_t
 from weakref import WeakValueDictionary
 
 from ..exceptions import DataError, AllocationError
@@ -14,7 +14,7 @@
 _dll.openmc_get_nuclide_index.argtypes = [c_char_p, POINTER(c_int)]
 _dll.openmc_get_nuclide_index.restype = c_int
 _dll.openmc_get_nuclide_index.errcheck = _error_handler
-_dll.openmc_load_nuclide.argtypes = [c_char_p]
+_dll.openmc_load_nuclide.argtypes = [c_char_p, POINTER(c_double), c_int]
 _dll.openmc_load_nuclide.restype = c_int
 _dll.openmc_load_nuclide.errcheck = _error_handler
 _dll.openmc_nuclide_name.argtypes = [c_int, POINTER(c_char_p)]
@@ -32,7 +32,7 @@ def load_nuclide(name):
         Name of the nuclide, e.g. 'U235'
 
     """
-    _dll.openmc_load_nuclide(name.encode())
+    _dll.openmc_load_nuclide(name.encode(), None, 0)
 
 
 class Nuclide(_FortranObject):


Test patch:
Repository: openmc-dev/openmc

Issue:
Fail to run a depletion from previous results
I ran a depletion from previous results, but the simulation started from the scratch.

I don't understand why assign None to self.prev_res here. 
https://github.com/openmc-dev/openmc/blob/4ce7df9f5408d7355ef4986e89a102e3b67708bc/openmc/deplete/operator.py#L186
Replacing "None" with "prev_results" seems to fix this problem.


Discussion:
Good catch. We don't need this line, since we pass `prev_res` off to the `TransportOperator` above. This incorrectly over-writes that action

Resolving patch:
diff --git a/openmc/deplete/operator.py b/openmc/deplete/operator.py
--- a/openmc/deplete/operator.py
+++ b/openmc/deplete/operator.py
@@ -183,7 +183,6 @@ def __init__(self, geometry, settings, chain_file=None, prev_results=None,
                 "or fission-q".format(energy_mode))
         super().__init__(chain_file, fission_q, dilute_initial, prev_results)
         self.round_number = False
-        self.prev_res = None
         self.settings = settings
         self.geometry = geometry
         self.diff_burnable_mats = diff_burnable_mats


Test patch:
Repository: openmc-dev/openmc

Issue:
Typo in `RectangularParallelepiped.__pos__` method.
A user [reported a problem](https://openmc.discourse.group/t/openmc-model-rectangularparallelepiped-usage/858) in the region output when using the positive halfspace of a `RectangularParallelepiped` object recently in discourse.

It seems that there was a typo when defining the `RectangularParallelepiped.__pos__` method (`ymax` is used as the positive x bound).

https://github.com/openmc-dev/openmc/blob/88fb7b03491907c7d4cddbdb67cfe289fda813ce/openmc/model/surface_composite.py#L165-L166

I'll submit a PR for this shortly.


Discussion:

Resolving patch:
diff --git a/openmc/model/surface_composite.py b/openmc/model/surface_composite.py
--- a/openmc/model/surface_composite.py
+++ b/openmc/model/surface_composite.py
@@ -163,7 +163,7 @@ def __neg__(self):
         return +self.xmin & -self.xmax & +self.ymin & -self.ymax & +self.zmin & -self.zmax
 
     def __pos__(self):
-        return -self.xmin | +self.ymax | -self.ymin | +self.ymax | -self.zmin | +self.zmax
+        return -self.xmin | +self.xmax | -self.ymin | +self.ymax | -self.zmin | +self.zmax
 
 
 class XConeOneSided(CompositeSurface):


Test patch:
Repository: openmc-dev/openmc

Issue:
Operator should respect Materials.cross_sections
There have been a couple posts on the [discussion forum](https://openmc.discourse.group/t/cross-section-not-found-in-certain-file/1226) about the `Operator` not respecting / keeping `Materials.cross_sections`. The workflow for reproducing is usually something like
```python
mats = Materials([...])
mats.cross_sections = path_to_xs
mats.export_to_xml()
...
operator = Operator(geometry, settings, chain_file)
...
```

Running the depletion routine can lead to errors about cross sections files not being found. Or the file indicated with `path_to_xs` not being used.

## Short term

The workaround is to set the `OPENMC_CROSS_SECTIONS` environment variable to point to the new cross section file. Either in your python script with
```python
import os
os.environ["OPENMC_CROSS_SECTIONS"] = path_to_xs
```
or in your shell 
```shell
$ OPENMC_CROSS_SECTIONS=/path/to/new/xs python depletion_script.py
```
where `depletion_script.py` contains the script that expects the new cross sections.

## Possible fix

We write the new xml file in https://github.com/openmc-dev/openmc/blob/ef128f56095ac197600684ba9241dedde2b10998/openmc/deplete/operator.py#L597-L613

It might be worth checking if a `materials.xml` file exists already, load with `Materials.from_xml` and then grab the `cross_sections` attribute.

It looks like we only call that once during the initial set up https://github.com/openmc-dev/openmc/blob/ef128f56095ac197600684ba9241dedde2b10998/openmc/deplete/operator.py#L521-L534 rather than at every depletion step. Yay for in-memory material updates!


Discussion:
@drewejohnson I like that idea. The only change I'd suggest is that we not use `Materials.from_xml`, which will load the entire file (that could be large), but rather just use `xml.etree` directly to look for the `<cross_sections>` element.

Resolving patch:
diff --git a/openmc/deplete/operator.py b/openmc/deplete/operator.py
--- a/openmc/deplete/operator.py
+++ b/openmc/deplete/operator.py
@@ -12,6 +12,7 @@
 import os
 import xml.etree.ElementTree as ET
 from warnings import warn
+from pathlib import Path
 
 import numpy as np
 from uncertainties import ufloat
@@ -610,6 +611,14 @@ def _generate_materials_xml(self):
         for mat in materials:
             mat._nuclides.sort(key=lambda x: nuclides.index(x[0]))
 
+        # Grab the cross sections tag from the existing file
+        mfile = Path("materials.xml")
+        if mfile.exists():
+            tree = ET.parse(str(mfile))
+            xs = tree.find('cross_sections')
+            if xs is not None:
+                materials.cross_sections = xs.text
+
         materials.export_to_xml()
 
     def _get_tally_nuclides(self):


Test patch:
Repository: openmc-dev/openmc

Issue:
Bug: Attribute error when using `--xsdata` flag in `openmc-ace-to-hdf5.py` 
I am trying to convert a JEFF 3.1.2 ACE library to HDF5 format so I can do some geometry plotting using the `color_by=material`

I attempted to run the following command:
```
python openmc-ace-to-hdf5 --xsdata sss_jeff312.xsdata --metastable nndc
```
I get the following error:
```
Traceback (most recent call last):
  File "/home/ooblack/projects/cross-section-libraries/jeff312/../../openmc/scripts/openmc-ace-to-hdf5", line 64, in <module>
    ace_libraries.extend(openmc.data.ace.get_libraries_from_xsdata(args.xsdata))
  File "/home/ooblack/projects/openmc/openmc/data/ace.py", line 583, in get_libraries_from_xsdata
    lib = (xsdata.parent / words[8]).resolve()
AttributeError: '_io.TextIOWrapper' object has no attribute 'parent'
```
Poking around `ace.py` a bit, it looks like there may be some variable overwriting going on in `get_libararies_from_xsdata`. Starting at line 575, we have
```
 xsdata = Path(path)
  with open(xsdata, 'r') as xsdata:
      # As in get_libraries_from_xsdir, we use a dict for O(1) membership
      # check while retaining insertion order
      libraries = OrderedDict()
      for line in xsdata:
          words = line.split()
          if len(words) >= 9:
              lib = (xsdata.parent / words[8]).resolve()
.
.
.
```
I believe that on line 583, `xsdata` is suppposed to be a `Path` object, but it has been overwritten by as a `_io.TextIOWrapper` object. Can anyone confirm?

OpenMC version 0.13.0, built from source on Ubuntu 21.04


Discussion:
@yardasol yes, looks like you're right. Thanks for catching this! Do you want to submit a PR to fix this?

Resolving patch:
diff --git a/openmc/data/ace.py b/openmc/data/ace.py
--- a/openmc/data/ace.py
+++ b/openmc/data/ace.py
@@ -573,11 +573,11 @@ def get_libraries_from_xsdata(path):
         List of paths to ACE libraries
     """
     xsdata = Path(path)
-    with open(xsdata, 'r') as xsdata:
+    with open(xsdata, 'r') as xsdata_file:
         # As in get_libraries_from_xsdir, we use a dict for O(1) membership
         # check while retaining insertion order
         libraries = OrderedDict()
-        for line in xsdata:
+        for line in xsdata_file:
             words = line.split()
             if len(words) >= 9:
                 lib = (xsdata.parent / words[8]).resolve()


Test patch:
Repository: openmc-dev/openmc

Issue:
documentation missing factor in TSL eq 81
Eq. 81 in section 5.11.2 is missing a factor of 2. Code is correct, only a documentation bug. 

https://github.com/openmc-dev/openmc/blob/2efe223404680099f9a77214e743ab78e37cd08c/src/secondary_thermal.cpp#L50

in docs/source/methods/neutron_physics.rst
this: "\mu = 1 - \frac{E_i}{E}"
should be "\mu = 1 - \frac{2E_i}{E}"


Discussion:

Resolving patch:
diff --git a/openmc/region.py b/openmc/region.py
--- a/openmc/region.py
+++ b/openmc/region.py
@@ -106,6 +106,11 @@ def from_expression(expression, surfaces):
                 # If special character appears immediately after a non-operator,
                 # create a token with the appropriate half-space
                 if i_start >= 0:
+                    # When an opening parenthesis appears after a non-operator,
+                    # there's an implicit intersection operator between them
+                    if expression[i] == '(':
+                        tokens.append(' ')
+
                     j = int(expression[i_start:i])
                     if j < 0:
                         tokens.append(-surfaces[abs(j)])


Test patch:
diff --git a/tests/unit_tests/test_region.py b/tests/unit_tests/test_region.py
--- a/tests/unit_tests/test_region.py
+++ b/tests/unit_tests/test_region.py
@@ -204,3 +204,7 @@ def test_from_expression(reset):
     # Make sure ")(" is handled correctly
     r = openmc.Region.from_expression('(-1|2)(2|-3)', surfs)
     assert str(r) == '((-1 | 2) (2 | -3))'
+
+    # Opening parenthesis immediately after halfspace
+    r = openmc.Region.from_expression('1(2|-3)', surfs)
+    assert str(r) == '(1 (2 | -3))'
Repository: openmc-dev/openmc

Issue:
write_data_to_vtk producing scambled vtk files
Hi all

While using the nice new ```write_data_to_vtk``` with regular mesh tallies. I've been getting a vtk file which appears to be a bit messed up and I just wanted to check if I am doing things correctly.

I've defined a mesh like this
```
mesh = openmc.RegularMesh()

mesh.dimension = [100, 50, 100]  # number of mesh cells in each dimension (resolution)

mesh.lower_left = [-750, 0, -750]  # x,y,z coordinates
mesh.upper_right = [750, 750, 750]  # x,y,z coordinates
```

I've extracted a mesh tally like this and written it to vtk
```
statepoint = openmc.StatePoint('statepoint.2.h5')

my_tbr_tally = statepoint.get_tally(name='tbr_on_mesh')

mesh.write_data_to_vtk(
    filename="tbr_tally_on_mesh5.vtk",
    datasets={"mean": my_tbr_tally.mean}
)
```

However I get a vtk geometry like this

![Screenshot from 2022-07-11 12-17-42](https://user-images.githubusercontent.com/8583900/178254663-12457817-bb66-478b-869d-9330861a80b6.png)



Discussion:
This is a bug. Sorry about that, I'm have a fix but I'm working on a test to catch the bug



Resolving patch:
diff --git a/openmc/mesh.py b/openmc/mesh.py
--- a/openmc/mesh.py
+++ b/openmc/mesh.py
@@ -240,7 +240,7 @@ def write_data_to_vtk(self, points, filename, datasets, volume_normalization=Tru
 
         vtk_grid = vtk.vtkStructuredGrid()
 
-        vtk_grid.SetDimensions(*self.dimension)
+        vtk_grid.SetDimensions(*[dim + 1 for dim in self.dimension])
 
         vtkPts = vtk.vtkPoints()
         vtkPts.SetData(nps.numpy_to_vtk(points, deep=True))


Test patch:
Repository: openmc-dev/openmc

Issue:
No extern function to delete a tally from a model in tally.cpp
During a simulation with adaptive mesh refinement, as well as in some other cases (e.g. FETs), it would be useful to delete a tally that will no longer be needed. For the adaptivity application, if a mesh changes, the tally need to be reinitialized with new bins that account for additions to and deletions from the mesh.  To accomplish this, an `extern` function will be added to `openmc/src/tallies/tally.cpp`

I will look into how to do this and create a new PR. @aprilnovak @pshriwise let me know if I missed anything important to the description of this issue.


Discussion:

Resolving patch:
diff --git a/openmc/lib/tally.py b/openmc/lib/tally.py
--- a/openmc/lib/tally.py
+++ b/openmc/lib/tally.py
@@ -87,6 +87,9 @@
 _dll.openmc_tally_set_writable.argtypes = [c_int32, c_bool]
 _dll.openmc_tally_set_writable.restype = c_int
 _dll.openmc_tally_set_writable.errcheck = _error_handler
+_dll.openmc_remove_tally.argtypes = [c_int32]
+_dll.openmc_remove_tally.restype = c_int
+_dll.openmc_remove_tally.errcheck = _error_handler
 _dll.tallies_size.restype = c_size_t
 
 
@@ -405,4 +408,8 @@ def __len__(self):
     def __repr__(self):
         return repr(dict(self))
 
+    def __delitem__(self, key):
+        """Delete a tally from tally vector and remove the ID,index pair from tally"""
+        _dll.openmc_remove_tally(self[key]._index)
+
 tallies = _TallyMapping()


Test patch:
diff --git a/tests/unit_tests/test_lib.py b/tests/unit_tests/test_lib.py
--- a/tests/unit_tests/test_lib.py
+++ b/tests/unit_tests/test_lib.py
@@ -340,6 +340,20 @@ def test_new_tally(lib_init):
     assert len(openmc.lib.tallies) == 5
 
 
+def test_delete_tally(lib_init):
+    # delete tally 10 which was added in the above test
+    # check length is one less than before
+    del openmc.lib.tallies[10]
+    assert len(openmc.lib.tallies) == 4
+
+
+def test_invalid_tally_id(lib_init):
+    # attempt to access a tally that is guaranteed not to have a valid index
+    max_id = max(openmc.lib.tallies.keys())
+    with pytest.raises(KeyError):
+        openmc.lib.tallies[max_id+1]
+
+
 def test_tally_activate(lib_simulation_init):
     t = openmc.lib.tallies[1]
     assert not t.active
diff --git a/tests/unit_tests/test_tallies.py b/tests/unit_tests/test_tallies.py
--- a/tests/unit_tests/test_tallies.py
+++ b/tests/unit_tests/test_tallies.py
@@ -38,4 +38,4 @@ def test_xml_roundtrip(run_in_tmpdir):
     assert len(new_tally.triggers) == 1
     assert new_tally.triggers[0].trigger_type == tally.triggers[0].trigger_type
     assert new_tally.triggers[0].threshold == tally.triggers[0].threshold
-    assert new_tally.triggers[0].scores == tally.triggers[0].scores
+    assert new_tally.triggers[0].scores == tally.triggers[0].scores
\ No newline at end of file
Repository: openmc-dev/openmc

Issue:
Elastic distributions are not used in thermal.py
I think I came across a bug. [Here](https://github.com/openmc-dev/openmc/blob/cbd8376238a71c36a57385df4c18471d5a785d64/openmc/data/thermal.py#L733) and [here](https://github.com/openmc-dev/openmc/blob/cbd8376238a71c36a57385df4c18471d5a785d64/openmc/data/thermal.py#L736) the elastic distributions are assigned to "dist", but [here](https://github.com/openmc-dev/openmc/blob/cbd8376238a71c36a57385df4c18471d5a785d64/openmc/data/thermal.py#L745) the elastic reaction is created with "distribution".

It is an easy fix, just change "dist" for "distribution" in the above two lines.


Discussion:

Resolving patch:
diff --git a/openmc/data/thermal.py b/openmc/data/thermal.py
--- a/openmc/data/thermal.py
+++ b/openmc/data/thermal.py
@@ -730,10 +730,10 @@ def from_ace(cls, ace_or_filename, name=None):
 
             if ace.nxs[5] == 3:
                 xs = incoherent_xs
-                dist = incoherent_dist
+                distribution = incoherent_dist
             elif ace.nxs[5] == 4:
                 xs = coherent_xs
-                dist = coherent_dist
+                distribution = coherent_dist
             else:
                 # Create mixed cross section -- note that coherent must come
                 # first due to assumption on C++ side


Test patch:
Repository: openmc-dev/openmc

Issue:
Enumerator for filter types
There are some cleverly-implemented `Filter::type` methods that allow a filter to return its type via a descriptive string, which is nice for use when writing out a mesh type as part of an error message or warning. To compare filter types (using two `Filter` pointers for instance) I think it would make sense to have a `FilterType` enumerator.

I'll propose changing the return type of `Filter::type()` from `std::string` to `FilterType` and adding a `Filter::type_str` method to replace the original.


Discussion:

Resolving patch:
diff --git a/openmc/filter.py b/openmc/filter.py
--- a/openmc/filter.py
+++ b/openmc/filter.py
@@ -533,7 +533,7 @@ class CellFromFilter(WithIDFilter):
     expected_type = Cell
 
 
-class CellbornFilter(WithIDFilter):
+class CellBornFilter(WithIDFilter):
     """Bins tally events based on which cell the particle was born in.
 
     Parameters
@@ -557,6 +557,14 @@ class CellbornFilter(WithIDFilter):
     expected_type = Cell
 
 
+# Temporary alias for CellbornFilter
+def CellbornFilter(*args, **kwargs):
+    warnings.warn('The name of "CellbornFilter" has changed to '
+                  '"CellBornFilter". "CellbornFilter" will be '
+                  'removed in the future.', FutureWarning)
+    return CellBornFilter(*args, **kwargs)
+
+
 class CellInstanceFilter(Filter):
     """Bins tally events based on which cell instance a particle is in.
 


Test patch:
diff --git a/tests/regression_tests/tallies/test.py b/tests/regression_tests/tallies/test.py
--- a/tests/regression_tests/tallies/test.py
+++ b/tests/regression_tests/tallies/test.py
@@ -40,7 +40,7 @@ def test_tallies():
 
     cellborn_tally = Tally()
     cellborn_tally.filters = [
-        CellbornFilter((model.geometry.get_all_cells()[10],
+        CellBornFilter((model.geometry.get_all_cells()[10],
                         model.geometry.get_all_cells()[21],
                         22, 23))]  # Test both Cell objects and ids
     cellborn_tally.scores = ['total']