Versions Compared

Old Version 12

changes.mady.by.user Christopher O'Grady

Saved on

compared with

New Version 13

changes.mady.by.user Christopher O'Grady

Saved on

Key

  • This line was added.
  • This line was removed.
  • Formatting was changed.

...

  • 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?how do the low-level attributes get access to config/calib? (later: I think by passing them in from _instantiate_det_xface in Event.py)
One (small) additional user-interface layer will exist: det = Detector('xppcspad'), where det will return evt.xppcspad. This will not be used by AMI.
ProposalArguments In FavorArgument Against

Data shall be accessible with a syntax like

evt.xppcspad.

:

det = run.Detector('xppcspad')

det.datatype.attr1.attr2

allows for easy tab-completion exploration of the contents of an event 

.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 attr1 above is the "data type" (e.g. raw data only rarely present)
"datatype" above , roi1, roi2). each "data type" corresponds to a detector interface class (e.g. "raw", "fex", "roi1") currently in psana/psana/detector/detectors.py. attr1/attr2 is 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).  
All attributes must exist on every event, with the The lowest-level attribute returning "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 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 informationcomputationally 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 attributesease-of-use in AMIartificial constraint on use of python. perhaps we have to do, for example, det.image(unassembled)? perhaps AMI could ignore functions.
All attributes should be discoverable on the Configure transition using the software/version information ease-of-use in AMI 
 
"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 Attributes will be automatically attached to each event by psana ease-of-use 
"method(evt)enables definition of detector names outside event loops The preferred lowest level attribute would be " shall return 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 generalfor 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.