...

• have an option to create detector object directly, outside run
  det = Detector(detname)
  advantage
  • OO design: object detector physically exists without run
  • reduce redundant dependences
  • have an option to work with info from calibration db - pixel geometry, imaging of constans like pedestals, gains, masks, pixel_status.
• eliminate forks for duplication of code in 
  data = det.raw.raw(evt)
  data = det.fex.raw(evt)
  replace it with det.raw(evt)
  The same is valid for det.calib() and det.image()

2020-09-08 Proposal for Geometry from Valerio

• 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 (!!!)

  • 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)

      • Documentation could be more accessible

• 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

  • 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

  • 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

  • All this can be accomplished with wrappers, without breakage

  • I volunteer to do that, of course