Comments (13)
Use of TupleToolStripping
comes with the caveats that:
- The stripping reports in the MC are for the same stripping version as in your data
- I don't think prescales are applied to stripping lines in MC, so you need to take that efficiency in to account
- Generally, you need to do something else if you have PID cuts in your stripping line
from first-analysis-steps.
Although on 1 you can rerun any stripping lines and specify the location of the selection reports, so you could give TupleToolStripping
this location and it should give you the correct decisions.
from first-analysis-steps.
What is an alternative way of doing this to avoid TupleToolStripping
?
We should gear everything towards the fact that we re-run the stripping for
our line of choice unless the bookkeeping suddenly has stripping21
"flagged" simulation samples.
On Fri, May 8, 2015 at 11:27 AM Alex Pearce [email protected]
wrote:
Although on 1 you can rerun any stripping lines and specify the location
of the selection reports, so you could give TupleToolStripping this
location and it should give you the correct decisions.—
Reply to this email directly or view it on GitHub
#13 (comment)
.
from first-analysis-steps.
Regarding (3), what do you do? Maybe we should just use that as the default. Following the idea of presenting just one (obvious) way of doing things.
from first-analysis-steps.
Unfortunately it somewhat depends: either you care about the reconstruction efficiency, in between the generator level cuts and the stripping, or you don't.
In the latter case you just run the stripping on your MC and count how much (truth-matched) signal you have in your ntuple. The ratio (N_stripped/N_accepted) gives you the combined reconstruction and stripping efficiency. (N_accepted is the number passing the generator level cut defined in the decay file.)
In the former case you also need access to the candidates before the stripping, which you can do with CombineParticles
and the mcMatch
functor. Then the reconstruction efficiency is (N_reconstructed/N_accepted) and the stripping efficiency is (N_stripped/N_reconstructed). Often the product of these two is equal to (N_stripped/N_accepted), but I'm not wise enough to say under what circumstances.
For 3, you can copy the stripping module that defines your stripping line and alter it to remove PID cuts. If the PID cuts are completely configured by the line's configuration dictionary then you can just change that without needing the copy Python files around. (So only if you use the NoPIDs
containers.)
from first-analysis-steps.
I guess though it's more useful to show them the techniques. Deciding what specifics things to use in their analyses is a problem they need to tackle themselves.
from first-analysis-steps.
You will write this bit then?
I think we should pick a way of doing it that isn't too simplistic (maybe also not the most complicated one) and show that off with a note (as usual): other methods are available
from first-analysis-steps.
We come after #12 so everyone knows how to look at a stripping line and understands what the cuts mean and do, and after #7 and #10 so people know how to make ntuples in DaVinci.
The steps are then:
- Understand what you want to measure. Broadly explain the efficiencies you can compute with MC
- Understand the limitations. If a selection variable is not well modelled, studying it's efficiency with standard (untouched) MC is wrong.
- If all your selection variables are well modelled and the correct stripping version is run on your MC, use
TupleToolStripping
. Code here. - If your stripping version was not run over your MC, you need to rerun it. Code here.
- If a selection variable is not well modelled by MC, you need to either edit the configuration dictionary or the copy and modify the stripping line itself in order to disable the cut on it. Code here.
Mention alternative methods: apply the well-modelled stripping cuts yourself on truth-matched reconstructed particles (people should understand CombineParticles
from #12).
from first-analysis-steps.
@alexpearce: Does this mean that my efficiency will already be wrong if StdLooseKaons
(with PIDK > -5
) is used in the stripping line?
Do I have to rerun the stripping line without that cut and use PIDCalib to get the correct efficiency?
from first-analysis-steps.
Yes, I think that is true. However, the PIDK > -5
is so loose that it probably doesn't matter unless you need a very large precision.
from first-analysis-steps.
Yes, that's right. I would be very wary of having any PID cuts at all in the MC (@apuignav such a loose cut is probably close to 100% efficient for many signals, but it's an assumption I personally would not make).
In the case that PID cuts can't be removed just by altering a configuration dictionary, what I've done in the past is copy the stripping module from StrippingArchive
and edit it to remove all PID cuts.
from first-analysis-steps.
For the moment I conclude that determining the efficiency of a stripping line is "subtle" and so we punt it to second-analysis-steps
or add a lesson later on.
from first-analysis-steps.
from first-analysis-steps.
Related Issues (20)
- Explain how to generate the web pages HOT 5
- Move ganga lb-dev lesson HOT 7
- Should we switch to LoKi functors for DecayTreeFitter?
- Use GaudiExec in all Ganga lessons HOT 11
- Lesson "More on Ganga" doesn't exist anymore HOT 3
- Add Turbo stream in callout box of lesson 11 HOT 1
- Migrate all possible SVN URLs to GitLab HOT 1
- Updates and issues in 2. Install Party
- Test issue
- Mention MassStorage in "EOS-Storage" Chapter
- There is an online tool for finding the EventType of your decay HOT 3
- Tag the commit used for the November 2016 session
- Typo on the 'Contribute to this lesson' page
- python http module only available in Python 3
- Clarify DST explorer lesson
- Improve LoKi Functors lesson
- Running DaVinci on the grid: PythonOptsCmakeParserError HOT 3
- Setting up project fails HOT 3
- Why edit .gangarc for MassStorageFile? HOT 4
- Use CERN-FNAL school slides on "from collisions to analysis"? HOT 2
Recommend Projects
-
React
A declarative, efficient, and flexible JavaScript library for building user interfaces.
-
Vue.js
🖖 Vue.js is a progressive, incrementally-adoptable JavaScript framework for building UI on the web.
-
Typescript
TypeScript is a superset of JavaScript that compiles to clean JavaScript output.
-
TensorFlow
An Open Source Machine Learning Framework for Everyone
-
Django
The Web framework for perfectionists with deadlines.
-
Laravel
A PHP framework for web artisans
-
D3
Bring data to life with SVG, Canvas and HTML. 📊📈🎉
-
Recommend Topics
-
javascript
JavaScript (JS) is a lightweight interpreted programming language with first-class functions.
-
web
Some thing interesting about web. New door for the world.
-
server
A server is a program made to process requests and deliver data to clients.
-
Machine learning
Machine learning is a way of modeling and interpreting data that allows a piece of software to respond intelligently.
-
Visualization
Some thing interesting about visualization, use data art
-
Game
Some thing interesting about game, make everyone happy.
Recommend Org
-
Facebook
We are working to build community through open source technology. NB: members must have two-factor auth.
-
Microsoft
Open source projects and samples from Microsoft.
-
Google
Google ❤️ Open Source for everyone.
-
Alibaba
Alibaba Open Source for everyone
-
D3
Data-Driven Documents codes.
-
Tencent
China tencent open source team.
from first-analysis-steps.