Page History

...

• 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
• (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
• (too complex) treat the encoder as an integrating detector
  • won't work with ami which doesn't use Mona's batching
  • creates a lot of constraints with other integrating detectors:  their trigger rates have to be multiples of each other with no phase difference.

Toy Example of DAQ Interpolation Option

...