Difference: AtlasDataAnalysis (88 vs. 89)
Revision 892011-03-01 - AlistairGemmell
| Line: 1 to 1 | ||||||||
|---|---|---|---|---|---|---|---|---|
<-- p { margin-bottom: 0.21cm; }h1 { margin-bottom: 0.21cm; }h1.western { font-family: "Liberation Serif",serif; }h1.cjk { font-family: "DejaVu Sans"; }h1.ctl { font-family: "DejaVu Sans"; }h2 { margin-bottom: 0.21cm; }h4 { margin-bottom: 0.21cm; }h5 { margin-bottom: 0.21cm; }h3 { margin-bottom: 0.21cm; }h3.western { font-family: "Liberation Serif",serif; }h3.cjk { font-family: "DejaVu Sans"; }h3.ctl { font-family: "DejaVu Sans"; }pre.cjk { font-family: "DejaVu Sans",monospace; }a:link { } -->
Computentp, Neural Nets and MCLIMITS | ||||||||
| Line: 21 to 21 | ||||||||
| Samples are produced for the Neural Net from AODs - results have previously been obtained for MC samples derived from v12 and v15 of athena. Current efforts are directed toward debugging the v15 results, and then upgrading to v16 input. The inputs are created from AODs using the TtHHbbDPDBasedAnalysis package (currently 00-04-18 and its branches are for v15, 00-04-19 is for v16). | ||||||||
| Added: | ||||||||
| > > | Current samples in useInput data and cross-sectionsThese cross-sections are for the overall process, at √s = 7 TeV. The ttH sample cross-sections are provided for the overall process - the MC is divided into two samples with W+ and W- independent of one another. These two samples are merged before being put through the ANN. The tt samples were initially generated to produce the equivalent of 75fb-1 of data, based on the LO cross-sections. Taking into account the k-factor of 1.84, this means that now all samples simulate 40.8fb-1 of data. These samples have also had a generator-level filter applied - most events (especially for tt+0j) are of no interest to us, so we don't want to fill up disk-space with them, so we apply filters based on the numbers of jets etc. The Filter Efficiency is the fraction of events that pass from the general sample into the final simulated sample. To clarify how all the numbers hang together, consider the case of tt+0j. We have simulated 66,911 events - as said above, this corresponds to 40.8fb-1 of data. We have a Filter Efficiency of 0.06774, so the full number of events that a complete semi-leptonic event would be comes to 987,762 events in 40fb-1. Divide this by 40 to get the number of events in 1fb-1 (i.e. the cross-section), and you get 24,694 events per fb-1. Our starting point for our cross-section is 13.18, with a k-factor of 1.84, which gives a cross-section of 24.25 - so all the numbers compare with each other pretty favourably. This of course makes getting from the number of sensible state events to the number expected per fb-1 rather easy - simply divide by 40.8.... You'll notice that the cross-section includes all the branching ratios already, so we don't need to worry about that. **IMPORTANT** The Filter Efficiency for these samples was calculated based on a no-pileup sample. The filter is generator level, and one of the things it will cut an event for is not enough jets. However, pileup adds jets, but these are added well after the filter. The net result is that a number of events that failed the filter would have passed, had the pileup been added earlier in the process. This means the filter efficiency (and thus the cross-sections) are incorrect, by a yet to determined amount.... For the other samples, however, we do need to worry about branching ratios - the quoted initial cross-section includes all final states, so we need to apply branching ratios to the cross-section to reduce it down, so that it reflects the sample we've generated. We then subsequently need to reduce the cross-section further so that it reflects the number of sensible states.<-- /editTable --> These cross-sections and branching ratios are correct as of 8 Feb 2011. qq→ttbb (EWK) is currently not being used, thanks to a bug in the production of the MC Number of events surviving preselection, weights and TrainWeights(See later in the TWiki for an explanation of weights and TrainWeights.) This table will be completed with all the relevant weights and TrainWeights at a later date - these values are to be compared to the output from Computentp to ensure everything is working as intended, and are calculated for the sensible cross-sections/events. (A quick check of the TrainWeight is to multiply the number so events of each background by their TrainWeight and sum them - by design, this should equal the number of entries in the ttH sample.)<-- /editTable --> | |||||||
Issues still to be resolved1. In share/TtHHbbSetups.py: | ||||||||
| Line: 270 to 358 | ||||||||
| Currently, the type of event you are looking at is determined by looking at my_failEvent. States failing preselection have this equal to 0, passing preselection but not having a sensible final state equal 1 and passing preselection and having a sensible final state equal 3. These numbers are the basis of a number of bitwise tests - thus when setting your own my_failEvents, consider which bits in a binary string you want to represent various things, and then convert those to decimal. | ||||||||
| Deleted: | ||||||||
| < < | Current samples in useInput data and cross-sectionsThese cross-sections are for the overall process, at √s = 7 TeV. The ttH sample cross-sections are provided for the overall process - the MC is divided into two samples with W+ and W- independent of one another. These two samples are merged before being put through the ANN. The tt samples were initially generated to produce the equivalent of 75fb-1 of data, based on the LO cross-sections. Taking into account the k-factor of 1.84, this means that now all samples simulate 40.8fb-1 of data. These samples have also had a generator-level filter applied - most events (especially for tt+0j) are of no interest to us, so we don't want to fill up disk-space with them, so we apply filters based on the numbers of jets etc. The Filter Efficiency is the fraction of events that pass from the general sample into the final simulated sample. To clarify how all the numbers hang together, consider the case of tt+0j. We have simulated 66,911 events - as said above, this corresponds to 40.8fb-1 of data. We have a Filter Efficiency of 0.06774, so the full number of events that a complete semi-leptonic event would be comes to 987,762 events in 40fb-1. Divide this by 40 to get the number of events in 1fb-1 (i.e. the cross-section), and you get 24,694 events per fb-1. Our starting point for our cross-section is 13.18, with a k-factor of 1.84, which gives a cross-section of 24.25 - so all the numbers compare with each other pretty favourably. This of course makes getting from the number of sensible state events to the number expected per fb-1 rather easy - simply divide by 40.8.... You'll notice that the cross-section includes all the branching ratios already, so we don't need to worry about that. **IMPORTANT** The Filter Efficiency for these samples was calculated based on a no-pileup sample. The filter is generator level, and one of the things it will cut an event for is not enough jets. However, pileup adds jets, but these are added well after the filter. The net result is that a number of events that failed the filter would have passed, had the pileup been added earlier in the process. This means the filter efficiency (and thus the cross-sections) are incorrect, by a yet to determined amount.... For the other samples, however, we do need to worry about branching ratios - the quoted initial cross-section includes all final states, so we need to apply branching ratios to the cross-section to reduce it down, so that it reflects the sample we've generated. We then subsequently need to reduce the cross-section further so that it reflects the number of sensible states.<-- /editTable --> These cross-sections and branching ratios are correct as of 8 Feb 2011. qq→ttbb (EWK) is currently not being used, thanks to a bug in the production of the MC Number of events surviving preselection, weights and TrainWeightsThis table will be completed with all the relevant weights and TrainWeights at a later date - these values are to be compared to the output from Computentp to ensure everything is working as intended, and are calculated for the sensible cross-sections/events. (A quick check of the TrainWeight is to multiply the number so events of each background by their TrainWeight and sum them - by design, this should equal the number of entries in the ttH sample.)<-- /editTable --> | |||||||
Setting Systematic UncertaintiesThe fitting code can take into account two different types of systematic uncertainty - rate and shape. The basic method to obtain both these uncertainties is that you should make your input samples for both your nominal sample, and for the two bounds of a given error (e.g. Initial State Radiation, ISR). Repeat this for all of the errors you wish to consider. The rate systematic uncertainty is simply how the number of events change that pass your preselection cuts etc. (you can only consider this, if you like). To obtain the shape uncertainty, you should pass each of the resulting datasets through the ANN (up to and including the templating, so that you have ANN results for both the nominal results, and as a result of varying each background). These ANN outputs can then be used to produce the rate uncertainties based on their integrals, before being normalised to the nominal cross-section so as to find the shape uncertainty - a measure of the percentage change in the bin-by-bin distribution for each error. | ||||||||
Copyright © 2008-2025 by the contributing authors. All material on this collaboration platform is the property of the contributing authors. Ideas, requests, problems regarding TWiki? Send feedback