- May 29, 2017
-
- May 25, 2017
-
-
Eduardo Rodrigues authored
Check for quarks and anti-quarks. See merge request !65
-
- May 21, 2017
-
-
Alex Pearce authored
-
- Apr 25, 2017
-
- Apr 24, 2017
-
-
Eduardo Rodrigues authored
Support Stripping26 MC productions going to microDST See merge request !59
-
- Apr 21, 2017
-
-
Vanya Belyaev authored
- Selections.py - add RebuildSelection - useful tool to rerun/rebuild common/standard selection ignoring the input from the tape Cherry-picked from Phys, commit 2499b5f0.
-
Alex Pearce authored
-
Alex Pearce authored
- AnalyssiConf: add property RootInTES - ChargedPP2MC: fix to respect RootInTES Cherry-picked from Analysis, commit f4ac92a8.
-
Alex Pearce authored
Cherry-picked from DaVinci, commit be906e8d.
-
Alex Pearce authored
-
Alex Pearce authored
-
- Mar 28, 2017
-
-
Eduardo Rodrigues authored
Support for Turbo MC microDST productions for Stripping26 See merge request !58
-
- Mar 27, 2017
-
-
Alex Pearce authored
This fix is implemented more cleanly in the combination of LHCb!571 and Analysis!108. This specific commit is a shorter workaround, intended for deployment as part of DaVinci patch releases for Stripping26 and Stripping28.
-
Alex Pearce authored
-
Alex Pearce authored
-
Alex Pearce authored
Tesla can then mimic the behaviour of a Stripping microDST writer, by saving a filtering copy of /Event/MC/{Particles,Vertices} as /Event/Turbo/MC/{Particles,Vertices}.
-
Alex Pearce authored
Similar to the existing CopyParticle2MCRelations cloner, but it specialises the cloner template that takes the relations tables locations rather than the particle locations. This is useful when you want use existing relations tables made from generic containers of ProtoParticles.
-
Alex Pearce authored
In the case where the user only wants the relations and MC particles cloned, and not the (proto)particles, the cloner should be allowed to just take the (proto)particles from the 'original' location, and should not force the user to have used the microDST cloners on them beforehand.
-
Alex Pearce authored
-
- Mar 01, 2017
-
- Feb 28, 2017
-
-
Eduardo Rodrigues authored
Fix PersistReco propagation and Turbo truth-matching See merge request !51
-
- Feb 24, 2017
-
-
Alex Pearce authored
-
Alex Pearce authored
-
Alex Pearce authored
Before this commit, PersistReco objects were linked in such a way as to mimic the output of Brunel, e.g. linking ProtoParticle objects to `Rec/ProtoP/Charged`. Now, the Brunel locations are namespaced under a configurable RootInTES. This allows Turbo and PersistReco to live entirely under one location, `/Event/Turbo` by default, which should allow a more peaceful co-existence between Turbo+PersistReco and Brunel output. This commit moves towards allowing end-user Turbo configuration to more closely resemble that for a microDST, i.e. setting `InputType = 'MDST'` and `RootInTES = '/Event/Turbo'`.
-
- Feb 23, 2017
-
-
Alex Pearce authored
The default list of the MC associator (ChargedPP2MC) contains the default Brunel output locations, like Rec/ProtoP/Charged, but the PersistReco links will populate these locations with PersistReco objects. Because we already explicitly add the unpacked PersistReco locations to the associator's input list, there's no need for the associator to also run over the Brunel locations.
-
Alex Pearce authored
Can cause confusion (for software and for users) later down the line if 'pure' Turbo is mixed with PersistReco.
-
Alex Pearce authored
Otherwise the MC relations aren't packed, because they don't exist when the packer runs. D'oh!
-
Alex Pearce authored
-
Alex Pearce authored
Doesn't always live in Trigger/RawEvent, such as after Brunel processing.
-
Alex Pearce authored
Using `findFirstRawEvent` assumes that the raw bank lives in the same location as the TCK, which is not guaranteed.
-
Alex Pearce authored
Such caching prevents decoder algorithms from using two separate raw event locations. Imagine an algorithm calling `findFirstRawBank`, and the last location in the list of locations to search contains to requested bank, such that the last location is cached. A subsequent call to `findFirstRawEvent` will then return the cached location, even if the first location exists (it just doesn't contain the raw bank requested during the call to `firstFirstRawBank`). A concrete example where this can happen is in PersitReco processing, where the PersistReco object live in separate raw bank to the TCK, and where both banks are required by the HLT decoder.
-
Alex Pearce authored
-
Alex Pearce authored
-
Alex Pearce authored
-
- Feb 21, 2017
-
-
Alex Pearce authored
-
Alex Pearce authored
-
Alex Pearce authored
-
- Jan 17, 2017
-
-
Eduardo Rodrigues authored
- Jan 16, 2017
-
-
Eduardo Rodrigues authored
-