Package: qtune
qtune Readme: IntroductionThe qtune package contains tools for the setup of a general optimization program. It is originally designed for the
automatic fine-tuning of semiconductor spin qubits based on gate defined quantum dots, but applicable to general
optimization problems with dependent target parameters.
An interface to the physical back-end must be provided. With this back-end, control
parameters (here assumed to be voltages) are set and target parameters are measured.Class names are writtenboldand functionscursivethroughout the readme. UML class diagrams are inserted to show
the heritage and dependencies, and UML activity diagrams visualize function calls.
The package abbreviations are pd for pandas and np for numpy.Installationqtune is compatible with Python 3.5+.
For development we recommend cloning the git repositoryhttps://github.com/qutech/qtuneand installing by:python setup.py developIt can also be installed as pip package:pip install qtuneInterface of the Physical Back-EndThe core features of this program package do not require a specific structure of the measurement software. This section
concerns only the required interface of the physical back-end.
TheExperimentclass serves as abstraction of the physical experiment. It provides an interface to the control
parameters with two functions calledread_gate_voltages() andset_gate_voltages(new_voltages). The functionset_gate_voltages(new_voltages) returns the voltages it has actually set to the experiment, which is useful if the
hardware connected to the physical experiment uses a different floating point accuracy, or theExperimentis
ordered to set voltages exceeding physical or safety limits.TheEvaluatorclass provides the functionevaluate() which returns a fixed number of parameters and a measurement
error, which is interpreted as the variance of the evaluation.Proposed Measurement and Evaluation StructureThe implementation of a physical back-end, as contained in the qtune package, should be regarded as proposal.TheExperimentprovides the functionmeasure(Measurement), which receives an instance of theMeasurementclass and returns the raw data.
TheMeasurementcontains a dictionary of data of any type used to define the physical measurement.
TheEvaluatorclass calls the functionExperiment.measure(Measurement) to initiate the physical
measurements. It contains a list ofMeasurementsand the analysis software required to extract the parameters from the raw data returned by the
experiment. This could be for example a fitting function or an edge detection.Parameter TuningThis section describes how the dependency between parameters is taken into account.
The parameters are grouped by instances of theParameterTunerclass. Each group is tuned simultaneously, i.e.
depends on the same set of distinct parameters. The dependencies are assumed always one directional and static. TheAutotunerstructures the groups of parameters in an hierarchy, which is represented as list ofParameterTuners.Consider the following example from the tuning of a quantum dot array.
Imagine the following hierarchy consisting of three groups of parameters i.e. threeParameterTuners:Contrast in the Sensing Dot SignalChemical Potentials / Positions of the Charge Stability DiagramTunnel CouplingsAll scans require a good contrast in the sensing dot for an accurate evaluation of the parameters. Therefore the
contrast in the sensing dot signal is the first element in the hierarchy. The measurement of tunnel couplings requires
knowledge of the positions of transitions in the charge diagram. If the chemical potentials change, the charge
diagram is shifted, therefore the position of the charge diagram i.e. the chemical potentials must be tuned before the
tunnel couplings.AParameterTunersuggests voltages to tune the parameters in his group.
It can be restricted to use any set of gates. It can also slice the voltage corrections
to restrict the step size so that the algorithm is less vulnerable to the non-linearity of the target parameters.
The tuning of a group of parameters does ideally not detune the parameters which the group depends on i.e. which are
higher in the hierarchy.TheAutotunerclass handles the coordination between the groups of parameters in the following sense. It decides which group of
parameters must currently be evaluated or tuned and calls theParameterTunerto evaluate the corresponding
group of parameters or to suggest new voltages. It also sets the new voltages on the Experiment.
It works as finite-state machine as described in the UML activity diagram below.Optimization AlgorithmsThe voltage steps of eachParameterTunerare calculated by its member instance of theSolverclass. This class
can implement any optimization algorithm e.g. Nelder-Mead or Gauss-Newton algorithm.
Gradient basedSolverslike the Gauss-Newton algorithm use a instance of theGradientEstimatorclass for the
calculation of the gradient of target parameter.TheGradientEstimatorsubclasses implement different methods for the gradient estimation. One example is the
Kalman filter in theKalmanGradientEstimator. This is an algorithm which calculates updates on the gradient by
interpreting each measurement as finite difference measurement with respect to the last voltages. The accuracy of the
parameter evaluation is then compared to the uncertainty of the estimation of the gradient in order to find the
most likely gradient estimation. Thereby, the gradient estimation is described as multidimensional normal distribution,
defined by a mean and a covariance matrix. If the covariance becomes to large in a certain direction, theKalmanGradientEstimatorsuggests a tuning step in the direction of the maximal covariance. This tuning step does not
optimize any parameter but should be understood as finite difference measurement.The crucial point in the optimization of non orthogonal systems is the ability to tune certain parameters without
changing the other ones. This requires communication between theSolverinstances. DifferentSolverscan
therefore share the same instances of theGradientEstimatorsso that they know the dependency of these parameters
on the gate voltages.Furthermore, theAutotunercommunicates which parameters are already tuned to theParameterTuners. AParameterTunercan share this information with it'sSolver, which then calculates update steps
in the null space of the gradients belonging to parameters which are tuned by anotherParameterTuners.
ASolveralso passes this information on to it'sGradientEstimators, which calculate the gradients only in the
mentioned null space.Getting StartedThe IPython notebook "setup_tutorial.ipynb" gives a detailed
tutorial for the setup of an automated fine-tuning program. The physical back-end is replaced by a simulation to enable
the tutorial to be executed before the connection to an experiment.
In this simulated experiment, a double quantum dot and a sensing dot are tuned. The tuning hierarchy is given byTheParameterTunersandSolverswhich are used in the setup serve as an illustrative example.
They are structured in the tuning hierarchy:the sensing dotthe x and y position of the charge diagramtwo parameters, being the inter dot tunnel coupling and the singlet reload timeThe gates of the sensing dot are assumed to have only an negligible effect on the positions and
parameters. Therefore theSolverof the sensing dot is independent of the others. The other gates are simultaneously
tuning the positions and parameters. The positions and parameters are tuned byParameterTunersrestricted to the
same gates and theirSolverinstances share allGradientEstimators. TheGradientEstimatorsbelonging to the
parameters estimate the gradients only in the null space of the gradients belonging to the positions.FeaturesStorageAfter each evaluation of parameters, change in voltages or estimation of gradients,
the full state of all classes except for the experiment is serialized and stored
in an HDF5 file. The full state of the program can be reinitialized from any library file. This way,
the program can be set back to any point during the tuning. TheHistoryclass
additionally saves all relevant information for the evaluation of the performance. TheHistoryclass can plot the
gradients, last fits, control and target parameters.GUIFor real-time plotting of parameters and gradients, the user can couple theHistoryand theAutotunerto the GUI. The GUI automatically stores the program data in the HDF5 library and lets the user start and
stop the program conveniently. The program can also be ordered to execute only one step at a time. The program is
logging its activity and the user can chose how detailed the logging describes the current activity by
setting the log level.Naming ConventionVoltagesare used in the Evaluator class to describe the voltages on the gates in the experiment.Positionsare an abstraction of gate voltages in the Gradient and Solver classes. These classes
could not only be used for the tuning algorithm but they could be reused in any gradient
based solving algorithm.Parameterscorrespond to properties of the physical experiment. They are extracted from the measurement data
by the Evaluator class and handed over to the ParameterTuner class.Valuesare the abstraction of parameters in the Gradient and Solver classes.Optionsdescribe the measurements in the Measurement class.LicenseCopyright (c) 2017 and later, JARA-FIT Institute for Quantum Information,
Forschungszentrum JÃ¼lich GmbH and RWTH Aachen University

This program is free software: you can redistribute it and/or modify
it under the terms of the GNU General Public License as published by
the Free Software Foundation, either version 3 of the License, or
(at your option) any later version.

This program is distributed in the hope that it will be useful,
but WITHOUT ANY WARRANTY; without even the implied warranty of
MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
GNU General Public License for more details.

You should have received a copy of the GNU General Public License
along with this program.  If not, see <https://www.gnu.org/licenses/>.