Page History
...
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 | |
Unlike LCLS1, the Detector interface should be used only to access per-event data, not per-run data like calibration constants | Cleaner separation of classes | Need to implement separate interface for calibration access that also takes detector name as its principal argument |
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. |
Implementation (Schematic)
In psana, the detector interface is constructed roughly like the following:
Code Block | ||
---|---|---|
| ||
class Container:
def __init__(self):
pass
det = Container()
class mybase(DetectorImpl):
def calib(self):
return mikhails_calib_works_with_both_rois_and_daq(self.raw())
class epix10k_daq_0_0_1(mybase):
def __init__(self):
super().__init__()
class epix10k_rois_0_0_1(mybase):
def __init__(self):
super().__init__()
setattr(det,'daq',epix10k_daq_0_0_1())
setattr(det,'rois',epix10k_rois_0_0_1())
det.daq.calib()
det.rois.calib() |
Scans and Epics
See this page for some Detector Interface behavior: Raw Data Python Interface
...
Overview
Content Tools