Versions Compared

Key

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

...

  • 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 dataMD: 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

...