Selection framework lesson #71
Conversation
|
(not read all of the content yet) Could this be a replacement for "General intro to stripping"? I have no good idea what you'd write there that isn't simply pages and pages of text. Maybe if we add a bit of "stripping" here and there in this it would make a much better topic? |
|
Travis is unhappy, which PR do we have to merge first? |
|
I don't think so, this is an independent concept.
But we can have a very simple intro for the Stripping, explaining how to
write a stripping line. Once this is merged, should be quite easy to get
there.
|
| The typical approach is to build the decay from the bottom up. Therefore, we need to | ||
|
|
||
| 1. Get input pions and kaons and filter them according to our physics needs. | ||
| 2. Combine a pion and a kaon to build a D0, filtering in the necessary physics quantities. |
There was a problem hiding this comment.
I don't like the english "filtering in the necessary physics". How about "and applying selection cuts to the D0."
|
|
||
| To do that, we need to know a little bit more about how the LHCb analysis framework works. | ||
| As discussed in the [Gaudi introduction](01-davinci.html), `Gaudi` is based on the event-by-event sequential (chained) execution of algorithms wrapped in a `GaudiSequencer`, which takes care of handling the execution order such that processing stops when an algorithm is *not passed*. | ||
| However, it doesn't handle is the data dependencies between these algorithms nor gives easy access to the used algorithms. |
There was a problem hiding this comment.
"However, .. handle is the data" -> "It does not handle the data ..."
There was a problem hiding this comment.
"nor gives" -> "nor does it give"
|
Let's try and merge #57 first then. For me the stripping is all about writing these selection sequences. Made even more complicated by adding all these dictionaries and stuff :-/ Afer reading it all I agree that we should keep it separate. |
| DaVinci().UserAlgorithms += [dstar_seq.sequence()] | ||
|
|
||
|
|
||
| # EOF |
There was a problem hiding this comment.
To make this more consistent with (most) of the other files:
- Move all imports to the top of the file, combining all the imports from
Configurables; - All double quotes
"to single'; - Remove last three lines
Seeing a the cuts for the D0 CombineParticles are made as variables like d0_daughters, should the same be done for the D*+ CombineParticles?
Personally, I would not alias the Std* containers. I think it makes the Selection instantiations less obvious.
There was a problem hiding this comment.
Double quotes cannot always be changed due to the use of ADMASS, the rest is changed.
I will keep the alias to the Std* containers to help with interchangeability with DataOnDemand.
|
Sorry for all the comments! This is a very nice lesson, I like how each step progresses in to the next. |
|
Thanks a lot! Changes have been implemented, as soon as #57 is merged I'll push. |
apuignav
force-pushed
the
selection-framework
branch
from
dfc0f1c
to
254a3a4
Compare
|
Thanks a lot for the reviewing and writing a nice topic. 🍰 for everyone! |
Addresses #46.