Mu2e Data Products

• Introduction
• Data Products in Mu2e Event Objects
• Data Products in Mu2e Run Objects
• Data Products in Mu2e SubRun Objects
• How to List All Data Products in a File
• Old Way to List All Data Products in a File

Introduction

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 background information about data products; in particular you can read about the 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 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 instance name field in the data product id; the third column lists instance names; an empty string is a valid instance name.

The known data products as of June 2011 are:

Data Products in Mu2e Event Objects

Data Products in Mu2e Run Objects

Data Products in Mu2e SubRun Objects

At present there are no data products stored in the SubRun object.

How to List All Data Products in a File

The recommended way to get a list of all data products in a Mu2e event-data file is:

 mu2e -c Analyses/test/fileDumper.fcl -s <input_file_name> -n <N>
 >>>>>>> after v6_0_0 moved to Print/fcl/fileDumper.fcl

Here is , an example of the output from this tool. It was created by

mu2e -c Analyses/test/fileDumper.fcl -s data_03.root -n 5

• If the data product class has a member function named size(), the fifth column contains the value returned by calling size().
• If the data product class does not have a member function named size(), the fifth column contains a dash.
• The circumstances under which a question mark may appear are discussed below.

Following the printout for the 5 events, there is similar printout describing the data products found in the SubRun record and the Run record.

You can change the behaviour of the fourth column, which contains the data type of the data product. The example illustrated shows the full class name. Instead you can choose to display the art "Friendly Classname"; to do so, edit fileDumper.fcl and change the value of the wantProductFullClassName parameter:

dumper : {
      module_type              : FileDumperOutput
      wantProductFullClassName : false
}

dumper : {
      module_type                  : FileDumperOutput
      wantProductFullClassName     : true
      wantProductFriendlyClassName : true
}

You may notice that the file dumper is implemented as an output module, not as an analyzer module. This is due to technical constaints inside art: the code that knows if a data product has a size function, is part of the art::Wrapper<T> class template. The Wrapper of a data product is not accessible to analyzer or producer modules but it is accessible to input and output modules. The code for the FileDumperOutput_module.cc is part of art, not part of Mu2e.

There is subtlety that was missed above. Each data product has an associated provenance that describes how the data product was made:

• Which module made this data product?
• What parameter set was used to configure that module?
• What data products, if any, were read by that module?

If we read this output file and write a new one in which we do NOT write data product DPB, then neither DPA nor DPB will be present in the output. In this case the provenances for both DPA and DPB will be removed from the registry that is written to the output file.

The general rule is that a provenance is retained in the registry so long as at least one of the following is true:

• The data product that it describes is present in the output file.
• Any of that data products descendant data products are present in the output file.

The actual behaviour of the file dumper module is that it loops over all provenances found in the provenance registry (not over all of the data products found in the file!). If a provenance is present in the registry but the corresponding data product is not present inthe file, then the last column contains a question mark.

In the example above, there are no provenances without a data product present in the file - so there are no lines that end in a question mark.

An example that contains provenance entries with no corresponding data product can be seen by:

mu2e -c Analyses/test/fileDumper.fcl -n 5 -s \
 /mu2e/data/tdr/beam/g4s1p1/tdr.beam.g4s1.primary.1025a.13797238/good/00000/dataBeamPrimaryToTS3DS23.root

There are several other optional parameters for the file dumper module:

• resolveProducts, which has a default value of true. If this is false then the file dumper module will only tell you the size of a data product that has already been loaded into memory by a previously executed module. If this is true, then file dumper module will read all data products into memory and, if they have a size member function, print their size. Setting this flag to true causes slower execution; setting it to false causes the size information to disappear.
• onlyIfPresent, which has a default value of false. If this is true then file dumper module will only print information about data products that are found in the file; it will skip provenances for which the corresponding data product is not present.
• onDemandProduction, which has a default value of false. If this is true, and if the data product is not found in the file but the data product can be produced using on-demand reconstruction, then the on-demand reconstruction system will be used to create the data product.

The Old Way to List All Data Products in a File

To list all data products in a file of event-data, you can run the command:

 mu2e -c Analyses/test/dumpDataProducts.fcl -s input_file_name.root
 >>>>>>> after v6_0_0 moved to Print/fcl/dumpDataProducts.fcl

Normally you should prefer to use fileDumper.fcl. However dumpDataProducts has been retained as an example of how to access provenance information.

Security, Privacy, Legal