Versions Compared

Key

  • This line was added.
  • This line was removed.
  • Formatting was changed.

...

  • time-resolved diffraction
    • signal concentrated in smaller area (like Bragg spots but can be a cluster: spots with satellites.  200x200 or 400x400 pixels, ROI is fixed)
    • look at time-evolution
    • can be a single pixel as a function of time
    • user interested in time-evolution of every pixel in ROI.
    • each event has delay time, delay correction, and I0, beam-position, beam-intensity, and other per-shot machine parameters (ebeam and gasdet BLD)
    • 400x400 ROI would be 8GB per second.
    • readout all detector just so we don't damage the detector, but could throw away data after viewing
    • save whole detector at low rate for determining ROI and then only save ROI at high rates
  • time-resolved diffuse scattering (evolution of radial integration over time)
    • need the whole image
    • currently do cube
      • risky: time-calibration and filtering, I0 (can be done in many different ways) can be error prone 
        • currently XPP gets this right "the first time" (after initial setup)
        • Diling and Vincent are confident that we can make the cube work "the first time" (after tuning)
          • need online visualization (AMI-style)
      • can't afford to do radial integration
      • I0 from wave8 or hsd or another area detector
        • DON'T normalize shot-to-shot
        • hypercube: image, I0, time-bins, electric-field bins (voltage, e.g. with wave8) and others (aim for 10000 total bins)
      • All this happens at 25kHz (not 1MHz)
    • less risky: angular integration ("pie slices")
    • 4Mpx*1000=16GB (float32 data type)
    • binning: need the piranha time tool calibrated edge, and need coarse timing per shot: delay-stage encoder
      • hope you could use same solution as RIX: interpolated absolute encoder (100Hz) or axilon MHz relative encoder (renishaw?)
    • to get error bars may need to store a second cube with image-sum-of-squares for each time-bin (also integrated over shots)
  • peakfinding
    • talk to Yanwen/Vincent to get a high-occupancy XPP/XCS dataset (a low-intensity XPCS where droplets are used).
    • eventually using sparkpix photon-assignment: either 0 (throw away) or photon locations
      • getting I,j,value from sparkpix
      • need to tune sparkpix "thresholds" first
    • occupancy is 1% or less, implies 2GB/s with 4Mpx 25kHz sparkpix
    • can be done with epixUHR or sparkpix, so we need software photon-finding for epixUHR
      • photon finding: threshold, find droplet
  • auto-correlation (XPCS within image)
    • save an ROI after an auto-correlation (i.e. calibrated image)
    • low priority
    • sparse images
    • complexity: no single computer sees the whole detector.  a big problem
      • need to try libSZ or peak finding?
    • could do it at high intensity

...