...

• proposal 1: (geometry file does not change when binning changes)
  • geometry "file" in the database represents the location of the detector and the beam center, and does not include any binning information
  • Detector interface should combine the detector configuration ("seg_configs") and the geometry "file" to  produce binning-dependent (or any other configuration dependent) geometry information.
    • having the information in the seg_configs makes it easiest for the detector interface to access (e.g. a detector interface doesn't know about a PV)
  • Could implement this with a new "MTRX:V3".
• proposal 2: (geometry file does change when binning changes)
  • current implementation with MTRX:V2. 
  • the configuration object controls the MTRX line in the geometry
  • the experimenters control the IP line in the geometry file
• advantage of (2):
  • geometry conversion only needs the file, where proposal 1 needs the detector's geometry/detector interface.
• advantage of (1):
  • geometry file doesn't need to be updated when binning changes, so easier for Chuck to update the IP, and easier for Mikhail since he doesn't worry about overwriting Chuck's IP position
  • supports the general software ROI/binning
• Currently: some geometry information (e.g. pixel size for Epix, Jungfrau, Cspad2x1, Cspad, Epix100) is not in the geometry file but is "in the code". pnccd/rayonix/opal use MTRX which has the pixel size (supports uniform rectangular pixels).  In some sense, not a big extension to have the software use the config object to compute pixels sizes (since there are hardwired pixel sizes for epix, Jungfrau).
• Other software ignores varying pixel sizes (e.g. epix border pixels)
• What do about converters? (see advantages of (1) and (2) above)
• ROIs (and software binning):
  • here we talk about rectangular objects 
  • in general, a detector many have N roi's which could change per-event, and software binning
  • keep the 1 geometry file
  • currently have det.raw (full detector Detector xface).
  • add det.roi which would have N roi's in it, each with an X,Y "corner coordinate" and X,Y binning, which in principle are definable per-event.
    • this would use the existing geometry file (and pedestals!)
    • what about pedestals for software binning?  if we add pixels 1 and 2, we subtract the sum of those 2 pedestals
    • the above two questions are specific examples of the general question: can we use the "full-detector" calibration constants for ROIs/software-binning?
    • det.roi could need a configuration and the detector interface for it may need to access that configuration
      • could have roi's that change per-event: in this case the corner-coordinate and binning would be in the l1accept data
      • could have roi's that are static for the run: in this case the corner-coordinate and binning would be in the configuration data for the "roi detector".
  • for more general shapes (circles, etc.) det.arbitrary_shape (have a mask). e.g. data might have x coords,  y coords, intensity. detector interface would use those "raw data" attributes to return something usable by the user (e.g. padded() for hsd).

Handling Detector Interface Parameters in

...

AMI2

• example: optionally enabling common mode
• Mikhail's initial conceptual proposal: det.calib(evt,cmpars=[1,3,'stuff'],mask=['status','edges','user'])
• more kwargs can be added in future, and they can be detector-specific
• only kwargs can be used (not args) because ami needs the standard pattern of passing an "evt" argument to every detector interface method
• the "red box" is key: it is the det.calib() method:
  • if we did it on the calib() method, would want to right-click on the red box to see list of kwargs
  • kwargs must be explicitly specified for AMI to automatically discover the list.  it is not required to explicitly specify all kwargs, but then those are expert modes, and aren't automatically discovered by AMI.  AMI could have a box to input an arbitrary kwarg (for experts)
  • how would we enter the kwargs? can we do type-checking? yes, using the standard python3 type annotations.  which could bring up appropriate QT widgets.
    • Seshu thinks the type-annotation are required to bring up type-specific QT widget (might not be enough?).  Maybe instead of type-specific QT widget, bring up a python-editor style box with a dictionary of kwargs that could be edited with standard python syntax (because it feels more general that type-specific QT widget).
    • Seshu thinks that when we do the introspection to find the detector methods (e.g. calib) at that point we could also do the inspection of the kwargs so we can present them to the user to edit.
    • Seshu thinks it might be doable (there are routines to get the list of kwargs and their defaults)
  • kwarg types should be "standard": no defining a custom type, only numpy arrays, lists, tuple, dicts, strings, int, floats
  • red box right-click would have a "select kwargs" option that would bring up the python-editor of the kwarg dictionary (with defaults)
  • Seshu asks: how would the kwargs get transmitted to the workers?  Workers are the only ones that see the red boxes.
    • Is there a way for the kwargs to be put in the graph?  Seshu thinks maybe it isn't part of the graph because the graph starts "after" the red box (the worker graph executes on data returned from a "yield").  This might be a question for Dan.  The "det.calib" information must be communicated to workers somehow, but in some object other than the graph ("SourceNode in the .fc file)?
    • Seshu thinks there might a zmq socket where the workers learn about the data sources (i.e. red boxes) via a PUB/SUB (presumably publish is done by the graph manager).  If so (pending confirmation by Dan) the kwargs would be added to that PUB message, ideally.  This is separate from the graph transmission, we think.
• can we drag in two calib boxes with different params?  ideally yes.  ami might not immediately support this.
• ideally we would be able to change the parameters while ami is running, since psana supports changing kwargs