You are viewing an old version of this page. View the current version.

Compare with Current View Page History

« Previous Version 19 Next »

 

Issues:

  • how will AMI elegantly handle dict/list attributes?
  • how will AMI elegantly handle complex types like the list of times/peaks from the hsd fex (or even values/times from hsd raw)?  Maybe stick to raw hsd data in AMI for now?
ProposalArguments In FavorArgument Against

Data shall be accessible with a syntax like:

det = run.Detector('xppcspad')

det.datatype.attr1.attr2.method(evt)

passing in event at lowest level means Detector object can be reused for many different events 
The object returned by the Detector constructor shall only need information from the run's configure transition (using the software/version information) and shall be tab-completable in ipython so users can explore the object.  
The object returned by Detector will have static attributes/methods (i.e. not event dependent).Simpler for users to explore and check for missing dataDoesn't reflect the dynamic nature of the data (e.g. raw data only rarely present)
"datatype" above corresponds to a detector interface class (e.g. "raw", "fex", "roi1") currently in psana/psana/detector/detectors.py. attr1/attr2 are used for the various fields supported by that data type (e.g. for an roi data-type, this might be the roi data, and the "corners" of the roi for that particular event).  
The lowest-level "method(evt)" must return None if the data is not accessible for any reason (e.g. missing detector, missing raw data, missing calibration constants). We should create a mechanism for the user to discover the reason why the data is missing.makes user code simpler to check for missing information 
"evt" is the only allowed argument for "method(evt)" and is mandatory. If a method doesn't use "evt", then it is an indication that it shouldn't be part of the Detector interface.AMI ease-of-use 
"method(evt)" shall return a fundamental type (int, float, numpy array) or a dict/list of fundamental types (e.g. for HSD chan(evt) will return a dict with key corresponding to the channel numbers). There are also more complex data not covered by these cases: e.g. xpphsd.fex.chan[0] returns a list of (times, peaks) which is a "complex type" that would need special handling in AMI.  
A psana-python detector interface class name must follow the naming convention "dettype_drpalg_major_minor_micro", e.g. (cspad_raw_2_3_42)  
If a detector interface needs a "channel number" concept, that channel number shall be a pair consisting of (segment, channel) and shall be used with the lowest-level attributes, e.g. hsd.waveforms(evt)[segment][channel]Allows multiple segments to have for example, channel 0. 

 

Area Detector Brainstorming

Jan. 29, 2019

Aug. 4, 2020 (cpo, Mikhail, Valerio)

  • det = run.Detector(det_name)
  • array = det.raw.calib(evt)
  • array = det.raw.raw(evt)
  • we will return a natural shape for the above (2D for opal, 3D for cspad/epix) and have a global-flag if we want everything to be 3D (e.g. for psocake)
  • maybe image(evt, array=array) should be an algorithm? det.raw.image(evt,array=None)? or could split det.raw.image(evt), det.raw.image(array=array)?
  • get_calib_const(det_name, timestamp or run or evt).  Mikhail suggests we should consider det.get_calib_const(timestamp or run or evt)
  • flexible number of segments (no hardwired "32" segments for a cspad).  e.g. a "full detector" may have segments 2,3,4,7,8,9.  one run may have segments 3,4,7 another run may have segments 2,3,8,9
    • calibration data must be taken and stored with all segments in the "full detector" (i.e. 2,3,4,7,8,9)
  • try to use same common-mode algorithm for all detectors (stripes/banks).  multiple passes needed for different directions. (e.g. Jungfrau and epix are currently same)
  • should we continue to use 3D arrays, or instead a list of 2D arrays because we might want to do ROIs?
    • propose we stick with 3D arrays as well
    • complicates the code for a "special case" of ROIs
    • ROIs also need the information about the "corner" of the ROI
    • maybe the ROIs are really "feature extracted" data i.e. instead det.raw.image() it's det.fex.image()
    • could have a separate det.raw.calib_rois(evt) to return the list?
  • how do we reuse the python code in the DRP which is multi-threaded C++?  cpo suggests maybe we have a python multi-process DRP.  another labor-intensive option is supporting multi-threaded C++. or write C++ and wrap with python (was complicated for the hsd, but perhaps just because we needed to avoid 1MHz malloc)
  • DRP will have to work on "segments" of a full detector (probably in units of panels)
  • No labels