Difference: WorkBookCollisionsDataAnalysis (1 vs. 15)

Revision 152018-09-03 - JhovannyMejia

Line: 1 to 1
 
META TOPICPARENT name="WorkBook"

Chapter 3.6: Analysis of the collision data

Line: 37 to 37
  Physics Data And Monte Carlo Validation (PdmV) group maintains some analysis recipe pages here. Especiale for run-II, next pages 2015, 2016, 2017 and 2018 collects useful information to be aware of when performing analysis or producing ntuples for analysis. Guidelines are collected on which release, detector conditions, and datasets. They also keep track of special filters or tools useful to remove atypical / problematic events
Changed:
<
<
There are several recipes for you to use to clean up the event sample as recommended by the PVT group. For 2010 and 2011 this is a collation of the information presented on the Collisions2010Recipes and Collisions2011Analysis TWiki pages.

The following sample cleanups should be done for most 2010 and 2011 analyses, unless you know what you are doing to change them.

  • Beam background removal
    process.noscraping = cms.EDFilter("FilterOutScraping",
                                    applyfilter = cms.untracked.bool(True),
                                    debugOn = cms.untracked.bool(True),
                                    numtrack = cms.untracked.uint32(10),
                                    thresh = cms.untracked.double(0.25)
                                    )
  • Primary vertex requirement
    process.primaryVertexFilter = cms.EDFilter("GoodVertexFilter",
                                               vertexCollection = cms.InputTag('offlinePrimaryVertices'),
                                               minimumNDOF = cms.uint32(4) ,
                                               maxAbsZ = cms.double(24), 
                                               maxd0 = cms.double(2) 
                                               )
  • HBHE event-level noise filtering
    process.load('CommonTools/RecoAlgos/HBHENoiseFilter_cfi')

More specific recipes on data analysis can be found in the Collisions2010Analysis and Collisions2011Analysis TWiki pages.

>
>
There are several recipes for you to use to clean up the event sample as recommended by the PVT group. For 2010 and 2011 check here.
 

Selection of good runs

The PVT group maintains centralized good run lists in two different formats here.

Revision 142018-08-29 - JhovannyMejia

Line: 1 to 1
 
META TOPICPARENT name="WorkBook"

Chapter 3.6: Analysis of the collision data

Line: 70 to 70
 
Added:
>
>
JSON file updates are announced on this HyperNews forum link.There you can found discussions regarding physics validation of MC and Data production for physics analyses, including good/bad run list based on DQM certification tools.
If you want to contact the experts the email gateway for this forum is: hn-cms-physics-validation@cernNOSPAMPLEASE.ch
 

Usage of computing resources

The best policy for users to use CRAB3 in order to process collision data is :

Line: 137 to 136
 filterJSON.py --min 21 --max 50 old.json --output second.json

This will create disjoint run ranges for all of your datasets, simplifying your accounting.

Changed:
<
<
>
>

Review status

Reviewer/Editor and Date (copy from screen) Comments
JhovannyMejia - 28 Aug 2018 Update to RunII
SalvatoreRoccoRappoccio - 28 Sep 2010 Author
 -- SalvatoreRoccoRappoccio - 28-Sep-2010

META FILEATTACHMENT attachment="tutorial.css" attr="" comment="" date="1337938564" name="tutorial.css" path="tutorial.css" size="254" user="rwolf" version="1"

Revision 132018-07-27 - JhovannyMejia

Line: 1 to 1
 
META TOPICPARENT name="WorkBook"

Chapter 3.6: Analysis of the collision data

Line: 35 to 35
  In terms of software the user should always follow the instructions from WorkBookWhichRelease.
Added:
>
>
Physics Data And Monte Carlo Validation (PdmV) group maintains some analysis recipe pages here. Especiale for run-II, next pages 2015, 2016, 2017 and 2018 collects useful information to be aware of when performing analysis or producing ntuples for analysis. Guidelines are collected on which release, detector conditions, and datasets. They also keep track of special filters or tools useful to remove atypical / problematic events
 There are several recipes for you to use to clean up the event sample as recommended by the PVT group. For 2010 and 2011 this is a collation of the information presented on the Collisions2010Recipes and Collisions2011Analysis TWiki pages.
Line: 117 to 119
 The PDWG is a group that defines and monitors these datasets. The PDWG TWiki describes details in how this process is done.
Added:
>
>
Particulary in runn-II, for producing ntuples for analysis the data are collected into different formats, such as, "AOD", "MiniAOD" and "NanoAOD" . The definitions are such that an attempt is made to maintain the necessary information according to the needs of each analysis.
 

Overlapping run ranges.

In general, there are many different primary datasets and/or run ranges that you will have to process for your analysis. As things evolve, older data is re-reconstructed, and primary datasets are split into smaller pieces. Because of the fact that oftentimes runs can appear in different datasets in re-reco's, it is often necessary to first define a run range for your dataset while running your grid job. This will ease your own accounting later on in the analysis chain.

Changed:
<
<
To do this, it is often advantageous to split up the DCS-ONLY good run lists into exclusive run ranges, and then pass the split sections to the various grid jobs you
>
>
To do this, it is often advantageous to split up the good run lists into exclusive run ranges, and then pass the split sections to the various grid jobs you
 are running for the various primary or secondary datasets. See the guide on good lumi sections with details of how to do this.

For instance, given two run ranges "1-20" and "21-50", you could split up your good run list in the JSON format as:

Revision 122018-07-19 - JhovannyMejia

Line: 1 to 1
 
META TOPICPARENT name="WorkBook"

Chapter 3.6: Analysis of the collision data

Line: 13 to 13
  The data are collected by the detector and processed through the HLT. From there, the HLT paths are designated to live inside a specific "Primary dataset" (PD). This is the "quantum" of the computing infrastructure. PD's are distributed in entirety to T1's and T2's, so accessing them is the primary mode that you will be
Changed:
<
<
using to access the data. The Primary Dataset Working Group (PDWG) is a good resource for you to
>
>
using to access the data. The Primary Dataset Working Group ( PDWG) is a good resource for you to
 keep up to speed with the PD's and their deployment.

There are quite a lot of random triggers that occur when the detector is not taking data, and so to account for this, the best practice is to only run on

Changed:
<
<
luminosity sections where the detector was "on". This webpage
>
>
luminosity sections where the detector was "on". This webpage
 is constantly updated with "good run lists" in a JSON format that correspond to the "DCS bit" being on, and the detector taking data. By using this "good run list" in your CRAB jobs, you will alleviate strain on the resources and run only on the data that is interesting for you for physics analysis.
Line: 35 to 35
  In terms of software the user should always follow the instructions from WorkBookWhichRelease.
Changed:
<
<
There are several recipes for you to use to clean up the event sample as recommended by the PVT group. This is a collation of the information presented on the Collisions2010Recipes and Collisions2011Analysis TWiki pages.
>
>
There are several recipes for you to use to clean up the event sample as recommended by the PVT group. For 2010 and 2011 this is a collation of the information presented on the Collisions2010Recipes and Collisions2011Analysis TWiki pages.
 
Changed:
<
<
The following sample cleanups should be done for most analyses, unless you know what you are doing to change them.
>
>
The following sample cleanups should be done for most 2010 and 2011 analyses, unless you know what you are doing to change them.
 
  • Beam background removal
    process.noscraping = cms.EDFilter("FilterOutScraping",
                                    applyfilter = cms.untracked.bool(True),
                                    debugOn = cms.untracked.bool(True),
Line: 52 to 52
  maxAbsZ = cms.double(24), maxd0 = cms.double(2) )
Changed:
<
<
  • HBHE event-level noise filtering
    process.load('CommonTools/RecoAlgos/HBHENoiseFilter_cfi')
    
>
>
  • HBHE event-level noise filtering
    process.load('CommonTools/RecoAlgos/HBHENoiseFilter_cfi')
 
Changed:
<
<
More specific recipes on data analysis can be found in the Collisions2010Analysis and Collisions2011Analysis TWiki pages.
>
>
More specific recipes on data analysis can be found in the Collisions2010Analysis and Collisions2011Analysis TWiki pages.
 

Selection of good runs

Line: 64 to 63
  The JSON format files should be used in conjunction with CRAB. Either the JSON or CMSSW formats should be used interactively in FWLite or the full CMSSW framework.
Changed:
<
<
  • Using the JSON format with CRAB is described here.
>
>
  • Using the JSON format with CRAB3 is described here.
 
  • Using the JSON format with CMSSW or FWLite is described in these links:
Changed:
<
<
>
>
 

Usage of computing resources

Changed:
<
<
The best policy for users to use CRAB in order to process collision data is :
  • Use the DCSONLY good run lists (in the JSON format) in CRAB as described here.
    • The DCSONLY good run lists are available here.
  • From there, publish the dataset if you intend to use grid resources to access it later. Instructions for CRAB publication can be found here.
  • The final good run lists should be applied at the analysis level. The latest good run lists are available here.
>
>
The best policy for users to use CRAB3 in order to process collision data is :
  • Use the good run lists (in the JSON format) in CRAB3 as described here.
    • The good run lists are available here.
  • From there, publish the dataset if you intend to use grid resources to access it later. Instructions for CRAB3 publication can be found here.
  • The final good run lists should be applied at the analysis level. The latest good run lists are available here.
 

Trigger Selection

Oftentimes, it is extremely useful to apply your trigger selection in your skim or PAT-tuple creation step directly. This reduces the load on the computing and gives you a smaller

Changed:
<
<
output. To do so, as an illustration, here is how to select HLT_Mu9 :
>
>
output. To do so, as an illustration, here is how to select HLT_Dimuon25_Jpsi :
 
Changed:
<
<
from HLTrigger.HLTfilters.hltHighLevel_cfi import * process.triggerSelection = hltHighLevel.clone(TriggerResultsTag = "TriggerResults::HLT", HLTPaths = ["HLT_Mu9"])
>
>
process.triggerSelection = cms.EDFilter("TriggerResultsFilter", triggerConditions = cms.vstring('HLT_Dimuon25_Jpsi_v*'), hltResults = cms.InputTag( "TriggerResults", "", "HLT" ), l1tResults = cms.InputTag( "" ), throw = cms.bool(False) )
  ...
Changed:
<
<
process.anaseq = cms.Sequence(
>
>
process.mySequence = cms.Sequence(
  process.triggerSelection* process.myOtherStuff
Changed:
<
<
)
>
>
)
 where myOtherStuff is whatever other modules you want to run.
Changed:
<
<
More information on trigger access in analysis can be found at WorkBookHLTTutorial and WorkBookPATExampleTrigger.
>
>
More information on trigger access in analysis can be found at WorkBookHLTTutorial and WorkBookMiniAOD2017#Trigger.
 

Analysis of the processed data

Changed:
<
<
There are several choices for the user to analyze collision data. There is an example in FWLite to help get you started.
>
>
There are several choices for the user to analyze collision data. There are several examples to help get you started: example in FWLite , TrackAnalysis and MuonAnalysis.
 

Luminosity information

Changed:
<
<
Luminosity should be calculated with the official lumiCalc tool that is described on the LumiCalc TWiki. Starting in 38x, the luminosity is stored directly in the event also, however the database value can change and the static copy inside the file should be taken as indicative only. An example of how to loop over the lumi sections and compute the lumi is available.
>
>
Luminosity should be calculated with the official brilcalc tool, recommended tool for both Run 1 and Run 2 data. For more information, please see the Lumi POG page and the official brilcalc documentation.
 

About Datasets

The data are collected into "primary datasets", "secondary datasets", and "central skims" for distribution to the computing resources. The definitions are such to keep roughly equal rates for each PD.

Changed:
<
<
The PDWG is a group that defines and monitors these datasets. The PDWG TWiki describes details in how
>
>
The PDWG is a group that defines and monitors these datasets. The PDWG TWiki describes details in how
 this process is done.

Overlapping run ranges.

Line: 128 to 124
 range for your dataset while running your grid job. This will ease your own accounting later on in the analysis chain.

To do this, it is often advantageous to split up the DCS-ONLY good run lists into exclusive run ranges, and then pass the split sections to the various grid jobs you

Changed:
<
<
are running for the various primary or secondary datasets. See the guide on good lumi sections with details of how to do this.
>
>
are running for the various primary or secondary datasets. See the guide on good lumi sections with details of how to do this.
  For instance, given two run ranges "1-20" and "21-50", you could split up your good run list in the JSON format as:

filterJSON.py --min 1 --max 20 old.json --output first.json
Changed:
<
<
filterJSON.py --min 21 --max 50 old.json --output second.json
>
>
filterJSON.py --min 21 --max 50 old.json --output second.json
  This will create disjoint run ranges for all of your datasets, simplifying your accounting.

Revision 112012-05-25 - RogerWolf

Line: 1 to 1
 
META TOPICPARENT name="WorkBook"

Chapter 3.6: Analysis of the collision data

Line: 144 to 144
 -- SalvatoreRoccoRappoccio - 28-Sep-2010

META FILEATTACHMENT attachment="tutorial.css" attr="" comment="" date="1337938564" name="tutorial.css" path="tutorial.css" size="254" user="rwolf" version="1"
Added:
>
>
META PREFERENCE name="USERSTYLEURL" title="USERSTYLEURL" type="Set" value="%25ATTACHURL%25/tutorial.css"

Revision 102012-05-25 - RogerWolf

Line: 1 to 1
 
META TOPICPARENT name="WorkBook"

Chapter 3.6: Analysis of the collision data

Line: 49 to 49
 process.primaryVertexFilter = cms.EDFilter("GoodVertexFilter", vertexCollection = cms.InputTag('offlinePrimaryVertices'), minimumNDOF = cms.uint32(4) ,
Changed:
<
<
maxAbsZ = cms.double(15),
>
>
maxAbsZ = cms.double(24),
  maxd0 = cms.double(2) )
  • HBHE event-level noise filtering
    process.load('CommonTools/RecoAlgos/HBHENoiseFilter_cfi')
Line: 142 to 142
 

-- SalvatoreRoccoRappoccio - 28-Sep-2010

Added:
>
>
META FILEATTACHMENT attachment="tutorial.css" attr="" comment="" date="1337938564" name="tutorial.css" path="tutorial.css" size="254" user="rwolf" version="1"

Revision 92011-12-20 - MartinWeber

Line: 1 to 1
 
META TOPICPARENT name="WorkBook"

Chapter 3.6: Analysis of the collision data

Line: 36 to 36
 In terms of software the user should always follow the instructions from WorkBookWhichRelease.

There are several recipes for you to use to clean up the event sample as recommended by the PVT group. This is a collation of the

Changed:
<
<
information presented here.
>
>
information presented on the Collisions2010Recipes and Collisions2011Analysis TWiki pages.
  The following sample cleanups should be done for most analyses, unless you know what you are doing to change them.
  • Beam background removal
    process.noscraping = cms.EDFilter("FilterOutScraping",
Line: 55 to 55
 
  • HBHE event-level noise filtering
    process.load('CommonTools/RecoAlgos/HBHENoiseFilter_cfi')
    
Changed:
<
<
There are more filters available, depending on which type of physics process you are looking for. The recommendations from various groups are added here:

>
>
More specific recipes on data analysis can be found in the Collisions2010Analysis and Collisions2011Analysis TWiki pages.
 

Selection of good runs

Line: 105 to 103
 

Analysis of the processed data

Changed:
<
<
There are several choices for the user to analyze collision data. There is an example in FWLite to help get you started here.
>
>
There are several choices for the user to analyze collision data. There is an example in FWLite to help get you started.
 

Luminosity information

Changed:
<
<
Luminosity should be calculated with the official lumiCalc tool that is described here. Starting in 38x, the luminosity
>
>
Luminosity should be calculated with the official lumiCalc tool that is described on the LumiCalc TWiki. Starting in 38x, the luminosity
 is stored directly in the event also, however the database value can change and the static copy inside the file should be taken as indicative only.
Changed:
<
<
An example of how to loop over the lumi sections and compute the lumi is here.
>
>
An example of how to loop over the lumi sections and compute the lumi is available.
 

About Datasets

Line: 120 to 118
 The data are collected into "primary datasets", "secondary datasets", and "central skims" for distribution to the computing resources. The definitions are such to keep roughly equal rates for each PD.
Changed:
<
<
The PDWG is a group that defines and monitors these datasets. The twiki here describes details in how
>
>
The PDWG is a group that defines and monitors these datasets. The PDWG TWiki describes details in how
 this process is done.

Overlapping run ranges.

Line: 130 to 128
 range for your dataset while running your grid job. This will ease your own accounting later on in the analysis chain.

To do this, it is often advantageous to split up the DCS-ONLY good run lists into exclusive run ranges, and then pass the split sections to the various grid jobs you

Changed:
<
<
are running for the various primary or secondary datasets. The details of how to do this are outlined here.
>
>
are running for the various primary or secondary datasets. See the guide on good lumi sections with details of how to do this.
  For instance, given two run ranges "1-20" and "21-50", you could split up your good run list in the JSON format as:

Revision 82011-12-19 - SalvatoreRRappoccio

Line: 1 to 1
 
META TOPICPARENT name="WorkBook"

Chapter 3.6: Analysis of the collision data

Line: 36 to 36
 In terms of software the user should always follow the instructions from WorkBookWhichRelease.

There are several recipes for you to use to clean up the event sample as recommended by the PVT group. This is a collation of the

Changed:
<
<
information presented here that is relevant for 38x analysis.
>
>
information presented here.
  The following sample cleanups should be done for most analyses, unless you know what you are doing to change them.
  • Beam background removal
    process.noscraping = cms.EDFilter("FilterOutScraping",

Revision 72011-12-19 - MartinWeber

Line: 1 to 1
 
META TOPICPARENT name="WorkBook"
Deleted:
<
<
 

Chapter 3.6: Analysis of the collision data

Line: 56 to 55
 
  • HBHE event-level noise filtering
    process.load('CommonTools/RecoAlgos/HBHENoiseFilter_cfi')
    
Added:
>
>
There are more filters available, depending on which type of physics process you are looking for. The recommendations from various groups are added here:

 

Selection of good runs

Revision 62011-12-16 - SalvatoreRRappoccio

Line: 1 to 1
 
META TOPICPARENT name="WorkBook"
Deleted:
<
<
*THIS PAGE IS UNDER CONSTRUCTION*
 
Changed:
<
<

Chapter 6: Analysis of the collision data

>
>

Chapter 3.6: Analysis of the collision data

 

Revision 52010-10-12 - SalvatoreRRappoccio

Line: 1 to 1
 
META TOPICPARENT name="WorkBook"
*THIS PAGE IS UNDER CONSTRUCTION*
Line: 59 to 59
 
Added:
>
>

Selection of good runs

The PVT group maintains centralized good run lists in two different formats here. The files are stored as either JSON format or directly as a CMSSW configuration snippet.

The JSON format files should be used in conjunction with CRAB. Either the JSON or CMSSW formats should be used interactively in FWLite or the full CMSSW framework.

 

Usage of computing resources

Line: 102 to 115
 An example of how to loop over the lumi sections and compute the lumi is here.
Added:
>
>

About Datasets

The data are collected into "primary datasets", "secondary datasets", and "central skims" for distribution to the computing resources. The definitions are such to keep roughly equal rates for each PD.

The PDWG is a group that defines and monitors these datasets. The twiki here describes details in how this process is done.

Overlapping run ranges.

In general, there are many different primary datasets and/or run ranges that you will have to process for your analysis. As things evolve, older data is re-reconstructed, and primary datasets are split into smaller pieces. Because of the fact that oftentimes runs can appear in different datasets in re-reco's, it is often necessary to first define a run range for your dataset while running your grid job. This will ease your own accounting later on in the analysis chain.

To do this, it is often advantageous to split up the DCS-ONLY good run lists into exclusive run ranges, and then pass the split sections to the various grid jobs you are running for the various primary or secondary datasets. The details of how to do this are outlined here.

For instance, given two run ranges "1-20" and "21-50", you could split up your good run list in the JSON format as:

filterJSON.py --min 1 --max 20 old.json --output first.json
filterJSON.py --min 21 --max 50 old.json --output second.json

This will create disjoint run ranges for all of your datasets, simplifying your accounting.

  -- SalvatoreRoccoRappoccio - 28-Sep-2010

Revision 42010-10-05 - SalvatoreRRappoccio

Line: 1 to 1
 
META TOPICPARENT name="WorkBook"
*THIS PAGE IS UNDER CONSTRUCTION*
Line: 7 to 7
 
Added:
>
>

Conceptual overview

Running over large amounts of data can be rather tricky, but good practices can make your life a lot easier. A judicious usage of the computing resources and software tools at your disposal can make your analysis run a lot more smoothly and efficiently, while at the same time causing less of a strain on the limited computing resources.

Before we get started on this WorkBook, it is useful to overview how data are acquired and distributed, in the context of accessing it for your analysis.

The data are collected by the detector and processed through the HLT. From there, the HLT paths are designated to live inside a specific "Primary dataset" (PD). This is the "quantum" of the computing infrastructure. PD's are distributed in entirety to T1's and T2's, so accessing them is the primary mode that you will be using to access the data. The Primary Dataset Working Group (PDWG) is a good resource for you to keep up to speed with the PD's and their deployment.

There are quite a lot of random triggers that occur when the detector is not taking data, and so to account for this, the best practice is to only run on luminosity sections where the detector was "on". This webpage is constantly updated with "good run lists" in a JSON format that correspond to the "DCS bit" being on, and the detector taking data. By using this "good run list" in your CRAB jobs, you will alleviate strain on the resources and run only on the data that is interesting for you for physics analysis.

There are also many triggers within a given primary dataset. It is fast and efficient to request a single trigger (or group of triggers) at the beginning of your path, such that the rest of the sequence will only process if that trigger fired. This also leads to an alleviated strain on the computing resources, and lets your jobs finish much more quickly.

Much of the machine background that comes from, for instance, beam+gas interactions, can be removed by prescriptions from various DPG's. This wisdom is best followed, and hence is provided as a standard cleaning recipe below.

The following recipes will help you to get started with performing effective analysis of the collision data while minimizing impact on the computing environment.

 

Recipes to get started

Line: 67 to 94
  There are several choices for the user to analyze collision data. There is an example in FWLite to help get you started here.
Added:
>
>

Luminosity information

Luminosity should be calculated with the official lumiCalc tool that is described here. Starting in 38x, the luminosity is stored directly in the event also, however the database value can change and the static copy inside the file should be taken as indicative only. An example of how to loop over the lumi sections and compute the lumi is here.

 -- SalvatoreRoccoRappoccio - 28-Sep-2010

Revision 32010-09-30 - SalvatoreRRappoccio

Line: 1 to 1
 
META TOPICPARENT name="WorkBook"
*THIS PAGE IS UNDER CONSTRUCTION*

Chapter 6: Analysis of the collision data

Added:
>
>
 

Recipes to get started

Added:
>
>
In terms of software the user should always follow the instructions from WorkBookWhichRelease.
 There are several recipes for you to use to clean up the event sample as recommended by the PVT group. This is a collation of the information presented here that is relevant for 38x analysis.
Line: 35 to 39
 The best policy for users to use CRAB in order to process collision data is :
  • Use the DCSONLY good run lists (in the JSON format) in CRAB as described here.
    • The DCSONLY good run lists are available here.
Changed:
<
<
  • From there, publish the dataset if you intend to use grid resources to access it later.
>
>
  • From there, publish the dataset if you intend to use grid resources to access it later. Instructions for CRAB publication can be found here.
 
  • The final good run lists should be applied at the analysis level. The latest good run lists are available here.
Added:
>
>

Trigger Selection

Oftentimes, it is extremely useful to apply your trigger selection in your skim or PAT-tuple creation step directly. This reduces the load on the computing and gives you a smaller output. To do so, as an illustration, here is how to select HLT_Mu9 :

from HLTrigger.HLTfilters.hltHighLevel_cfi import *
process.triggerSelection = hltHighLevel.clone(TriggerResultsTag = "TriggerResults::HLT", HLTPaths = ["HLT_Mu9"])

...


process.anaseq = cms.Sequence(
    process.triggerSelection*
    process.myOtherStuff
)
where myOtherStuff is whatever other modules you want to run.

More information on trigger access in analysis can be found at WorkBookHLTTutorial and WorkBookPATExampleTrigger.

 

Analysis of the processed data

There are several choices for the user to analyze collision data. There is an example in FWLite to help get you started here.

Revision 22010-09-28 - SalvatoreRRappoccio

Line: 1 to 1
 
META TOPICPARENT name="WorkBook"
*THIS PAGE IS UNDER CONSTRUCTION*
Line: 9 to 9
 

Recipes to get started

There are several recipes for you to use to clean up the event sample as recommended by the PVT group. This is a collation of the

Changed:
<
<
information presented here.
>
>
information presented here that is relevant for 38x analysis.
  The following sample cleanups should be done for most analyses, unless you know what you are doing to change them.
Changed:
<
<
  • Beam background removal
  • Primary vertex requirement
  • HBHE event-level noise filtering
>
>
  • Beam background removal
    process.noscraping = cms.EDFilter("FilterOutScraping",
                                    applyfilter = cms.untracked.bool(True),
                                    debugOn = cms.untracked.bool(True),
                                    numtrack = cms.untracked.uint32(10),
                                    thresh = cms.untracked.double(0.25)
                                    )
  • Primary vertex requirement
    process.primaryVertexFilter = cms.EDFilter("GoodVertexFilter",
                                               vertexCollection = cms.InputTag('offlinePrimaryVertices'),
                                               minimumNDOF = cms.uint32(4) ,
                                               maxAbsZ = cms.double(15), 
                                               maxd0 = cms.double(2) 
                                               )
  • HBHE event-level noise filtering
    process.load('CommonTools/RecoAlgos/HBHENoiseFilter_cfi')
    
 

Usage of computing resources

The best policy for users to use CRAB in order to process collision data is :

  • Use the DCSONLY good run lists (in the JSON format) in CRAB as described here.
Added:
>
>
    • The DCSONLY good run lists are available here.
 
  • From there, publish the dataset if you intend to use grid resources to access it later.
Changed:
<
<
  • The final good run lists should be applied at the analysis level.
>
>
  • The final good run lists should be applied at the analysis level. The latest good run lists are available here.
 

Analysis of the processed data

Revision 12010-09-28 - SalvatoreRRappoccio

Line: 1 to 1
Added:
>
>
META TOPICPARENT name="WorkBook"
*THIS PAGE IS UNDER CONSTRUCTION*

Chapter 6: Analysis of the collision data

Recipes to get started

There are several recipes for you to use to clean up the event sample as recommended by the PVT group. This is a collation of the information presented here.

The following sample cleanups should be done for most analyses, unless you know what you are doing to change them.

  • Beam background removal
  • Primary vertex requirement
  • HBHE event-level noise filtering

Usage of computing resources

The best policy for users to use CRAB in order to process collision data is :

  • Use the DCSONLY good run lists (in the JSON format) in CRAB as described here.
  • From there, publish the dataset if you intend to use grid resources to access it later.
  • The final good run lists should be applied at the analysis level.

Analysis of the processed data

There are several choices for the user to analyze collision data. There is an example in FWLite to help get you started here.

-- SalvatoreRoccoRappoccio - 28-Sep-2010

 
This site is powered by the TWiki collaboration platform Powered by PerlCopyright & 2008-2019 by the contributing authors. All material on this collaboration platform is the property of the contributing authors.
Ideas, requests, problems regarding TWiki? Send feedback