Move most tally filters to C++ (!1101) · Merge Requests · Shikhar Kumar / openmc

Move most tally filters to C++

Created by: smharper

With this PR, nearly all of the tally filter implementation is handled by C++. I didn't touch EnergyFilter, its subclass EnergyoutFilter, or DelayedGroupFilter because I assume they will be trouble due to how they're used in subroutines like score_fission_eout.

The implementation for each of the filters is pretty short, so I've decided to try leaving them as header-only. I think it can be a bit of a pain to constantly have to search both .cpp and .h files for implementation, and that split doesn't feel worth it for these filters which usually have far less than 100 LoC of actual implementation. Let me know if you guys disagree.

One nice benefit of this PR is that it allows us to remove a bunch of geometry-related Fortran interoperability boilerplate. Particularly good examples of this are the distribcell setup code and the mesh binning code.

Note that a big chunk of C-API code touched by this PR is not covered by our test suite. I made my own one-off tests and I believe I've checked all the C-API functions, but I do still request a careful review of those bits.

On that note, @paulromano, how would you feel about cutting back the scope of the C-API a bit in terms of tally filters? Consider functions like openmc_zernike_filter_set_params. I can't think of many use cases for changing a Zernike filter's parameters midway through a run so I guess the primary use case for functions like this is as an alternative to XML-based input. But I remember you said recently that we should probably be pushing the C++ API as the XML alternative which makes a lot of sense to me.

*Created by: smharper*

With this PR, nearly all of the tally filter implementation is handled by C++.  I didn't touch `EnergyFilter`, its subclass `EnergyoutFilter`, or `DelayedGroupFilter` because I assume they will be trouble due to how they're used in subroutines like `score_fission_eout`.

The implementation for each of the filters is pretty short, so I've decided to try leaving them as header-only.  I think it can be a bit of a pain to constantly have to search both .cpp and .h files for implementation, and that split doesn't feel worth it for these filters which usually have far less than 100 LoC of actual implementation.  Let me know if you guys disagree.

One nice benefit of this PR is that it allows us to remove a bunch of geometry-related Fortran interoperability boilerplate.  Particularly good examples of this are the distribcell setup code and the mesh binning code.

Note that a big chunk of C-API code touched by this PR is not covered by our test suite.  I made my own one-off tests and I believe I've checked all the C-API functions, but I do still request a careful review of those bits.

On that note, @paulromano, how would you feel about cutting back the scope of the C-API a bit in terms of tally filters?  Consider functions like `openmc_zernike_filter_set_params`.  I can't think of many use cases for changing a Zernike filter's parameters midway through a run so I guess the primary use case for functions like this is as an alternative to XML-based input.  But I remember you said recently that we should probably be pushing the C++ API as the XML alternative which makes a lot of sense to me.