CodeArtFclTutorial: Difference between revisions
(Created page with "* existing releases * so's * command line * print and validate * modifying fcl Category:Computing Category:Tutorial") |
No edit summary |
||
(5 intermediate revisions by one other user not shown) | |||
Line 1: | Line 1: | ||
<font size=+2 color=red>Warning - this page is out of date, needs to be updated for Muse</font> | |||
==Introduction== | |||
In the case of [[DetectorIntro|Mu2e]], an [[Computing Concepts#art_Events| event]] | |||
records the detector response during one proton pulse, consisting of a short burst of millions of protons hitting the production target, thousands of muons stopping in the aluminum stopping target, and those muons interacting or decaying. This happens nominally every 1695 ns and each of these burst forms and event. | |||
When we read and process these events we will need a framework to organize our executables, and way to control the behavior of the executable, and a format to write the events into. These functions are provided by the ''art''' software package. | |||
==Art== | |||
The art package provides: | |||
* executable framework | |||
* the event format | |||
* a control language called "fcl" (pronounced fickle) | |||
* services such as random numbers | |||
===Framework=== | |||
The art format (developed at Fermilab) is a highly-structured format which contains the events, processing history, and other items. Under the covers, art uses the [https://root.cern.ch/root/ root] package (used widely in HEP) to read and write the files. You can see this: | |||
<pre> | |||
> file /pnfs/mu2e/tape/phy-sim/sim/mu2e/DS-beam/MDC2018a/art/ff/f7/sim.mu2e.DS-beam.MDC2018a.001002_00373598.art | |||
/pnfs/mu2e/tape/phy-sim/sim/mu2e/DS-beam/MDC2018a/art/ff/f7/sim.mu2e.DS-beam.MDC2018a.001002_00373598.art: ROOT file Version 61204 (Compression: 7) | |||
</pre> | |||
You will also notice the file has a name that ends in ".art". We try to use a small set of well-defined [[FileNames|file types]]. | |||
When we write code, typically to simulate the detector, reconstruct the data, or analyze the data, we write our code in '''modules'''. We then run the framework, and tell it to call our module. We also tell it what input files to use, if any. The framework opens the input files, reads data, calls our module with the data, event by event, and then handles any filtering of events, and writing output. | |||
In a fresh window, setup an Offline release, | |||
source /cvmfs/mu2e.opensciencegrid.org/setupmu2e-art.sh | |||
source /cvmfs/mu2e.opensciencegrid.org/Offline/v7_4_1/SLF6/prof/Offline/setup.sh | |||
==Code== | |||
Any module we write is compiled into a shared object library which is loaded by the framework on demand. For example, | |||
ls -l $MU2E_BASE_RELEASE/TrkHitReco/src/StrawHitReco_module.cc | |||
is compied into | |||
ls -l $MU2E_BASE_RELEASE/lib/libmu2e_TrkHitReco_StrawHitReco_module.so | |||
which we can then ask the framework to run (or not). | |||
Just as a quick peak, open the cc file: | |||
emacs $MU2E_BASE_RELEASE/TrkHitReco/src/StrawHitReco_module.cc | |||
Find the line | |||
class StrawHitReco : public art::EDProducer | |||
Since the module inherits from a framework base class, the framework can manipulate it. | |||
Find the line | |||
StrawHitReco::beginJob | |||
this moethod is called once at the beginning of the job. Similarly | |||
StrawHitReco::beginRun | |||
is called when the input events change run number. | |||
StrawHitReco::produce | |||
is called for every event. It is called "produce" because it typically produces date to insert in the event, in this case, the reconstructed tracker hits. | |||
Find the line | |||
event.getValidHandle(_sdtoken) | |||
this is retrieving the raw hits from the event. All of this will be covered in more detail later. | |||
==Fcl== | |||
Since all modules are available to the framework as shared objects, we have to tell the framework which modules to run. We also need the capability to configure the modules, for example, to set thresholds for what makes a good hit. This executable configuration handled by the fcl language. | |||
Take look at a simple fcl file: | |||
emacs $MU2E_BASE_RELEASE/Validation/fcl/ceSimReco.fcl | |||
which generates events with a conversion electron. | |||
Find the process_name line: | |||
process_name : ceSimReco | |||
this is important because any output from his executable run will be labeled by a string, to help track the data's processing history. | |||
Find the services | |||
services : { | |||
@table::service.all | |||
} | |||
This defines a set of standard services, such as geometry or random numbers (the "@table" says just use standard stuff defined in the includes). | |||
The next part | |||
physics : { | |||
producers: { | |||
.... | |||
defines what modules to configure and what that configuration is. Again all the "@" is saying use stuff defined in the includes. You can [[FclIntro#.40local_and_.40table|read more about it]]. | |||
Let trace back one example. The line: | |||
@table::digis.straw.mod | |||
is defined in | |||
$MU2E_BASE_RELEASE/Validation/fcl/prolog.fcl | |||
many subdirectories have a prolog.fcl which defines useful shortcuts for other fcl files to include. Note that fcl code in the prolog file is between BEGIN_PROLOG and END_PROLOG. This tells fcl that the | |||
code is only defining things that will be used later. | |||
The Valdation prolog includes | |||
$MU2E_BASE_RELEASE/fcl/standardProducers.fcl | |||
Find the line | |||
@table::TrackerMC.producers | |||
You can see it is enclosed in brackets labeled by the strings digis, straw and mod in the top level file. Thisis what allows it to be defined The TrackerMC table is defined in | |||
$MU2E_BASE_RELEASE/fcl/standardProducers.fcl | |||
which includes | |||
$MU2E_BASE_RELEASE/fcl/TrackerMC/fcl/prolog.fcl | |||
which finally defines the module configuration. starting with this line: | |||
*********************** | |||
where is the code (do not run git yet tho), intro to releases, cvmfs, run genReco, set output file names and Nevents | |||
intro to fcl, paths and filters. maybe a couple of tutorials? | |||
* existing releases | * existing releases | ||
* so's | * so's |
Latest revision as of 16:30, 3 October 2023
Warning - this page is out of date, needs to be updated for Muse
Introduction
In the case of Mu2e, an event records the detector response during one proton pulse, consisting of a short burst of millions of protons hitting the production target, thousands of muons stopping in the aluminum stopping target, and those muons interacting or decaying. This happens nominally every 1695 ns and each of these burst forms and event.
When we read and process these events we will need a framework to organize our executables, and way to control the behavior of the executable, and a format to write the events into. These functions are provided by the art' software package.
Art
The art package provides:
- executable framework
- the event format
- a control language called "fcl" (pronounced fickle)
- services such as random numbers
Framework
The art format (developed at Fermilab) is a highly-structured format which contains the events, processing history, and other items. Under the covers, art uses the root package (used widely in HEP) to read and write the files. You can see this:
> file /pnfs/mu2e/tape/phy-sim/sim/mu2e/DS-beam/MDC2018a/art/ff/f7/sim.mu2e.DS-beam.MDC2018a.001002_00373598.art /pnfs/mu2e/tape/phy-sim/sim/mu2e/DS-beam/MDC2018a/art/ff/f7/sim.mu2e.DS-beam.MDC2018a.001002_00373598.art: ROOT file Version 61204 (Compression: 7)
You will also notice the file has a name that ends in ".art". We try to use a small set of well-defined file types.
When we write code, typically to simulate the detector, reconstruct the data, or analyze the data, we write our code in modules. We then run the framework, and tell it to call our module. We also tell it what input files to use, if any. The framework opens the input files, reads data, calls our module with the data, event by event, and then handles any filtering of events, and writing output.
In a fresh window, setup an Offline release,
source /cvmfs/mu2e.opensciencegrid.org/setupmu2e-art.sh source /cvmfs/mu2e.opensciencegrid.org/Offline/v7_4_1/SLF6/prof/Offline/setup.sh
Code
Any module we write is compiled into a shared object library which is loaded by the framework on demand. For example,
ls -l $MU2E_BASE_RELEASE/TrkHitReco/src/StrawHitReco_module.cc
is compied into
ls -l $MU2E_BASE_RELEASE/lib/libmu2e_TrkHitReco_StrawHitReco_module.so
which we can then ask the framework to run (or not).
Just as a quick peak, open the cc file:
emacs $MU2E_BASE_RELEASE/TrkHitReco/src/StrawHitReco_module.cc
Find the line
class StrawHitReco : public art::EDProducer
Since the module inherits from a framework base class, the framework can manipulate it.
Find the line
StrawHitReco::beginJob
this moethod is called once at the beginning of the job. Similarly
StrawHitReco::beginRun
is called when the input events change run number.
StrawHitReco::produce
is called for every event. It is called "produce" because it typically produces date to insert in the event, in this case, the reconstructed tracker hits.
Find the line
event.getValidHandle(_sdtoken)
this is retrieving the raw hits from the event. All of this will be covered in more detail later.
Fcl
Since all modules are available to the framework as shared objects, we have to tell the framework which modules to run. We also need the capability to configure the modules, for example, to set thresholds for what makes a good hit. This executable configuration handled by the fcl language.
Take look at a simple fcl file:
emacs $MU2E_BASE_RELEASE/Validation/fcl/ceSimReco.fcl
which generates events with a conversion electron.
Find the process_name line:
process_name : ceSimReco
this is important because any output from his executable run will be labeled by a string, to help track the data's processing history.
Find the services
services : { @table::service.all }
This defines a set of standard services, such as geometry or random numbers (the "@table" says just use standard stuff defined in the includes).
The next part
physics : { producers: { ....
defines what modules to configure and what that configuration is. Again all the "@" is saying use stuff defined in the includes. You can read more about it.
Let trace back one example. The line:
@table::digis.straw.mod
is defined in
$MU2E_BASE_RELEASE/Validation/fcl/prolog.fcl
many subdirectories have a prolog.fcl which defines useful shortcuts for other fcl files to include. Note that fcl code in the prolog file is between BEGIN_PROLOG and END_PROLOG. This tells fcl that the code is only defining things that will be used later.
The Valdation prolog includes $MU2E_BASE_RELEASE/fcl/standardProducers.fcl Find the line
@table::TrackerMC.producers
You can see it is enclosed in brackets labeled by the strings digis, straw and mod in the top level file. Thisis what allows it to be defined The TrackerMC table is defined in
$MU2E_BASE_RELEASE/fcl/standardProducers.fcl which includes $MU2E_BASE_RELEASE/fcl/TrackerMC/fcl/prolog.fcl
which finally defines the module configuration. starting with this line:
where is the code (do not run git yet tho), intro to releases, cvmfs, run genReco, set output file names and Nevents intro to fcl, paths and filters. maybe a couple of tutorials?
- existing releases
- so's
- command line
- print and validate
- modifying fcl