Use cases may apply to both ami and psana

  • In psana, compare results using 2 different gain files.
  • When we move a detector from one experiment to another; how do we transport geometry information from one detector to another?
  • When we switch cables (in MEC) on a cspad2x2 in the middle of the night, how do you carry the geometry information with the device?
  • Need a command line tool that generates calibration data for a given run number
  • When you have 3 dark runs in a row, how do you pick the "good" one?
  • I have my calibrations, and I have a new dark run and I would like to produce calibrations. Want to associate that dark run with runs 1-10 (apply it to run 1 - 10).
  • User should be able to put in pointers to which calibration files they want to use for a certain analysis.
  • I have some default calibrations; how can I run against my own instance of calibrations where I can modify and make them different from the default one?
  • How do I get a different version of pedestals?
  • We, as an experiment came up with a better calibration; we would like to put it in the default area. Who do we approach? Do we do it ourselves? How do we do this?
  • An opposite scenario: we've just deployed some new calibrations, but it turns out they were total garbage. How do we revert to the previous state?
  • If I come up with a new gain calibration, how do other users get it without overwriting their other data in an uncontrolled way?
  • User file supersedes anything that is the default?
  • What is difference between the default and your modified stuff?
  • Scenario: Runs 40 - 50 are signal, run 51 is dark and want it to apply to previous runs (40 - 50). 53 is a dark run (good), 54 is a dark run that turns out to be bad, so we want 53 to apply to all subsequent runs, 55 - end. How do we do this?
  • There are scenarios where we would want to produce calibrations based on data from more than one run (gains, for example). Metrology also - powderings at different radii from multiple runs.
  • Need to be able to find out which calibration was used for analysis and what was the origin of the data? There should be a clear origin - this file was made from exxx-rxxx...xtc
  • When we modify default calibrations, how do we push new calibrations to the users without stepping on their analyses?
  • Need to keep a history so that we can revert to an older version.
  • Different analysis teams within a user group may be working on different things; one group might be working on alignment and another group might be working on gains. At some point you want to start crossing them, merging them.
  • What about a case where the user group is split into two groups, the first group is working on runs 1 - 50, the second on 50 - 100. What if they overlap? How do they coordinate their efforts?
  • Users should be able to export data from Online ami to directly compare to psana
  • could we develop an automatic gain calibration algorithm
  • radial integration with fitting of center, distance and offsets for powder rings would speed things up (like fit2d)

From XPP:
The mentioned aspects are features that our users never used, we do all 'manually' dark and gain, and during beamtime usually only dark.

What is probably missing is

  • a global database for all detectors, for geometry and dark and gain, and tools that provide filepath and eventually Data logically derived from timestamp.
  • Automatic behavior in ami and offline ami, that can be easy overridden by the user.

The main reasons that we never apply correction tools is that they don't necessarily do the right thing. other approaches we found necessary are e.g.

  • intensity dependent gain map determined by a known signal at different intensities
  • finding singular vectors of detector dependent fluctuations and filtering their content from the Data.
  • taking local darks e.g. 1d stripes on same 2x1 that were unexposed.

Indeed, geometry is an important aspect, especially when it comes to radial integration, angular convolution, etc, that people cares about relative position of pixels between tiles, even sometimes for the 2X2. This is very typically first thing users ask.

At XPP we do a lot of scans, so filtering, rebinding, based on other detectors or event codes, is something that is needed all the time. Very few of our users uses psana. With the one case I know, the challenging part is mainly the speed, that the analysis rate (mostly filtering and averaging) barely get to 30-50 Hz, a bit slow if you want to get any live feed back during the experiment.

  • No labels