Project

General

Profile

exercises » History » Version 24

Eric Church, 02/08/2014 11:02 PM

1 7 Eric Church
h1.  LArSoft Exercises
2 1 Eric Church
3 16 Eric Church
{{>toc}}
4 16 Eric Church
5 5 Eric Church
h2. Run a simple lar job to create mu-'s of momentum 1.5 GeV/c from a point source.
6 1 Eric Church
7 7 Eric Church
We will create a file containing events that each have a single muon using the code in a public place. That means you will not need to build any code at this stage. So, go to your test release, that is your working directory. You made this in the guide. Set yourself up to run there with an appropriate mrb working directory, which we call @lgm@ here. All this is explained at  https://cdcvs.fnal.gov/redmine/projects/uboonecode/wiki/Uboone_guide. In this first exercise you are going to run from fcl files and .so libraries -- files that form the heart of the framework -- that live in the official places. You will setup to run against uboonecode nightly (or v1_00_02, say) and against larsoft nightly (or v1_00_02). Namely, you are not using your own code. So, let's first show the setup, which we urge you perform via an alias, like the following. Have a line like the below line starting @alias@ in your ~/.bashrc. (Use an alias and hand-execute the alias each login; *do not execute this stuff in your shell-initiated start up scripts* like ~/.profile or ~/.bashrc.)
8 7 Eric Church
9 5 Eric Church
<pre>
10 6 Eric Church
<uboonegpvm02.fnal.gov> alias ulgmr='source /grid/fermiapp/uboone/software/setup_uboone.sh; cd /uboone/app/users/username/lgm/build; setup uboonecode nightly -qe4:prof; source mrb slp;'  # a potential setup alias
11 6 Eric Church
<uboonegpvm02.fnal.gov> ulgmr # actually execute the commands in the alias
12 5 Eric Church
</pre>
13 4 Eric Church
14 5 Eric Church
And now, run the executable on this canned fcl job script file.
15 4 Eric Church
<pre>
16 1 Eric Church
lar -c prodsingle_uboone.fcl
17 1 Eric Church
</pre>
18 4 Eric Church
19 5 Eric Church
This fcl file will produce 5 muons through the set of modules SingleGen, LArG4, and DetSim. That's pretty cool. But where did it find prodsingle_uboone.fcl? How do I know it will run 5 events? 
20 19 Eric Church
The answer comes from looking at our job script fcl file. We find our fcl files from sleuthing in directories whose names we know from the key environment variable $FHICL_FILE_PATH.
21 1 Eric Church
22 5 Eric Church
<pre>
23 1 Eric Church
<uboonegpvm02.fnal.gov> echo $FHICL_FILE_PATH 
24 1 Eric Church
.:./job:/grid/fermiapp/uboone/software/products/uboonecode/nightly/job:.:./job:/grid/fermiapp/products/larsoft/larpandora/nightly/job:/grid/fermiapp/products/larsoft/larana/nightly/job:/grid/fermiapp/products/larsoft/larreco/nightly/job:/grid/fermiapp/products/larsoft/larexamples/nightly/job:/grid/fermiapp/products/larsoft/lareventdisplay/nightly/job:/grid/fermiapp/products/larsoft/larsim/nightly/job:/grid/fermiapp/products/larsoft/larevt/nightly/job:/grid/fermiapp/products/larsoft/lardata/nightly/job:/grid/fermiapp/products/larsoft/nutools/v1_01_05/fcl:/grid/fermiapp/products/larsoft/larcore/nightly/job:/grid/fermiapp/products/larsoft/art/v1_08_10/fcl
25 5 Eric Church
<uboonegpvm02.fnal.gov> more /grid/fermiapp/uboone/software/products/uboonecode/nightly/job/prodsingle_uboone.fcl 
26 1 Eric Church
</pre>
27 1 Eric Church
28 20 Eric Church
The job starts each event with a clean slate as indicated by the EmptyEvent key word. If you're running a job with recon modules in it only, EmptyEvent instead says RootInput, as you'll be sucking up an already-written root file in a previous job. Note that in prodsingle_uboone.fcl maxEvents is 5.  Note the output root file full of histograms (that we declared and filled in the source code) is specified to be at @single_hist_uboone.root@ and the output ART root file (which serves as the one that we'll pass onto any further modules in subsequent @lar@ jobs) is to be called @single_gen_uboone.root@. Note, that these did indeed appear in your directory! 
29 1 Eric Church
30 7 Eric Church
How did I make 1.5GeV/c muons and not, say, Higgsinos? The answer comes from drilling down into the included fcl files. From the job script we note that for the generator we need the fcl parameter set called @microboone_singlep@. fcl parameter sets are in fcl files in the same places as the job script fcl files: at all possible directories in $FHICL_SEARCH_PATH. So, let's search 
31 1 Eric Church
32 6 Eric Church
@<uboonegpvm02.fnal.gov> grep microboone_singlep  /grid/fermiapp/uboone/software/products/uboonecode/nightly/job/* @
33 21 Eric Church
@<uboonegpvm02.fnal.gov> grep microboone_singlep  /grid/fermiapp/products/larsoft/lar*/nightly/job/* @
34 7 Eric Church
The relevant return line is from the second effort: @/grid/fermiapp/products/larsoft/larsim/nightly/job/singles.fcl:microboone_singlep: @local::standard_singlep@. That's the only place where microboone_singlep appears on the left hand side of a colon, and that's where the parameter set is defined. Although, what we've learned is that this parameter set is equated to @standard_singlep@, which we must now hunt down, in turn. Note that the return from the greps shows us that after defining microboone_singlep to be standard_singlep, we then proceed to over-write some parameters like X0 and Z0, meaning we force the particles to be generated from a particular point in the TPC. We will return to this idea. We grep the lar* job areas again for singlep and discover the motherlode at @/grid/fermiapp/products/larsoft/larsim/nightly/job/singles.fcl@, which upon investigation shows the full single particle parameter set, including  the line @PDG: [13]@. Hence, we have generated mu-s.
35 6 Eric Church
36 24 Eric Church
h2. Reconstruct your muons
37 1 Eric Church
38 24 Eric Church
lar -c standard_reco_uboone.fcl -s single_gen_uboone.root
39 24 Eric Church
40 24 Eric Church
Note that this fcl script is magically just found in some other job/ directory. Also, note it uses a rather bland series of reconstruction modules: calwire, which you absolutely must perform, then ffthitfinder, then dbcluster.
41 24 Eric Church
42 24 Eric Church
What would it take to make this fcl script use gaushitfinder (sic) and fuzzycluster instead of ffthitfinder and dbcluster? What would be required to make it also create spacepoints and run track3dkalmansps on those spacepoints? We leave that as an exercise to the reader. (A suggested starting point is to just copy down this fcl script to some local area and edit it, as before with prodsingle_uboone.fcl.)
43 24 Eric Church
44 24 Eric Church
h2. Change the mu-'s to K+'s of lower momentum, originating throughout the TPC.
45 1 Eric Church
46 7 Eric Church
Here we want to still use canned code: stuff from the nightly's or the vX_YY_ZZ's.
47 1 Eric Church
48 7 Eric Church
But we have to get ahold of the prodsingle_uboone.fcl to alter a couple parameters to do what we want to do in this exercise. For now, let's just grab a copy and put it in our local area and use that. (We know this will work, cuz the very first item in $FHICL_SEARCH_PATH is "."). So, in your working area go @cp /grid/fermiapp/uboone/software/products/uboonecode/nightly/job/prodsingle_uboone.fcl .@
49 7 Eric Church
50 14 Eric Church
We'll show it here, as we'll refer to it a lot.
51 13 Eric Church
52 13 Eric Church
<pre>
53 13 Eric Church
#include "services.fcl"
54 13 Eric Church
#include "singles.fcl"
55 13 Eric Church
#include "largeantmodules.fcl"
56 13 Eric Church
#include "detsimmodules.fcl"
57 13 Eric Church
#include "mccheatermodules.fcl"
58 13 Eric Church
59 13 Eric Church
process_name: SinglesGen
60 13 Eric Church
61 13 Eric Church
services:
62 13 Eric Church
{
63 13 Eric Church
  # Load the service that manages root files for histograms.
64 13 Eric Church
  TFileService: { fileName: "single_hist_uboone.root" }
65 13 Eric Church
  Timing:       {}
66 13 Eric Church
  RandomNumberGenerator: {} #ART native random number generator
67 13 Eric Church
  user:         @local::microboone_simulation_services
68 13 Eric Church
}
69 13 Eric Church
70 13 Eric Church
71 13 Eric Church
#Start each new event with an empty event.
72 13 Eric Church
source:
73 13 Eric Church
{
74 13 Eric Church
  module_type: EmptyEvent
75 13 Eric Church
  maxEvents:   5        # Number of events to create
76 13 Eric Church
  firstRun:    1           # Run number to use for this file
77 13 Eric Church
  firstEvent:  1           # number of first event in the file
78 13 Eric Church
}
79 13 Eric Church
80 13 Eric Church
# Define and configure some modules to do work on each event.
81 13 Eric Church
# First modules are defined; they are scheduled later.
82 13 Eric Church
# Modules are grouped by type.
83 13 Eric Church
physics:
84 13 Eric Church
{
85 13 Eric Church
86 13 Eric Church
 producers:
87 13 Eric Church
 {
88 13 Eric Church
   generator: @local::microboone_singlep	  
89 13 Eric Church
   largeant:  @local::microboone_largeant	  
90 13 Eric Church
   daq:       @local::microboone_simwire  
91 13 Eric Church
   backtrack: @local::standard_backtrackerloader
92 13 Eric Church
 }
93 13 Eric Church
94 13 Eric Church
 analyzers:
95 13 Eric Church
 {
96 13 Eric Church
   largana:   @local::microboone_largeantana
97 13 Eric Church
 }
98 13 Eric Church
99 13 Eric Church
 #define the producer and filter modules for this path, order matters, 
100 13 Eric Church
 #filters reject all following items.  see lines starting physics.producers below
101 13 Eric Church
 simulate: [ generator, largeant, daq, backtrack ] 
102 13 Eric Church
 analyzeIt:  [ largana ]
103 13 Eric Church
 #define the output stream, there could be more than one if using filters 
104 13 Eric Church
 stream1:  [ out1 ]
105 13 Eric Church
106 13 Eric Church
 #trigger_paths is a keyword and contains the paths that modify the art::event, 
107 13 Eric Church
 #ie filters and producers
108 13 Eric Church
 trigger_paths: [simulate] 
109 13 Eric Church
110 13 Eric Church
 #end_paths is a keyword and contains the paths that do not modify the art::Event, 
111 13 Eric Church
 #ie analyzers and output streams.  these all run simultaneously
112 13 Eric Church
 end_paths:     [analyzeIt, stream1]  
113 13 Eric Church
}
114 13 Eric Church
115 13 Eric Church
#block to define where the output goes.  if you defined a filter in the physics
116 13 Eric Church
#block and put it in the trigger_paths then you need to put a SelectEvents: {SelectEvents: [XXX]}
117 13 Eric Church
#entry in the output stream you want those to go to, where XXX is the label of the filter module(s)
118 13 Eric Church
outputs:
119 13 Eric Church
{
120 13 Eric Church
 out1:
121 13 Eric Church
 {
122 13 Eric Church
   module_type: RootOutput
123 13 Eric Church
   fileName:    "single_gen_uboone.root" #default file name, can override from command line with -o or --output
124 13 Eric Church
 }
125 13 Eric Church
}
126 13 Eric Church
127 13 Eric Church
physics.producers.generator.SigmaThetaXZ: [ 5.0 ]
128 13 Eric Church
physics.producers.generator.SigmaThetaYZ: [ 5.0 ]
129 13 Eric Church
physics.producers.generator.X0: [ 100.0 ]
130 13 Eric Church
physics.producers.generator.Z0: [ 50.0 ]
131 13 Eric Church
physics.producers.generator.P0: [ 1.5 ]
132 13 Eric Church
133 13 Eric Church
</pre>
134 13 Eric Church
135 11 Eric Church
Remembering that we can overwrite parameters at this stage,  and that the generator module lives in the producers clause of the physics parameter set, open an editor on your new copy of prodsingle_uboone.fcl and put these lines at the bottom in order to run 0.2 GeV/c K+s generated throughout the TPC, and not 1.5 GeV/c mu-s from a fixed point:
136 7 Eric Church
137 7 Eric Church
<pre> 
138 7 Eric Church
physics.producers.generator.PDG: [321] # K+ 
139 7 Eric Church
physics.producers.generator.P0: [ 0.2 ]
140 7 Eric Church
physics.producers.generator.SigmaX: [ 125.0 ] # width of Gaussian distribution, in cm
141 7 Eric Church
physics.producers.generator.SigmaY: [ 125.0 ]
142 7 Eric Church
physics.producers.generator.SigmaZ: [ 500.0 ]
143 7 Eric Church
</pre>
144 7 Eric Church
145 22 Eric Church
Parameters in brackets are vectors. If instead we say 
146 7 Eric Church
147 12 Eric Church
<pre> physics.producers.generator.PDG: [321, 13, 22, 2112] # K+, mu-, gamma, n 
148 1 Eric Church
</pre>
149 1 Eric Church
150 8 Eric Church
we'll choose randomly (flat distribution) to generate any of those 4 particle types. However, if we do that, we should now go overwrite every possible parameter in that set, as inherited from standard_singlep and make sure all of them are 4-elements long.
151 1 Eric Church
152 8 Eric Church
Let's note one more thing we have done with our canned code. We have run the module we label @largana@ in prodsingle_microboone.fcl. It is an analyzer, meaning it puts nothing on the event. This is in contrast with the producers which _do_ put persistent data onto the event. largana runs after all the producers. The key word @trigger_paths@ runs the producers, which you'll note are all captured in the @simulate@ array of modules, and the key word @end_paths@ holds the analyzers (held in @analyzeIt@) and the output.  We remind you that you will always run producers or analyzers or filters in your fcl scripts. 
153 1 Eric Church
154 8 Eric Church
If we go open the output @single_hist_uboone.root@ file we'll find a directory corresponding to largana, in which its histograms and a TTree reside.
155 8 Eric Church
<pre>
156 8 Eric Church
root [0] TFile f("single_hist_uboone.root")
157 8 Eric Church
root [1] TDirectoryFile* l = f->Get("largana")
158 8 Eric Church
root [2] l->cd()
159 8 Eric Church
root [3] MCTTree->Show(0)
160 8 Eric Church
======> EVENT:0
161 8 Eric Church
 MCEvt           = 1
162 8 Eric Church
 MCSub           = 0
163 8 Eric Church
 MCRun           = 1
164 8 Eric Church
...
165 8 Eric Church
</pre>
166 8 Eric Church
167 11 Eric Church
The natural question that follows might be Do these module labels, @generator, largeant, daq@, etc, mean anything? In fact, they don't mean anything per se, but they do mean something in a relative sense. The data from one producer module might well be used in subsequent modules. And thus, among the parameter set information for a producer is generally a label, or series of labels, that specifies which previous modules are needed from which the current module will get data. Those labels then are the names of the previously-run modules _from this or a previous job_. So, yes, those module labels generally have meaning down the line. 
168 1 Eric Church
169 17 Eric Church
h3. Let us urge at this point that you go chase the @daq@ module's parameter set  @microboone_simwire@. 
170 18 Eric Church
171 1 Eric Church
*  Note that each module's parameter set, first and foremost, gives a @module_type@ field, which is the name of the @*_module.cc@ file that holds the producer/analyzer class whose main produce()/analyze() method is run each event-- finally, we make contact with the C++! 
172 17 Eric Church
*  Note also the @DriftEModuleLabel@ field. You'll find that this is @largeant@, by default. That means the daq module needs the data from @largeant@, which it happens is exactly the module that runs before it in our prodsingle_uboone.fcl. If we'd called that module @largeeeeeant@ in prodsingle_uboone.fcl instead, we'd need to overwrite the module name expected by @daq@, which is done by tacking on physics.producers.daq.DriftEModuleLabel: "@largeeeeeant@" at the bottom.
173 17 Eric Church
* Go try rerunning prodsingle_uboone.fcl, changing producer module names and, simultaneously, the expected module labels by downstream modules
174 10 Eric Church
175 10 Eric Church
h2. Edit the module that captures the truth information into histograms and TTree branches.
176 8 Eric Church
177 15 Eric Church
Alright, we've gone as far as we can with the canned code. We need to edit some C++ now. We used above the module we labeled @largana@. That module is, after some exploration, LArG4Ana_module.cc.
178 15 Eric Church
179 15 Eric Church
So, we need to grab that up. How does that work? Well, it's not MicroBooNE specific code, so it's not in uboonecode. That means it's in one of the lar* repositories. I am not so savvy with the O(10) lar* repositories as to know immediately where that is. My approach is to @ls -lt /grid/fermiapp/products/larsoft/lar*/nightly/source/*/LArG4Ana*@. We learn it's in larsim. We no longer want the nightly version. We want our own version. So, go now to https://cdcvs.fnal.gov/redmine/projects/uboonecode/wiki/Uboone_guide and remind yourself how you git clone a repository into your srcs directory.
180 15 Eric Church
181 23 Eric Church
Once you have larsim, go to @srcs/larsim/LArG4/LArG4Ana_module.cc@ and open it in an editor. Note the TTree and Histograms. Add a branch, remove a histogram, whatever. For sure, for piece of mind and if you do nothing else, add a line like @std::cout << "This is my code!!" << std::endl;@ Now, from the guide, go build, install and setup against your installed version. Run your prodsingle_uboone.fcl again.
182 15 Eric Church
183 15 Eric Church
Look for your message that shows you you've really run your code! Open the output hist*.root file in ROOT and look for your changed histograms and TTrees.