Page History
...
Methods beginrun()
, endrun()
, begincalibcycle()
, and endcalibcycle()
are optional, analysis module does not have to define them and they are called only if defined. Anchor
Event Loop Control
Code in user modules can control framework event loop by returning a value from event()
method which is different from None
(if there is no return statement in the method it is equivalent to returning None
). Following values are recognized by framework:
pyana.Skip
This will skipevent()
all downstream modulespyana.Stop
This will stop event loop, allend*()
methods are called as usualpyana.Terminate
This will cause immediate job termination,end*()
methods are not called
Two methods evt.put
and evt.get
allow to transfer data between different modules.
- Save new object in event:
evt.put( object, object_name )
– this method is called when any newly evaluated
object
needs to be saved in theevt
store. To access this object from other module it needs to be associated with uniqueobject_name
– string parameter.
- Retrieve object from event:
object = evt.get( oobject_name )
– this method is called whenobject
needs to be retrieved form theevt
store.
Anchor | ||||
---|---|---|---|---|
|
Event Loop Control
Code in user modules can control framework event loop by returning a value from event()
method which is different from None
(if there is no return statement in the method it is equivalent to returning None
). Following values are recognized by framework:
pyana.Skip
This will skipevent()
all downstream modulespyana.Stop
This will stop event loop, allend*()
methods are called as usualpyana.Terminate
This will cause immediate job termination,end*()
methods are not called
Values pyana.Stop
Values pyana.Stop
and pyana.Terminate
only work in single-process mode, in multi-process they are ignored with warning message issued if user module tries to use them.
...
Code Block |
---|
# import is necessary to use return codes import pyana class ExampleModule(object): def event(self, evt, env): ... if pixelsAboveThreshold < 1000: # This event is not worth looking at, skip it return pyana.Skip if self.nGoodEvents > 1000: // we collected enough data, can stop now and go to endjob() return pyana.Stop if temperatureKelvin < 0: # data is junk, stop right here and don't call endJob() return pyana.Terminate and don't call endJob() return pyana.Terminate |
Anchor | ||||
---|---|---|---|---|
|
Exception Handling
Pyana does not do anything special to handle exceptions which happen in user modules, main reason for this is that it is not safe in general to continue after unknown exception was raised. If user code knows which exception can be raised and is prepared to handle those exception then corresponding code should be added to the user module.
If user module generates an exception and does not handle it the whole job is terminated immediately. In single-process mode the standard traceback will printed by the interpreter and you should see clearly the reason and location of the exception. In multi-process mode (see #Multi-processing) the job will still fail but failure will look more complex. The original exception will cause termination of only a single worker process, the standard traceback for that exception will be printed as usual. The termination of one worker process will cause communication failure inside the main process which will terminate immediately with error message (Broken pipe). This in turn will cause exceptional failures of other worker processes which will print their own tracebacks. So instead of one single traceback for an exception there will be more than one error message appearing in the output.
Anchor | ||||
---|---|---|---|---|
|
...
Anchor | ||||
---|---|---|---|---|
|
Core Options
By default the core application options are read from {{\ Wiki Markup [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\]}} 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. |
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="810f63d8-08da-418a-a7dc-8e6c4c12d93b"><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 | 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 | ||||
---|---|---|---|---|
|
User Module Options
...
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 {{\[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 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 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:
...