• 2D (1D) ROI or an hsd threshold
  • Go into the configuration database?
    • go direct to DRP via ZMQ?
    • needs to be stored in xtc on configure (might be tricky)
    • config db persists the settings
    • users may forget those settings, need a way to look at them?
  • DRP would read the parameters from the configuration db (would require a reconfigure) (might be tricky)
  • need tool for switching between configurations?  BEAM/NOBEAM is not sufficient because it's too global, maybe need something detector specific
    • have a time-series of detector configs in db is not good enough: need a way to "name" them, switch between them and view them at a detector level (might be tricky)
  • have a general interface to ConfigDB, ami is one example of a client using that interface
  • don't want this LCLS-specific feature/dependency to prevent ami from being used world-wide
    • try-import and disable the feature if it doesn't exist
  • parameters that are presented to the user are set in some sort of config file (not everything in configdb) (might be tricky).  could use config dgram as a starting point, but might be too much stuff
    • special tag for user-drp parameters in xtc? then ami could figure out automatically.
  • for simplicity this approach does not address fast/automated changes (1 second): treat real-time ami feedback (e.g. to control a motor) as a separate issue
  • should ami have "apply" button to (1) send to db and (2) generate a daq configure transition?
  • AMI writes json to configdb
  • would be good to have a good way of loading a drp reduction algorithm (e.g. libroi.so) "shared library" with dlopen perhaps and then specify the shared library on the drp command line in the cnf file.

Starting points:

  • look at caf's "configdb" CLI
  • look psdaq/psdaq/configdb/*store.py (opal_config_store.py is simple)
  • for drp xtc generation: maybe xtcdata/xtcdata/xtcwriter.cc (C++), or (probably better) is returning json from python (like psdaq/psdaq/configdb/opal_config.py) and converting to XTC like psdaq/drp/BEBDetector.cc:translateJson2Xtc(). a third approach is the cydgram (cython) approach in psdaq/psdaq/control/control.py.  All involve some complexity.

Nov. 1, 2021 Discussion


current detector configs:
- per detector segment (e.g. tmo/BEAM/tmohsd_0)

for fex want:
- per detector (e.g. ROI)
- no segments?
- store as "tmo/BEAM/tmohsd/roi"?
  enable,prescale,x,y,dx,dy
- read by drp process (start with python)
- startup drp process in .cnf with "drp -p myroi.py -f tmo/BEAM/tmohsd/roi"
  o "-p myroi.py" is a psana-python script like Mona/Valerio working on
  o "-f tmo/BEAM/tmohsd/roi" is the database entry to look at
- need to be able to easily disable the fex (e.g. to run a calibration on epix)
  o would be another parameter in the configdb
- dynamic ROI (e.g. peak-finding) still needs parameter configuration
  o could be done in ami as well
- future: Regions Of Unusual Shape

questions:
- how do ami know which algorithms have fex-configurations? e.g. roi
  o opal_config_store.py which runs one at beginning-of-time, and then
    it is updated with config editor
  o drp process reads that initial config and writes to the xtc
  o maybe have a similar beginning-of-time script, then ami can see
    those configurations in the xtc on the configure transition and
    "dynamically/magically" provides the ability to edit it?
    o how does ami do that association between config transition to
      trigger the editing ability?  this has to be specified by the
      user (because there can be multiple roi's not all of which
      are drp-related) but can have a list to choose from that is
      populated by the config transition
- worry about scalability: could have many cores fetching from configdb
  (same problem we have with calibdb both in drp and shmem)
  o ideally we would designate a supervisor core (first node in collection
    json and first core?) and a broadcast mechanism.  could also cache.
- what names do we use if we have 2 roi's?
- how do we run ami to tell it to use "tmo/BEAM/tmohsd/roi" for parameter
  storage?
- could we automatically populate the config transition with the fex-config
  for easy access in psana?
  o feels like the myroi.py should fetch it's own configuration directly,
    from "tmo/BEAM/tmohsd/roi". (BEAM is in the .cnf file)
    not through the config transition, for reasons of "encapsulation"
  o of course, myroi.py should add the fex-config to the config transition
- how does ami determine BEAM? answer: user-selects "/tmo/BEAM/tmohsd/roi"
  from a list given on config transition

  • No labels