ReadProducts

From Mu2eWiki
Revision as of 15:28, 23 March 2017 by Rlc (talk | contribs) (Created page with " ===Introduction === You can think of a "data product" as a piece of information to which you may get access by calling an appropriate get function on the event object. Equiv...")
(diff) ← Older revision | Latest revision (diff) | Newer revision → (diff)
Jump to navigation Jump to search

Introduction

You can think of a "data product" as a piece of information to which you may get access by calling an appropriate get function on the event object. Equivalently, you can think of the art::Event object as an art::EventId plus a collection of data products. Most data products are collections of simpler objects but a few are just a single object; an example of a single object is the StatusG4 object that describes the completion status of Geant4.

Actually, the definition of a data product is slightly broader than this. The art::Run object is just an art::RunId object plus a collection of data products; similarly for the art::SubRun object. When we intialize Geant4, we do it in the beginRun method of Mu2eG4/src/G4_plugin.cc. At the end of Geant4 initialization we create a std::vector of all physical volumes known to G4 and we put this information into the art::Run object as a PhysicalVolumeInfoCollection. The SimParticle class holds two indices into this collection; one describes the volume in which the particle was born and the other describes the volume in which the particle stopped.

When you look at a class like StrawHitCollection, you will see that it is just a typedef to std::vector<StrawHit>. Why do we do this? Suppose that one day we wish to extend StrawHitCollection so that it behaves like a std::vector<StrawHit> plus some additional features. When we do this, your code should continue to work without any editing. We have already done this once. In the early days, SimParticleCollection was an std::vector<SimParticle> but it is now a cet::map_vector<SimParticle>. This change was required because we changed the behaviour G4 so that there are some missing track numbers; when we made this change, no one noticed.

You can read some [DataProducts.shtml ] background information about data products<a>; in particular you can read about the [DataProducts.shtml#identifiers naming conventions for data products] .

The tables below list the data products that are supported for general use within Mu2e. A few are still in draft form and may change; these include the two StrawCluster classes. In each table, the first column lists that name of the class that produces them. Remember that data products are labeled by the [DataProducts.shtml#identifiers label of the module that created them] , not by the name of the class that created them; but you need to know the class name to find the code that created the data product. For a class named XXXXX you can find the corresponding code in XXXXX_plugin.cc. The second column lists the data type of the product; the definitions of the data products can be found in the header files in DataProducts/inc, MCDataProducts/inc or RecoDataProduct/inc. When one class may produce more than one data product of the same data type, these are distinguished using the [DataProducts.shtml#identifiers instance name field in the data product id] ; the third column lists instance names; an empty string is a valid instance name.