BNMR: Mode changer: Difference between revisions

From DaqWiki
Jump to navigation Jump to search
No edit summary
No edit summary
 
(4 intermediate revisions by the same user not shown)
Line 1: Line 1:
TODO
{{Pagelinks}}
 
== Introduction ==
 
The mode changer program {{Client|name=mode_changer.py}} is responsible for:
* re-configuring the ODB when the user wants to change [[BNMR:_Experimental_Modes|experimental mode]]
* letting the user change between [[BNMR:_Run_numbering|real and test runs]] (including changing the run number accordingly)
* saving ODB settings (both manually and automatically when the user changes mode)
* loading ODB settings (both manually, automatically when the user changes mode, and from previous [[BNMR:_Data_Logging#MUD_files|MUD files]])
 
The program is built using Midas' python tools, and provides a JRPC interface that webpages can use to interact with it (e.g. getting the list of supported modes; requesting that the mode be changed).
 
== Changing mode ==
 
Modes are defined as a combination of features. For example:
* Mode <code>1c</code> has <code>Enables CAMP scan=True</code> and <code>PPG timing=1n</code>
* Mode <code>2b</code> has <code>Enables RF=True</code>, <code>RF scanned in PPG loop=True</code> and <code>PPG timing=2b</code>
 
When changing modes, the program:
* saves the current ODB settings for the old mode
* loads the most recent settings that were used with the new mode (if available)
* changes the flags in {{Odbpath|path=/CurrentMode}} to those of the new mode (this lets other programs know what features should be enabled, without having to refer directly to mode names)
 
== Saving and loading ODB settings ==
Saving and loading of ODB parameters build on the [https://bitbucket.org/ttriumfdaq/odb_save_load/src odb_save_load] package, which provides the raw tools for saving parts of the ODB as JSON files on disk, with metadata like a comment and save date.
 
The mode changer program extends this functionality by automatically saving/loading settings when changing modes, and integrating the "manual" saving/loading with the custom settings page.
 
=== What gets saved ===
 
The definition of which bits of the ODB get saved is stored in {{Odbpath|path=/Saveload/Sections}}. It currently includes:
* {{Odbpath|path=/Equipment/PPGCompiler/Settings}}
* {{Odbpath|path=/Equipment/PPGCompiler/Programming}}
* {{Odbpath|path=/Equipment/RFCalculator/PPG questions}}
* {{Odbpath|path=/Scanning/PSM/Settings}}
* {{Odbpath|path=/Scanning/BNXRCustomCycleLogic/Settings}}
* {{Odbpath|path=/Scanning/Histograms/Settings}}
* {{Odbpath|path=/Scanning/SampleReference/Settings}}
* {{Odbpath|path=/Scanning/Epics/Settings}}
* {{Odbpath|path=/Scanning/Camp/Settings}}
* {{Odbpath|path=/Scanning/Global/Settings}}
* {{Odbpath|path=/Scanning/Helicity/Settings}}
 
=== Handling changes to the ODB structure ===
 
Experiments often edit their DAQ code to add/remove keys. This can cause a problem if you later try to load some settings that were saved with the "old" ODB structure. To avoid these issues, the {{Client|name=odb_save_load/save_load.py}} python script allows you to adjust the saved settings in a fairly user-friendly way.
 
All of the commands accept an <code>--odb-path</code> argument. The script will automatically determine which section that ODB path belongs to, find the right bit of the ODB structure in the saved file, and modify it accordingly.
 
The possible commands are:
* <code>add_from_live</code> - read the current value of an ODB key from the live experiment, and store it in any files that don't currently have that key. Files that already have that key present are not touched.
* <code>add</code> - like add_from_live, but manually specify the value to store as the --json-value parameter. You should encode the new value as the value member of a JSON string, e.g. --json-value='{"value": true}'</code> to store a boolean true. Files that already have the key present are not touched.
* <code>delete</code> - remove the specified ODB key from all saved settings that contain it.
* <code>edit_from_live</code> - like add_from_live, but also change the value in files that already have the key present.
* <code>edit</code> - like add, but also change the value in files that already have the key present.
 
A full example command would be:
 
<code>python save_load.py add_from_live --odb-path="/Equipment/PPGCompiler/Settings/Enable formulae"</code>
odb_save_load/save_load.py
 
=== Loading settings from a MUD file ===
 
The mode changer also allows loading any [[BNMR:_Data_Logging#ODB_variables|ODB settings that were saved in the MUD file]]. It uses the [https://github.com/dfujim/bdata bdata] package to load the file and get the list of variables that were saved. The [[BNMR:_RF_calculator|RF calculator]] uses the <code>mud_ind_var_links.py</code> file to decide which ODB variables should be saved for each mode (mapping "real" ODB locations to names in the MUD file), and the mode changer uses the same file to go in the opposite direction (mapping names in the MUD file to ODB locations).
 
Unfortunately, some variables are stored differently in the MUD file vs the ODB (e.g. booleans in the ODB vs a string in the MUD file). These "manipulations" are defined in two places:
* ODB to MUD in <code>compute_ppg_xxx()</code> in <code>ppg_prog_helper.py</code>
* MUD to ODB in <code>load_from_old_run()</code> in <code>mode_changer.py</code>
 
Note that not all ODB settings are stored in the MUD file; in particular, PSM RF modulation parameters are generally not stored.
 
=== Changing mode without loading saved settings ===
 
Sometimes the saved settings for a mode can fail to load correctly. If this is the case, you can use the [[BNMR:_Custom_Expert_page|Expert]] webpage to change the mode and load the default settings for that mode.
 
=== Changing mode from the command-line ===
 
You may change the mode via a command-line interface as well as via webpages. This may be useful for scripting a series of runs.
 
<code>python mode_changer.py --oneshot --mode=1f</code>
 
== Changing between real and test runs ==
Note that the user may change between real/test while a run is in progress!
 
When changing between real and test runs, the program:
* changes the key {{Odbpath|path=/RealOrTest/Name}} to <code>real</code> or <code>test</code>
* computes the new run number to use
* enables the alarm system and helicity checks if changing to a real run
* tells the [[BNMR:_Data_Logging#bnxr_logger.exe_introduction|data logger]] about the new configuration via JRPC (this lets it rename data files that have already been written for this run and name new files appropriately). JRPC is used rather than an ODB hotlink so that errors can be reported to the user more effectively.


[[Category:BNMR]] [[Category:Client]]
[[Category:BNMR]] [[Category:Client]]

Latest revision as of 13:30, 2 October 2024

Introduction

The mode changer program mode_changer.py is responsible for:

  • re-configuring the ODB when the user wants to change experimental mode
  • letting the user change between real and test runs (including changing the run number accordingly)
  • saving ODB settings (both manually and automatically when the user changes mode)
  • loading ODB settings (both manually, automatically when the user changes mode, and from previous MUD files)

The program is built using Midas' python tools, and provides a JRPC interface that webpages can use to interact with it (e.g. getting the list of supported modes; requesting that the mode be changed).

Changing mode

Modes are defined as a combination of features. For example:

  • Mode 1c has Enables CAMP scan=True and PPG timing=1n
  • Mode 2b has Enables RF=True, RF scanned in PPG loop=True and PPG timing=2b

When changing modes, the program:

  • saves the current ODB settings for the old mode
  • loads the most recent settings that were used with the new mode (if available)
  • changes the flags in /CurrentMode to those of the new mode (this lets other programs know what features should be enabled, without having to refer directly to mode names)

Saving and loading ODB settings

Saving and loading of ODB parameters build on the odb_save_load package, which provides the raw tools for saving parts of the ODB as JSON files on disk, with metadata like a comment and save date.

The mode changer program extends this functionality by automatically saving/loading settings when changing modes, and integrating the "manual" saving/loading with the custom settings page.

What gets saved

The definition of which bits of the ODB get saved is stored in /Saveload/Sections. It currently includes:

  • /Equipment/PPGCompiler/Settings
  • /Equipment/PPGCompiler/Programming
  • /Equipment/RFCalculator/PPG questions
  • /Scanning/PSM/Settings
  • /Scanning/BNXRCustomCycleLogic/Settings
  • /Scanning/Histograms/Settings
  • /Scanning/SampleReference/Settings
  • /Scanning/Epics/Settings
  • /Scanning/Camp/Settings
  • /Scanning/Global/Settings
  • /Scanning/Helicity/Settings

Handling changes to the ODB structure

Experiments often edit their DAQ code to add/remove keys. This can cause a problem if you later try to load some settings that were saved with the "old" ODB structure. To avoid these issues, the odb_save_load/save_load.py python script allows you to adjust the saved settings in a fairly user-friendly way.

All of the commands accept an --odb-path argument. The script will automatically determine which section that ODB path belongs to, find the right bit of the ODB structure in the saved file, and modify it accordingly.

The possible commands are:

  • add_from_live - read the current value of an ODB key from the live experiment, and store it in any files that don't currently have that key. Files that already have that key present are not touched.
  • add - like add_from_live, but manually specify the value to store as the --json-value parameter. You should encode the new value as the value member of a JSON string, e.g. --json-value='{"value": true}' to store a boolean true. Files that already have the key present are not touched.
  • delete - remove the specified ODB key from all saved settings that contain it.
  • edit_from_live - like add_from_live, but also change the value in files that already have the key present.
  • edit - like add, but also change the value in files that already have the key present.

A full example command would be:

python save_load.py add_from_live --odb-path="/Equipment/PPGCompiler/Settings/Enable formulae" odb_save_load/save_load.py

Loading settings from a MUD file

The mode changer also allows loading any ODB settings that were saved in the MUD file. It uses the bdata package to load the file and get the list of variables that were saved. The RF calculator uses the mud_ind_var_links.py file to decide which ODB variables should be saved for each mode (mapping "real" ODB locations to names in the MUD file), and the mode changer uses the same file to go in the opposite direction (mapping names in the MUD file to ODB locations).

Unfortunately, some variables are stored differently in the MUD file vs the ODB (e.g. booleans in the ODB vs a string in the MUD file). These "manipulations" are defined in two places:

  • ODB to MUD in compute_ppg_xxx() in ppg_prog_helper.py
  • MUD to ODB in load_from_old_run() in mode_changer.py

Note that not all ODB settings are stored in the MUD file; in particular, PSM RF modulation parameters are generally not stored.

Changing mode without loading saved settings

Sometimes the saved settings for a mode can fail to load correctly. If this is the case, you can use the Expert webpage to change the mode and load the default settings for that mode.

Changing mode from the command-line

You may change the mode via a command-line interface as well as via webpages. This may be useful for scripting a series of runs.

python mode_changer.py --oneshot --mode=1f

Changing between real and test runs

Note that the user may change between real/test while a run is in progress!

When changing between real and test runs, the program:

  • changes the key /RealOrTest/Name to real or test
  • computes the new run number to use
  • enables the alarm system and helicity checks if changing to a real run
  • tells the data logger about the new configuration via JRPC (this lets it rename data files that have already been written for this run and name new files appropriately). JRPC is used rather than an ODB hotlink so that errors can be reported to the user more effectively.