Parametrization of pulses

[hbluhm]

Many pulses will have variable parameters that are not known when the pulse is defined. Examples include:

1. Parameters that drift over time and are determined from calibration experiments
2. Parameters for generic (i.e., qubit independent) pulses that vary from qubit to qubit
3. Parameters to be varied in an experiment

Type 3 are currently handled through pardefs in pulsegroups, type 1 by modifying dictionaries. There is probably no sharp boundary between 1 and 2.
One very desirable change is to introduce parameter names for easier information.
Furthermore, there should be mechanism to control how parameter values are propagated through a pulse tree. Some will be taken from qubit - specific or global calibrations, some will be set when a specific experiments is conducted. There will probably be occasions when one wants to override default parameters from the calibrations - e.g. to check if a calibration is still good.

Similar to pulses, the parameters need to be documented. The reference and complexity issue is probably less severe here. Saving the values of all relevant pulses with each measurement might be enough.

I would suggest to develop the concept along these lines:

• Pulses have named parameters (perhaps also unnamed ones so that even those that are not named can be changed if needed?)
• Different objects (e.g. qubits) can provide parameter values.
• When pulses are generated and sent to the hardware, the parameters are propagated through the pulse tree. There must be some rule of precedence, e.g.
  Pulse default < qubit/system values < User specified (A < B means B overrides A)

[j340m3]

As I understand out of your request, you want the parameters to be more flexible and smarter than just being values. You want to classify and prioritize them, and, at some point, they are more than just values, more like the result of a function call.

In reaction to this request and @pcerf's in #7, I would propose the following changes to the pulse class:

• In each basic pulse class, we may define a dictionary of parameters.
• Each higher level of pulse contains the union over all dictionaries of their children.
• As one declares a pulse, one will have to declare default parameter if used.

Parameters itself will become an abstract class, of which we can derive 4 subclasses:

• SingleValueParam: Parameter only defined as one value (classic parameter).
• FunctionParam: Parameter which contains several values (iterable) according to a given function.
• MeasuredParam: Parameter with an initial value i and channel c. For the first iteration, this Parameter will have the value i. For all the other steps, this Parameter will have the value returned from the last measurement on the channel c. (Note that the channel will be a virtual one, with already postprocessed measurement data)
• EnvironmentParam: Parameters which are mostly function calls to the HAL or the qubit. These are for example also the calibration settings of the experiment.

I would propose the following behaviour of the propagation:

• First of all, the dictionaries will only map onto the default parameter.
• When we want to change a parameter, we will do it at the topmost node, and all for all child nodes, the parameter will adjust accordingly.
• Only when the pulse will be send to the hardware, the parameters will be interpreted and their value inserted into the pulse.

In my eyes, these modifications are not very clean and structured, but they are a first step to fulfill your requirements.

[hbluhm]

Sounds like a good start.

Note that measured values may be associated with qubits, so MeasuredParam and EnvironmentParam may overlap.

Another aspect that may take some additional thought is mapping qubit parameters onto a specific qubit. The value of a parameter used in a generic pulse will often depend on which qubit the pulse is applied to, so the pulse definition should include something like "use parameter X for the qubit targeted". The target qubit would only be determined later, e.g. when an algorithm is defined.