Page History

...

For quick example suppose that we have this class defined in user module:

# user analysis class
class myana(object):
    def __init__(self, name, lower, upper, bins=100)
        self.name = name
        self.lower = float(lower)
        self.upper = float(upper)
        self.bins = int(bins)
    ...

and this job configuration file:

[pyana]
modules = mypackage.myana mypackage.myana:wide

[mypackage.myana]
lower = 0
upper = 100
name = default

[mypackage.myana:wide]
lower = 0
upper = 1000
bins = 1000
name = wide

With this the analysis job will instantiate two analysis objects with different parameters, equivalent to this pseudo-code:

# import class myana
from mypackage.myana import myana

# create instances
instances = [ myana(lower = "0", upper = "100", name = "default"),
    myana(lower = "0", upper = "1000", bins = "1000", name = "wide") ]

...

Core Options

...

By default the core application options are read from {{\[pyana\]}} section of the configuration file. If the option {{\-C}} {{{_}name{_}}} or {{\--config-name=}}{{{}{_}name{_}}} is given on the command line then additional section {{\[pyana.}}{{{}{_}name{_}{}}}{{\]\}} is read and values in that section override values from {{\[pyana\]}} section.

Here is the list of all command line and configuration file options availabale currently:

Short	Long	Config File	Option type	Default	Description
-v	--verbose	verbose	integer	0	Command line options do not need any values but can be repeated multiple times, configuration file option accepts single integer number.
-c file	--config=file		path	pyana.cfg	Name of the configuration file.
-C name	--config-name=name		string	<ac:structured-macro ac:name="unmigrated-wiki-markup" ac:schema-version="1" ac:macro-id="5c0a7fd1-2feb-421b-9b0b-86af72cf8693"><ac:plain-text-body><![CDATA[	-C name	--config-name=name		string		If non-empty string is given then configuration will be read from section [pyana.name] in addition to [pyana]. ]]></ac:plain-text-body></ac:structured-macro>
-l file	--file-list=file	files	path		The list of input data files will be read form a given file which must contain one file name per line.
-n number	--num-events=number	num-events	integer	0	Maximum number of events to process, this counter will include damaged events too.
-s number	--skip-events=number	skip-events	integer	0	number of events to skip
-j name	--job-name=name	job-name	string		Sets job name which is accessible to user code via environment method. Default name is based on the input file names.
-m name	--module=name	modules	string		User analysis module(s). Command line options can be repeated several times, configuration file option accepts space-separated list of names.
-p number	--num-cpu=number	num-cpu	integer	1	Number of processes to run, if greater than 1 then multi-processing mode will be used.

Anchor
UserModuleOptions UserModuleOptions

User Module Options

...

For every user module the configuration file may contain one or more configuration sections. The section header for the user module has format {{\[module\]}} or {{\[module:}}{{{}{_}name{_}{}}}{{\]}}. When defining the user modules either with {{\--module}} command line option or {{modules}} configuration file option one can optionally qualify the module name with a colon followed by arbitrary single-word string. Without this optional qualification the framework will load the user module and will use the options from {{\[module\]}} section to initialize the instance of the analysis class (as explained in [Initialization|#Initialization] section). If, on the other hand, the qualified name is used then the framework will initialize the instance with the options combined from the sections {{\the sections [module\]}} and {{\[module:}}{{{}{_}name{_}{}}}{{\]}} with the latter section overriding the values from the former section. One could use several qualified forms of the same module name to produce several instances of the analysis class in the same job with different options.

Here is an almost identical example from Initialization section above which illustrates the inheritance and overriding of the user options:

none

Code Block
none title pyana.cfg borderStyle solid none
[pyana] modules = mypackage.myana mypackage.myana:wide [mypackage.myana] lower = 0 upper = 100 name = default [mypackage.myana:wide] ; 'lower' option will be reused from [mypackage.myana] section bins = 1000 ; this overrides default module value ; two options below will override [mypackage.myana] values upper = 1000 name = wide

...

Here is a brief example of booking and filling of few histograms in user module:

Code Block
none none title mypackage/src/myana.py borderStyle solid none
# user analysis class class myana(object): def beginjob(self, event, env): # get histogram manager hmgr = env.hmgr() # book histograms, store references self.hist1 = hmgr.h1d('energy', 'Energy Distribution', 100, 0., 1.) self.hist2 = hmgr.h2d('energy vs something', 'Histo2 title', 100, 0., 1., 100, -20., 20.) def event(self, event, env): # fill histograms energy = ... something = ... self.hist1.Fill(energy) self.hist2.Fill(energy, something)

...

Here is very brief example of using SciPy for integration of experimental data:

Code Block
none none title mypackage/src/myana.py borderStyle solid none
from scipy import integrate class myana(object): def event(self, event, env): # Get Acqiris waveform object ddesc = evt.getAcqValue( "AmoITof", channel, env ) wf = ddesc.waveform() ts = ddesc.timestamps() # integrate it using Simpson's rule integral = integrate.simps (wf, ts)

...