Back to home page

EIC code displayed by LXR

 
 

    


Warning, /tutorial-reconstruction-algorithms/_episodes/03-calling-a-factory.md is written in an unsupported language. File is not indexed.

0001 ---
0002 title: "Calling a factory"
0003 teaching: 10
0004 exercises: 1
0005 objectives:
0006 - "Learn how to wire a factory using a factory generator"
0007 - "Learn how to call the factory as a once-off"
0008 - "Learn how to call the factory every time"
0009 ---
0010 
0011 ## Wiring a factory using a factory generator
0012 
0013 Instead of handing over the OmniFactory to JANA directly, we create a `JOmniFactoryGeneratorT` which is basically a recipe that JANA uses to create factories later. There are several reasons we need this:
0014 
0015 1. JANA is designed to process events in parallel, when enabled. Factories are allowed to cache *local* state using member variables (e.g. calibrations and resources) Despite this, factories don't need to be thread-safe, because each factory is only used by one thread at a time. This means that JANA needs to spin up at least one instance of each factory for each thread. 
0016 
0017 2. We want to be able to spin up separate instances of the same factory class (within the context of a single event and thread), and give them different parameter values and collection names. The way we manage these different instances is by giving each factory instance a unique prefix which will be used to namespace its parameters, inputs, outputs, and logger. This happens at the JFactoryGenerator level.
0018 
0019 Here is how you set up a factory generator:
0020 
0021 ```c++
0022     app->Add(new JOmniFactoryGeneratorT<MC2SmearedParticle_factory>(
0023             "GeneratedParticles",
0024             {"MCParticles"},
0025             {"GeneratedParticles"},
0026             app
0027             ));
0028 ```
0029 
0030 In this example, "GeneratedParticles" is the factory instance's unique tag, `{"MCParticles"}` is the list of input collection names, and `{"GeneratedParticles"}` is the list of output collection names. Some observations:
0031 
0032 - If you are only creating one instance of this factory, feel free to use the "primary" output collection name as the factory prefix. (This has to be unique because PODIO collection names have to be unique.)
0033 
0034 - Collection names are positional, so they need to be in the same order as the `PodioInput` and `VariationalPodioInput` declarations in the factory. 
0035 
0036 - Variadic inputs are a little bit interesting: You can have any number of variadic inputs mixed in among the non-variadic inputs, as long as there are the same number of collection names for each variadic input. If this confuses you, just restrict yourself to one variadic input and put it as the very last input, like most programming languages do.
0037 
0038 - When assigning names to collections and `JOmniFactory` prefixes, uniqueness is extremely important! JANA will throw an error if it detects a naming collision, but because of the dynamic plugin loading, some collisions can't be detected. DO NOT use the same output collection name or prefix in different plugins, and DO NOT rely the plugin loading order to make sure you ran the "correct" factory! To swap out different versions of a factory, change or override the *input* collection name on the factories and processors downstream.
0039 
0040 ## Where to put factory generators
0041 
0042 Factory generators need to be added inside an `InitPlugin` for a particular plugin. If the factory generator is specific to one particular detector, it would go in that detector's plugin. Because electron reconstruction is not, the generator is set up in one of the plugins under `src/global`. Because this falls in the category of reconstruction, we put it in `src/global/reco/reco.cc`. 
0043 
0044 ## Calling the factory
0045 
0046 
0047 #### To temporarily include your factory's outputs in the output file
0048 
0049 On the command line, set the `podio:output_collections` parameter to include your collection names:
0050 
0051 ```bash
0052 eicrecon -Ppodio:output_collections=MyNewCollectionName1,MyNewCollectionName2 in.root
0053 ```
0054 
0055 #### To permanently include your factory's outputs in the output file:
0056 
0057 Add your collection name to the `output_collections` list in src/services/io/podio/JEventProcessorPODIO.cc:44
0058 ```c++
0059     std::vector<std::string> output_collections={
0060             "EventHeader",
0061             "MCParticles",
0062             "CentralTrackingRecHits",
0063             "CentralTrackSeedingResults",
0064             "CentralTrackerMeasurements",
0065             //...
0066 ```
0067 
0068 ### To temporarily use your factory's outputs as inputs to another factory
0069 
0070 ```bash
0071 eicrecon -Ptargetfactory:InputTags=MyNewCollectionName1,MyNewCollection2 in.root
0072 ```
0073 
0074 ### To permanently use your factory's outputs as inputs to another factory
0075 
0076 Change the collection name in the `OmniFactoryGeneratorT` or `JChainMultifactoryGeneratorT`:
0077 ```c++
0078     app->Add(new JOmniFactoryGeneratorT<MC2SmearedParticle_factory>(
0079             "GeneratedParticles",
0080             {"MCParticlesSmeared"},            // <== Used to be "MCParticles"
0081             {"GeneratedParticles"},
0082             app
0083             ));
0084 ```
0085 
0086 > Exercise:
0087 > - Create a JOmniFactoryGenerator for your ElectronReconstruction factory
0088 > - Give your factory's output collection a fun name
0089 > - Call your factory from the command line and verify that you see its logger output.
0090 > - Add it to the `JEventSourcePODIO::output_collections`, so that it gets called automatically.
0091 > - Experiment with multiple factory generators so you can have multiple instances of the same factory
0092 {: .challenge}
0093