-
Notifications
You must be signed in to change notification settings - Fork 7
-
Notifications
You must be signed in to change notification settings - Fork 7
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
[Feature]: Sampling-based robust control #89
Comments
I have almost completed the Issue 102 so I would like to start working on this one. This problems seems interesting. I see, so we can directly call the TransmonSystem as well.
|
I read the paper [1]. I have a few questions which I would kindly request some clarification: We don't need to use gradient-flow based iterative algorithm during step 2 of training? Instead, we use the gradient-based optimization algorithm used here like for UnitarySmoothPulseProblem ? Instead of I am not clear on the "create an ensemble of quantum systems". We have to create a system that can cater to all three (or generally) types of systems presented in the paper namely, right?
Seems very interesting! Please provide some reference from the code to get some idea about this part. I am also attaching some points from the Paper for my reference:
Three Examples in the Paper: (I think let's do with the first example)
In the meantime, I would have a look at the code that was mentioned in the above description. Thanks a lot for clarification! |
P.S. In order to better understand the problem, I am preparing the documentation about SLC. I think we use this form of system Hamiltonian in problem templates as mentioned in the QuickStart Guide But, there is a slight modified version of system hamiltonian due to uncertanities that is assumed by the authors where the uncertainity parameters (θ) are sampled from uniform distribution. Assumption for the first example of implementation of SLC: f_m(θ_m) = f(ϑ) for all m = 1,2,3,4 and f_0(θ_0) = f_0(ϑ). For instance, in the first example of 5-type 3-level system (please see details above), they provide H_0, H1, H2, H3, H4. |
Let's start by making a notebook that demonstrates how to solve this problem, then we can think of packaging the code into a problem template and simplifying the notebook for the documentation. To be specific, let's take a simple system: 1. Define an ensemble of From here, we could set up an independent control problem for each of these systems. Let's say we want an 2. Redo UnitarySmoothPulseProblem with the help of for loops Check out how 3. Glue the trajectory together with the right dynamics if integrator == :pade
unitary_integrator =
UnitaryPadeIntegrator(system, :Ũ⃗, :a; order=pade_order, autodiff=autodiff)
elseif integrator == :exponential
unitary_integrator =
UnitaryExponentialIntegrator(system, :Ũ⃗, :a)
else
error("integrator must be one of (:pade, :exponential)")
end Notice that we get to supply the keys. With diligent use of for loop and add_suffix, we can make the integrators we need for each quantum system in our ensemble. 4. Make sure we have all the pieces! return QuantumControlProblem(
system,
traj,
J,
integrators;
constraints=constraints,
max_iter=max_iter,
linear_solver=linear_solver,
verbose=verbose,
ipopt_options=ipopt_options,
jacobian_structure=jacobian_structure,
hessian_approximation=hessian_approximation,
eval_hessian=!hessian_approximation,
kwargs...
) Make sure you collect all the pieces you need. For example, we pass our fancy, joint trajectory and list of many integrators. We also want the quantum system to be the |
Thank you very much the description!, @andgoldschmidt. That's awesome! I have completed Step 1, Step 2 (partially, created NamedTracjectory for each system in ensemble), and Step 3. I would highly appreciate if you have a look (Please download it!) at the notebook . Thanks for your time! |
For your error at #this causes error: ArgumentError: Provided trajectories must have fixed timesteps
traj = direct_sum([add_suffix(traj, ℓ) for (traj, ℓ) ∈ zip(initial_trajectories, prob_labels)]) the issue is that you have constructed the trajectories with a Relying on direct sum can be trouble because it is designed to duplicate every part of the trajectory, including the controls. Instead, work one level up, where you construct the system: components = (
Ũ⃗ℓ=Ũ⃗,
a = a,
da = da,
dda = dda,
Δt = Δt,
) where this is pseudocode for creating a variable number of initial trajectories, Ũ⃗ℓ---one for each system. You no longer need an outerloop, |
Notice that to glue everything together, UnitaryPadeIntegrator(system, :Ũ⃗, :a; order=pade_order, autodiff=autodiff) while in a |
Oh, Yeah, I did notice after you pointed out that in |
Hi, @andgoldschmidt, I completed the Step 4 about glueing everything together where we use Please have a look notebook. Thanks! In the meantime, I am introspecting on your comments trying to understand better. |
Take a look at the NamedTuple docs, in particular julia> keys = (:a, :b, :c); values = (1, 2, 3);
julia> NamedTuple{keys}(values)
(a = 1, b = 2, c = 3)
julia> (; (keys .=> values)...)
(a = 1, b = 2, c = 3) You can create a vector of symbols, one for each trajectory Ũ⃗ℓ, plus the controls, in order to make the components, keys = # make all the symbols
values = # match the original data
components = (; (keys .=> values)...) |
Regarding your error, pay particular attention to the |
Thanks for your comments. My apologies if too many question in one day was bothersome. |
Yeah, in Free time, we use =:Δt , where as in else, we use =Δt. |
Please check out components created at system level. We want something like this, right? Thanks
|
It looks like this is the right track, except I don't understand the presence of Once you have the entire trajectory, can you share the constructed NamedTrajectory components that are output by calling, e.g. |
Glad to hear that. Sure, I will share output of |
Kindly please tell me is this what we want our keys and values to be?
I have made an inner loop to construct keys and components. Please see the notebook here: link |
I think I have solved the components problem thanks to your guidance, @andgoldschmidt!
Please see the output of
Now, I am getting the error towards the end! Question: Just like in the Method is present that we can take Does we take
This is because for all QuantumControlProblem, we have Please see the error:
Please find the notebook here: drive link |
In this other second version , I get 'timestep Δt::Symbol must be a symbol or real'. It does seems to have shared control though if we see the stacktrace. Please do let me know about this as well! Thanks a lot!
|
You will want to be sure that you have a state |julia> println(traj.components)
(Ũ⃗_1 = 1:8, Ũ⃗_2 = 9:16, Ũ⃗_3 = 17:24, a = 25:26, da = 27:28, dda = 29:30, Δt = 31:31, ... If you set up your problem in this way, you will not need to create a |
Yes. Notice what the error message is telling you. There is no method matching the arguments. Look at the argument that did not match (in red). It is the integrators, which in your code is a type Create integrators with integrators = AbstractIntegrator[] Then, instead of rewriting the object, integrators = vcat(
integrators,
DerivativeIntegrator(:a, :da, traj),
DerivativeIntegrator(:da, :dda, traj)
) try push!(integrators, DerivativeIntegrator(:a, :da, traj))
push!(integrators, DerivativeIntegrator(:da, :dda, traj)) |
Thank you very much! |
Pardon me for a naive Question: In the So, we should follow similar approach in our case, right? Like
In a way, you already answered this question above as following:
The error now Please find the latestnotebook here: drivelink Thanks! |
Check that things like |
I checked and cross-verified with the Error Location: The error occurs in
Output of
|
Compare the output keys of the |
In order to correct this, I am trying something like
Please find the notebook attached: link Thanks! |
It seems that the DimensionMismatch is coming from the
|
Hi, @andgoldschmidt, Could you please re-open the PR that was closed 2 weeks ago about this? I would like to add the notebook for review. |
Feature Description
Quantum collocation currently has a
UnitaryRobustnessProblem
which can be used to make a control solution robust to an error operator. However, there is more than one way to make a control solution robust. For this feature request, we want to implement sampling-based robust control problem template (see also, Reference [1])Suppose we have a qubit system$H(t) = \zeta Z + a(t) X$ , where $\zeta \sim \mathcal{N}(\mu=0.01, \sigma=0.05)$ . That is, we know that there is some dephasing noise on the qubit (acting via the operator Z), and we even characterized the distribution! To implement sampling-based robust control, we want to find the best control for the qubit, in expectation. This can be accomplished by drawing samples $\zeta_i$ , and constructing an ensemble of quantum systems $H_i(t)$ . The goal of the problem template is to maximize the expected fidelity of the sampling-based robust control by solving each of the control problems simultaneously.
A useful place to look at is
UnitaryDirectSumProblem
.Implementation guidelines
To accomplish this using Quantum Collocation, follow the
UnitarySmoothPulseProblem
template, but make the following changes:QuantumSystem
with a constructor (e.g.,TransmonSystem
). The constructor will be used to pass parameters to create an ensemble of quantum systems.unitary_symbol
).Requirements
Tests of the problem template should be implemented.
Other information
A relevant example for this type of problem template is control uncertainty,$H(t) = (a(t) + \delta a)X$ , which cannot be captured using the previous robustness framework. I'm not entirely sure how the sampling solution will do, but it would be cool to check and see!
Importance
1 (lowest)
What does this feature affect?
References
[1] Sampling-based Learning Control for Quantum Systems with Uncertainties
The text was updated successfully, but these errors were encountered: