Feature proposal: selectable fragments

[JammyL]

The problem

Many structures within our ndscan/ARTIQ experiments use almost identical structures, with slightly different implementations/datasets.

An example of this is theSelectableGateWrapper in Oxart, that creates a new fragment for every possible transition. This has a cost of adding several fragments to the binary, and interaction on the dashboard is clunky - changing a scan parameter needs to be redone if the active gate is changed.

In ABaQuS this type of structure is likely to come up quite a few times, as we have multiple qubit types which use (almost) all the same hardware and structures, the main difference being if we do a few extra mapping pulses with our Quadrupole laser. Additionally, we can drive the different qubit types using co/counter propagating beams to couple to the motion. (granted there's no reason to use counter propagating in single qubit operations - keeping things general would be nice). Additionally, running an experiment on multiple qubits vs just one should not require complete rewrites of experiments, but just a change of the selected fragment(s) - if the experiment structure allows for it.

The example we've run into which prompted this idea is a simple Rabi flop experiment. This could use the following gates:

• Quadrupole
• Raman - Ground - copropagating
• Raman - Ground - counterpropagating (no real reason but could)
• Raman - Metastable - copropagating
• Raman - Metastable - counterpropagating (no real reason but could)

Each of these then has its own set of possible transitions. Creating five different experiments seems unnecessary.

Desired feature

Ideally I would have one experiment that has a dropdown to select the gate.
Then another dropdown, whose options changes to select the transition.
If I want to scan some parameter, this is pulled from the actively selected fragement, and I see the default.

The proposal is to implement some form of selectability in Fragment, granted that the fragments to select from share all the same methods (though not strictly the same implementations).

Initial thoughts on implementation

I think this could be done without creating an extra SelectableFragment class. Instead an attribute on Fragment._selectable_fragments: List[List[Fragment]] each fragment list provivides a set of options, and creates a dropdown to select from the available fragments.

This will likely encounter the following difficulties:

1. Displaying defaults on the dashboard for different selected fragments - If I understand correctly, this is currently done at build time and would need to change to become dynamic
2. Changing available options based upon the selected fragment (maybe even hiding/introducing new scan options) - similar 1., but with the options directly from the fragment.
3. Only including the chosen fragment in the build - the string based device_setup in build_fragment should be "easy" (doable) though with any kind of nested structure, this selectability could even make build stages on the host rather bloated.

@pmldrmota was also thinking about this. Anything to add Peter? :)

@dnadlinger I'm keen to hear your thoughts on this

[hartytp]

c.f. #269 (comment)

[JammyL]

@hartytp have you/the team at OI had any thoughts about this since?
It seems the conclusion from #269 was that this isn't possible.

Another thought @pmldrmota and I had is something along the lines of an "experiment group".
This could be a less invasive method of achieving a similar goal. A function that takes a series of "implementations" to a ExpFragment and groups them on the dashboard in some way.
This would mean each ExpFragment is at least fully contained/static.

The thing we'd give up here is composing multiple layers of selectability.

It could be done currently without any changes and a dedicated folder for each experiment group, but that feels a little clunky. It would work for a small number of experiments, but for something like a transition map the SelectableGateWrapper becomes more appropriate because of the dropdown.

[hartytp]

@hartytp have you/the team at OI had any thoughts about this since?
It seems the conclusion from #269 was that this isn't possible.

That's a pretty good summary of where we got to. Creating specialised subclasses for each transition we wanted to drive felt like the least bad option without major work.

In particular, I think this is less bad than any approach which doesn't set parameter defaults correctly in the UI which was my major issue with how we had previously done things.

It could be done currently without any changes and a dedicated folder for each experiment group, but that feels a little clunky.

If I've followed you correctly, this is essentially what we're doing.

An example of this is theSelectableGateWrapper in Oxart, that creates a new fragment for every possible transition.
It would work for a small number of experiments, but for something like a transition map the SelectableGateWrapper becomes more appropriate because of the dropdown.
The thing we'd give up here is composing multiple layers of selectability.

One point I'd make here is that usually one doesn't actually need, for example, to drive every possible sideband of every transition. If one moves from the space of physically possible things to the space of things that are used in practice, the issues didn't feel so bad (at least for what we were doing).

A function that takes a series of "implementations" to a ExpFragment and groups them on the dashboard in some way.
This would mean each ExpFragment is at least fully contained/static.

I don't think I follow here.