Page History
...
- 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