Enable more ThOr functor tests
The new ThOr functor framework already includes various tests, the most powerful of which is the test_vector_functors
test.
For a fixed set of container types, this looks up all the functors that "should make sense for that input data" and tries to compile/instantiate them.
For example, ISMUON
is expected to work for a charged basic particle (zip of tracks, muon PIDs, ...), but not a composite particle, so the test will try and instantiate this functor for LHCb::v2::ChargedBasics
input but not for LHCb::v2::Composites
input (where it would not compile).
The algorithm that is executed by these tests comes in two flavours:
-
ThOr::Functors::Tests::Initialise<Ts...>
: compiles functors with all available combinations of functor cache + JIT/cling and different SIMD backends, doesn't do anything at runtime (inoperator()
) -
ThOr::Functors::Tests::Evaluate<Ts...>
: as above, but at runtime execute the compiled functors. This relies on their being a source ofTs...
objects to execute the functors on. For example, this could be theProducePrFittedForwardTracks
algorithm, which generates sort-of-sensible track containers on the fly.
So far, the parameter pack Ts...
always has length zero (for "void" functors that take no arguments), or one.
In principle, we should always use the second (...::Evaluate<Ts...>
) version, but in practice right now the first one is used when data producer algorithms do not exist, and for specific functors that would expose limitations in the data producer algorithms. (concretely here, NHITS
cannot work on the output of ProducePrFittedForwardTracks
because the latter does not populate the ancestor relations).
As new event model classes are defined, for example when addressing LHCb#97 (closed) and LHCb#104, these functor tests should be "switched on" for those new event model types. This ensures that the various template methods in proxy definitions, and so on, are actually compiled as part of the nightlies (see LHCb!2805 (closed) for example an example of problems this would prevent), and the runtime tests ensure there are no regressions in terms of different SIMD backends giving (approximately) the same numerical results.
As a practical consideration, it may make sense to run the tests for different event model types in different QMTests.
The test_functors
and VertexCutFunctors
tests should be retired once their content is included in the test_vector_functors
test.
cc: @apearce @mvesteri @agilman @mramospe @nnolte @sstahl @vrenaudi @samarian @pkoppenb