Page History
...
| Proposal | Arguments In Favor | Argument Against |
|---|---|---|
| Data shall be accessible with a syntax like evt.xppcspad.attr1.attr2 | allows for easy tab-completion exploration of the contents of an event | |
| attr1 above is the "data type" (e.g. raw, roi1, roi2). each "data type" corresponds to a detector interface class, currently in psana/psana/detector/detectors.py. attr2 is used for the various fields supported by that data type (e.g. the roi data, and the "corners" of the roi for that particular event). | ||
| All attributes must exist on every event, with the lowest-level attribute returning None if the data is not accessible for any reason (e.g. missing detector, missing raw data, missing calibration constants) | makes user code simpler to check for missing information | computationally expensive to add all attributes when data is not present |
| No functions allowed. Configurable parameters (e.g. common-mode params) will be set with other attributes | ease-of-use in AMI | artificial constraint on use of python |
| All attributes should be discoverable on the Configure transition using the software/version information | ease-of-use in AMI | |
| Attributes will be automatically attached to each event by psana | ease-of-use | |
| One (small) additional user-interface layer will exist: det = Detector('xppcspad'), where det(evt) will return evt.xppcspad. This will not be used by AMI. | enables definition of detector names outside event loops | |
| The preferred lowest level attribute would be a fundamental type (int, float, numpy array) or a dict/list of fundamental types (e.g. xpphsd.chan[3]). For the HSD detector it will be a dict, since only a subset of channels will be active, in general. 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. |
Overview
Content Tools