Add missing "core" ThOr functors

There are a few commonly-used LoKi functors that do not yet have ThOr equivalents. For example:

• proper lifetime with respect to the "best" primary vertex
• functors to interact with "extra info" (see LHCb#106), for example reading saved selection or isolation MVA values
• functors to do with changing assigned mass hypotheses
• ID, ABSID and possibly other functors accessing true ID information
• [other missing functors to be filled in here]

The range of functors used in the Run 2 trigger was surveyed in this talk.

At this stage of ThOr/LoKi cross-validation these should probably be implemented with an (if constexpr) branch on LHCb::Particle, although this can be dropped in due course.

DPA gitlab has a more complete list of missing functors, https://gitlab.cern.ch/lhcb-dpa/project/-/issues/61, please use this issue from now on.

added Functors label

/cc @vrenaudi, who's looking into converting a few B2OC lines to see what's missing for a 'production' line.

added ThOr label

Hello, when modifying bandq(onia) particle builders into Thor style, we find several functions missing:

1. F.BPVLTIME seems to return a too small value. A known issue mentioned in Rec#204.
2. BPVDLS not in Thor. A temporary solution is to use the FDCHI2 variable F.BPVFDCHI2(pvs), and assume significance = sqrt(chi2).
3. In dimuon builders, we start from the basic dimuon combiner make_dimuon_base in standard_particles, then use CHILDCUT, MINTREE and MAXTREE to cut the muons. Seems these functions are not supported in Thor. A potential solution is to define a new combiner, and use F.SUM, F.MIN, F.MAX or directly cut input muons; but maybe there are more beautiful solutions.

Thanks for the report.

On 2, do you know if BPVDLS really is equal the square root of the flight distance chi-squared?

On 3, I'd say defining specific combiners is OK.

Hi Alex,

On 2, they are not exactly the same. as an example: after using the flight distance chi-square, the efficiency changes from 55.4% to 55.8%.

On 3, thank you for the suggestion! I will try that.

OK thanks. It would be great if you were able to understand whether they should be the same, i.e. if DLS is defined as √(FDCHI2), or whether they just are numerically similar.

I think DLS is not just sqrt(FDCHI2).

The definition of DLS, namely LoKi::Particles::DecayLengthSignificance is in: https://lhcb-doxygen.web.cern.ch/lhcb-doxygen/lhcb/v50r2/db/d89/_particles37_8cpp_source.html#l00078 . It is decayLength / decayLengthErr, and both the denominator and numerator use the space (line 94) and momentum (line 98) information .

For the flight distance chi2 variable BPVVDCHI2, we could see its definition in the twiki: https://twiki.cern.ch/twiki/bin/view/LHCb/LoKiHybridFilters#BPVVDCHI2_separation_from_relate. It's basically a chi2 value obtained using the position vector and corresponding error matrix. I did not see contribution from the momentum information. (Or if we check /cvmfs/lhcb.cern.ch/lib/lhcb/PHYS/PHYS_v26r0/Phys/LoKiPhys/src/Particles1.cpp, the VertexChi2Distance function, which is used to define BPVVDCHI2, also takes only the 3D vertex information as input.)

Thank you! It sounds like DLS can be computed using the same machinery as the lifetime then. I wonder if we can use the information already computed in !2486 (closed) to implement DLS.

Sounds promising ! I noticed that several necessary functions have been used in https://gitlab.cern.ch/lhcb/Rec/-/blob/6f7a284f2076ebc8e3ff67ef421065c2a3424aa8/Phys/SelTools/include/SelTools/DistanceCalculator.h.

Could you please open an issue in Rec for this specific functor and assign it to me? I will try to take care of it soon.

Cool ! It's created now #207 (closed) :) BTW, when compling Phys/SelKernel package in Moore, you might see error message like

-- Adding directory Phys/SelKernel (1/1)
CMake Error at Phys/SelKernel/CMakeLists.txt:16 (gaudi_add_header_only_library):
  Unknown CMake command "gaudi_add_header_only_library".


-- Configuring incomplete, errors occurred!
See also "/afs/cern.ch/user/m/mengzhen/Work/workspace/upgrade_dimuon_studies/MooreDev_HEAD/build.x86_64_v2-centos7-gcc10-opt/CMakeFiles/CMakeOutput.log".
See also "/afs/cern.ch/user/m/mengzhen/Work/workspace/upgrade_dimuon_studies/MooreDev_HEAD/build.x86_64_v2-centos7-gcc10-opt/CMakeFiles/CMakeError.log".
make: *** [/afs/cern.ch/work/m/mengzhen/workspace/upgrade_dimuon_studies/MooreDev_HEAD/build.x86_64_v2-centos7-gcc10-opt/build.ninja] Error 1

I asked experts in hackathon mattermost channel. It is an issue under discussion, and should be solved today.

Dear @mengzhen, The Error has not been solved. Is it right? When compiling Muon/MuonID package in Rec, I see the same error message:

CMake Error at Muon/MuonID/CMakeLists.txt:20 (gaudi_add_header_only_library): Unknown CMake command "gaudi_add_header_only_library".

mentioned in merge request Moore!924 (merged)

mentioned in merge request Moore!931 (merged)

a ThOr functors returning the CL for neutral particles (gamma, pi0) is missing

@configurable
def make_photons(make_particles=make_photons, CL_min=0.25, et_min=150 * MeV):
    """For the time being just a dummy selection"""

    #require_all('CL > {CL_min}', 'PT > {et_min}').format(                                                                                                                
    #    CL_min=CL_min, et_min=et_min)                                                                                                                                    
    code = require_all(F.PT > et_min)
    return ParticleFilter(make_particles(), F.FILTER(code))

for now in B2OC we are omitting the CL cut

changed the description

I'd like to try implementing ID, ABSID etc. to get some experience with ThOr framework. As I understand, Particle_v2 already has ParticleIDs container (https://gitlab.cern.ch/lhcb/LHCb/-/blob/master/Event/PhysEvent/include/Event/Particle_v2.h#L135), so it must be ~trivial. But where should the C++ code go in Rec/Phys/FunctorCore/include/Functors? https://gitlab.cern.ch/lhcb/Rec/-/blob/master/Phys/FunctorCore/include/Functors/Composite.h? https://gitlab.cern.ch/lhcb/Rec/-/blob/master/Phys/FunctorCore/include/Functors/TrackLike.h? Does it matter? @nnolte, @mramospe, @agilman.

it doesn't really matter. ID and ABSID are good functors for both, we might want to think about something like (or more descriptive than) Particle.h/Common.h

mentioned in issue #215

marked this issue as related to #215

marked this issue as related to #240 (closed)

marked this issue as related to #233

marked this issue as related to #232

changed the description

I've added a link the similar (and more complete) issue in DPA gitlab, https://gitlab.cern.ch/lhcb-dpa/project/-/issues/61 to the description. Should we close this one in order not to duplicate stuff? Of course, ideally this issue should be in the Rec/ package. DPA is not the most obvious place for HLT2 line developers to search for. But I guess it will be now too painful to move things around.