LCLS off-line provides two frameworks for analysis of the LCLS data – pyana which is a Python-based framework; and psana which is based on C++. Pyana was developed during the first year of LCLS running with the intention to experiment with the several different approaches for data access and analysis. Pyana supports data reading from XTC files only. Psana was built later based on the experience obtained while experimenting with pyana. Currently psana can read data from XTC files but it will be extended to support HDF5 data too. In the future pyana framework may be reimplemented based on psana framework.

Framework in general can be an overloaded term, but in the context of our off-line system it is a set of components and libraries with the few distinctive features:

  • control flow in analysis application is dictated by the framework and not by user code (framework calls user methods),
  • framework can be easily extended by providing new modules which implement specific interface,
  • users do not need to modify framework code, but user modules are allowed to customize framework behavior to a limited extent.

Analysis framework is a pre-built application which is responsible for:

  • loading one or many user modules,
  • opening data files (XTC or HDF5) and iterate over events in the data files,
  • reading event data and represent event data in some internal format,
  • calling user modules on every event and provide access to event data,
  • providing access to other services and libraries that user modules might need to do their job.

User module is the main customization point for the framework. User module is a component (such as Python or C++ class) which defines specific methods called by framework and implements useful behavior (analysis) in those methods. The set of methods that user module may need to provide depends on a particular framework.

LCLS off-line frameworks are build for processing of LCLS data and their control flow and customization points are determined by the organization of the data itself. Typical framework job can process data from one or more runs, and one run can contain one or more scans ("calib cycles" in LCLS DAQ jargon). To perform analysis user modules need information not only for individual events but also for runs and scans (e.g. to collect per-run or per-scan statistics). Frameworks provide notifications to user modules about all these events through a set of methods:

  • begin job/end job – methods called at the begin and end of the whole analysis job
  • begin run/end run – methods called at the begin and end of every run in a job
  • begin scan/end scan – methods called at the begin and end of every scan in a run
  • event – method called on every new event

User modules do not need to implement all these methods, methods have default implementation (except event method) which does nothing.

More framework-specific details appear in the following sections.

  • No labels