Meeting with XPP 2023

Diling, Vincent, Mona, Valerio, Takahiro, Stefano, Cong, Chris

...

• 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 angular integration
      • Vincent writes about the reason for this: The diffuse scattering signal generally does not have cylindrical symmetry, so azimuthal integration is not appropriate for it
      • Diling writes about the reason for this:  Right, the pie slice was an example I raised for Tim’s liquid scattering analysis, generally does not apply to material science.
    • 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)
  • another option: angular integration ("pie slices") (wasn't preferred by XPP scientists? Silke is surprised they didn't like this approach, maybe depends on physics?)
  • 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 for "speckle visibility spectroscopy"
  • "speckles" 
  • low-intensity XPCS where droplets (synonymous with peak-finding?) are used
  • 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
  • need to "count photons" within each peak (which pixels have which photons)
    • this could be done as a second step offline?
    • could be done as one step in Cong's neural net ("hydranet")
  • Yanwen writes: "an example will be run 622, experiment xppx49520. most runs in xppx49520 are usable."
  • Analysis code appears to be here: /cds/data/psdm/xpp/xppx49520/scratch/ffb/smalldata_tools/
• 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

Analysis Meeting

Dec. 18, 2023

Yanwen, Vincent, Valerio, Cong, Stefano, Fred, cpo

To learn how to run the analysis scripts

Meeting with Diling 2021

Nov. 12, 2021 and Nov. 18, 2021

...