Difference: WorkBookDataFormats (29 vs. 30)

Revision 302015-02-24 - RaviJanjam

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

3.2 Data Formats and Data Tiers

Added:
>
>
 Complete: 4
Detailed Review status
Line: 43 to 44
 

About Data Formats

Changed:
<
<
Each bit of data in an event must be written in a supported data format. A data format is essentially a C++ class, where a class defines a data structure (a data type with data members). The term data format can be used to refer to the format of the data written using the class (e.g., data format as a sort of template), or to the instantiated class object itself. The DataFormats package and the SimDataFormats package (for simulated data) in the CMSSW CVS repository contain all the supported data formats that can be written to an Event file. So, for example, if you wish to add data to an Event, your EDProducer module must instantiate one or more of these data format classes.
>
>
Each bit of data in an event must be written in a supported data format. A data format is essentially a C++ class, where a class defines a data structure (a data type with data members). The term data format can be used to refer to the format of the data written using the class (e.g., data format as a sort of template), or to the instantiated class object itself. The DataFormats package and the SimDataFormats package (for simulated data) in the CMSSW CVS repository contain all the supported data formats that can be written to an Event file. So, for example, if you wish to add data to an Event, your EDProducer module must instantiate one or more of these data format classes.
  Data formats (classes) for reconstructed data, for example, include Reco.Track, Reco.TrackExtra, and many more. See the Offline Guide section SWGuideRecoDataTable for the full listing.
Line: 75 to 75
  RECO data contains objects from all stages of reconstruction. AOD are derived from the RECO information to provide data for physics analyses in a convenient, compact format. Typically, physics analyses don't require you to rerun the reconstruction process on the data. Most physics analyses can run on AOD data.
Changed:
<
<
whats_in_aod_reco.gif
>
>
whats_in_aod_reco.gif
 

RECO

Line: 79 to 79
 

RECO

Added:
>
>
 RECO is the name of the data-tier which contains objects created by the event reconstruction program. It is derived from RAW data and provides access to reconstructed physics objects for physics analysis in a convenient format. Event reconstruction is structured in several hierarchical steps:
Changed:
<
<
  1. Detector-specific processing: Starting from detector data unpacking and decoding, detector calibration constants are applied and cluster or hit objects are reconstructed.
  2. Tracking: Hits in the silicon and muon detectors are used to reconstruct global tracks. Pattern recognition in the tracker is the most CPU-intensive task.
  3. Vertexing: Reconstructs primary and secondary vertex candidates.
  4. Particle identification: Produces the objects most associated with physics analyses. Using a wide variety of sophisticated algorithms, standard physics object candidates are created (electrons, photons, muons, missing transverse energy and jets; heavy-quarks, tau decay).
>
>
  1. Detector-specific processing: Starting from detector data unpacking and decoding, detector calibration constants are applied and cluster or hit objects are reconstructed.
  2. Tracking: Hits in the silicon and muon detectors are used to reconstruct global tracks. Pattern recognition in the tracker is the most CPU-intensive task.
  3. Vertexing: Reconstructs primary and secondary vertex candidates.
  4. Particle identification: Produces the objects most associated with physics analyses. Using a wide variety of sophisticated algorithms, standard physics object candidates are created (electrons, photons, muons, missing transverse energy and jets; heavy-quarks, tau decay).
  The normal completion of the reconstruction task will result in a full set of these reconstructed objects usable by CMS physicists in their analyses. You would only need to rerun these algorithms if your analysis requires you to take account of such things as trial calibrations, novel algorithms etc.
Line: 129 to 131
 Calibration/HcalIsolatedTrackReco/interface/IsolatedPixelTrackCandidateProducer.h -- Calibration/HcalIsolatedTrackReco/src/SealModule.cc -- Calibration/HcalIsolatedTrackReco/src/IsolatedPixelTrackCandidateProducer.cc --
Changed:
<
<
Calibration/HcalIsolatedTrackReco/BuildFile --
>
>
BuildFile --
 DataFormats/EgammaTrackReco/doc/html/overview.html -- DataFormats/EgammaTrackReco/doc/html/index.html -- DataFormats/EgammaTrackReco/interface/TrackCandidateSuperClusterAssociation.h --
Line: 140 to 142
 DataFormats/TrackReco/interface/TrackBase.h -- DataFormats/TrackReco/interface/TrackExtra.h --
Changed:
<
<
...
>
>
...
 Clicking on /CMSSW/src/DataFormats/TrackReco/interface/Track.h, we find several functions (methods) defined with clear function names, e.g.:
Added:
>
>
 
...
061     /// x coordinate of momentum vector at the outermost hit position
Line: 152 to 155
 065 /// z coordinate of momentum vector at the outermost hit position 066 double outerPz() const { return extra_->outerPz(); } 067 /// x coordinate of the outermost hit position
Changed:
<
<
... Another way to learn about the interface of the data inside an event is described in FWLite in Python.
>
>
...
 
Added:
>
>
Another way to learn about the interface of the data inside an event is described in FWLite in Python.
 

Information Sources

 
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