...

High Rate Mono Encoder Interpolation Options

Goal: keep the parallelization happy (both ami and mpi-psana) so that every shot has an encoder value (either real or interpolated)

• ~5kHz of measured data is roughly the maximum readout rate
• interpolation will make the data better

Example motor motion:

Image Modified

Options:

• DAQ interpolation.  Ugly DAQ C++, may want to change later.  Works for AMI
  • "freezes" the interpolation to what is done at DAQ time: but doesn't preclude someone going back and doing a better analysis later
  • what if what we think is noise is actually real vibration of the mono grating.  in that case interpolation loses important information.  one would test this by doing the analysis both with the raw data and with "smoothed" data to see which yields better physics resolution
• only send events with measurements to AMI? requires a ric-style python script to select AMI events
  • limits statistics in AMI.  in principle could get 5kHz.
  • in future could avoid limited-statistics issue by going to 1MHz relative encoder
  • cpo worry: we already need such a script for RIX to send the andor events to AMI.  two issues:
    • that script becomes more complex trying to do two things
    • cpo thinks: if the (rare) andor events don't have an encoder value it will make the analysis (or ami display) tricky.  would need to have "trigger overlap"
• (doesn't work for real-time analysis like ami) psana interpolation in-memory
  • on SMD0 core (would dramatically complicate our most complicated psana event-builder code)
  • psana "broadcasts" all the encoder data to all the cores.  quite messy and would affect performance unless SlowUpdate broadcast at 10Hz was feasible
• psana post(doesn't work for real-time analysis like ami) psana pre-processing interpolation written to a new xtc2 file
  • could also analyze the shape above and write out very little information (10 numbers?): regions 1 (flat),2(sloped),3(flat),4(sloped),5(flat). 
• (doesn't work because of chaos caused by batching, deadtime, arbitrary number of cores, load-balancing) DAQ repeats without interpolation.
  • Ideally xtc2 would be able to say 3 (repeats 5 times) 7 (repeats 5 times).  xtc2 can't say this easily.
  • (preferred) or another version would be 3(deltatime=0),3(+deltatime),3(+deltatime),3,3,7,7,7,7,7,.... each core could do it's own interpolation.  provides flexibility and scalability.  extra data volume isn't too bad.  will make user code more complex (they will have to "buffer")
  • Chris Ford's thought on this "debinning":  Encoder Debinning