Feedback from working group 4

[GamelinAl]

Feedback for pyAML

• Monitor / TuneCorrection
  • a default should be determined for betatron tune, with option to select an other tune monitor.
    tune_monitor = control_mode.get_betatron_tune_monitor("BETATRON_TUNE") should be tune_monitor = control_mode.get_betatron_tune_monitor() and give default configuration.
  • control_mode.tune.get() # should work but does not when not called before
  • tune correction should tell what are the quadrupoles used by the tune monitor (add as properties).
  • Need that the measurement tool like TuneCorrection provide a direct access to the used magnets (not only names). sr.design.tune.quad_array as a property.
  • Complete docstrings, also for properties.
  • Tune Response matrix, once it is computed, store it somewhere and write it in the pyaml configuration

- type: pyaml.tuning_tools.tune
  name: DEFAULT_TUNE_CORRECTION
  quad_array: QCORR
  betatron_tune: BETATRON_TUNE
  delta: 1e-3
  response: /my/optics/path/tune_response_matrix_live.json

• The tune monitor and correction objects make sense. May be need more clarification in the examples

• Be able to change the defualts that are in the configuration via the call in the scripts. For example change the default tune monitor. (tune_correction = control_mode.get_tune_tuning(tune_monitor=BETATRON_TUNE_SPARE) with BETATRON_TUNE_SPARE defined in the config file)

• General pyAML feedback

  • Would be nice to have a "Restore feature" with some history. Hold the delta tune correction and quadrupoles values in a short buffer history
  • measurements should handle excluded/disabled/frozen magnets ? Frozen magnet boolean field like in MML
  • All properties in config yaml files should be lowercase (chromaticity)
  • SOLEIL to share automated config from lattice (add as example)
  • for every tuning tools: defaults in config, add timeouts and settle times, units
  • docstrings should contain units (Chromaticity measurement)
  • make sure all methods exposed to users have a numpy format doc string (as chosen in the past) (may be AI could help)
  • one single example for Tune, ORM, etc.. and several config files (minimal) to show the same example works for many machines.

• General accml feedback

  • nice thing is that value comes with timestamp and (even better with units). In epics timestamp is always available from the device. Start and end of measurement in datetime format
  • accml is missing string representation of objects.
  • accml has nice measurement progress bars
  • accml example are rather difficult and obscure. harder to follow. Although we also has some difficulty with pyAML one.
  • in accml is state_cache a measurement history?
  • difficult to find configuration file in accml. it is in accml_lib
  • accml configuration and user interface are quite far from the user interface specification document. For example all config files are spars and it is not trivial to find to which lattice the configuration refers to
  • accml has implented timeout and settle_time in configuration layer
  • configuration should not include dynamic information such as magnets strengths.
  • configuration should not be python code

• pySC interface

  • user never sees pySC (good feature)
  • pySC in very much tighly linked with pyAML (could be bad)
  • config files of examples should be in the specific example folder
  • lattice_names key in ORM object is not clear. may be an unusefull
  • orm is not an object to correct, no load. But could be added in future for optics correction
  • need to do sr.design.get_magnets(orm.vcor_array) a short cut could be usefull

• Measurement standards

We propose a series of generic measurement functions/methods which can be customized and completed with callback functions.
It could be implemented in a TemplateMeasurement class with measurements steps.

• initial data loading
• metadata
  • global data + measurement specific data
  • timestamps for each data piece
• initial state / final state and going back
  • should save a file and not keep things in memory
  • could use the metadata from general measurement
  • could be a specific item for the measurement where only what is changed is written
• watch for feedback running
  • need of a Watcher class which look in the CS for flags like the FOFB one
  • skip the check if in simulator mode
  • could make use of pydantic validators (https://docs.pydantic.dev/latest/concepts/validators/#field-validators)
• take care of signals like "crtl C"
  • could be done in the callback function
  • handle any errors which could come out in measurement and return to initial state
• general function to take data + metadata
  • configurable on the fly but with default configuration in yaml file
  • output dict with default config
  • default can be overwritten at execution
  • function should be able to average data
  • save data at each step into the file
• Optional intermediate checks
  • for example, check if current is suffisant in the ring
• Progress bar and interactive plotting
  • In separate threads
• Callback function
  • very useful to customize default measurement behaviour
• Measurement output
  • Could be a generic pyAML object to allow easy reusage for other measurements step
  • Generic object provide a method to ouput results to hdf5 with metadata inside
  • Class based on pydantic

In this working group, all of us agree that there is no need for specific or complex measurement engine.

[simoneliuzzo]

python-accelerator-middle-layer/pyaml#179
python-accelerator-middle-layer/pyaml#180
python-accelerator-middle-layer/pyaml#181
python-accelerator-middle-layer/pyaml#182
python-accelerator-middle-layer/pyaml#183
python-accelerator-middle-layer/pyaml#184

[GamelinAl]

measure_ORM_with_context.py

[GamelinAl]

Normal ouput:

Ouput when error or crlt+C: