This page includes material from PSDM space, due to that navigation on page does not work properly. To see original page go to psana - User Manual

Introduction

This document describes C++ analysis framework for LCLS and how users can make use of its features. Psana design borrows ideas from multitude of other framworks such as pyana, myana, BaBar framework, etc. It's main principles are summarized here:

• support processing of both XTC and HDF5 data format
• user code should be independent of specific data format
• should be easy to use and extend for end users
• support re-use of the existing analysis code
• common simple configuration of user analysis code

This manual is accompanied by the Psana reference Manual which describes interfaces of the classes available in Psana.

Framework Architecture

The central part of the framework is a regular pre-built application (psana) which can dynamically load one or more user analysis modules which are written in C++. The core application is responsible for the following tasks:

• loading and initializing all user modules
• loading one of the input modules to read data from XTC or HDF5
• calling appropriate methods of user modules based on the data being processed
• providing access to data as set of C++ classes
• providing other services such as histogramming to user modules

Other important components of the Psana architecture:

• user module – instance of the C++ class which inherits pre-defined Module class and defines few special methods which are called by framework
• event – special object which transparently stores all event data
• environment – special object which stores non-event data such as configuration objects or EPICS data

Analysis Job Life Cycle

Psana analysis job goes through cycles of state changes such as initialization, configuration, event processing, etc. calling methods of the user modules at every such change. This model follows closely the production activities in LCLS on-line system. DAQ system defines many types of transitions in its data-taking activity, most interesting are here:

• Configure - provides configuration data for complete setup
• BeginRun - start of data taking for one run
• BeginCalibCycle - start of the new scan, some configuration data may change at his point
• L1Accept - this is regular event containing event data from all detectors
• EndCalibCycle - end of single scan
• EndRun - end of data taking for one run
• Unconfigure - stop of all activity

Typically there will be more than one run taken with the same configuration, so there may be more than one BeginRun/EndRun transition for one Configure/Unconfigure, but a data file from single run should contain only one BeginRun/EndRun. Depending on a setup there could be one or more BeginCalibCycle/EndCalibCycle transitions in single run.

For each of the above transitions psana will call corresponding method in user modules notifying them of the possible change in the configuration or just providing event data. Following method names are defined in the user modules:

...