accml.app.tune.bluesky package
Submodules
accml.app.tune.bluesky.preprocess_databroker_data module
- accml.app.tune.bluesky.preprocess_databroker_data.data_to_model(data)[source]
For data as stored by bluesky / databroker
- Return type:
- Parameters:
- accml.app.tune.bluesky.preprocess_databroker_data.select_repetitions(data, acceptable_repetition)[source]
- Return type:
- Parameters:
data (MeasuredTuneResponse)
- accml.app.tune.bluesky.preprocess_databroker_data.select_repetitions_for_power_converter(data, acceptable_repetition)[source]
Filter out the acceptable data using repetition
For BESSY II e.g. the Tune measurement is free running, thus the first value taken can be correct, but not necessarily. So the race condition is avoided taken only acceptable repetitions
- Return type:
- Parameters:
accml.app.tune.bluesky.tune_correction module
- async accml.app.tune.bluesky.tune_correction.tune_correction(dm, tune_target, mexec, n_iterations=3, n_samples=2, wait_after_set=0.5, wait_between_sample=0.1, **kwargs)[source]
- Parameters:
tune_target (Tune)
mexec (MeasurementExecutionEngine)
accml.app.tune.bluesky.tune_correction_controller module
- class accml.app.tune.bluesky.tune_correction_controller.BlueskyTuneCorrectionController(*, mexec, oracle, policy, num_readings, wait_after_set, wait_between_sample, logger=<Logger accml (WARNING)>)[source]
Bases:
TuneControllerInterface- Parameters:
mexec (MeasurementExecutionEngine)
oracle (Oracle)
policy (PolicyBase)
num_readings (int)
wait_after_set (float)
wait_between_sample (float)
- async continuous(*, read_commands, set_commands, n_steps=None)[source]
- Parameters:
read_commands (
Sequence[ReadCommand]) – commands to retrieve the observed positionsset_commands (
Sequence[Command]) – commands to set the actuators. Note that a copy of the command will be made and the value will be adaptedn_steps – if set to None, run forever, otherwise run maximum number of steps and stop then
- Discussion:
Should “read commands” and “set commands” be made available already at init?
Read commands tell the controller how to get to an “observable” state. “set_commands” allow the controller to e.g. probe the used measurement/cmd execution engine if these commands are understood and available.
The commands actually set will be typically produced by the “policy”. An alternate way would be that the policy changes the step to be taken. The commands to be executed are then generated by the controller.