Steer phase space selection from the shell?
In !221 (merged), we opened a debate about defining a new section in config files, namely cuts. Such a block should be distinguished from skims: whereas skims removes events directly in the n-tuples and should be kept loose, a cut could be rather tight and be applied typically right before filling a histogram without affecting the n-tuple. Furthermore, a cut would be tested for each systematic variation separately.
On the one hand, making config files possibly longer, hence less readable. On the other hand, this could help producing a similar figure for different selections possibly from the command line. We have to make sure that such a functionality is worth it. We should also consider how many executables should be affected and how this can affect a whole workflow in practice.
Designs
- !221
Activity
added changepatch statusneeded? typephysics labels
added to epic &3
mentioned in merge request !221 (merged)
From the reproducibility perspective, it would be much better not to have to recompile the software (and commit) when studying a cut. Even if creating local commits, some of them will likely never end up in the main tree.
We already do this for e.g. muon ID and isolation cuts. These are stored under
corrections, but they're part of the selection.
The example of muon IDs is a bit different, because such cuts come with scale factors, and that these are often stored in different tables. Here we're talking about variations of the cut only. For a simple phase space cut, one could advocate to put such a loop in the executable, or to make a histogram of a slightly higher dimension, instead of looping from the shell.