Suggested future change to runmanager globals management

[Trey Porto]

Hi community,

I wanted to suggest a possible change to how runmanager deals with display and control of globals that would improve our current use of it. I don't think it would involve much code change, but more of a conceptual change. 

The globals function of runmanager currently acts as (among other things) a "globals repository and globals management interface": each globals "group" is a separate collection of global variables that are stored in a separate file.  As far as I can see, you can only look at, and control, one  group at a time.

For our uses, it would be more convenient for rumanager to be a "globals VIEWER and globals management interface":  the act of displaying and providing an interface to global variables should, in my mind,  be completely independent of how those globals are stored on disk, or grouped in any other programatic way.  If I want to see and manipulate globalA and globalB at the same time, but at some later time want to see and manipulate globalA and globalC, I shouldn't have to toggle between groups.

As a concrete example:

In a dual species experiment, there are frequently similar variables for both species, eg.

MOT_detuning_species1,  Molasses_time_species1 

MOT_detuning_species2, Molasses_time_species2

Sometimes we may be optimizing both species at the MOT stage, in which case we would like to see/control 

      MOT_detuning_species1 and 

      MOT_detuning_species2.

Other times we might be optimizing the full time sequence of a single species, in which case we would like to see/control 

     MOT_detuning_species1 and 

     Molasses_time_species1.

In the current implementation of runmanager, we are left with two choices, either

    - pick a specific grouping of variables, and if we want to run experiments that involve frequently changing variables from different groups, we toggle back and forth between the groups to find the variables we are looking for.

or

    - keep all globals in the same group, yielding an unwieldy, long list of globals that we are perpetually scrolling through to find the right variable.

In our previous computer control software, we had a "globals viewer"  that contained objects that represented "views" of globals.  You could create as many views as you wanted, and each view could present any number of the existing variables. These "views" were completely independent of the structure of how the globals were stored or otherwise managed.

In addition to being able to have a "Both MOTs optimization view", presenting MOT_detuning_species1 and MOT_detuning_species2, we could have a "Species 1 optimization view" that allowed us to see and control MOT_detuning_species1 and Molasses_time_species1.

Particularly useful was the ability to have views that contained only a small number (two or three) of variables that we were currently working with, so we didn't have to look at and scroll through a list of extraneous variables, or toggle between groups.

With the viewer, it becomes less important or useful to group the globals in any way, and in our previous code, we just stored all globals collectively. Basically, using a tag-based approach as opposed to a folder-based approach.

Cheers,

Trey

[dihm....@gmail.com]

Trey,

This is a good idea, and possibly only a moderately difficult lift. I could envision a second "globals view" window below the current offering, with members dictated by checkboxes in the primary. Of course there are many possible ways to implement the functionality.

As a "works now" hack that I have used in the past, you can always specify the same globals in multiple groups then toggle which groups are active at any given time. So you could divide MOT1 and MOT2 globals into their own groups for normal use, then have a combined MOT12 global group you switch to for quick tuning. Only requirement is that the same global can't be defined in two _active_ groups so arbitrary views become annoying very quickly.

-David

[Philip Starkey]

Hi Trey,

This sounds like a great feature to have! I've wanted to do the equivalent of this with device controls in BLACS for a long, long time, and I can see how it would be beneficial for the same feature to exist in runmanager as well for globals.

As a potential work around for the immediate case, you could do the following right now, making use of the ability for globals to reference other globals:

Dual species optimisation group

• name:  MOT_detuning_species1
• value:  MOT_detuning_species1_source

Single species optimisation group

• name:  MOT_detuning_species1_source
• value: 5.6e6

Your labscript file should always refer to MOT_detuning_species1 and not MOT_detuning_species1_source

When in the single species view, you can edit the value as you would normally. Note that if you set MOT_detuning_species1_source to an array of values, runmanager is smart enough to automatically detect that the two globals depend on each other and will place them in a zip group rather than producing a pointless outer product.

When using the Dual species optimisation view, you can change the value there as well, as long as you remember to put the reference to the other global back, and adopt any new values for the detuning in the single species group. E.g., in the dual species group, you could set the value to linspace(1e6, 10e6, 10) # MOT_detuning_species1_source (comments are a great way of preserving previous values!).

I realise it's a bit cumbersome, and relies on a consistent process being developed and adhered to by everyone in the lab. But I thought I'd raise it as an option!

Cheers,

Phil