Phys/LoKiArrayFunctors: add LoKi::CheckOverlap tool implementation of ICheckOverlap interface

see merge request !70 (closed)

add LoKi::CheckOverlap tool implementation of ICheckOverlap interface b with specific "overlap" treatment. (There are specific "clones" for Turbo++PerstistReco) New tool makes a three step identification of such overlaps for charged tracks

• as "type1" clones
• as "type2" clones
• as fraction of shared hits

For neutrals is goes to CaloHypo-by-CaloHypo comparison.

For each CaloHypo first it tries to compare (numerically) CaloPosition ( center and parameters), otherwise switches to comparison of CaloCluster-by CaloCluster.

For each CaloCluster it compares seed-cells only (it is enough)

There are several configuration parameters:

     declareProperty
        ( "Type1CloneSlopeDifference"   , 
          m_clone_type1_slope           , // clone "Type1" slope difference
          "Slope difference to identify ``Type1-clone'' [ignore, if negative]" ) ;
      declareProperty
        ( "Type2CloneSlopeDifference"   , 
          m_clone_type2_slope           , // clone "Type2" slope difference
          "Slope difference to identify ``Type2-clone'' [ignore, if negative]" ) ;
      declareProperty
        ( "Type2CloneQoverPDifference"   , 
          m_clone_type2_qOverP           , // clone "Type2" slope difference
          "Q/p   difference to identify ``Type2-clone'' [ignore, if negative]" ) ;
      declareProperty
        ( "TrackOverlap"   , 
          m_overlap_tracks ,               // overlap criteria for tracks 
          "Overlap criteria for tracks (LHCb::HashID::overlap) [ignore if not 0<p<=1]" ) ;
      declareProperty
        ( "CaloOverlap"    , 
          m_overlap_calos  ,               // overlap criteria for calo  
          "Overlap criteria for calo   (LHCb::HashID::overlap) [ignore if not 0<p<=1]" ) ;

Mentioned in merge request !70 (closed)

Status changed to merged

Mentioned in commit ae5e1998

I forgot to ask (doesn't matter that this is now merged): do people have an opinion on making this the default overlap checker?

@jonrob @erodrigu @apearce @lzhang I personally would allow some period without changing the default tool in DaVinci. It is worth to informing the users of Turbo++PerstistReco about the possible solution (e.g. Liming is using it already). and the decision on default tool can be done after this testing period.

From other side (unrelated to this particular case) the existing DaVinci tool must be either replaced or modified/fixed/rewritten. It relies on very strange design pattern with saving the data into static local containers with subsequent juggling of these container between different methods (it at least senseless, and for sure is a time bomb for future development)

.... (and it is worth to fix ICheckOverlap interface to keep all methods constant.... - it will be in line with all new features and recommendations)

Could you please put the fix here, either @lzhang or @ibelyaev? Might be useful for near-future reference, before this (or something else that can fix the PersistReco problem) becomes the default.

algorithm = CombineParticles ( 
   'Combine' , 
   ....  , 
  CheckOverlapTool = 'LoKi::CheckOverlap' )

Using selections:

selection = CombineSelection ( ... , 
   CheckOverlapTool = 'LoKi::CheckOverlap' 
 )

If one needs to play with parameters and tune them:

algorithm = CombineParticles (
  'Combine' , 
  ....  , 
CheckOverlapTool = 'LoKi::CheckOverlap/CHECKOVERLAP' )
from Configurables import LoKi__CheckOverlap as COT 
algorithm.addTool ( COT , 'CHECKOVERLAP') 
cot = algorithm.CHECKOVERLAP
cot.Type1CloneSlopeXDifference  = 0.0004 
cot.Type1CloneSlopeYDifference  = 0.0002
cot.Type2CloneSlopeDifference  = 0.005 
cot.Type2CloneQoverPDifference = 1.e-6 
cot.TrackOverlap = 0.70
cot.CaloOverlap = 0.50 

What is really needed is a JIRA task for the development + future decision :-). @ibelyaev and @lzhang, can you create one such task so that this is not forgotten and the move is actually done in the future? Having it decided for the 2017 data taking start seems fair to me.

Everyone: did you see my comment above about the need for a JIRA task so that the decision of changing the checker does not get lost? Thanks.

Mentioned in commit ad9dbf0f

Mentioned in commit 7f78e9b7

Mentioned in merge request !64 (merged)

Mentioned in commit ddcc1c8a

mentioned in merge request !211 (merged)

mentioned in merge request !231 (merged)