Big Idea

• everything goes in the config db with config keys BEAM/CAL/FEXA/FEXB
• need better tools for managing configurations (e.g. prescales, drp-python scripts (per-detector), teb python scripts (Ric already has this in this configdb))
• maybe use BEAM/NOBEAM idea
• maybe create python tools to clone the default configuration with "deltas" for calibration, feature-extraction "A" mode, feature-extraction "B" mode
  • if we tweak the default configuration, then should be quick to regenerate the calib/fexA/fexB configurations (like BEAM/NOBEAM)
  • a detail: the default configuration should be "write protected"
  • it may be that the default main-branch configuration changes in a non-backwardly compatible way so the python "cloning scripts" need to be updated
  • ideally would use the existing major/minor/micro version numbers that the config objects already have to determine compatibility?
• operator would select the configuration like they do with BEAM/NOBEAM (should be scriptable for "takepeds")
• the NOBEAM idea is out-of-date (was used to manage timing differences of event codes in LCLS1) so now we would have BEAM/CAL/FEXA/FEXB, and that set would be dynamic
  • ideally the user can change this outside of configure (we may have code that needs to be fixed: sometimes "connect" code runs at startup ... could be a problem if configdb is referenced)
• concern: 
• the idea of the "default" or "main branch" configuration (BEAM?) is a key idea. maybe we should change the name.
• in future drp-python may not be fast enough for high rate expts.  We may have to use .so with dlopen for the equivalent C++ approach (like Ric already does with trigger .so).

Discussion of drp-python

on March 2, 2023:

• how to configure
  
  • see above for use on configdb
• when do things happen
  • should start drp-python in config phase1: Ric suggests do the process-fork at startup, then have the python interpreter switch which scripts it runs at configure phase1.
  • (a detail) FYI: worker threads get shutdown on unconfigure (is this necessary? Ric says maybe some array sizes change.  Ric thinks changing startup/shutdown times would be a lot of work.)
• shmem ownership/cleanup
  • valerio uses sysv ipc instead of posix_ipc (because the conda version of posix_ipc claims to not support message queues, but a pip-installed version does: this should be a solvable problem ... feels like it's not built optimally?) 
  • unlike our shmem there are not physical in /dev/shm
  • for sysv we control the naming of the numeric keys (which are the equivalent of the filenames) so we can avoid permissions issues that way.  currently the numeric key is formed from the thread number and partition number.  Ric suggests perhaps adding the primary XPM number (cpo points out this is indirect, somehow ideally would use "username").  maybe not such a big issue because the username is controlled by the platform number and procmgr.conf.
• pebble size (both for transition buffers and L1 buffers: the maximum of these two is used for the drp-python shmem)
  
  • in Ric's new mode the pebble size is determined from the .cnf, or defaults to .service if not specified (used to be the .service) but drp-python can return a dgram larger than the pebble size.  what do we do?
  • we will manage the two bufend's in the drp-python and we will crash if that gets exceeded
  • if we have low-rate large events, could be better to assert damage rather than crash
  • Ric says maybe this is the job of the fex?  cpo says it might be better if we could solve it in one place for all possible fex's.  since truncating the data corrupts it then we have to mark the xtc as corrupt/not-iterable.
  A downside of not crashing:  people won't realize there's a problem