Page History

...

• 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 necessary required to explicitly specify all kwargs (can be "wildcards") , 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.
    kwarg types should be "standard": no defining a custom type, only numpy arrays, lists, tuple, dicts, strings, int, floats
• 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