Assignment of parameters in pulse Schedule/ScheduleBlock doable through parameter name

[arthurostrauss]

Summary

This PR extends the previous usage of the method assign_parameters of Scheduleand ScheduleBlock by enabling the specification of the parameter name instead of the parameter directly. This assignment by name also works when assigning values to a ParameterVector(the length of the list of parameter values should in this case match the length of the vector).

Details and comments

[qiskit-bot]

Thank you for opening a new pull request.

Before your PR can be merged it will first need to pass continuous integration tests and be reviewed. Sometimes the review process can be slow, so please be patient.

While you're waiting, please feel free to review other open PRs. While only a subset of people are authorized to approve pull requests for merging, everyone is encouraged to review open pull requests. Doing reviews helps reduce the burden on the core team and helps make the project's code better for everyone.

One or more of the the following people are requested to review this:

• @Qiskit/terra-core
• @nkanazawa1989

[wshanks]

@arthurostrauss Is there previous discussion of this? It is convenient, but it is not something that QuantumCircuit allows either. I wonder if we want to discuss both contexts and keep behavior consistent. There is also a tradeoff between convenience and the potential for assigning to more parameters than intended (the user can avoid the ambiguity by using parameters but we should consider how much room for ambiguity to allow). We have struggled with string names versus parameters in the Qiskit Experiments calibration module in the past (with blocks like this one).

[arthurostrauss]

The motivation behind such feature lies in the will to integrate in a closer form the primitives V2 to pulse level control, as the former do carry BindingArrays storing the parameter names only. The idea would be to assign parameters to the schedule based solely on the information of the BindingArrays. For instance, one could imagine in the future when Qiskit Pulse will be fully JAX compatible, doing a subroutine using the primitives (with DynamicsBackend) and simulating the pipeline at the pulse level. Instead of binding the parameters before Jit compiling the workflow, one could accelerate the pipeline by compiling over the parametrized schedule, and bind the values using vectorized modelling of Jax, significantly improving performance. I am already working myself on such use case, happy to tell you more if relevant.

[coveralls]

Pull Request Test Coverage Report for Build 8855032197

Details

• 29 of 33 (87.88%) changed or added relevant lines in 2 files are covered.
• 3 unchanged lines in 1 file lost coverage.
• Overall coverage increased (+0.01%) to 89.442%

---

Changes Missing Coverage	Covered Lines	Changed/Added Lines	%
qiskit/pulse/parameter_manager.py	15	16	93.75%
qiskit/pulse/utils.py	14	17	82.35%

Files with Coverage Reduction	New Missed Lines	%
crates/qasm2/src/lex.rs	3	92.88%

Totals
Change from base Build 8851171785:	0.01%
Covered Lines:	60950
Relevant Lines:	68145

---

💛 - Coveralls

[arthurostrauss]

By the way after checking, it is possible to use QuantumCircuit.assign_parameters()with strings representing the parameter name. Cf this note in the documentation under the method:
.. note::
When parameters is given as a mapping, it is permissible to have keys that are
strings of the parameter names; these will be looked up using :meth:get_parameter.
You can also have keys that are :class:.ParameterVector instances, and in this case,
the dictionary value should be a sequence of values of the same length as the vector.

        If you use either of these cases, you must leave the setting ``flat_input=False``;
        changing this to ``True`` enables the fast path, where all keys must be
        :class:`.Parameter` instances.

[wshanks]

@arthurostrauss That sounds nice! My main concern was adding something to pulse assign_parameters that was not in circuit assign_parameters but I had missed that circuits supported string parameters. I think this should be fine conceptually then (I haven't looked at it closely enough to approve right now).

[arthurostrauss]

Hi @wshanks, any updates on this?

[wshanks]

@arthurostrauss For my part, I had an initial concern about deviating from QuantumCircuit.assign_parameters that you addressed, and then I just have not had time to look at this more closely. I will when I have time. I don't want to block this though if @nkanazawa1989 or @TsafrirA are able to look at it before me.

[wshanks]

Although the type annotations do not advertise it, assign_parameters already supports str. What you are adding here is support for assigning a sequence to elements of a ParameterVector using the name of the ParameterVector like:

from qiskit import pulse
from qiskit.circuit import ParameterVector

vec = ParameterVector("test", 2)

with pulse.builder.build() as sched:
    pulse.builder.play(pulse.Gaussian(100, vec[0], vec[1]), pulse.DriveChannel(0))

sched.assign_parameters({"theta": [1, 2]})

Since ParameterVector support was only added recently in #12045, this PR should be viewed as a follow up to it.

Going back to my original concern about deviation from the behavior of QuantumCircuit, I note that QuantumCircuit.assign_parameters does not allow assigning to a parameter vector by name. We should see if there is interest in such support for that case as well.

[wshanks]

Sorry for the slightly redundant comments in the previous review. I was shifting comments around and hadn't meant to submit the review yet. Here were a couple other comments.

[wshanks]

I find this part to be getting a little complicated. Could we lift the string handling to before this loop? So in a preceding loop, loop over parameter_binds and make a new copy that has all Parameter and ParameterVector keys by replacing any strings with the appropriately named matches?

[wshanks]

@arthurostrauss Could you address my comment about lifting up the string handling to earlier in the function and my minor suggestion about the release note? Otherwise, I think this looks good.

[wshanks]

This does not account for the fact that more than one parameter could have the same name, which pulse allows but circuit does not (it gives an error when trying to add the second parameter).

I think would be best to loop over self.parameters and make one dict shaped like dict[str, list[Parameter | ParameterVector]] mapping each name to the parameters with that name. Then make a new dict and loop over parameter_binds copying in the key and values for when the key is a Parameter or ParameterVector and replacing the key when it is a string with an entry for each value in the first dict for that string (could be more than one parameter). Then loop over that dict like below but without accounting for string keys.

You may want to account for a name being used for a parameter and a parameter vector. There is validation for vectors but not for scalars. If you tried to assign to a list a string name used by both a ParameterVector and a Parameter, it would not catch the assignment of a list to a Parameter here.

Maybe it is worth testing duplicated names?

[arthurostrauss]

So just to clarify, the expected behaviour is that every Parameter carrying the same name should be assigned to the same value? Or should it be that a list of values could be passed such that all parameters carrying the same name are taken into account? If it's the latter case, then how can we resolve this when using string parameter assignment?

[wshanks]

Every Parameter carrying the same name should be assigned the same value when a string is assigned a value. Also, every ParameterVector should be assigned the same list of values.

[wshanks]

This looks good to me now!