AnalysisExample.fcl

Go to the documentation of this file.

# A script to run an analysis module: AnalysisExample. You may want to
# compare this script with ${LARSIM_DIR}/job/prodsingle.fcl; in
# particular, in this script there are no output streams because the
# module doesn't write any events, just histograms or n-tuples.

# See <https://cdcvs.fnal.gov/redmine/projects/larsoft/wiki/_Running_Jobs_> 
# for more information on the structure of .fcl files. 

# The following line has to be changed to match your experiment; e.g.,
# "services_dune.fcl", "services_lariat.fcl". I'm using microboone
# solely because, as a MicroBooNE collaborator, it's easier for me to
# test this script to make sure it works.

# Note that the following line loads many more services than we're
# going to use in this example. If we're clever enough, and we worked
# through the nested layers of fcl scripts, we could only include
# those services that we actually use, which would save some time and
# memory. For this example I'm going for simplicity (but scroll to the
# bottom of this script to see the price of simplicity).

#include "services_microboone_simulation.fcl"

process_name: AnalysisExample

services:
{
  # Load the service that manages root files for histograms.
  # Any histograms or n-tuples that you create in the program will be
  # written to this file. You can override the file name with the -T
  # option on the command line; e.g.,
  #  lar -c AnalysisExample.fcl -T myhistograms.root -s myinput.root

  TFileService:           { fileName: "AnalysisExample.root" }

  # This constrols the display in the output of how long each job step
  # takes for each event. A lot of configuration can be added: details at
  # https://cdcvs.fnal.gov/redmine/projects/art/wiki/TimeTracker#TimeTracker

  TimeTracker:            {}

  # This parameter controls the level of descriptive output from
  # various LArSoft modules. For a list of different message levels,
  # see ${LARDATA_DIR}/job/messageservice.fcl. For most jobs this is
  # set to standard_warning; here it is set to standard_info because I
  # write some LogInfo messages in the analysis module for
  # demonstration purposes.

  # Note that if you set this to standard_debug (to see the LOG_DEBUG
  # messages in the analysis module) the job's messages will not
  # appear on screen. They're written to a debug.log file instead.

  message:                @local::standard_info

  # This following line defines many default LArSoft resources for
  # this job. It's more than we'll need, but it's easier to include
  # all of them than to pick and choose. We want "simulation" services
  # because the example module accesses LArG4Parameters.
  @table::microboone_simulation_services

} # services

>>>>>>> origin/feature/seligman_uptodateAnalysisExample
# The 'source' section tells the script to expect an input file with art::Event records.
# Note that the name of the input file is not included here. You specify that on the
# command line when you run this script; e.g.,
#    lar -c AnalysisExample.fcl -s myinput.root
# The file "myinput.root" is assumed to have been created by a previous LArSoft job.

source:
{
  module_type: RootInput

  # Number of events to analyze; "-1" means all of the events in the input
  # file. You can override this value with the "-n" option on the command line. 
  maxEvents:  -1 

  # I've commented this out, but if you want to include the name of
  # an art::Event input file in a script, here's how you do it.
  # fileNames: ["myinput.root"]
}

# This is empty, because we're not writing an output file with
# art::Event objects.
outputs:{}

# The 'physics' section defines and configures some modules to do work
# on each event.  First modules are defined; they are scheduled
# later. Modules are grouped by type.
physics:
{
  # Define the variables we'll need to read for this analysis program.
  analyzers:
  {
    # This name defines a job step below, and will appear as a directory 
    # in the output histogram file. 
    AnalysisExample: 
    {
      # The "module_type" tells us which module to run. The name here
      # must match the name supplied to DEFINE_ART_MODULE near the end
      # of AnalysisExample_module.cc.

      module_type:     "AnalysisExample"

      # The input parameters for our AnalysisExample module. Compare
      # the names you see here with the "struct Config" in
      # AnalysisExample_module.cxx. You will want to add/remove/rename
      # the example parameters below to suit your task.

      # If you are reading any objects created by the standard
      # simulation scripts, then don't change the value of this
      # parameter. This is the name of the 'producer' that ran the
      # simulation module in a previous job. An example of a job file
      # that runs the simulation is ${LARSIM_DIR}/job/prodsingle.fcl;
      # look for "largeant:". It's unlikely that anyone would change
      # the name of this producer.

      SimulationLabel: "largeant"

      # Hits can be created by more than one module in
      # ${LARRECO_DIR}/source/larreco/HitFinder. For this example, I
      # picked the one that's usually run first.

      HitLabel:        "gaushit"

      # The same for clusters:

      ClusterLabel:    "trajcluster"

      # In this example, which primary particle(s) we'll focus on in an event.
      # PDG code 13 = mu-.
      PDGcode:          13

      # dx used for the dE/dx calculation; units are cm. 
      BinSize:          0.3
    }
  }

  # Schedule job step(s) for execution by defining the analysis module
  # for this job. An 'analysis' module (as opposed to a 'producer' or
  # a 'filter') does not alter the contents of events in the input
  # file, nor does it create any events as output. Any step names
  # listed here must match a name in the 'analyzers' section above.

  analysis: [ AnalysisExample ]

  # "end_paths" is a keyword and contains the modules that do not modify the art::Event;
  # i.e., analyzers and output streams.

  end_paths: [ analysis ]
}

# In order to work with the reconstructed objects I use in
# AnalysisExample, I found I needed to add the following lines. For
# more details, see
# <https://cdcvs.fnal.gov/redmine/projects/uboonecode/wiki/Guide_to_Using_FCL_files_in_MicroBooNE>
# Note that this is a MicroBooNE-only requirement; your experiment may
# need different adjustments to handle the difference between
# simulation and reconstruction waveform times.

services.DetectorClocksService.InheritClockConfig: false
services.DetectorClocksService.TriggerOffsetTPC: -400
services.DetectorPropertiesService.NumberTimeSamples: 6400
services.DetectorPropertiesService.ReadOutWindowSize: 6400