Page History
...
User analysis class can define zero or more parameters in its constructor (__init__() method). Parameters are initialized from the values defined in the job configuration file (see below). All parameters are passed to the Python code as strings, if the code expects a number or some other type then it's the code responsibility to convert the strings to appropriate type. If there are no default values defined for some parameters in constructor declaration then those parameters must be present in the configuration file.
...
"AmoETof-0|Acqiris-0"– selects data produced by detector AmoETof, detId 0, device Acqiris, devId 0"AmoETof|Acqiris"– selects data produced by detector AmoETof, any detId, device Acqiris, any devId"AmoETof-*|Acqiris-*"– same as above"AmoETof-0"– selects data produced by detector AmoETof, detId 0, any device, any devId"|Acqiris-0"– selects data produced by any detector, any detId, device Acqiris, devId 0"*-*|Acqiris-0"– same as above
...
| Wiki Markup |
|---|
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. |
...
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. | ||
<ac:structured-macro ac:name="unmigrated-wiki-markup" ac:schema-version="1" ac:macro-id="971c68e9534bf042-9a735d75-40de490a-8cfab479-09ecea11929f24ad2d866b7e"><ac:plain-text-body><![CDATA[ | -C name | --config-name=name |
| string |
| If non-empty string is given then configuration will be read from section | ]]></ac:plain-text-body></ac:structured-macro> |
-l file | --file-list=file | file-list | 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. |
...
| Wiki Markup |
|---|
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 {{\[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:
...
For other types of the data it would be a user responsibility to store it in some location and then do manual merging after the job is finished.
| Anchor | ||||
|---|---|---|---|---|
|
Writing User Modules
Preferred way to run user analysis code is to create a separate package for each user and store all user modules in src directory in that package. If you plan to commit you code to repository then the package name must be unique and probably include your user name (or experiment name). To create an empty package run this command (it implies that analysis environment has been set):
...
Overview
Content Tools