Page History
...
- 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)
- risky: time-calibration and filtering, I0 (can be done in many different ways) can be error prone
- 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
...
Overview
Content Tools