-- RicardoVazquezGomez - 2015-10-16

The S24 is the restripping of the 25ns data after the technical stop from begining of September 2015.

The DaVinci version to be used for testing is DV v38r0. So before starting testing the performances do

lb-dev DaVinci v38r0

The data sample used in the test script (TestMyStrippingLine.py) is from run 164668, taken with the trigger configuration of 1600 bunches with TCK 0x010600A2.

The tags to use are

CondDBTag =cond-20150828

DDDBTag=dddb-20150724

TisTossing in 2015 data

due to a problem in tistossing in 2015 data for DV versions <= of v38r0, users filtering on trigger decisions should in addition getpack the head of

Event/HltEvent
Hlt/HltDAQ
Phys/TisTosTobbing

in order to get consistent results

New RelatedInfos framework.

There has been a modification on the way the related info are set up (in the StrippingLine class) for cases in which these are applied NOT to the head of the decay chain

   Instead of 'Locations' and 'RecursionLevel', a single dictionary must be provided with the 
   'DaughterLocations' key, in the form 
   {
     'LoKi daughter selection string' : 'RelatedInfo TES location'
   }
   e.g. 
   "DaughterLocations" : {
     "[Lambda_c+ -> ^p+ K- K+]CC" : "Cone2p",
     "[Lambda_c+ -> p+ ^K- K+]CC" : "Cone2k",
     "[Lambda_c+ -> p+ K- ^K+]CC" : "Cone2pi",
   }

To store also related info for the head, one should still use the 'Location' key:

   "Location" : "Cone Lc",  #stores the information for the Lambda_c
   "DaughterLocations" : {
     "[Lambda_c+ -> ^p+ K- K+]CC" : "Cone2p",
     "[Lambda_c+ -> p+ ^K- K+]CC" : "Cone2k",
     "[Lambda_c+ -> p+ K- ^K+]CC" : "Cone2pi",
   }

To avoid to write individual decay descriptors, one solution is to use the wildcard particle descriptor of the LoKi decay finder, such as "X" (for any particle), "l+-" (for leptons) etc. For a detailed explanation take a look at https://twiki.cern.ch/twiki/bin/view/LHCb/FAQ/LoKiNewDecayFinders An example of usage would be:

  "[Beauty -> ^X0 l+ l-]" : 'X0Cone'
  "[Beauty -> X0 ^l+ l-]" : "LpCone"
  "[Beauty -> X0 l+ ^l-]" : 'LmCone'

Imports from ConfigurableGenerators.

Algorithm such as FilterDesktop, CombineParticles, NXBodyDecays can be imported both from "Configurables" or from "GaudiConfUtils.ConfigurableGenerators". If imported from Configurables, a name for the algorithm has to be specified (make sure it is unique). If the import coms from ConfigurableGenerators the name cannot be specified and the framework will take care automatically if making it unique. In practice, this is how it works:

In case of import from Configurables

from Configurables import CombineParticles
_myCombo = CombineParticles(  name="<uniquename>",
                                                       DecayDescriptors = "<somedecaydescriptor>",
                                                       DaughtersCuts = { "pi+" : "<daugthercuts>" },
                                                  CombinationCut = "<combinationcuts>",
                                                  MotherCut = "<mothercuts>" )

In case of import from ConfigurableGenerators

from GaudiConfUtils.ConfigurableGenerators import CombineParticles
_myCombo = CombineParticles( DecayDescriptors = "<somedecaydescriptor>",
                                                      DaughtersCuts = { "pi+" : "<daugthercuts>" },
                                                 CombinationCut = "<combinationcuts>",
                                                 MotherCut = "<mothercuts>" )

The main difference is that the tools from the algorithms imported from "GaudiConfUtils.ConfigurableGenerators" are inmutable while the tools from the algorithms imported from "Configurables" can be modified after it is instantiated. If the configuration of the algorithm is not different from the default regarding ReFitPVs, VertexFitter,... it is recommended to import the algorithm from "GaudiConfUtils.ConfigurableGenerators". Please modify your stripping line accordingly.

If you really need to import from Configurables, please make sure that your algorithm has a unique name every time it is instantiated.