Separate tally filters from tallies
This PR addresses #841 (closed), separating tally filters from tally elements. As @smharper brings up in #214, if the same filter is used on multiple tallies, it will be replicated for each of these tallies in tallies.xml and in OpenMC. Separating filters from tallies will both simplify the XML input and eliminate the redundant checking of filters during tallying.
Changes are as follows:
There is now a global
filtersarray rather than separate arrays for each tally. The
filterarray for each tally instead stores indices into the global array.
Filters are only checked once when tallying rather than once for each tally that uses them. The
filter_weightsarrays are replaced by the
type(TallyFilterMatch)which stores all valid bins and weights for the filters in STL-style vectors.
The active tally lists were changed from
type(VectorInt)so they no longer need to be threadprivate.
The XML input format now has filter elements separate from tallies:
<filter id="1" type="energy" bins="0.0 20000000.0" /> <tally id="1" filters="1" scores="total" />
as @smharper describes in #214.
Inputs for tests changed to match the new input format.
I’ve tried to keep changes to the Python API minimal. Filter objects now have IDs. Since the aim of this PR is to do away with replicated filters, each filter should only show up once in the XML input. At the moment, this is handled in
export_to_xml. If identical filters with different IDs are encountered, both IDs are set to the same value. This prevents filters from being replicated while ensuring the filter IDs in the tally subelement correspond to the correct, existing filter. However, it modifies the user-defined filter ID.
Though the hope was that performance would be improved by no longer redundantly checking filters at tally-time, I see little difference in tests so far. Part of this is due to limited reuse of filters across tallies in the problems. Additionally, if one filter is used on multiple tallies with different tally estimators, it is still checked separately for each estimator. In any case, there shouldn’t be any performance degradation.