Script Generator

The purpose of this page is to collect requirements, ideas, suggestions, etc. for a Script Generator for IBEX. The requirements are listed in no particular order. Some of the requirements, ideas, suggestions may conflict with each other - that's fine, this is just a collection facility. When the time comes to create the Script Generator, we will review these ideas, identify a selection of these ideas to implement and turn them into user stories for implementation. If there are inconsistencies or conflicts, we'll resolve them when we make the selection (Note: resolution may mean reaching a compromise between two inconsistent requirements or dropping one in favour of another).

Script Generator Requirements

1. Script Generator should be capable of working offline (i.e. stand-alone, remotely from IBEX). This has several advantages:
   1. the Script Generator can be given to visiting scientists to prepare their own scripts ahead of their visit to ISIS. This helps maximise the use of beam time (i.e. there are no delays while users write scripts).
   2. a separate Script Generator does not need to run on the IBEX control PC. This means that the IBEX control PC is not tied up whilst someone is writing scripts.
2. Script Generator could be integrated with IBEX. This has the advantage of being able to use IBEX configs (to get information about blocks) and local genie_python libraries (to use instrument specific methods).
   1. a tightly integrated Script Generator would not be capable of running stand-alone (conflicts with the above requirement). Perhaps there is a looser degree of integration that could satisfy both requirements.
3. Implementing the Script Generator as a web application might be one approach to creating a solution that satisfies the two previous requirements.
4. The Script Generator should be capable of submitting scripts to the IBEX ScriptServer.
   1. this capability should only be available to users in the instrument control cabin (i.e. it should not be possible to submit scripts from remote locations).
   2. once a script has been sent from the Script Generator to the IBEX ScriptServer any modification (e.g. on-the-fly editing of the script, adjusting its position in the queue) should be done via IBEX ScriptServer.
5. The Script Generator should allow the user to save a script to file.
6. The Script Generator should allow the user to load a previously saved script.
7. The Script Generator should allow the user to set a run title
8. The Script Generator should allow the user to switch between detector & monitor type measurements (is this the same as switching between transmission & reflection measurements?). Maybe this is a requirement for LSS instruments only?
9. The Script Generator should be able to estimate how long it will take to execute a script (maybe this is functionality that really ought to belong to the ScriptServer?).
10. The following comments apply to Muon instruments:
    1. The vast majority of muon experiments involve looping over temperature and/or magnetic field.
    2. The Muon group are aware that MkScript (the old Script Generator) allows you to create nested loops, but they tend not to use this capability.
    3. Muon group tends to create scripts at the instrument control PC (i.e. they don't work offline)
    4. Muon group often works in the following mode:
       1. start a new run (i.e. BEGIN)
       2. run a script
       3. run another script
       4. ...
       5. stop the run (i.e. END)
    5. The ability to run custom commands is handy. In fact, the following (logical) construction would be useful, if it could be supported:

my_custom_scan_setup_command()
for (min < scan_variable < max) {
set (scan_variable)
make_measurement()
next (scan_variable)
}
my_custom_scan_close_command()

1. It would be nice if the scan loop (above) could be condensed to a single line (i.e. wrapped up in a general scan command).
   1. it could be difficult to unroll the loop inside such a command. Maybe this is acceptable because it could make things easier for end-users (who may lack programming skills).
2. linear and log/exponential step sizes in scans would be useful. For example:
   • linear: 5, 10, 15, 20, ...
   • log/exponential: 1000, 100, 10, 1, ... or 2, 4, 8, 16, ...
3. The MACS system allows users to change comments
4. The MACS system allows users to change "metadata"
5. The MACS system allows users to select variables from a list of block names (or, at least, their MACS equivalent).
6. It would be nice if the Script Generator knew a little about device capabilities (e.g. 100K is a ridiculous temperature for a dilution fridge).

Muon group's view on Script Generator Requirements

The following are some comments made by the Muon group, regarding their views on desirable attributes of a Script Generator.

1. Replicating something similar to or more capable than the existing editors we use is vital to operations.
2. Dynamic scripting along the lines of MACS is an important feature for us. The Japanese muon instruments that have now entered the scope of the IBEX project because of the RIKEN handover (and technical changes since the original URD) have had this feature for ~20 years and should not fall back in capability.
3. We don’t routinely generate scripts away from the instruments but it seems like a nice-to-have feature.
4. Script queuing is important to us – this seems to be in hand already. Saving and loading scripts also.
5. Making sure that the output of the script editor is straightforwardly human editable is important. The editor is unlikely to deal with every edge use case so this is a good way to deal with that. Our original editor up to mkscript3 has this feature, but MuonGUI is much worse for this.
6. If the script editor is on an instrument control machine it should be aware of the range of control parameters currently available and highlight if the script asks for the impossible. I think MuonGUI is able to do this.
7. The script duration should be estimated given reasonable assumptions that may be adjusted by the user. Counting time estimation is a good baseline requirement that is already fulfilled on our existing editors, some other control parameters that are predictable could be desirable to include.
8. Progress indication is also useful and could go hand-in-hand with dynamic execution.
9. The script editor should be able to define comments to be put in the data files. (Muon datasets have a consistent basic metadata format including comments. I’m not sure how standard this is in the NeXus definitions around ISIS.)
10. There should be a way of including arbitrary cset comments so you can type in non-standard things as needed.