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?
| Proposal | Arguments In Favor | Argument 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 data | Doesn'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)
Overview
Content Tools