Overview: Difference between revisions

From cctbx_xfel
Jump to navigation Jump to search
No edit summary
 
(7 intermediate revisions by the same user not shown)
Line 1: Line 1:
LCLS provides several frameworks for data analysis, and also provides methods for translating collected data to HDF5, a general and portable container format for storage of large amounts of numerical data''cctbx.xfel'' extends the LCLS analysis packages with a set of analysis modules.  In particular, the ''cctbx.xfel'' analysis modules are run through ''pyana'', the Python-implementation of LCLS's analysis framework.  Since analysis proceeds directly from the raw data, no intermediate conversion is necessary, and it can be done while an experiment is running.
Data collection and processing using LCLS involves recording data from an X-ray detector (Jungfrau, Rayonix, CSPAD, etc.) in XTC format, reading the data using ''DIALS'' libraries that wrap the LCLS-provided library ''psana'', processing on either the SLAC Shared Science Data Facility (S3DF) or NERSC, and coordinating the processing using ''cctbx.xfel'' itself.  Since analysis proceeds directly from the raw data, no intermediate conversion is necessary, and it can be done while an experiment is running.


''cctbx.xfel'' at LCLS is built on five systems: the CSPAD detector, pyana, LCLS’s queuing system, phil, and fundamentally, cctbx.
== The X-ray detector ==
[[File:750.png|200px|thumb|right|Example CSPAD image]]
The LCLS at full capacity operates at 120 Hz.  The incident photon packets are delivered in ≈40 femtosecond wide pulses, each containing ≈10<sup>12</sup> photons.  This high repetition rate and compact beam delivery time necessitated the construction of a new detector [http://www-public.slac.stanford.edu/sciDoc/docMeta.aspx?slacPubNumber=SLAC-PUB-15284 Hart, P The Cornell-SLAC Pixel Array Detector at LCLS. <i>SLAC Scientific Documents</i> (2012).], where the work of reading out and streaming recorded data at these high speeds is accomplished through the use of 64 sensors, arranged in a quadrangular pattern around a central hole (in the place of a beam stop).  Each of the 4 quadrants, containing 16 of the sensors, was adjustable on rails radially away from the central hole to adjust the size of this hole.


== The CSPAD detector ==
The CSPAD was replaced with two detectors: the Rayonix [https://www.rayonix.com/product/mx340-xfel/ MX340-XFEL] (recently retired), and the [https://pmc.ncbi.nlm.nih.gov/articles/PMC7044001/ Jungfrau 16M] (in current use).
[[File:750.png|200px|thumb|right|Example CSPAD image]]
The LCLS at full capacity operates at 120 Hz.  The incident photon packets are delivered in ≈40 femtosecond wide pulses, each containing ≈10<sup>12</sup> photons.  This high repetition rate and compact beam delivery time necessitated the construction of a new detector<ref>[http://www-public.slac.stanford.edu/sciDoc/docMeta.aspx?slacPubNumber=SLAC-PUB-15284 Hart, P The Cornell-SLAC Pixel Array Detector at LCLS. <i>SLAC Scientific Documents</i> (2012).]</ref>, where the work of reading out and streaming recorded data at these high speeds is accomplished through the use of 64 sensors, arranged in a quadrangular pattern around a central hole (in the place of a beam stop).  Each of the 4 quadrants, containing 16 of the sensors, is adjustable on rails radially away from the central hole to adjust the size of this hole.  Indexing, predicting spot locations using a crystal orientation matrix, and integrating reflection intensities requires precise knowledge of the location of these sensors in three-dimensional space.  For this reason, a portion of this tutorial describes the calibration and refinement of the tile metrology.


Indexing, predicting spot locations using a crystal orientation matrix, and integrating reflection intensities requires precise knowledge of the location of the sensors in these detectors in three-dimensional space.  For this reason, a portion of this wiki describes the calibration and refinement of the tile metrology.


== ''psana'' ==
== ''psana'' ==


The LCLS data acquisition systems stream the terabytes of diffraction data collected from the CSPAD detector to container files in XTC format.  XTC is a linear, sequential-access file format, where individual images can be recorded rapidly by the file system as they are collected.  The programmatic interface to interact with these files at LCLS is ''psana'', a C++/Python-based interface.
The LCLS data acquisition systems stream the terabytes of diffraction data collected from the X-ray detector to container files in XTC format.  XTC is a linear, sequential-access file format, where individual images can be recorded rapidly by the file system as they are collected.  The programmatic interface to interact with these files at LCLS is ''psana'', a C++/Python-based interface.
 
''cctbx.xfel'' wraps access to XTC using small, custom text files called locators, bypassing the need for users to work with ''psana'' directly.  For example, the ''DIALS'' image viewer can be used to view images using a command like this:
 
  dials.image_viewer run100.loc load_models=False


''psana'' is driven by configuration files to process frames individually, and is designed with computational parallelization in mind.  As each image is independent, processing of each image can be done by separate computer cores.  ''cctbx.xfel'' uses ''psana'' and ''psana'''s configuration files to read and process image files stored in XTC format.  The user specifies how each image is to be processed in the configuration file, and the passes the configuration file and the path to the XTC streams of interest to ''cctbx.xfel'', which calls ''psana'' and submits the job to the queuing system.
Where <code>run100.loc</code> looks like this


For example, if the user wanted to filter an XTC stream for hits, index the hits and then integrate images which successfully indexed, the user would supply a configuration file which specified ''cctbx.xfel'' modules that did these tasks, provide options to these modules, and submit the job.  Specific details are in the tutorials.
  experiment=mfx0000000
  run=100
  detector=rayonix


During processing, hits are extracted from the XTC stream and written to separate files for each individual imageAt the moment these separate files are in a in a Python-programming language friendly format called pickle format. However, by the end of 2014, ''cctbx.xfel'' will be exclusively using CBF and HDF5 formats to output results.
And the parameter <code>load_models=False</code> makes reading and display the data fasterFurther details about the detector or experiment can be provided in the locator.
 
Note that the ''cctbx.xfel'' GUI provides convenient ways to specify the parameters need to the user needs not create these locator files directly.


More information about psana: [https://confluence.slac.stanford.edu/display/PSDM/psana+-+Python+Script+Analysis+Manual]
''psana'' itself is designed with computational parallelization in mind.  As each image is independent, processing of each image can be done by separate computer cores.  [https://en.wikipedia.org/wiki/Message_Passing_Interface MPI] is required, which is configured automatically in LCLS/psana/cctbx builds.


== LCLS queuing system ==
More information about psana: [https://pswww.slac.stanford.edu/swdoc/releases/ana-current/psana-ref/html/psana/]


SLAC maintains several computing clusters available to its users for processing data.  While detailed knowledge of their workings isn't required for ''cctbx.xfel'' operation, an overview of these systems is provided here: [https://confluence.slac.stanford.edu/display/PCDS/Computing].  Specific commands for submitting ''cctbx.xfel'' jobs to the cluster are given in the tutorials.
== S3DF ==


General instructions for submitting batch jobs can be found here: [https://confluence.slac.stanford.edu/display/PCDS/Submitting+Batch+Jobs].  Of note are these commands:
SLAC provides access to the [https://isdci.slac.stanford.edu/initiative-areas/s3df SLAC Shared Science Data Facility (S3DF)].  There are several pools of computers available:
* bsub: used to submit jobs to the queuing system
* bjobs: used to list the jobs being run by the current user
* bkill: used to stop a job that is running


All of these commands have extensive man pages available at LCLS.
* <code>s3dflogin</code>: login nodes, not used for processing or computation.  Reach these using <code>ssh -YAC <username>@s3dflogin.slac.stanford.edu</code>
* <code>psana</code>: not to be confused with the ''psana'' library, these are used for small computation/compilation and for running graphical programs.
* <code>s3dfnx</code>: NoMachine gateway, use the full address <code>s3dfnx.slac.stanford.edu</code> with NoMachine for faster graphical displays.
* Queues: generally users should use the <code>milano</code> queue for routine processing.
 
Queing is done using [https://slurm.schedmd.com/overview.html slurm].  Of note are these commands:
* <code>sbatch</code>: used to submit jobs to the queuing system
* <code>squeue -u <username></code>: used to list the jobs being run by the current user
* <code>scancel</code>: used to stop a job that is running


== ''Phil'' ==
== ''Phil'' ==


While ''psana'' is configured using its own configuration files, ''cctbx.xfel'' itself is driven using Python-based hierarchical interchange language (''phil'') files, the same format that drives Labelit and ''PHENIX'' (though ''PHENIX'' calls them .eff files).  The format is intuitive and allows easy specification of per-processing run parameters.
''cctbx.xfel'' provides a GUI but the programs it wraps are driven using Python-based hierarchical interchange language (''phil'') files, the same format that drives ''DIALS'' and ''PHENIX'' (though ''PHENIX'' calls them .eff files).  The format is intuitive and allows easy specification of per-processing run parameters.


A user's ''psana'' configuration file will have an entry called xfel_target.  This entry will provide a phil filename that contains ''cctbx.xfel'' configuration settings.  These settings will include thing such as thresholds for determining hits (number of spots on an image, spot brightness cutoff, etc.), unit cell targets for indexing, resolution cutoffs, and so forth.
''cctbx.xfel'' collects processing parameters using its GUI, then when submitting jobs it writes these configuration settings to a phil file.  These settings will include things such as thresholds for determining hits (number of spots on an image, spot brightness cutoff, etc.), unit cell targets for indexing, resolution cutoffs, and so forth.


Technical information regarding ''phil'': [http://cctbx.sourceforge.net/libtbx_phil.html]
Technical information regarding ''phil'': [https://cci.lbl.gov/docs/cctbx/doc_low_phil/]


Specific ''phil'' files used in this tutorial: ''[[phil]]''
Specific ''phil'' files used in this tutorial: ''[[phil]]''
Line 47: Line 61:
Introduction: [http://cctbx.sourceforge.net/current/]
Introduction: [http://cctbx.sourceforge.net/current/]
Homepage: [http://cctbx.sourceforge.net/]
Homepage: [http://cctbx.sourceforge.net/]
== References ==
<references/>

Latest revision as of 22:41, 18 August 2026

Data collection and processing using LCLS involves recording data from an X-ray detector (Jungfrau, Rayonix, CSPAD, etc.) in XTC format, reading the data using DIALS libraries that wrap the LCLS-provided library psana, processing on either the SLAC Shared Science Data Facility (S3DF) or NERSC, and coordinating the processing using cctbx.xfel itself. Since analysis proceeds directly from the raw data, no intermediate conversion is necessary, and it can be done while an experiment is running.

The X-ray detector

Example CSPAD image

The LCLS at full capacity operates at 120 Hz. The incident photon packets are delivered in ≈40 femtosecond wide pulses, each containing ≈1012 photons. This high repetition rate and compact beam delivery time necessitated the construction of a new detector Hart, P The Cornell-SLAC Pixel Array Detector at LCLS. SLAC Scientific Documents (2012)., where the work of reading out and streaming recorded data at these high speeds is accomplished through the use of 64 sensors, arranged in a quadrangular pattern around a central hole (in the place of a beam stop). Each of the 4 quadrants, containing 16 of the sensors, was adjustable on rails radially away from the central hole to adjust the size of this hole.

The CSPAD was replaced with two detectors: the Rayonix MX340-XFEL (recently retired), and the Jungfrau 16M (in current use).

Indexing, predicting spot locations using a crystal orientation matrix, and integrating reflection intensities requires precise knowledge of the location of the sensors in these detectors in three-dimensional space. For this reason, a portion of this wiki describes the calibration and refinement of the tile metrology.

psana

The LCLS data acquisition systems stream the terabytes of diffraction data collected from the X-ray detector to container files in XTC format. XTC is a linear, sequential-access file format, where individual images can be recorded rapidly by the file system as they are collected. The programmatic interface to interact with these files at LCLS is psana, a C++/Python-based interface.

cctbx.xfel wraps access to XTC using small, custom text files called locators, bypassing the need for users to work with psana directly. For example, the DIALS image viewer can be used to view images using a command like this:

 dials.image_viewer run100.loc load_models=False

Where run100.loc looks like this

 experiment=mfx0000000
 run=100
 detector=rayonix

And the parameter load_models=False makes reading and display the data faster. Further details about the detector or experiment can be provided in the locator.

Note that the cctbx.xfel GUI provides convenient ways to specify the parameters need to the user needs not create these locator files directly.

psana itself is designed with computational parallelization in mind. As each image is independent, processing of each image can be done by separate computer cores. MPI is required, which is configured automatically in LCLS/psana/cctbx builds.

More information about psana: [1]

S3DF

SLAC provides access to the SLAC Shared Science Data Facility (S3DF). There are several pools of computers available:

  • s3dflogin: login nodes, not used for processing or computation. Reach these using ssh -YAC <username>@s3dflogin.slac.stanford.edu
  • psana: not to be confused with the psana library, these are used for small computation/compilation and for running graphical programs.
  • s3dfnx: NoMachine gateway, use the full address s3dfnx.slac.stanford.edu with NoMachine for faster graphical displays.
  • Queues: generally users should use the milano queue for routine processing.

Queing is done using slurm. Of note are these commands:

  • sbatch: used to submit jobs to the queuing system
  • squeue -u <username>: used to list the jobs being run by the current user
  • scancel: used to stop a job that is running

Phil

cctbx.xfel provides a GUI but the programs it wraps are driven using Python-based hierarchical interchange language (phil) files, the same format that drives DIALS and PHENIX (though PHENIX calls them .eff files). The format is intuitive and allows easy specification of per-processing run parameters.

cctbx.xfel collects processing parameters using its GUI, then when submitting jobs it writes these configuration settings to a phil file. These settings will include things such as thresholds for determining hits (number of spots on an image, spot brightness cutoff, etc.), unit cell targets for indexing, resolution cutoffs, and so forth.

Technical information regarding phil: [2]

Specific phil files used in this tutorial: phil

cctbx

The computational crystallographic toolbox is a foundational set of python and C++ modules that allow abstraction of the crystallographic experiment. Under continual development, the toolbox provides interfaces for working with crystal models, reflection data, and much more.

Introduction: [3] Homepage: [4]