Updated ParticleID to handle new PDG conventions.

Am I rigth that now instead of one single int the class contains 10 additional int-values as data-memebrs? Is it really needed? why the single int is not enough?

@ibelyaev It's a good question, let's ask @philten

Because there are exceptions for all the rules, more or less. So, one can take this approach, where you modify each digit (so these actually don't need to be int-valued) for the exceptions, or you instead code the exceptions for each method individually. I did it this way because it seemed simpler to handle all these exceptions in one place in the code. But, of course if this is an issue you can handle exceptions per method.

for me it is fine, btw, it is backward compatible? in the sense that can previously generated files be read with new software stack? In other words, is a kind of schema evolution supported?

anyhow probably it is worth to declare these new fields as transient-only (can be done in corresponding xml-file). probably such action implicitly favours the schema evolution and ensures the compatibility with old-data files - but it needs to be checked.

Adding data members should always supported by the Root schema evolution but I suspect that's not relevant, as far as I know this class does not get written out to our persistent formats. Since this has already been released on master and 206-patches branches as well, I suggest we leave it as is for now

I'm with @ibelyaev on this one: I would have picked the solution with coding the exceptions explicitly in the individual functions that need them -- basically follow the principle that what you do not use you should not have to pay for. Increasing the size of ParticleID ten fold is not for free, and I suspect that the bulk of the usage does not care.

[2018-04-07 00:06] Validation started with lhcb-2018-patches#171
[2018-04-07 00:07] Validation started with lhcb-moore-test#19
[2018-04-12 00:06] Validation started with lhcb-moore-test#24
[2018-04-12 00:08] Validation started with lhcb-2018-patches#177
[2018-04-12 11:29] Validation started with lhcb-2018-patches#178

Making this WIP as I need to prepare a fix for Rec in order to link to this library, c.f. Rec!975 (merged). Affected packages are PatVeloTT, PatVelo, TrackExtrapolators, PrVeloUT

marked as a Work In Progress

changed the description

mentioned in merge request Rec!996 (merged)

Rec dependencies fixed in Rec!996 (merged)

unmarked as a Work In Progress

@erodrigu I think this MR is the cause of the compilation failures in Phys/2018-patches this morning, but I cannot see how. Particularly as it was OK in lhcb-head. @graven @ibelyaev @clemenci any idea? Perhaps a missing include?

In file included from input_line_9:54:
In file included from Phys/LoKiArrayFunctors/LoKi/LoKiArrayFunctors_dct.h:9:
In file included from LHCB/LHCB_2018-patches/InstallArea/x86_64-slc6-gcc62-opt/include/Event/Particle.h:28:
In file included from LHCB/LHCB_2018-patches/InstallArea/x86_64-slc6-gcc62-opt/include/Kernel/ParticleID.h:9:
In file included from GAUDI/GAUDI_v29-patches/InstallArea/x86_64-slc6-gcc62-opt/include/GaudiKernel/HashMap.h:5:
In file included from GAUDI/GAUDI_v29-patches/InstallArea/x86_64-slc6-gcc62-opt/include/GaudiKernel/Hash.h:9:
In file included from /cvmfs/lhcb.cern.ch/lib/lcg/releases/gcc/6.2.0/x86_64-slc6/bin/../lib/gcc/x86_64-pc-linux-gnu/6.2.0/../../../../include/c++/6.2.0/numeric:62:
/cvmfs/lhcb.cern.ch/lib/lcg/releases/gcc/6.2.0/x86_64-slc6/bin/../lib/gcc/x86_64-pc-linux-gnu/6.2.0/../../../../include/c++/6.2.0/bits/stl_numeric.h:217:32: error: no matching function for call to object of type 'std::plus<ROOT::Math::LorentzVector<ROOT::Math::PxPyPzE4D<double> > >'
        __init = __binary_op1(__init, __binary_op2(*__first1, *__first2));
                                      ^~~~~~~~~~~~
LHCB/LHCB_2018-patches/InstallArea/x86_64-slc6-gcc62-opt/include/LoKi/WrongMass.h:176:19: note: in instantiation of function template specialization 'std::inner_product<__gnu_cxx::__normal_iterator<const LHCb::Particle *const *, std::vector<const LHCb::Particle *, std::allocator<const LHCb::Particle *> > >, __gnu_cxx::__normal_iterator<double *, std::vector<double, std::allocator<double> > >, ROOT::Math::LorentzVector<ROOT::Math::PxPyPzE4D<double> >, (lambda at LHCB/LHCB_2018-patches/InstallArea/x86_64-slc6-gcc62-opt/include/LoKi/WrongMass.h:179:5), std::plus<ROOT::Math::LorentzVector<ROOT::Math::PxPyPzE4D<double> > > >' requested here
      return std::inner_product(first, last,
                  ^
Phys/LoKiPhys/LoKi/Particles23.h:186:29: note: in instantiation of function template specialization 'LoKi::Kinematics::wrongMass<__gnu_cxx::__normal_iterator<const LHCb::Particle *const *, std::vector<const LHCb::Particle *, std::allocator<const LHCb::Particle *> > >, __gnu_cxx::__normal_iterator<double *, std::vector<double, std::allocator<double> > >, LoKi::Objects::_VALID<const void *> >' requested here
          LoKi::Kinematics::wrongMass
                            ^
Phys/LoKiPhys/LoKi/Particles23.h:146:16: note: in instantiation of function template specialization 'LoKi::Particles::WrongMass::wmass<__gnu_cxx::__normal_iterator<const LHCb::Particle *const *, std::vector<const LHCb::Particle *, std::allocator<const LHCb::Particle *> > > >' requested here
      { return wmass ( p.begin() , p.end() ) ; }
               ^
/cvmfs/lhcb.cern.ch/lib/lcg/releases/gcc/6.2.0/x86_64-slc6/bin/../lib/gcc/x86_64-pc-linux-gnu/6.2.0/../../../../include/c++/6.2.0/bits/stl_function.h:171:7: note: candidate function not viable: no known conversion from 'const LHCb::Particle *const' to 'const ROOT::Math::LorentzVector<ROOT::Math::PxPyPzE4D<double> >' for 1st argument
      operator()(const _Tp& __x, const _Tp& __y) const
      ^

@philten please see previous comment

mentioned in merge request !1227 (merged)

Updated ParticleID to handle new PDG conventions.

Merge request reports

Activity