--
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
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
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'
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.