Collect Feature Requests for Parameter Management

[lumip]

The currently used parameter management (on top of qc-toolkit) by @pcerf and co. is as follows: There are several dictionaries of the form

{
  "global": { <parameter_name>: <value>, ... },
  "<pulse_id>": { <parameter_name>: <value>, ...}
}

given in order. The parameter values for a pulse p are determined by

1. for each dictionary, adding all entries of global to each pulse specific parameter subdictionary
2. merging the pulse specific subdictionaries from each main dict. in case of a parameter appearing in both, the more one later in the sequence is taken

A dictionary only affects a pulse if it contains a subdictionary for that pulse, i.e., globals from a dictionary are not applied to "unknown" pulses.

Example:

d1 = { "global": { "x": 2 }, "pulse_1": {"x": 1, "y": 0}, "pulse_2": {"z": 7, "v": 1} }
d2 = { "global": { "x": 1 }, "pulse_1": {} }
d3 = { "global": { "z": 0 }, "pulse_2": {"v": 3} }

with order d1, d2, d3. Parameters for pulse_1 are then { "x": 1, "y": 0} and for pulse_2 { "x": 2, "z": 0, "y": 3}. Note that pulse_2 is not affected by d2s global change to x since it is not included in d2 and pulse_1 does not get a value for z from d3. d2 has an empty subdictionary for pulse_1 so that it is affected by its global change to x. This is explicitely desired behavior:

Requirement (?): Concatenation of several "layers" of dictionaries specificing parameter values. "Later" dictionaries overwriting values from previous ones. This allows to have general dictionaries with values that are useful defaults and then dictionaries with values for e.g. specific hardware or experiements. Requirement (?): There must be finegrained control over which dictionary affects which pulse (as stated by @pcerf ) (currently solved by including affected pulses explicitely, even if they don't have pulse specific parameter values, i.e. empty subdictionary).

Additionally, the current implementation has the ability to append a suffix identifier to pulses from specific dictionaries. Suppose d1 and d2 both specify a parameter x for some pulse, it is then possible to have those parameters loaded as x_d1 and x_d2.

This is currently used in cases where a parameter value depends on the specific qubit a pulse is executed on. Single-qubit pulses require only the parameter value and do not care from which dictionary is provided. However, there exist two-qubit pulses that need to deal with values for both qubits.

Requirement (?): Some parameters have specific values for specific hardware. They must be addressed agnostically by pulses that do not care about the hardware but it must also be possible to differentiate between different hardware-specific values for pulses that operate on several qubits. (namespaces might be a solution)

@pcerf: please check whether I got this right so far