Add Python script to approximate filtered h-gain waveform#387
Add Python script to approximate filtered h-gain waveform#387qwriter wants to merge 19 commits intodwavesystems:masterfrom
Conversation
JoelPasvolsky
left a comment
There was a problem hiding this comment.
Comment made before you switched to draft. Will review in full once it becomes a non-draft PR again.
docs/quantum_research/annealing.rst
Outdated
| ============================================== | ||
|
|
||
| Time-dependent gain for qubit biases can be used with the standard-anneal | ||
| protocol and reverse annealing ([Vod2025]_, [Pel2023]_). |
There was a problem hiding this comment.
docs/quantum_research/annealing.rst
Outdated
|
|
||
| Time-dependent gain for qubit biases can be used with the standard-anneal | ||
| protocol and reverse annealing ([Vod2025]_, [Pel2023]_). | ||
| The :ref:`parameter_qpu_h_gain_schedule` parameter is applied to qubit |
There was a problem hiding this comment.
There are two alternatives for feature descriptions in the Annealing Implementation and Controls that seem to me to follow good practices:
- Single source these details
- Refer users to h-gain-schedule parameter for the details; e.g., "For details on how to set h-gain for a problem, see the h-gain-schedule parameter"
Having two copies of these details, here and under h-gain-schedule parameter, risks discrepancies and adds maintenance costs.
Currently the Varying the Global Anneal Schedule section follows alternative 1, single sourcing the details with the anneal_schedule parameter. I actually think alternative 2 is better: the Annealing Implementation and Controls should explain what these features are used for and provide technical implementation details while the Solver Parameters section should specify usage rules. The former is for learning about the features and its hardware; the latter is a reference page for programmers.
|
|
||
| Approximating the Filtered h-gain Waveform | ||
| ------------------------------------------ | ||
|
|
There was a problem hiding this comment.
The first sentence under this section (or a sentence before this section) needs to explain why we're talking about a filtered waveform:
The I/O system that delivers the h-controlling waveform to a QPU limits bandwidth using a low-pass filter; if you configure a too-rapidly changing curve, even within the supported bounds, expect distorted values of h for your problem
docs/quantum_research/annealing.rst
Outdated
| Approximating the Filtered h-gain Waveform | ||
| ------------------------------------------ | ||
|
|
||
| In this sample Python script, the method ``approximate_filtered_h_gain`` |
There was a problem hiding this comment.
Consider the following structure for this section (rough draft). My concern with the current structure is that we have a very long section taken up with code to produce information unneeded by most researchers reading the Annealing Implementation and Controls, which is the critical physics page. To me it makes sense that for the occasional researcher who needs to get the filtered waveform, they can open a dropdown for the code.
QPU-Executed Schedule
A sentence here about how the input (nominal) schedule is filtered by the I/O and so the schedule executed on the QPU is bandwidth limited, as shown in the figure below.
You can use the provided script to approximate the schedule executed on the QPU.
.. dropdown:: Approximating the Filtered h-gain Waveform
Here comes the script.
docs/quantum_research/annealing.rst
Outdated
| >>> from scipy import signal | ||
| >>> import warnings | ||
| >>> | ||
| >>> def approximate_filtered_h_gain (pwl, bandwidth): |
There was a problem hiding this comment.
Forgot: we should make a PR to add this function to dwave-system, and once that is in the SDK, we would just refer to it here.
5340a80 to
c684414
Compare
| sampling_rate = int(bandwidth * 100) | ||
| time_array = np.linspace(t_i, t_f, int(np.ceil(sampling_rate * (t_f - t_i)))) | ||
| sig = np.interp(time_array, pwl[:, 0], pwl[:, 1]) | ||
| b, a = signal.bessel(2, 2/100, btype="lowpass", analog=False, output="ba", norm="mag") |
There was a problem hiding this comment.
Is this filter consistent with what's actually used, or it's just for illustrative purposes? Different filter types and design choices produce quite different results.
| Varying the Linear-Bias Schedule | ||
| ================================ | ||
|
|
||
| For more control of the annealing process, you can schedule the time-dependent |
There was a problem hiding this comment.
A couple of thoughts:
- "For more control of the annealing process" --> is this clause adding anything helpful?
- "schedule the time-dependent" --> here, before it is defined, the non-definite article makes more sense
Basically, I'm suggesting "You can schedule a time-dependent gain for the Hamiltonian's linear biases (i.e., qubit biases)" is shorter without loss of info.
| gain for qubit biases can be used with the standard annealing and reverse | ||
| annealing protocols ([Vod2025]_, [Pel2023]_). The |
There was a problem hiding this comment.
This section would be stronger if the two use cases are moved to the end, something like:
"For examples of using this feature, see [Vod2025]_ and [Pel2023]_ "
|
|
||
| .. _approximate_filtered_h_gain: | ||
|
|
||
| .. dropdown:: Approximating the Filtered h-gain Waveform |
There was a problem hiding this comment.
Here too, instead of the new "h-gain" term, why not "Approximating the Filtered Waveform" or "Approximating the Filtered Gain Waveform" or "Approximating the Gain Applied on the QPU" or many other options?
| that is filtered and executed on the QPU. The script's | ||
| ``approximate_filtered_h_gain`` method derives an approximation of the | ||
| filtered h-gain waveform by applying a second-order low-pass Bessel filter | ||
| to the input waveform. |
There was a problem hiding this comment.
Same comments as previously to this intro
Co-authored-by: Joel Pasvolsky <34041130+JoelPasvolsky@users.noreply.github.com>
Co-authored-by: Joel Pasvolsky <34041130+JoelPasvolsky@users.noreply.github.com>
Co-authored-by: Joel Pasvolsky <34041130+JoelPasvolsky@users.noreply.github.com>

This PR includes the following updates:
h_gain_schedulesolver parameter to a new section in the QPU annealing topic.h_gain_schedulesolver parameter is experimental only.Question: Does the footnote about the supported slope still apply? (see this comment.)
The HTML for the
h_gain_schedulesolver parameter is here.The HTML for the new section is here.