...

• 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

Implementation (Schematic)

...

class Container:
    def __init__(self):
        pass

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__()

det = Container()
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 Also see this page for some Detector Interface behavior: Raw Data Python Interface

For Epics variables we need two names: the complex epics variables name (e.g. HX2:DVD:GCC:01:PMON) and a simple user alias e.g. STAGE_POSITION.  Mona currently allows variables in the epics-store to have illegal python names (i.e. with ":" in them).  This is different than other detector names.

Proposal:

• the DAQ reads epixArch.txt.  it can use either the epics name or the alias as the detname in xtc2.  This keeps things "natural" in xtc2, where each detector has one and only one user name.  
• the DAQ optionally stores an extra epics_info object in the configure transition.  this single object would contain ancillary information about each epics variable, e.g.
  • the full epics name
  • the alias name (defaults to the full name if not specified in epicsArch.txt)
  • description of the epics variable
• the epics_info object would have its own Detector interface
• the epics_info object (and Detector interface) could expand over time, presumably in a backwardly-compatible way by using the usual middle-version-number increment pattern
• for PvaDetector Ric uses a user-specified detName, and the full epics name is not persisted in the data.  But in the future it could be persisted using the above epics_info mechanism.
• in epicsArch right now, Ric/Matt now use the epics variable name (was "value" previously) and ignores the alias.  Ideally this would change to use the Alias if it existed in epicsArch.txt.
• right now Ric passes the alias as the .cnf "id" (e.g. tmomanta_0).
  • probably needs a command-line argument to support both an andor/manta in one pva
• we should try to make the DetType more generic (not "manta" but maybe "pv")
• all PvaDetectors in one segment level (e.g. andor/manta) need to be in the same readout group
  • not certain about this.  ask Matt.  maybe we could have one segment sign up for multiple lanes, each on a different readout group?
  • in control_gui have to assign one segment level to a readout group.  is this cast in stone, or can it be changed?
• PvaDetector two options for supporting multiple pv's within one segment level:
  • all epics variables (e.g. manta, Andor) within one PvaDetector.  if so:
    
    • if a detector is missing on a particular shot we should throw out all
  • (preferred) each epics variable has its own detector (similar to raw/fex) e.g. tmomanta/tmoandor (probably both have DataType "raw")
    • this could tolerate individual missing detectors

Area Detector Brainstorming (AreaDetector)

...

• Geometry package for psana: psgeom or PSCalib

  • psgeom:
    • Pros:

      • Clean and modern interface

      • Clean and nice coding style

    • Cons:

      • No single true internal geometry representation

      • Main mantainer not working at LCLS (!!!)

      • Comments from MD:
        • duplication of psana geometry code for panels and entire detector - wrong design, for conversion purpose it should inherit from psana geometry, not substitute it.
        • as a result, it does not normally support hierarchal description of sub-detectors, always needs to be updated for new panel geometry which is done much earlier in psana (example epix10ka, jungfrau).
        • there is no guarantee that converter works correctly (multiple issues in the past) because it uses internal engine for pixel geometry which might be different from original psana.
  • PSCalib.GeometryAccess:
    • Based on the content of this page Detector Geometry

    • Pros:

      • True internal representation of the geometry

      • Better integration with the rest of psana

      • Maintained and developed at LCLS (!!!)

    • Cons:

      • Interface is often not very Pythonic (example: vebosity bits) - MD: outdated comment - for lcls2 geometry is changed significantly

      • Documentation could be more accessible - MD: could be, in-line documentation is available and work in psana1, please provide documentation processor for lcls2.

• Proposal: I propose that we make PSCalib the default geometry package for psana

• Geometry Interface improvement proposals (Work in progress):

  • Expose the bit flags in various functions as Python bool flags - NOTE: maybe already fixed in LCLS2. MD: it is matter of style. I like compact and clean style. In critical places of user interface like det.mask we provide methods with explicit specification of parameters.

  • Do not require parameters that are not strictly needed (for clarity) Example: det.daq.image(evt,array=None) could be det.daq.image(evt) or det.daq.image(array), either with two separate functions or with different behavior depending on the input data. MD: lcls2 method det.daq.image(evt,array=None) does not exist yet. In psana(1) det.image(evt,array=None) evt needs to be passed along with array.

  • Use more descriptive names for some parameters. Examples: oname, oindex, vbase, etc.

  • Make documentation more accessible (use one of the standard for docstrings?) - NOTE: maybe already fixed in LCLS2. MD: please first provide documentation processor for lcls2. 

  • All this can be accomplished with wrappers, without breakage. MD: what is exact purpose for wrapper?

  • I volunteer to do that, of course

...