SciPost Submission Page
Krotov: A Python implementation of Krotov's method for quantum optimal control
by Michael H. Goerz, Daniel Basilewitsch, Fernando Gago-Encinas, Matthias G. Krauss, Karl P. Horn, Daniel M. Reich, Christiane P. Koch
|As Contributors:||Michael Goerz|
|Submitted by:||Goerz, Michael|
|Submitted to:||SciPost Physics|
|Subject area:||Quantum Physics|
We present a new open-source Python package, krotov, implementing the quantum optimal control method of that name. It allows to determine time-dependent external fields for a wide range of quantum control problems, including state-to-state transfer, quantum gate implementation and optimization for an arbitrary perfect entangler. The user-friendly interface allows for combination with other Python packages, and thus high-level customization.
Submission & Refereeing History
Reports on this Submission
Anonymous Report 1 on 2019-5-20 Invited Report
1. The Krotov method is well-known in the optimal control community.
2. The addition of a high-quality open-source implementation is very welcome and could be of use to a large audience of both optimal control theoreticians and experimentalists.
1. The description of the base Krotov algorithm must be self-contained. This is currently not the case.
2. The Authors intermingle the specification of the algorithm with an explanation as to why it is formulated the way it is.
The Authors present a Python implementation of the Krotov quantum optimal control method. The Krotov method is well-known in the optimal control community, and the addition of a high-quality open-source implementation is very welcome and could be of use to a large audience of both optimal control theoreticians and experimentalists. As such, the work is important and should be published.
There are, however, are some issue with the current form of the manuscript which, in my opinion, MUST be amended prior to publication. Primarily, the explanation of the Krotov algorithm in Section 2 requires revising, to make it self-contained as to clearly separate a detailed description of the algorithm from the explanation as to its construction.
13 additional issues which must be addressed (numbered 3-15), and 12 optional comments (numbered 16-27) are listed below.
The explanation of the Krotov algorithm in Section 2 requires revising, on two fronts:
1. The description of the base Krotov algorithm MUST BE SELF-CONTAINED. For example, the introduction of the Schrödinger equation, a basic feature of the method, is left to references [5,42,43], which puts an unreasonable burden on the reader. While there are many Krotov use cases and variants which can be cited away, one Krotov variant must be presented in full within the manuscript.
2. The Authors intermingle the specification of the algorithm with an explanation as to why it is formulated the way it is. The result left this reader confused. Please SPECIFY THE ALGORITHM IN A CLEAR, EXPLICIT, CONCISE AND COMPLETE FORM. One possible example is section "Algorithmic Steps" of the cited . The explanation of the algorithm, a self-contained version of Section 2, can then refer to the steps of the algorithm, making it easier for the reader to follow.
Additional issues which, in this reviewer's opinion, MUST be addressed are as follows:
3. Section 1: The statement "Gradient-based methods typically converge faster, unless the number of optimization parameters can be kept small, and can be separated into methods that update the external control field concurrently or sequentially in time " does not appear to be supported by the data in the cited reference.
4. Section 2.2: The sentence "It achieves this by adding a vanishing quantity ..." is unclear or incomplete. What is this quantity?
5. Section 2.2: It is unclear how Eq. (5) follows from Eq. (4).
6. Section 2.3, point "1. Construct the states ..." The statement "These typically depend on the states..." is unclear. How do they depend on the states? When don't they? It feels as if this explanation is not starting at the beginning.
7. Section 2.3, point "3. Starting from the known ..." The paragraph is unclear. Please revise. Include Eq. (5) as you wish it to be used. Explain 'This approximation of t ≈ t + dt=2 is what constitutes the "time discretization" mathematically'.
8. Section 3: "pip install krotov" from Appendix A and the URLs from appendix C belong in section 3.1 or "section 3.0", otherwise one reads about a package without knowing where to get it. The license (BSD, as I discovered on the package's site) should also be noted.
9. Section 4 and especially 4.3: The comparison made here is limited to the two other methods available in QuTip, GRAPE and CRAB. It is therefore far from a comprehensive comparison of quantum optimal control methods. Therefore, at the very least, the limited scope should be stated clearly - both in the text and in Figure 2.
10. Section 4.1, "* Krotov’s method mathematically guarantees monotonic convergence in the continuous limit": From the manuscript I understand this to be true only for time-continuous formulations, and explicitly untrue for the time-discrete implementation which is presented here. Therefore, either the manuscript has confused me, or this statement is misleading. Either way something needs to be fixed.
11. Section 4.1, "Krotov’s method does not require a line search to determine the ideal magnitude of the pulse update in the direction of the gradient.": Aren't we supposed to set \lambda manually? Again, I'm confused.
12. Section 4.2: "A possible drawback of gradient-free optimization is that it is also prone to get stuck in local optimization minima." - This statement is equally true of many gradient-driven methods, and patently untrue of some gradient-free methods, such as simulated annealing.
13. Section 4.2: Singling out Subplex in NLopt  is unjustified. NLopt, nevergrad [https://github.com/facebookresearch/nevergrad] and other packages contain dozens of relevant algorithms.
14. Section 4, last paragraph: The text does not clarify why "gradient free" = CRAB, and why the random choice is beneficial.
15. Section 4, discussion of "time continuous controls": The krotov package explicitly deals with discretized controls. Moreover, it is not clear why the resultant control fields would approximate a continuous control field (i.e. bandwidth constrained), as no smoothing penalty term was demonstrated. And should such a term be introduced, in fairness one must acknowledge a similar term has been used in GRAPE. So it is unclear why the Krotov method should have an advantage in discretized time-continuous controls.
Additional issues, which the Authors may choose to address, are:
16. Section 1: The paragraph starting with "Large Hilbert space dimensions" - have the authors tried cython?
17. Section 2, around Eq. (9): Is S(t) multiplied with the control fields? If so, are they bound? If they are unbounded, it is unclear why S(t) would enforce anything; and if they are bounded, the bounding mechanism is unclear.
18. Section 2.3: The statement "monotonic convergence is mathematically guaranteed" is claimed but not argued. At minimum, repeat citations appearing at the top of Section 2.2.
19. Section 3.1: How is the use of Krotov with QuTip similar / different than using GRAP or CRAB for the same task? A side-by-side or similar would be useful.
20. Section 3.1: "* objectives: a list of objectives ..." Why is H per objective? Isn't is identical for all?
21. Section 3.1: "* propagator: A routine that calculates ..." Why not use the QuTip propagator (I'm guessing there is a good reason - it would be helpful if you specify it).
22. Section 3.2: "H: dict(lambda_a =5, shape =S)": Unclear what is H (eps0??) and why is it a key in a dictionary.
23. Section 3.2: "The value of λa may be adjusted dynamically with respect to the rate of convergence" - How? Which function call?
24. Appendix A: The discussion of (Ana)conda is extraneous. Python environment management is a mess better left to programming forums.
25. Appendix B: Moving the complete example to the main text, would greatly help the reader in understanding the calling structure in its entirety. Then special cases can be specified.
26. Appendix B: The function "hamiltonian.functions def_control" and "S" are almost identical. Isn't there a way to guarantee the required consistency by having "hamiltonian" use "S"?
27. Appendix B: Several statements in the code are not explained, e.g. "chi_constructor = krotov . functionals . chis_re", "J_T= krotov . functionals . J_T_re".