University of Southern California Dissertations and Theses

Minor embedding for experimental investigation of a quantum annealer

(USC Thesis Other)

Minor embedding for experimental investigation of a quantum annealer

PDF

Download a page range

Download transcript

Copy asset link

Request this asset

Transcript (if available)

Content Minor Embedding for Experimental Investigation of a Quantum Annealer by Zeve Akerling August, 2015 A Thesis Presented to the FACULTY OF THE USC GRADUATE SCHOOL UNIVERSITY OF SOUTHERN CALIFORNIA In Partial Fulfillment of the Requirements for the Degree MASTER OF SCIENCE (PHYSICS) The D-Wave Quantum Annealer is of interest both for its potential as a quantum information processing platform and as an engineered quantum system for controlled physical experimentation. In this work the minor embedding graph theory prob- lem is discussed in the context of mapping Ising model Hamiltonians onto quantum annealing devices. Some original implementations of minor embedding codes are then demonstrated. The work concludes by applying minor embedding to extend a quantum system identification experiment into a novel physical regime. 2 To my parents, for their support and patience. To Professor Ken Houk and Professor Robin Garrell, for inspiration that started it all. CONTENTS I. Introduction 4 A. Quantum Annealing and Adiabatic Quantum Computing 5 B. Minor Embedding for Quantum Annealing 6 C. Survey of Minor Embedding Methods 8 II. Discussion and Comparison of Implemented Methods 11 A. Simulated Annealing 11 B. Genetic Algorithm 14 C. Minor Embedding Performance Observations 17 III. Minor Embedding the Quantum Signature Hamiltonian 20 IV. Acknowledgments 23 V. References 23 VI. Appendix I: Code Listings 26 VII. Appendix II: GPLv2 or Later License 75 VIII. Appendix III: LGPLv3 or Later License 81 3 I. INTRODUCTION Study of quantum phenomena in bulk matter has been augmented in the past decades by experiments involving the preparation of first simple and then progressively more elaborate artificial quantum systems, often requiring exquisite control over the physical properties of the experiment on the nanoscopic or mesoscopic scale. There are many motivations driving development of ever more intricate controlled quantum constructs. Among these are studies of entangled system dynamics 1 , and the mechanism of decoherence in open quantum systems and allied questions regarding the quantum to classical transition 2,3 . In the limit of complexity such systems may even be considered a novel regime for testing the foundations of quantum mechanics. Construction of such devices is also of great interest in the field of quantum information processing, both for the practical consideration of building computational systems with fundamental speed advantages for certain classes of problems 4–6 , and for empirical investigation of certain theoretical problems in complexity theory and other aspects of computer science. Controlled quantum systems have been demonstrated in a variety of physical media, in disciplines including condensed matter 7,8 and atomic physics 9 . Certain aspects of preparing progressively more sophisticated quantum systems present novel intrinsic difficulties for the investigator, beyond those commonly associated with preparing even the simplest quantum system in a particular state. Prominent among these problems is one that, on its face, appears nearly tautological. In the limit of increasing com- plexity, composing the system in the experimental configuration becomes increasingly and ultimately prohibitively laborious, if all physical parameters of the elements of the system are to be manually adjusted by the experimenter. Ideally, it would be desirable to construct an experimental framework permitting the researcher any desired degree of control over the manifestation of physical features and phenomena of experimental interest in a controlled quantum system, while abstracting away all other aspects of the experimental configura- tion by constraining those parameters to values expected to minimize unwanted interference with the features and processes of interest. A first step towards such a system is presented here, for one class of devices using controlled quantum states, the quantum annealer as implemented in the D-Wave Systems apparatus. 4 A. Quantum Annealing and Adiabatic Quantum Computing Quantum Annealing (QA) is a physical process carried out on a system of interacting spin degrees of freedom governed by an Ising model Hamiltonian. It can be utilized as a computational process for solving a class of discrete optimization problems, Quadratic Unconstrained Binary Optimizations, that can be mapped onto the 2-local Ising model system of the annealer. This mode of computation is a continuous time quantum heuristic closely related to the adiabatic quantum computation model of Farhi et. al. 10 In Adiabatic Quantum Computing (AQC), a quantum system with a time varying Hamil- tonian is employed, where the ground state of the initial HamiltonianH 0 is easy to computa- tionally determine and physically prepare. The system Hamiltonian is slowly and smoothly varied toH τ , which is constructed such that the ground state ofH τ represents the optimal solution to a computational problem. A representative monotonic evolution of the Hamilto- nianH to this final stateH τ over the space of time bound by (0,τ) is compactly described by (1). H(t) = ( t τ )H τ + (1− t τ )H 0 (1) It can be shown via the Adiabatic Theorem that so long as τ is sufficiently large relative to the minimum energy gap between the instantaneous ground and first excited states during the evolution, a closed system remains in its instantaneous ground eigenstate throughout the process, and consequently its state at time τ is guaranteed to be the ground state representing the solution of the computational problem. However, this condition on τ has a highly nontrivial relationship with the structure and complexity of the physical system being evolved 11 , and is no longer sufficient to guarantee arrival at the desired final ground state when considered under more general applicability conditions involving decoherence in open systems 12 . The construction of the quantum annealing algorithm (QA), proposed by Finilla et. al. 13 , has much in common with AQC. They are similar in that QA evolves a system’s Hamiltonian from an easily computable and accessible initial form to a final form whose ground state represents the solution to a computational problem of interest. However, while the most general form of the AQC algorithm permits the initial and final Hamiltonians to be arbitrary, in QA as implemented in the D-Wave annealer,H 0 is a transverse magnetic field that places 5 the spins of the hardware’s Ising graph in a uniform superposition over the system’s states in the computational basis, and the final Hamiltonian is the Ising model Hamiltonian (2). H Ising = N X i=1 h i σ z i + N X i<j J ij σ z i σ z j (2) While this condition on its own would make QA a specialization of AQC, additionally and critically in QA it is not formally demanded that the time evolution of the Hamilto- nian be adiabatic. During its evolution, the QA system may experience nonadiabatic or thermally driven transitions to excited states, with the expectation that either the solution corresponding to the excited state found at the end time τ of the annealing process is suffi- ciently close to the global optimum to be a “good enough” solution to the posed problem, or that error correction will be employed to return the system to its ground state in the course of its dynamical evolution 14 . In the QA process, the experimenter has direct control over the Ising Hamiltonian local field strengths h i and couplings J ij , as well as the annealing sched- ule, the rates at which the initial transverse field and final Ising Hamiltonians are ramped down and up, respectively. The temperature of the environmental bath is also in principle directly controllable, although this is not practically accessible in the current D-Wave an- nealer setup. Whether the annealer is being used for quantum information processing or for direct physical experimentation, these parameters must be configured to perform the desired operation. B. Minor Embedding for Quantum Annealing For computational applications, much work has gone into developing techniques for map- ping problems onto the particular physical configurations of the hardware devices. One of these techniques, minor embedding, will be exhibited in this work in an alternative mode, describing at a higher level of abstraction the configuration of certain non-computational experiments employing quantum annealing setups. The decision version of finding the ground state of a non-planar Ising system is known to be NP-complete 15 and therefore any other NP-complete problem can be reduced to it, by way of gadgets that reduce multi-body interactions in the original problem’s clauses to constrained systems of the two-body interactions allowed in the Ising Model. Reductions of many NP-hard optimization problems to the Ising Model ground state optimization prob- 6 lem have been demonstrated 16 . The resulting Ising Model graph network representation of a computational problem may have a higher degree of connectivity than is available in a particular quantum annealer’s hardware graph. In such cases, it may still be possible to indirectly map the input graph onto the hardware graph if hardware graph vertices (qubits) can be merged to form a subgraph whose connectivity is isomorphic with the input graph’s, in a process known as minor embedding. Physically, this is accomplished by setting coupler values between adjacent qubits to stronger settings than used for the energy scale of the problem graph’s connectivity. With the proper selection of h i and J ij values, the result- ing hardware Ising Model Hamiltonian’s ground state is equivalent to that of the original problem’s ground state 17 . Since any problem graph that cannot be directly mapped onto a particular quantum annealer’s hardware Ising graph can only (possibly) be minor embedded, the computational cost of the embedding step must be taken into account when comparing the performance of quantum annealing on such problems against classical heuristics. As finding a minor embedding of an arbitrary problem graph H on an arbitrary hardware graph G is itself an NP hard optimization problem 18 , some considerable effort has been invested in finding faster embedding heuristics 18,19 , and in discovering hardware graph topologies that are intrinsically more conducive to minor embedding 20 . Below, a survey of existing work on the minor embedding problem is presented. Some original reference implementations of global optimization heuristics for the problem are then exhibited, with empirical observations on their performance. It is first worth noting that development of an improved code for optimization on a particular problem class or set of problem classes is itself a kind of search or optimization problem, over the configuration space of possible exact and heuristic codes. The degree of improvement that can be made is bounded by the no free lunch theorem of Wolpert and MacReady, 21,22 which forbids the construction of a universal optimizer that is superior to all other optimizers on all possible objective functions. This theorem is weaker than it may appear at first glance, as the set of all possible objective functions must include an overwhelming number of functions with a high degree of incompressible randomness (characterized by their Kolmogorov complexity), while “interesting” problem domains tend to have structure in their objective functions that can, at least in principle, be exploited better by some heuristics than others 23 . There has been recent work 24 in formally defining measures of the interestingness of a system 7 or problem. These measures appear to have applicability in both CS complexity theory and also in characterization of physical dynamical processes, an overlap that could make such measures of interest in the complexity analysis of AQC and QA, and in assessment of candidate problem domains for use with these computational processes. C. Survey of Minor Embedding Methods The idea of minor embedding an Ising model graph with an NP-hard ground state problem onto a simpler hardware graph was first proposed by Kaminsky et. al. 25 , who discussed the mapping of 3-local planar Ising model graphs onto a triangular hardware lattice via ferromagnetic coupling of physical qubits to effect graph contraction. However, this work did not present any procedure for actually performing this mapping process. Choi discussed 17 the minor embedding problem and demonstrated 20 that a complete graph K n of arbitrary size n can be decomposed and so minor embedded onto a sufficiently large perfect lattice of complete bipartite subgraphs K m,m . Embedding complete graphs (Fig 1) is particularly useful, as any arbitrary graph ofn vertices can be directly mapped onto the minor embedding solution for the complete graph of size n. (a) Complete GraphK 7 (b) Complete Bipartite Graph K 4,4 Figure 1 8 Limitations on fabrication technology make the perfect lattice assumed by Choi difficult to implement in practice. Hardware faults were addressed by Humbleet. al. 19 , who first present an exact algorithm for embedding a complete graphK cm+1 on a perfectm∗m square lattice of K c,c complete bipartite subgraphs. Their approach works by first embedding aK c+1 complete graph into a singleK c,c subgraph at one of the corners of the square lattice. The embedding is then iteratively constructed by extending the chains of ferromagnetically coupled qubits representing the current partial embedding into successive new rows and columns, while interleaving with new, previously unmapped input graph vertices. The process is repeated until K cm+1 is embedded. They then exhibit methods of augmenting this basic algorithm to cope with defects, the failed, unusable qubits in the hardware graph. One method excludes a particular qubit or qubits from every bipartite subgraph in the lattice, in the attempt to recover a perfect lattice with smaller bipartite subgraphs on which their original algorithm can be applied. A second attempts to combine parts of bipartite subgraphs possessing defects when such subgraphs are found on the diagonal of the lattice. Both approaches may be combined with elimination of successive outer bordering columns and rows in the grid, to see if excluding the defects in those regions can allow the exact algorithm to embed a larger K n starting from any of the four corners of the lattice. Humble et. al. observed the effectiveness of their fault mitigation strategies by running them on series of hardware graphs of linearly increasing lattice size m and fixed bipartite subgraph size K 4,4 , for different rates of randomly distributed qubit faults. They compared the largest complete graph embedding found on a particular hardware graph with faults against the largest embedding possible on the equivalent fault free hardware graph. The ratio of maximum embedding sizes for the best performing combination of their fault approaches was found to drop from around .75 on a 8x8 grid, to .4 for the largest graph they studied, a 32x32 grid, at the lowest qubit failure rate, .02, that they tried. Caiet. al. 18 present a minor embedding heuristic that can attempt to embed an arbitrary problem graph H on an arbitrary hardware graph G. Each heuristic step takes a partial embedding solution as an input, with the first step’s initialization performed by randomly mapping some subset of problem graph verticesy∈V (H) one to one onto a set of hardware qubits. The heuristic step attempts to improve on the input partial embedding by first erasing the set of qubit mappings, thevertex modelφ(y), representing one particular problem 9 graph vertex y in G. It then finds the optimal hardware vertex to become the new root for φ(y) with respect to the existing vertex models φ(x i ), for vertices x i ∈V (H) and adjacent toy. Here optimality could naively be defined as the root node location inG which requires the smallest number of physical hardware nodes to be mapped toφ(y), when using Dijsktra shortest path routing algorithms to connect via mapping the candidate root node to all the neighboring φ(x i ) necessary to represent the connectivity of vertex y in H. Instead, Cai et. al. borrow a technique used by many routing heuristics for conventional computing systems, and define optimality as the minimum summed path cost of routing to the φ(x i ), when permitting overlapping routings with an exponential cost function in the number of overlaps on a particular hardware node. Updating the optimal root node ofφ(y) may change the optimal root node location inG for any or all of the other vertex models φ(y i ) in G. The optimization step is repeated in round-robin fashion on eachφ(y i ) in succession, until some termination condition is reached. Generally, the heuristic continues some number of steps after the last improvement has been made, with improvement defined as either a reduction in the total number of mapping overlaps on hardware qubits, or alternatively a reduction in the total number of physical qubits used in the embedding. If the number of overlaps is zero at termination, then a valid embedding has been found. The heuristic is essentially a greedy one, taking the best available, minimally overlapping routing at every step, with the expectation that as the heuristic runs the number of overlaps will be driven to zero, and improvements made in the total number of qubits used. Cai et. al. attempt to avoid trapping in unsatisfactory local minima by accepting suboptimal improvements with a probability exponentially decaying in the cost of the disadvantage, as in simulated annealing. Cai et. al. make no mention of an annealing schedule for adjusting the probability of acceptance as a function of step number or other parameters. Cai et. al. also describe a variant of this heuristic, which attempts to reduce the cost of updating vertex model root locations by using a multisource approach. This method looks for an improved root node location forφ(y) by growing graph trees outwards from allφ(y)’s neighboring vertex models φ(x i ) simultaneously, using the A* algorithm, and terminating when the intersection of theφ(x i )’s sets of accumulated hardware nodes becomes non-empty, the resulting node becoming the new root node for φ(y). 10 Cai et. al. report performance results for minor embedding on ideal 8x8 and 16x16 square lattices ofK 4,4 bipartite subgraphs. They succeeded in embedding 33 node complete graphs and up to 100 node grid and cubic (degree 3) graphs on the 8x8 lattice with high probability of success, and up to 200 node or larger cubic graphs with lower rate of success in the 16x16 lattice. Interestingly, their faster heuristic variant, while reaching termination five times faster on cubic hardware graphs than the original, has one fifth the success rate on average, suggesting a strict tradeoff on search time versus success probability. A heuristic approach such as Cai et. al.’s vertex model embedder could reasonably be expected to display greater robustness in the face of error than the exact algorithm of Humble et. al. In fact, the Cai et. al. embedding heuristic represents the best performing code currently published in the literature, to the knowledge of the author. This discussion on minor embedding heuristics concludes with demonstrated implementation and comparison of minor embedding heuristics based on simulated annealing, genetic algorithms, and a simplified reference implementation of the vertex model embedder of Cai et. al. This comparison results in general observations on certain elements of embedding heuristics that appear critical for effectiveness. II. DISCUSSION AND COMPARISON OF IMPLEMENTED METHODS A. Simulated Annealing The classical simulated annealing (SA) heuristic makes a convenient reference or base- line implementation for minor embedding, due to the obvious connections with quantum annealing, and also because with respect to the set of general purpose global optimization heuristics, SA is often among the easiest to implement for a particular problem class. Like all global optimization heuristics, SA searches over a space 26 of potential solutions to the posed problem. The space explored is one of legal solution configurations, with legality as defined in some rule set constructed by the heuristic designer. The solution configuration space is spanned by some chosen set of variable parameters. The objective, as in all global optimizers, of the SA heuristic is to find the best possible solution as evaluated by a cost function. 11 What is unique to SA (and its derivatives) is the method by which the search space is traversed. At initialization a starting solution is chosen by a random sampling or some other heuristic. A set of proposed neighboring solutions are generated by small perturbations of one or more of the starting solution’s parameters. One of these proposed solutions is randomly selected, and the cost function is evaluated for the proposed solution. If the proposed solution is an improvement over the existing one, it is accepted and replaces the existing solution. If it has a higher cost, then it is accepted with probability e − 4E T , where 4E is the difference in cost between the two solutions, and T is a parameter referred to as a temperature. The steps of generating new proposed solutions neighboring the current solution, and probabilistically accepting them as the new solution, is then repeated until the heuristic terminates. In analogy to the physical process of annealing, the temperature parameter of the acceptance probability is slowly decreased to zero over the course of the SA process, on a schedule which is a function of the number of steps taken, and often of the quality of the solutions that are being found in the local part of the search space. SA can be formally described as a Markovian process, and it can be demonstrated 27 that the SA search will converge to the globally optimum solution in the space, in the limit of a large number of search steps and sufficiently gradual cooling schedules. Unfortunately, for problems of sufficient complexity for practical interest, the globally optimum solution often cannot be found by SA in a usefully short period of time. Nonetheless, SA is often employed for optimization on problems where a “best possible” solution that can be found by a heuristic in a reasonable search time is still desirable. The SA approach to minor embedding discussed here is implemented in listing 1 of Appendix I. The toplevel function, simple sim ulated annealing(), implements a temperature scheduled annealing process and selects an updated solution as described above. Generation of each set of new candidate solutions is performed by blob p erturb graph(). Permitted perturbations act on vertex models of physical qubits that map to one logical input node. Mappings on physical qubits may be 1.) moved from their current location in a vertex model to an empty available space elsewhere on the border of the same vertex model, 2.) added to an empty space bordering the vertex model, if not in excess of a maximum number of permitted nodes, or 3.) deleted from the vertex model if multiple physical nodes are currently present. Legal perturbations cannot split a vertex model into two or more unconnected components, but may break the connectivity of vertex models with each other in the overall 12 embedding, permitting vertex model mappings to float around the configuration space. The annealing process is run for some fixed number of steps. In this implementation, candidate solutions are evaluated based on the total number of physical qubits used. The best scoring solution found after a fixed number of annealing steps is returned. The heuristic is initialized by a process that random walks over the hardware graph, directly mapping each input node to one hardware node. Additionally, constraints may be placed on the optimization problem, requiring that a solution be found subject to the requirement that a particular hardware node is mapped to a particular input Ising model vertex. A single constraint associated with a particular input vertex will have the effect of pinning the associated vertex model to a particular region of the physical device, while additional constraints will influence the topology or shape of that vertex model in any legal embedding ultimately found. For all that, the reference design of the SA heuristic implemented here performs startlingly poorly on the minor embedding problem. Results are presented in figure 2 for minor embed- ding cubic and complete graphs onto the USC D-Wave Two quantum annealer’s “Chimera” hardware graph, an 8x8 square lattice of K 4,4 bipartite subgraphs with a 1% qubit fault rate. Embedding runtimes are averaged over a minimum of six runs per test input graph. Annealing was run for a fixed 50,000 steps for all cases. This SA heuristic is only capable of finding legal embedding solutions, when limited to low multi-hour runtimes on a single core of a 1.7 GHz CPU, for the smallest members of series of cubic graphs (graphs whose nodes all have three edges each) and complete graphs. Results are shown up to the largest prob- lem size where the embedder was capable of finding a solution. A genetic algorithm based heuristic, presented below, takes a different approach to the minor embedding problem. 13 4.0 4.5 5.0 5.5 6.0 6.5 7.0 7.5 8.0 Embedding Problem Size (Qubits) 50 100 150 200 250 300 Computation Time (s) Simulated Annealing Minor Embedding Computation Time vs. Minor Embedding Problem Size SA cubic SA complete Figure 2: Performance benchmarking for a Simulated Annealing minor embedder. Average runtimes are presented for 1) cubic graphs, whose vertices all have three edges, and 2) complete graphs, each of whose vertices is connected to all other vertices in the graph. Annealing was run for a fixed 50,000 steps in all cases. Runtimes are values averaged over a minimum of 6 successful runs. Problem size is the number of qubits in the input problem Ising model’s graph. B. Genetic Algorithm Genetic algorithms are another approach to global optimization. An initial population of multiple solutions are chosen by random sampling of the configuration space, or some other heuristic approach. Some subset of these solutions with the best fitness as defined by the cost function is selected from which to generate the next generation of solutions. Features of multiple parent solutions are combined by a crossover operator to form a child solution. This child solution may be further mutated by an operator that acts like the permutation of the 14 simulated annealing algorithm, to allow exploration of novel regions of the search space. One proposed rationale 28 for the method of operation of genetic algorithms is that the crossover operator allows a unique approach to exploiting structure in the problem and the search space. The crossover operator permits exploration of different combinations of good partial solutions contained in the current population of the most fit individual solutions found. It is contended that on appropriate problem domains these partial solutions can be combined and ultimately extended into a complete and satisfactory solution to the full optimization problem. The particular approach to GA implemented here in listing 2 of Appendix I for the minor embedding problem is NSGA-II 29 , as implemented in the DEAP evolutionary computation package 30 . NSGA-II attempts to find a set of non-dominated or Pareto-optimal solutions, which cannot be improved on with respect to any particular objective without diminishing their fitness with respect to other objectives. It is frequently applied to problem domains requiring multi-objective optimization over partially or wholly antagonistic objectives. This genetic algorithm minor embedding heuristic initially chooses single qubits as root locations for the vertex models corresponding to the vertices of the input Ising Hamiltonian. This is done either by random selection or by attempting to fit the input and hardware graphs to a metric space, overlaying them, and mapping each input node to the unmapped hardware qubit that is nearest by metric distance. This latter approach is proposed as a method of exploiting the structure of sparsely connected input and hardware graphs to find better initializations for the optimization problem. The heuristic then connects these root nodes using a shortest path router, with the order of connections chosen serving as the individual phenotype for purposes of crossover and mutation. The router may either connect all root nodes to each other, permitting overlapping mappings on some nodes, or connect as many root nodes together as possible without overlapping. Either the number of overlaps or the number of missing connections is counted for the routing fitness. This connection fitness is taken as one objective, and the total number of physical qubits used as another. Since it is much easier to find a legal embedding in the configuration space that uses a larger number of physical qubits than one using fewer, these two objectives are at least partially antagonistic. Results are presented in figure 3 for minor embedding onto the USC D-Wave Two quantum annealer’s “Chimera” hardware graph, with runtimes averaged over ten independent runs per test graph embedded. For each run, GA optimization was performed over 100 generations, 15 with an initial population size of 50 individuals. If a single 100 generation GA optimization failed to find a legal solution the process was repeated until a successful embedding was found, and the process times added cumulatively to compute total runtime for a single successful run. Results are shown up to the largest problem size where the embedder was capable of finding a solution. The reference genetic algorithm minor embedder implemented here still exceeds multi-hour runtimes for relatively small graph sizes. 4 5 6 7 8 9 10 Embedding Problem Size (Qubits) 0 5 10 15 20 25 30 35 Computation Time (s) Genetic Algorithm Minor Embedding Computation Time vs. Minor Embedding Problem Size GA cubic GA grid GA complete Figure 3: Performance benchmarking for a Genetic Algorithm minor embedder. Average runtimes are presented for 1) cubic graphs, whose vertices all have three edges, 2) grid graphs, square lattices of vertices connected to nearest neighbors, and 3) complete graphs, each of whose vertices is connected to all other vertices in the graph. Runtimes are averaged over 10 independent successful embeddings. Each run was repeated until a successful embedding was found, or until runtime exceeded multiple hours. Problem size is the number of qubits in the input problem Ising model’s graph. 16 C. Minor Embedding Performance Observations 0 5 10 15 20 25 Embedding Problem Size (Qubits) 0 500 1000 1500 2000 2500 3000 3500 Computation Time (s) Vertex Model Minor Embedding Computation Time vs. Minor Embedding Problem Size Vertex cubic Vertex grid Vertex complete Figure 4: Performance benchmarking for a Vertex Model minor embedder. Average runtimes are presented for 1) cubic graphs, whose vertices all have three edges, 2) grid graphs, square lattices of vertices connected to nearest neighbors, and 3) complete graphs, each of whose vertices is connected to all other vertices in the graph. Runtimes are averaged over 10 independent successful embeddings. Each run was repeated until a successful embedding was found, or until runtime exceeded multiple hours. Problem size is the number of qubits in the input problem Ising model’s graph. A reference re-implementation of Cai et. al.’s vertex minor embedder was also developed, for comparison with the SA and GA minor embedders above. As with the SA and GA embedders, graphs were minor embedded onto the USC D-Wave Two quantum annealer’s “Chimera” hardware graph. Runtimes were averaged over 10 successful runs, with each optimization repeated until a legal embedding was found. Once an embedding was found, 17 the cumulative runtime over these optimizations was computed, becoming the runtime for a single successful run. Results are shown up to the largest problem size where the embedder was capable of finding a solution, in figure 4. While the GA embedder is faster in absolute terms than the vertex model embedder on problem sizes up to 9 or 10 input graph qubits, it stalls on larger problem sizes, and the vertex model embedder is able to find legal solutions for significantly larger problems on all three types of Ising model problem graphs. It is therefore likely that the vertex model embedder runtime scales better with problem size than either the GA or SA embedders. The classical simulated annealing algorithm minor embedder, while free to move its ver- tex models about the configuration space, only performs local updates. It is incapable of exploiting knowledge of nonlocal problem structure to eliminate regions of the search space, as a heuristic employing a shortest path router like Dijkstra’s or A* can. The genetic al- gorithm minor embedder does employ routing, but its vertex model root node locations are fixed at the heuristic’s initialization time and cannot be updated during the run. Caiet. al.’s vertex model embedder heuristic has a successful approach to both dynamically improving root node locations and routing between them to generate an embedding. Unfortunately, employing their combined mechanism for root node update and routing is expensive. Cai et. al. report a worst-case time complexity of O(n H n G e H (e G +n G log(n G ))), where n and e are total numbers of nodes and edges in a graph, respectively. As observed by Cai et. al. themselves, it would be desirable to decouple the problem of finding good root node locations from that of routing between those root nodes to generate a legal and good minor embedding. Certain geometric approaches may be helpful for approaching both problems. An argument in support of this approach may be drawn from another technique in global optimization, smoothing. In global optimization on a continuous objective function, it is often helpful to apply a smoothing function to the objective, ironing out local minima. This may make it easier for the optimizing heuristic to navigate the energy surface of the objective function or may even reduce the original problem to a convex optimization problem to which efficient techniques such as Newton-Raphson or PRCG may be applied. Such smoothing techniques may seem irrelevant for a discrete optimization problem such as minor embedding. However, there are ways to transform discrete graph theory optimization problems into geometric problems on continuous domains. 18 The geometric overlay root node initialization implemented for the genetic algorithm embedder discussed above is a simple example. It attempts to solve the problem of selecting good root nodes by employing a layout heuristic, a technique more commonly used for 2-D or 3-D visualization of a graph structure. Here, this layout algorithm is used in a more general sense to map or project the problem Ising model and hardware graphs into a continuous metric space. Once embedded, metric space properties of intra-node distance can be cheaply computed. Root nodes for the GA embedding are then selected by overlaying the input Ising model graph and the hardware graph layouts, and choosing the hardware node nearest to each input graph node as a root node, with the hope that this can exploit global structural properties in sparsely connected graphs to select better root node locations. In this case, layout is performed by the NetworkX implementation of the Fruchterman-Reingold layout algorithm, which itself generates a geometric layout by simulated annealing minimization over spring constant force potentials assigned between the nodes of the graph. Unfortunately, at least this implementation of overlay initialization did not lead to significantly improved performance for the GA embedder on sparsely connected cubic and grid graphs. More sophisticated approaches to geometric approximations for graph optimization prob- lems are suggested by investigations by Wang et. al. 31 into constructing tests of the em- beddability of one graph onto another, using a graph theoretical property called treewidth. They demonstrate a linear time approach to estimating the treewidth of a graph, where ex- act determination of the treewidth of a graph is an NP-Complete problem. Their estimation relies on computing the Ollivier-Ricci curvature for the graph, a generalization of the Ricci curvature of differential geometry to discrete graph structures. It should be noted that while significant effort was expended to optimize the perfor- mance of each of the minor embedding codes demonstrated here, it is of course possible that a suboptimal design choice may be holding one or more of these codes back from their true potential, invalidating these phenomenonological observations on performance and the importance of decoupling root node selection from routing. The explanations here for the relative performance of these minor embedding codes could in a sense be falsified if future implementations of minor embedding codes architected to exploit the perceived advantage of this decoupling fail to improve over the best known minor embedding code performance. 19 III. MINOR EMBEDDING THE QUANTUM SIGNATURE HAMILTONIAN The D-Wave annealer is a complicated engineered system, whose governing Hamiltonian cannot at the present time be elucidated by direct methods such as quantum tomography. Considerable effort has gone into constructing increasingly sophisticated experiments to determine whether the system dynamics of the D-Wave annealer are better described by a quantum annealing model, or one of a number of proposed classical models. Much evidence supporting the quantum annealing model has been derived by experimen- tal and theoretical studies of the quantum signature Hamiltonian, first proposed by Boixo et. al. 32 The quantum signature Hamiltonian is a family of Ising model systems with manifoldly degenerate ground states. Specializing to the 8-qubit quantum signature system, there are 16 so-called clustered ground states that are related to each other by sequences of single spin flips, and a 17th, isolated state differing from each of the other 16 by four spin flips. For an Ising model evolving under a classical annealing Hamiltonian, the expected population statistics show the probability P I of the isolated state appearing as greater than the prob- ability P C of a single cluster state, when averaged over all 16 clustered states. Quantum annealing predicts thatP I is suppressed relative toP C . In their initial experiment, Boixo et. al. observed suppression of the isolated state. Albash et. al. 33 generalized this experiment and observed suppression of the isolated state over a series of progressively larger quan- tum signature Ising systems, and over a range of energy scales and proportional thermal noise effects. Behavior of the excited state of the system was also studied. The extended experimental regime and consideration of the excited state was sufficient to rule out many competing classical models for the dynamic behavior of the D-Wave annealer. A variation on the experimental methodology of Albash et. al. is presented. Albash et. al. directly embedded a series of Ising models employing larger numbers of qubits, resulting in systems with 2 N/2 clustered ground states, withN the number of vertices in the quantum signature Ising model graph. Here, a series of minor embeddings of the original 8- qubit quantum signature Hamiltonian were generated, each utilizing more and more physical qubits than the 8 needed for direct mapping (figure 5) in order to study the effect of resource inefficient or “wasteful” minor embeddings on the isolated state suppression signature. This was accomplished by re-running a vertex model minor embedding heuristic multiple times, 20 Figure 5: Representative Minor Embedding of the 8 Qubit Quantum Signature Hamiltonian each time with an increasing number of user mapping constraints. This forced the minor embedder to find embedding solutions requiring progressively more physical qubits. These minor embeddings of the 8-qubit signature Hamiltonian were run on the USC Vesuvius D-Wave annealer, and results are presented in figure 6. For this experiment, no particular control was exerted over the distribution of vertex model sizes in the embeddings. For each embedding size, 10 programming cycles of 4000 readouts each were performed, for each of two gauge selections. Annealing and programming thermalization times of 1 ms were used, and a readout thermalization time of 5 microsec- onds. Strengths of ferromagnetic couplings between physical qubits in a vertex model were optimized by a D-Wave API call, which also decoded the embeddings and rejected readouts with contradicting, tied readout values on individual physical qubits of a vertex model. For each embedding size, mean P I /P C ratios were computed for each programming cycle, aver- aging over the two gauge choices. Standard deviations were computed over the population of programming cycles at each embedding size. Suppression of the isolated state was observed for minor embeddings up to 47 qubits in size, and there was no pronounced variation in the suppression effect observed up to this embedding size, the largest generated and run on hardware in this experiment. It is tempting to assume that an embedding using more physical qubits must experience more interaction with the environment than one using fewer qubits. If so, this experimental approach could then provide an additional way to effectively tune the strength of decoherence 21 5 10 15 20 25 30 35 40 45 50 Number of Physical Qubits 0.05 0.00 0.05 0.10 0.15 0.20 0.25 p I /p C Isolated/cluster probability ratio vs minor embedding size (number of physical qubits). Error bar = one standard deviation over population of programming cycles Figure 6: Observed Suppression in Minor Embedding of the 8 Qubit Quantum Signature Hamiltonian effects in an engineered quantum system. To make such a claim sufficiently rigorous, the minor embedding experiment reported above would need to be augmented by manually scanning over a range of ferromagnetic coupling strengths in the vertex models, in addition to more tightly controlling the distribution of vertex model sizes in the embeddings. Increasingly sophisticated experiments will be performed for characterization of engi- neered quantum devices, such as the D-Wave annealer. These experiments will be con- structed both for purposes of pure inquiry into foundational aspects of quantum theory, such as decoherence, as well as for engineering considerations in optimizing device perfor- mance. The embedding codes discussed here, and their demonstration by application to such an experiment, may represent a step towards a new supporting infrastructure for such investigations. 22 IV. ACKNOWLEDGMENTS Professor Daniel Lidar, for all of his guidance and particularly for his suggestions on the Simulated Annealing and Genetic Algorithm approaches. Professor Stephan Haas and Professor Federico Spedalieri, for their time and assistance. Dr. Itay Hen, for suggestions on the Simulated Annealing and Genetic Algorithm ap- proaches. Dr. Walter Vinci, for helpful conversations regarding parameter setting and the quantum signature Hamiltonian. Dr. Tameem Albash, for support on classical simulations. I would also like to thank The Aerospace Corporation for fellowship and moral support. Dr. Martin Panevsky, for helpful conversations regarding minor embedding the quantum signature Hamiltonian. Dr. Evan Ulrich, for useful feedback on my defense presentation. Dr. Walter Lillo, for helpful conversations regarding smoothing functions for global opti- mization. V. REFERENCES 1 C. A. Sackett, D. Kielpinski, B. E. King, C. Langer, V. Meyer, C. J. Myatt, M. Rowe, Q. A. Turchette, W. M. Itano, D. J. Wineland, and C. Monroe, “Experimental entanglement of four particles,” Nature 404, 256–259 (2000). 2 M. Brune, E. Hagley, J. Dreyer, X. MaÃőtre, A. Maali, C. Wunderlich, J. M. Raimond, and S. Haroche, “Observing the Progressive Decoherence of the “Meter” in a Quantum Measurement,” Physical Review Letters 77, 4887–4890 (1996). 3 S. Haroche, “Entanglement, mesoscopic superpositions and decoherence studies with atoms and photons in a cavity,” Physica Scripta 1998, 159 (1998). 4 A. Aspuru-Guzik, A. D. Dutoi, P. J. Love, and M. Head-Gordon, “Simulated quantum computation of molecular energies,” Science 309, 1704–1707 (2005). 5 P. Shor, “Polynomial-Time Algorithms for Prime Factorization and Discrete Logarithms on a Quantum Computer,” SIAM Journal on Computing 26, 1484–1509 (1997). 23 6 A. W. Harrow, A. Hassidim, and S. Lloyd, “Quantum algorithm for linear systems of equations,” Physical review letters 103, 150502 (2009). 7 V. Bouchiat, D. Vion, P. Joyez, D. Esteve, and M. H. Devoret, “Quantum coherence with a single Cooper pair,” Physica Scripta 1998, 165 (1998). 8 M. Bayer, P. Hawrylak, K. Hinzer, S. Fafard, M. Korkusinski, Z. R. Wasilewski, O. Stern, and A. Forchel, “Coupling and Entangling of Quantum States in Quantum Dot Molecules,” Science 291, 451–453 (2001). 9 J. I. Cirac and P. Zoller, “Quantum Computations with Cold Trapped Ions,” Physical Review Letters 74, 4091–4094 (1995). 10 E. Farhi, J. Goldstone, S. Gutmann, J. Lapan, A. Lundgren, and D. Preda, “A Quan- tum Adiabatic Evolution Algorithm Applied to Random Instances of an NP-Complete Problem,” Science 292, 472–475 (2001). 11 D. A. Lidar, A. T. Rezakhani, and A. Hamma, “Adiabatic approximation with exponential accuracy for many-body systems and quantum computation,” Journal of Mathematical Physics 50, 102106 (2009). 12 M. S. Sarandy and D. A. Lidar, “Adiabatic Quantum Computation in Open Sys- tems,” Physical Review Letters95 (2005), 10.1103/PhysRevLett.95.250503, arXiv: quant- ph/0502014. 13 A. B. Finnila, M. A. Gomez, C. Sebenik, C. Stenson, and J. D. Doll, “Quantum annealing: a new method for minimizing multidimensional functions,” Chemical physics letters 219, 343–348 (1994). 14 K. L. Pudenz, T. Albash, and D. A. Lidar, “Error-corrected quantum annealing with hundreds of qubits,” Nature communications 5 (2014). 15 B. A. Cipra, “The Ising model is NP-complete,” SIAM News 33, 1–3 (2000). 16 A. Lucas, “Ising formulations of many NP problems,” Frontiers in Physics 2 (2014), 10.3389/fphy.2014.00005, arXiv: 1302.5843. 17 V. Choi, “Minor-embedding in adiabatic quantum computation: I. The parameter setting problem,” Quantum Information Processing 7, 193–209 (2008). 18 J. Cai, W. G. Macready, and A. Roy, “A practical heuristic for finding graph minors,” arXiv preprint arXiv:1406.2741 (2014). 19 C. Klymko, B. D. Sullivan, and T. S. Humble, “Adiabatic quantum programming: minor embedding with hard faults,” Quantum information processing 13, 709–729 (2014). 24 20 V. Choi, “Minor-embedding in adiabatic quantum computation: II. Minor-universal graph design,” Quantum Information Processing 10, 343–353 (2011). 21 D. H. Wolpert and W. G. Macready, “No free lunch theorems for search,” Tech. Rep. (Technical Report SFI-TR-95-02-010, Santa Fe Institute, 1995). 22 D. H. Wolpert and W. G. Macready, “No free lunch theorems for optimization,” Evolu- tionary Computation, IEEE Transactions on 1, 67–82 (1997). 23 T. M. English, “Optimization is easy and learning is hard in the typical function,” in Evolutionary Computation, 2000. Proceedings of the 2000 Congress on, Vol. 2 (IEEE, 2000) pp. 924–931. 24 S. Aaronson, S. M. Carroll, and L. Ouellette, “Quantifying the Rise and Fall of Complexity in Closed Systems: The Coffee Automaton,” arXiv preprint arXiv:1405.6903 (2014). 25 W. M. Kaminsky, S. Lloyd, and T. P. Orlando, “Scalable Superconducting Architecture for Adiabatic Quantum Computation,” arXiv:quant-ph/0403090 (2004), arXiv: quant- ph/0403090. 26 While it is not technically correct to describe the set of solutions of a discrete optimization problem as a space, we will accept the common relaxation of terminology for greater convenience in discussion. 27 B. Hajek, “Cooling schedules for optimal annealing,” Mathematics of operations research 13, 311–329 (1988). 28 D. E. Goldberg and J. H. Holland, “Genetic algorithms and machine learning,” Machine learning 3, 95–99 (1988). 29 K. Deb, S. Agrawal, A. Pratap, and T. Meyarivan, “A fast elitist non-dominated sorting genetic algorithm for multi-objective optimization: NSGA-II,” Lecture notes in computer science 1917, 849–858 (2000). 30 F.-A. Fortin, D. Rainville, M.-A. G. Gardner, M. Parizeau, C. GagnÃľ, and others, “DEAP: Evolutionary algorithms made easy,” The Journal of Machine Learning Research 13, 2171–2175 (2012). 31 C. Wang, E. Jonckheere, and T. Brun, “Ollivier-Ricci curvature and fast approximation to tree-width in embeddability of QUBO problems,” in Communications, Control and Signal Processing (ISCCSP), 2014 6th International Symposium on (IEEE, 2014) pp. 598–601. 32 S. Boixo, T. Albash, F. M. Spedalieri, N. Chancellor, and D. A. Lidar, “Experimental signature of programmable quantum annealing,” Nature communications 4 (2013). 25 33 T. Albash, W. Vinci, A. Mishra, P. A. Warburton, and D. A. Lidar, “Consistency tests of classical and quantum models for a quantum annealer,” Physical Review A 91, 042314 (2015). 34 D. A. Schult and P. J. Swart, “Exploring network structure, dynamics, and function using NetworkX,” in Proceedings of the 7th Python in Science Conferences (SciPy 2008), Vol. 2008 (2008) pp. 11–16. 35 G. Csardi and T. Nepusz, “The igraph software package for complex network research,” InterJournal, Complex Systems 1695, 1–9 (2006). 36 S. Van Der Walt, S. C. Colbert, and G. Varoquaux, “The NumPy array: a structure for efficient numerical computation,” Computing in Science & Engineering 13, 22–30 (2011). VI. APPENDIX I: CODE LISTINGS Citation and Licensing notice: in the following code listings, the anneal.py module em- ploys the NetworkX 34 graph theory package. The tsp embed.py employs the NetworkX and igraph 35 graph theory packages. The tsp embed.py module also employs the DEAP genetic algorithm package 30 , and the NumPy mathematical package 36 . NetworkX is licensed under the three-clause BSD license, and igraph is licensed under GPLv2. DEAP is licensed under LGPLv3. NumPy is licensed under the three-clause BSD license. The entirety of the GPLv2 license is reproduced in Appendix II. The entirety of the LGPLv3 license is reproduced in Appendix III. 26 Listing 1: anneal.py: annealing based minor embedding heuristic 1 3 5 ””” 7 The anneal module provides the functionality needed to implement the vertex model minor embedding heuristic of 9 Cai , Macready and Roy, ArXiv:1406.2741. 11 The module is released under the 3−Clause BSD license . It links to the NetworkX library , which is separately released under the 3−Clause BSD license . See ”NetworkX Library license ,” below. 13 Copyright (c) 2015, Zeve Akerling 15 All rights reserved . 17 Redistribution and use in source and binary forms , with or without modification , are permitted provided that the following conditions are met: 19 1. Redistributions of source code must retain the above copyright notice , this list of conditions and the following 21 disclaimer . 23 2. Redistributions in binary form must reproduce the above copyright notice , this list of conditions and the following 27 disclaimer in the documentation and/or other materials provided with the distribution . 25 3. Neither the name of the copyright holder nor the names of its contributors may be used to endorse or promote products 27 derived from this software without specific prior written permission . 29 THIS SOFTWARE IS PROVIDED BY THE COPYRIGHT HOLDERS AND CONTRIBUTORS ”AS IS” AND ANY EXPRESS OR IMPLIED WARRANTIES, INCLUDING, BUT NOT LIMITED TO, THE IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS FOR A PARTICULAR PURPOSE ARE 31 DISCLAIMED. IN NO EVENT SHALL THE COPYRIGHT HOLDER OR CONTRIBUTORS BE LIABLE FOR ANY DIRECT, INDIRECT, INCIDENTAL, SPECIAL, EXEMPLARY, OR CONSEQUENTIAL DAMAGES (INCLUDING, BUT NOT LIMITED TO, PROCUREMENT OF SUBSTITUTE GOODS OR 33 SERVICES; LOSS OF USE, DATA, OR PROFITS; OR BUSINESS INTERRUPTION) HOWEVER CAUSED AND ON ANY THEORY OF LIABILITY, WHETHER IN CONTRACT, STRICT LIABILITY, OR TORT (INCLUDING NEGLIGENCE OR OTHERWISE) ARISING IN ANY WAY OUT OF THE USE 35 OF THIS SOFTWARE, EVEN IF ADVISED OF THE POSSIBILITY OF SUCH DAMAGE. 37 ======================================================================================================================== 39 Network X Citation : 41 Aric A. Hagberg , Daniel A. Schult and Pieter J. Swart , Exploring network structure , dynamics , and function using NetworkX in Proceedings of the 7th Python in Science Conference ( SciPy2008) , Gael Varoquaux, Travis Vaught, 28 43 and Jarrod Millman (Eds) , (Pasadena , CA USA) , pp. 11−15, Aug 2008 45 NetworkX Library license : 47 This code links to the NetworkX library , released under the 3−clause BSD license with the terms below. 49 Copyright (C) 2004−2012, NetworkX Developers 51 Aric Hagberg <hagberg@lanl.gov> Dan Schult <dschult@colgate .edu> 53 Pieter Swart <swart@lanl.gov> All rights reserved . 55 Redistribution and use in source and binary forms , with or without 57 modification , are permitted provided that the following conditions are met: 59 ∗ Redistributions of source code must retain the above copyright 61 notice , this list of conditions and the following disclaimer . 63 ∗ Redistributions in binary form must reproduce the above copyright notice , this list of conditions and the following 65 disclaimer in the documentation and/or other materials provided with the distribution . 67 ∗ Neither the name of the NetworkX Developers nor the names of its 69 contributors may be used to endorse or promote products derived from this software without specific prior written permission . 71 29 73 THIS SOFTWARE IS PROVIDED BY THE COPYRIGHT HOLDERS AND CONTRIBUTORS ”AS IS” AND ANY EXPRESS OR IMPLIED WARRANTIES, INCLUDING, BUT NOT 75 LIMITED TO, THE IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS FOR A PARTICULAR PURPOSE ARE DISCLAIMED. IN NO EVENT SHALL THE COPYRIGHT 77 OWNER OR CONTRIBUTORS BE LIABLE FOR ANY DIRECT, INDIRECT, INCIDENTAL, SPECIAL, EXEMPLARY, OR CONSEQUENTIAL DAMAGES (INCLUDING, BUT NOT 79 LIMITED TO, PROCUREMENT OF SUBSTITUTE GOODS OR SERVICES; LOSS OF USE, DATA, OR PROFITS; OR BUSINESS INTERRUPTION) HOWEVER CAUSED AND ON ANY 81 THEORY OF LIABILITY, WHETHER IN CONTRACT, STRICT LIABILITY, OR TORT (INCLUDING NEGLIGENCE OR OTHERWISE) ARISING IN ANY WAY OUT OF THE USE 83 OF THIS SOFTWARE, EVEN IF ADVISED OF THE POSSIBILITY OF SUCH DAMAGE. ====================================================================================================================== 85 ””” 87 import networkx as nx 89 import distutils . util as config util import utils 91 import quench map import math 93 import random import time 95 97 def simple simulated annealing(hardware graph , input graph , map config , constraint dict , t0 , app): ”””performs a basic global optimization mapping using classical simulated annealing . Takes a logical 30 99 input graph and a hardware connectivity graph hardware graph as inputs , along with a dictionary containing configuration options for the map process , and a reference to the Cement CLI application instance . 101 If annealing is successful , returns a graph containing the optimal mapping. Otherwise , returns None. 103 :param input graph : :type input graph : NetworkX undirected graph 105 :param hardware graph: :type hardware graph: NetworkX undirected graph 107 :param map config: :type map config: dictionary of configuration parameters (see quench config file ) 109 :param constraint dict : :type constraint dict : dictionary of mapping constraints (see quench qcf . ini file ) 111 :param app: :type app: Cement CLI application object 113 : rtype : NetworkX undirected graph 115 ””” 117 #Initialize local configuration parameters from configuration dict 119 config best energy = int(map config[ ’best energy ’ ]) config max step = int(map config[ ’max step ’ ]) 121 config temp = float (map config[ ’temp’ ]) config best debug = config util . strtobool(map config[ ’best debug ’ ]) 123 config step debug = config util . strtobool(map config[ ’step debug ’ ]) 31 125 anneal success = False 127 energy = 50 step = 0 129 best graph = hardware graph.copy() best step = 0 131 step temp = config temp 133 temp inc = ( float (step temp) / config max step) step temp += 1 # ensures that temperature will be above zero at last annealing step 135 print( ’Config Max Step: ’) 137 print(str(config max step)) 139 #print(’Map: temp inc ’) #print(str(temp inc)) 141 while step < config max step : 143 config temp −= .01 # Linear temperature ramp 145 step temp −= temp inc 147 step += 1 149 if step % 1000 == 0: 151 print(”Step: ” + str(step)) 32 153 undo list = blob perturb graph(input graph , hardware graph , map config , constraint dict) 155 157 new energy = quench map. blob cost function(input graph , hardware graph) 159 #If the config step debug flag is enabled , plot the new graph perturbation at each step if config step debug : 161 utils . debug plot(hardware graph) 163 #reject any perturbation that breaks a subgraph. #always accept the new graph if it is lower in energy than the current value ; otherwise , 165 #accept with some probability if not quench map. broken chains(input graph , hardware graph) and \ 167 accept(math.exp(−(100∗(new energy − energy)/step temp))): energy = new energy 169 #If we didn ’t accept this perturbation , call undo to undo the perturbation for the next attempt else : 171 undo(hardware graph , undo list) 173 if new energy < config best energy and not quench map. broken chains( input graph , best graph): config best energy = new energy 175 best graph = hardware graph.copy() print (”New best energy: ” + str(config best energy)) 177 print(”Step: ” + str(step)) 33 best step = step 179 #app. log .debug(blob print cost(input graph , best graph)) 181 #If the config best debug flag is true , we want to see a matplotlib visualization every time 183 # we improve on the previous best mapping found 185 if config best debug : utils . debug plot(best graph) 187 if config best energy <= 0 and not quench map. broken chains(input graph , best graph): 189 print(”Optimized at step : ” + str(best step)) print time. clock () − t0 , ”wall time (seconds)” 191 anneal success = True #utils . plot subgraphs(input graph , best graph) 193 #construct a stats object to report heuristic performance 195 #count vertex model chain sizes 197 chain dict = utils . count chains(input graph , best graph) 199 #construct a stats object to report heuristic performance anneal stats = utils . construct stats(success=anneal success , 201 overlaps=None, # no overlapping routing mode for simulated annealing cpu time=time. clock () − t0 , 203 nodes used=sum(1 for hw node in best graph if best graph .node[hw node ][ ’mapping’] != ’empty’) , 205 max chain=max(chain dict . values()) , 34 iterations=step 207 ) 209 return anneal success , anneal stats 211 #@profile 213 def blob perturb graph(input graph , hardware graph , map config , constraint dict): ”””blob perturb graph takes an input graph , a hardware connectivity graph , and a dictionary of annealing 215 parameters , and applies a simple simulated annealing global optimization algorithm to map the input graph onto the hardware connectivity graph. Permitted perturbations act on physical qubits in relation to subtrees of physical 217 qubits that map to one logical input node. Physical qubits may be 1) moved from their current location in a subtree to an empty available space elsewhere on the border of the subtree , 2) added to an empty space bordering the 219 subtree , if not in excess of a maximum number of permitted nodes , or 3) deleted from the subtree if multiple physical nodes are currently present . Legal perturbations cannot break the connectivity of the subgraph of nodes in 221 a subtree , but may break the connectivity of subtrees with each other in the overall map. 223 blob perturb graph returns an undo list of map values to apply to hardware graph to undo the perturbation just made. This allows the calling function to cheaply reject the perturbation offered by blob perturb graph 35 225 :param input graph : 227 :type input graph : NetworkX undirected graph :param hardware graph: 229 :type hardware graph: NetworkX undirected graph :param map config: 231 :type map config: dictionary of configuration parameters (see quench config file ) : rtype : List of tuples . The first item in the tuple is the node to act on, 233 the second is the value to map to the node. Used to undo a perturbation . 235 ””” 237 #Initialize local configuration parameters from configuration dict 239 config prob move = float (map config[ ’prob move ’ ]) config prob add = float (map config[ ’prob add ’ ]) 241 config max subtree nodes = int(map config[ ’max subtree nodes ’ ])∗len( input graph .nodes()) config debug move = config util . strtobool(map config[ ’debug move ’ ]) 243 config debug add = config util . strtobool(map config[ ’debug add ’ ]) config debug remove = config util . strtobool(map config[ ’debug remove ’ ]) 245 config floating subtrees = config util . strtobool(map config[ ’ floating subtrees ’ ]) 247 #list of actions to take to undo any perturbation action made by this call undo list = [] 249 subtrees = [] free subtrees = [] 251 36 #generate a list of the subtrees in the hardware graph; free subtrees contain only nodes not locked by user 253 #constraints 255 for node in input graph : this subtree = [hw node for hw node in hardware graph if hardware graph.node[ hw node ][ ’mapping’] == node] 257 this free subtree = [hw node for hw node in hardware graph if (hardware graph .node[hw node ][ ’mapping’] == node and hw node not in constraint dict)] 259 subtrees .append(this subtree) free subtrees .append( this free subtree ) 261 done = False 263 # keep looping until a valid perturbation is made for this step 265 while not done: #reset the undo list 267 undo list = [] #randomly choose a subtree from the list to perturb 269 perturb subtree = random. choice(subtrees) 271 #look up the correct subtree in free subtrees based on the index of the current perturb subtree in the #list of perturb subtrees . 273 free subtree = free subtrees [ subtrees .index(perturb subtree)] 275 #Generate a random number between 0 and 1. #Use this to choose a type of perturbation step . 277 #Can tweak the probability of choosing each type of perturbation 37 279 decision = random.random() 281 if decision < config prob move : 283 #Move one qubit in a subtree 285 #Construct a list of all the empty neighbor nodes for this subtree neighbors set = set () 287 for node in perturb subtree : neighbors set = neighbors set | set(quench map.node empty neighbors( hardware graph , node)) 289 # If this subtree has empty neighbor nodes and there are unconstrained nodes in the subtree 291 # that can be moved if len(neighbors set) > 0 and len(free subtree) > 0: 293 #randomly pick a target node to move elsewhere , as long as it isn ’t constrained to its current location . 295 target = random. choice(free subtree) 297 #Remove the target node ’s neighbors from the list of possible choices . 299 neighbors set = neighbors set − set(quench map.node empty neighbors( hardware graph , target)) 301 if config debug move: 303 utils . debug plot(hardware graph , nodelists=[(perturb subtree , ’b’) , ( list ( 38 neighbors set) , ’g’) , ([ target ] , ’y’) ]) 305 #If there are still neighbor nodes available now we’ve removed the target node ’s: 307 if len(neighbors set) > 0: 309 #pick a destination node from the modified neighbors list destination = random.sample(neighbors set , 1) [0] 311 #Save the current state of the target and destination hardware nodes to the undo list . 313 undo list .append((target , hardware graph.node[ target ][ ’mapping’ ]) ) undo list .append(( destination , hardware graph.node[ destination ][ ’mapping’ ]) ) 315 #copy the target node ’s mapping to the destination node ’s. 317 hardware graph.node[ destination ][ ’mapping’] = hardware graph.node[ target ][ ’ mapping’] 319 #Reset the old node ’s mapping to empty, effectively moving the node hardware graph.node[ target ][ ’mapping’] = ’empty’ 321 #update the curent subtree to reflect the move we just made 323 this subtree = [hw node for hw node in hardware graph if hardware graph.node[ hw node ][ ’mapping’] == hardware graph.node[ destination ][ ’mapping’ ]] 325 #create a networkx subgraph from the this subtree list of nodes , for connectivity testing perturb subgraph = nx.Graph.subgraph(hardware graph , this subtree) 327 39 #if floating subtrees is False , check that the subgraph and complete graph remain connected. 329 #otherwise , check only that the subgraph is connected. if nx. is connected(perturb subgraph) and (nx. is connected(hardware graph) or 331 config floating subtrees ): done = True # we’ve succeeded in doing a legal perturbation , so exit the while loop 333 else : 335 undo(hardware graph , undo list) 337 if config debug move: utils . debug plot(hardware graph , graph color=’b’) 339 elif config prob move <= decision < config prob add : 341 #Add a qubit to a subtree 343 #Construct a list of all the empty neighbor nodes for this subtree neighbors set = set () 345 for node in perturb subtree : neighbors set = neighbors set | set(quench map.node empty neighbors( hardware graph , node)) 347 if config debug add : 349 utils . debug plot(hardware graph , nodelists=[(perturb subtree , ’b’) , ( list ( neighbors set) , ’g’) ]) utils . plot subgraphs(input graph , hardware graph) 351 #don’t add more than config max subtree nodes physical nodes of one type , and don’t try to add if there 40 353 #are no empty neighbors if len(perturb subtree) < config max subtree nodes and len(neighbors set) > 0: 355 #extract a random element from the set 357 target = random.sample(neighbors set , 1) [0] 359 #Whatever neighbor node we’ve decided to add, fetch the logical node mapping from a node in this subtree #so we know what to copy 361 hardware graph.node[ target ][ ’mapping’] = hardware graph.node[ perturb subtree [0]][ ’mapping’] 363 #prepare the undo operation for this perturbation undo list .append((target , ’empty’)) 365 perturb subgraph = nx.Graph.subgraph(hardware graph , perturb subtree) 367 #if floating subtrees is False , check that the subgraph and complete graph remain connected. 369 #otherwise , check only that the subgraph is connected. if nx. is connected(perturb subgraph) and ( config floating subtrees or nx. is connected(hardware graph)): 371 done = True else : 373 undo(hardware graph , undo list) print(”Adding qubit broke the subgraph!”) 375 else : 377 neighbors set = set () 41 #Remove a qubit from a subtree , if there are at least two unconstrained nodes in the subtree 379 if len(free subtree) > 1: 381 #choose a random node in the subtree to remove , as long as it isn ’t constrained to that node target = random. choice(free subtree) 383 #save the original mapping value of the target hw node subtree mapping = hardware graph.node[ target ][ ’mapping’] 385 if config debug remove : 387 for node in perturb subtree : 389 neighbors set = neighbors set | set(quench map.node empty neighbors( hardware graph , node)) 391 utils . debug plot(hardware graph , nodelists=[(perturb subtree , ’b’) , ( list ( neighbors set) , ’g’) , ([ target ] , ’y’) ]) 393 #prepare the undo operation for this perturbation 395 undo list .append((target , hardware graph.node[ target ][ ’mapping’ ]) ) 397 hardware graph.node[ target ][ ’mapping’] = ’empty’ 399 if config debug remove : 401 utils . debug plot(hardware graph) 403 #update the current subtree to reflect the deletion we just made 42 this subtree = [hw node for hw node in hardware graph if hardware graph.node[ hw node ][ ’mapping’] == 405 subtree mapping] #create a NetworkX subgraph from the this subtree list of nodes , for connectivity testing 407 perturb subgraph = nx.Graph.subgraph(hardware graph , this subtree) 409 #if nx. is connected(hardware graph) and nx. is connected(perturb subgraph): 411 #if floating subtrees is False , check that the subgraph and complete graph remain connected. #otherwise , check only that the subgraph is connected. 413 if nx. is connected(perturb subgraph) and (nx. is connected(hardware graph) or config floating subtrees ): done = True 415 else : undo(hardware graph , undo list) 417 if config debug remove : 419 utils . debug plot(hardware graph , graph color=’b’) 421 return undo list 423 def undo(input graph , undo list): 425 ”””undo takes a NetworkX graph , and a list of tuples . The first item in the tuple is the node to act on, the second is the value to map to the node. Used to undo a perturbation . 427 :param input graph : 43 429 :type input graph : NetworkX undirected graph :param undo list : 431 :type undo list : tuple of NetworkX nodes , value to map to node 433 ””” 435 for item in undo list : input graph .node[item [0]][ ’mapping’] = item [1] 437 439 def accept(probability): ””” Very simple function that takes a probability between 0 and 1, and returns true if a random() call is less than 441 or equal to that probability , and false otherwise . This simple wrapper function allows annealing step to be described in language closer to conventional pseudo−code notation for annealing algorithms . 443 :param float probability : The probability that a True value will be returned by accept 445 : rtype : Bool 447 ””” 449 return random.random() <= probability Listing 2: tsp embed.py: genetic algorithm based minor embedding heuristic 2 ””” 4 The tsp embed module provides functionality associated with implementing a 44 Genetic Algorithm based approach to minor embedding on hardware graphs. It is released under the GPLv2 (or later) license . 6 It links to the NetworkX, igraph , DEAP, and NumPy libraries . NetworkX is separately licensed under 3−Clause BSD. 8 igraph is separately licensed under GPLv2. DEAP is separately licensed under LGPLv3. NumPy is separately licensed under 3−Clause BSD. 10 Please see the appropriate licenses for these libaries in the sections immediately below , and comply with the 12 appropriate terms. 14 The tsp embed module provides functionality associated with implementing a Genetic Algorithm based approach to minor embedding on hardware graphs. 16 Copyright (C) 2015, Zeve Akerling (akerling@usc .edu) 18 This program is free software ; you can redistribute it and/or modify it under the terms of the GNU General Public License 20 as published by the Free Software Foundation; either version 2 of the License , or (at your option) any later version . 22 This program is distributed in the hope that it will be useful , 24 but WITHOUT ANY WARRANTY; without even the implied warranty of MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the 26 GNU General Public License for more details . 28 You should have received a copy of the GNU General Public License 45 along with this program; if not , write to the Free Software 30 Foundation , Inc. , 51 Franklin Street , Fifth Floor , Boston , MA 02110−1301, USA. 32 ======================================================================================================================== 34 Network X Citation : 36 Aric A. Hagberg , Daniel A. Schult and Pieter J. Swart , Exploring network structure , dynamics , and function using NetworkX, in Proceedings of the 7th Python in Science Conference ( SciPy2008) , Gael Varoquaux, Travis Vaught, 38 and Jarrod Millman (Eds) , (Pasadena , CA USA) , pp. 11−15, Aug 2008 40 NetworkX Library license : 42 This code links to the NetworkX library , released under the 3−clause BSD license with the terms below. 44 Copyright (C) 2004−2012, NetworkX Developers 46 Aric Hagberg <hagberg@lanl.gov> Dan Schult <dschult@colgate .edu> 48 Pieter Swart <swart@lanl.gov> All rights reserved . 50 Redistribution and use in source and binary forms , with or without 52 modification , are permitted provided that the following conditions are met: 46 54 ∗ Redistributions of source code must retain the above copyright 56 notice , this list of conditions and the following disclaimer . 58 ∗ Redistributions in binary form must reproduce the above copyright notice , this list of conditions and the following 60 disclaimer in the documentation and/or other materials provided with the distribution . 62 ∗ Neither the name of the NetworkX Developers nor the names of its 64 contributors may be used to endorse or promote products derived from this software without specific prior written permission . 66 68 THIS SOFTWARE IS PROVIDED BY THE COPYRIGHT HOLDERS AND CONTRIBUTORS ”AS IS” AND ANY EXPRESS OR IMPLIED WARRANTIES, INCLUDING, BUT NOT 70 LIMITED TO, THE IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS FOR A PARTICULAR PURPOSE ARE DISCLAIMED. IN NO EVENT SHALL THE COPYRIGHT 72 OWNER OR CONTRIBUTORS BE LIABLE FOR ANY DIRECT, INDIRECT, INCIDENTAL, SPECIAL, EXEMPLARY, OR CONSEQUENTIAL DAMAGES (INCLUDING, BUT NOT 74 LIMITED TO, PROCUREMENT OF SUBSTITUTE GOODS OR SERVICES; LOSS OF USE, DATA, OR PROFITS; OR BUSINESS INTERRUPTION) HOWEVER CAUSED AND ON ANY 76 THEORY OF LIABILITY, WHETHER IN CONTRACT, STRICT LIABILITY, OR TORT (INCLUDING NEGLIGENCE OR OTHERWISE) ARISING IN ANY WAY OUT OF THE USE 78 OF THIS SOFTWARE, EVEN IF ADVISED OF THE POSSIBILITY OF SUCH DAMAGE. ====================================================================================================================== 80 igraph Citation : 82 47 Csardi G, Nepusz T: The igraph software package for complex network research , InterJournal , Complex Systems 1695. 2006. 84 http://igraph .org 86 igraph Library License : 88 Copyright (C) 2006−2012 Tamas Nepusz <ntamas@gmail.com> 90 Pazmany Peter setany 1/a, 1117 Budapest , Hungary 92 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 94 the Free Software Foundation; either version 2 of the License , or (at your option) any later version . 96 This program is distributed in the hope that it will be useful , 98 but WITHOUT ANY WARRANTY; without even the implied warranty of MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the 100 GNU General Public License for more details . 102 You should have received a copy of the GNU General Public License along with this program; if not , write to the Free Software 104 Foundation , Inc. , 51 Franklin Street , Fifth Floor , Boston , MA 02110−1301 USA 106 108 ======================================================================================================================== DEAP Citation : 110 48 Francois−Michel De Rainville , Felix−Antoine Fortin , Marc−Andre Gardner , Marc Parizeau and Christian Gagne, 112 ”DEAP: A Python Framework for Evolutionary Algorithms”, in EvoSoft Workshop, Companion proc. of the Genetic and Evolutionary Computation Conference (GECCO 2012) , July 07−11 2012. 114 116 DEAP Library License : 118 This code links to the DEAP library , originally released under the Lesser GPL v3 License : 120 # This file is part of DEAP. # 122 # DEAP is free software : you can redistribute it and/or modify # it under the terms of the GNU Lesser General Public License as 124 # published by the Free Software Foundation , either version 3 of # the License , or (at your option) any later version . 126 # # DEAP is distributed in the hope that it will be useful , 128 # but WITHOUT ANY WARRANTY; without even the implied warranty of # MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the 130 # GNU Lesser General Public License for more details . # 132 # You should have received a copy of the GNU Lesser General Public # License along with DEAP. If not , see <http://www.gnu.org/licenses/>. 134 ======================================================================================================================== 49 136 NumPy Citation : 138 Stefan van der Walt, S. Chris Colbert and Gael Varoquaux. The NumPy Array: A Structure for Efficient Numerical 140 Computation , Computing in Science & Engineering , 13, 22−30 (2011) , DOI :10.1109/MCSE.2011.37 142 Numpy Library License : 144 Copyright (c) 2005, NumPy Developers 146 All rights reserved . 148 Redistribution and use in source and binary forms , with or without modification , are permitted provided that the following conditions are met: 150 Redistributions of source code must retain the above copyright notice , this list of conditions and the following 152 disclaimer . Redistributions in binary form must reproduce the above copyright notice , this list of conditions and the following 154 disclaimer in the documentation and/or other materials provided with the distribution . Neither the name of the NumPy Developers nor the names of any contributors may be used to endorse or promote 156 products derived from this software without specific prior written permission . 50 158 THIS SOFTWARE IS PROVIDED BY THE COPYRIGHT HOLDERS AND CONTRIBUTORS ”AS IS” AND ANY EXPRESS OR IMPLIED WARRANTIES, INCLUDING, BUT NOT LIMITED TO, THE IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS FOR A PARTICULAR PURPOSE ARE 160 DISCLAIMED. IN NO EVENT SHALL THE COPYRIGHT OWNER OR CONTRIBUTORS BE LIABLE FOR ANY DIRECT, INDIRECT, INCIDENTAL, SPECIAL, EXEMPLARY, OR CONSEQUENTIAL DAMAGES (INCLUDING, BUT NOT LIMITED TO, PROCUREMENT OF SUBSTITUTE GOODS OR 162 SERVICES; LOSS OF USE, DATA, OR PROFITS; OR BUSINESS INTERRUPTION) HOWEVER CAUSED AND ON ANY THEORY OF LIABILITY, WHETHER IN CONTRACT, STRICT LIABILITY, OR TORT (INCLUDING NEGLIGENCE OR OTHERWISE) ARISING IN ANY WAY OUT OF THE 164 USE OF THIS SOFTWARE, EVEN IF ADVISED OF THE POSSIBILITY OF SUCH DAMAGE. 166 ======================================================================================================================== 168 The tsp embed module provides functionality associated with implementing a Genetic Algorithm based approach to minor embedding on hardware graphs. Uses the DEAP framework , (https://code. google .com/p/deap/) , to implement the 170 genetic algorithm . Individual phenotypes are the order of edges to route . Input to the algorithm includes the input graph to embed, the hardware graph to embed onto , and a set of seed /root nodes in the hardware graph 172 mapped to input vertices to start routing from. 174 ””” 176 51 178 import random 180 import distutils . util as config util import time 182 from deap import creator , base , tools , algorithms 184 import networkx as nx import igraph 186 import numpy import matplotlib . pyplot as plt 188 import quench map import utils 190 192 class GraphContainer(object): ”””Container class for EA population individuals . Initialized with a graph attribute . 194 Fitness attribute is added to the GraphContainer by the DEAP toolbox in individual registration . 196 ””” def init (self , networkx graph): 198 self .graph = networkx graph 200 def evo plot(logbook): 202 ”””evo plot plots the best fitness and best number of nodes used over the generations 52 204 :param logbook: :type logbook: A DEAP logbook object 206 ””” #The following code plots the best and average fitness over the generations 208 gen = logbook. select (”gen”) #fit mins = logbook. chapters [” fitness ”]. select (”min”) 210 #size avgs = logbook. chapters [” size ”]. select (”avg”) 212 fit min = [item [0] for item in logbook. select (”min route”)] size min = [item [1] for item in logbook. select (”min route”)] 214 print(”len(gen , fit min , size min): ” , len(gen) , len(fit min) , len(size min)) 216 fig , ax1 = plt . subplots() 218 line1 = ax1. plot(gen , fit min , ”b−” , label=”Best Routing”) ax1. set xlabel(”Generation”) 220 ax1. set ylabel(”Fitness” , color=”b”) for tl in ax1. get yticklabels () : 222 tl . set color (”b”) 224 ax2 = ax1.twinx() line2 = ax2. plot(gen , size min , ”r−” , label=”Best Size”) 226 ax2. set ylabel(”Size” , color=”r”) for tl in ax2. get yticklabels () : 228 tl . set color (”r”) 230 lns = line1 + line2 labs = [ l . get label () for l in lns ] 232 ax1. legend(lns , labs , loc=”center right”) 53 234 plt .show() 236 def shuffled( list obj ): 238 ”””Creates a copy of a list , shuffles the copy , and returns the shuffled copy . 240 :param list obj : :type list obj : the list to shuffle 242 : rtype : list ””” 244 new list = list ( list obj ) random. shuffle (new list) 246 return new list 248 def init order ( list obj , route order): 250 ”””Generates the initial , random routing order for this individual of the genetic algorithm optimization 252 :param list obj : :type list obj : a list individual generated by DEAP’s Creator. Individual 254 :param route order : :type route order : the original ordering of edges in the NetworkX graph ’s edgelist . 256 : rtype : a DEAP individual of list type initialized to a shuffled ordering of the edges in the input graph. ””” 258 #Generate a list of indices in the range (1,2,3 ... . len(route order) 54 260 index list = [] index list .extend(range(0, len(route order))) 262 #shuffle the order of the indices in the index list 264 shuffled list = shuffled( index list ) 266 individual = list obj ( shuffled list ) 268 return individual 270 def ig route eval(input graph , hardware graph , init graph , routing order , constraint dict , ig hw graph , igraph node map , inv igraph node map , igraph edge map ,diameter , map config , individual , plot= False , debug=False): 272 ”””Evaluation function for the DEAP genetic algorithm optimization . 274 :param input graph : 276 :type input graph : NetworkX undirected graph :param hardware graph: 278 :type hardware graph: NetworkX undirected graph :param init graph : 280 :type init graph : NetworkX undirected graph. Stores the original hardware graph with only seed/root nodes mapped, to avoid unnecessary copy operations . 282 :param routing order : :type routing order : list of integers , the order of edges in the input graph edgelist 284 :param constraint dict : :type constraint dict : dictionary mapping logical node names as keys to 55 hardware node names as values . 286 :param individual : :type individual : the DEAP individual object being evaluated 288 rtype : integer fitness computed by quench map. blob cost function , integer sum of nodes which have been mapped to in this routing solution . 290 : 292 ””” 294 ga overlap = config util . strtobool(map config[ ’ga overlap ’ ]) 296 max chain opt = config util . strtobool(map config[ ’max chain opt ’ ]) 298 hardware graph = quench map. ig overlap shortest path(input graph , hardware graph , init graph , ig hw graph , igraph node map , inv igraph node map , igraph edge map , 300 diameter , constraint dict , route order=None) 302 #count the number of hardware nodes with more than one input vertex mapped on them connectivity fitness = sum(1 for hw node in hardware graph if 304 len(hardware graph.node[hw node ][ ’map set ’ ]) not in (0, 1)) 306 total size = sum(len(hardware graph.node[hw node ][ ’map set ’ ]) for hw node in hardware graph) 308 chain dict = {input node : sum(1 for hw node in hardware graph if input node in hardware graph.node[hw node ][ ’map set ’ ]) 310 for input node in input graph .nodes()} 56 max chain = max(chain dict . values()) 312 if plot : 314 if ga overlap : 316 for hw node in hardware graph: 318 if hardware graph.node[hw node ][ ’map set ’ ]: hardware graph.node[hw node ][ ’mapping’] = next( iter (hardware graph.node[ hw node ][ ’map set ’ ]) ) 320 utils . plot subgraphs(input graph , hardware graph) 322 if debug: 324 print(”blob cost function : ” , quench map. blob cost function(input graph , hardware graph , debug=True)) 326 if quench map. broken chains(input graph , hardware graph): 328 print(” ! ! ! ! ! ! ! ! At least one embedding chain is broken ! ! ! ! ! ! ! ”) else : 330 print(”All chains are connected ... ”) 332 #print(”nodes used: ”, quench map. nodes used(hardware graph)) 334 if max chain opt: return connectivity fitness , max chain 336 else : 338 return connectivity fitness , total size 57 340 def route eval(input graph , hardware graph , init graph , routing order , constraint dict , diameter , map config , 342 individual , plot=False , debug=False): 344 ”””Evaluation function for the DEAP genetic algorithm optimization . 346 :param input graph : :type input graph : NetworkX undirected graph 348 :param hardware graph: :type hardware graph: NetworkX undirected graph 350 :param init graph : :type init graph : NetworkX undirected graph. Stores the original hardware graph with only seed/root nodes mapped, 352 to avoid unnecessary copy operations . :param routing order : 354 :type routing order : list of integers , the order of edges in the input graph edgelist :param constraint dict : 356 :type constraint dict : dictionary mapping logical node names as keys to hardware node names as values . :param individual : 358 :type individual : the DEAP individual object being evaluated rtype : integer fitness computed by quench map. blob cost function , integer sum of nodes which have been mapped to 360 in this routing solution . : 362 ””” 58 364 ga overlap = config util . strtobool(map config[ ’ga overlap ’ ]) 366 max chain opt = config util . strtobool(map config[ ’max chain opt ’ ]) 368 this routing order = [ routing order [index] for index in individual ] 370 #If we are doing overlap−based routing if ga overlap : 372 result graph = quench map. overlap shortest path(input graph , hardware graph , init graph , diameter , 374 constraint dict , route order=this routing order) 376 #count the number of hardware nodes with more than one input vertex mapped on them connectivity fitness = sum(1 for hw node in result graph if 378 len(result graph .node[hw node ][ ’map set ’ ]) not in (0, 1)) 380 total size = sum(len(result graph .node[hw node ][ ’map set ’ ]) for hw node in result graph) 382 chain dict = {input node : sum(1 for hw node in result graph if input node in result graph .node[hw node ][ ’map set ’ ]) 384 for input node in input graph .nodes()} max chain = max(chain dict . values()) 386 #..we are not doing overlap based routing 388 else : 390 result graph = quench map. shortest path router(input graph , hardware graph , 59 init graph , constraint dict , route order=this routing order) 392 connectivity fitness = quench map. blob cost function(input graph , result graph) 394 total size = sum(1 for hw node in result graph if result graph .node[hw node ][ ’mapping’] != ’empty’) 396 if plot : 398 if ga overlap : for hw node in result graph : 400 if result graph .node[hw node ][ ’map set ’ ]: 402 result graph .node[hw node ][ ’mapping’] = next( iter (result graph .node[hw node ][ ’map set ’ ]) ) 404 utils . plot subgraphs(input graph , result graph) 406 if debug: 408 print(”blob cost function : ” , quench map. blob cost function(input graph , result graph , debug=True)) 410 if quench map. broken chains(input graph , result graph): print(” ! ! ! ! ! ! ! ! At least one embedding chain is broken ! ! ! ! ! ! ! ”) 412 else : print(”All chains are connected ... ”) 414 #print(”nodes used: ”, quench map. nodes used(hardware graph)) 60 416 if max chain opt: 418 return connectivity fitness , max chain 420 else : return connectivity fitness , total size 422 def graph pop(size , toolbox , hw partition , input graph): 424 ”””Generates a population of individuals , initializing each one using the individual initialization 426 function registered in the DEAP toolbox . 428 :param size : :type size : integer size of the population to generate 430 :param toolbox : :type toolbox : A DEAP toolbox object containing registered (aliased) functions associated with 432 initializing GA populations and operating on them :param hw partition : 434 :type hw partition : NetworkX undirected graph :param input graph : 436 :type input graph : NetworkX undirected graph : rtype : list of genetic algorithm individuals 438 ””” 440 return [ toolbox . individual(hw partition , input graph) for item in xrange(size )] 442 61 #init tsp (routing order , input graph , eval graph , init graph , constraint dict , 15, map config) 444 def init tsp (routing order , input graph , eval graph , init graph , ig hw graph , igraph node map , inv igraph node map , igraph edge map , constraint dict , map config): 446 ”””Sets up the configuration of the DEAP genetic algorithm optimization , and an initial population of individuals . 448 :param routing order : 450 :type routing order : list of integers , the order of edges in the input graph edgelist :param input graph : 452 :type input graph : NetworkX undirected graph :param eval graph : 454 :type eval graph : NetworkX undirected graph :param init graph : 456 :type init graph : NetworkX undirected graph. Stores the original hardware graph with only seed/root nodes mapped, to avoid unnecessary copy operations . 458 :param constraint dict : :type constraint dict : dictionary mapping logical node names as keys to hardware node names as values . 460 :param pop size : :type pop size : integer size of the initial population . Population size will change during the run 462 if NSGA−II is used. : rtype : DEAP toolbox , test population , a DEAP population of individuals 464 ””” 62 466 init pop size = int(map config[ ’ ga init pop size ’ ]) ga ig router = config util . strtobool(map config[ ’ga ig router ’ ]) 468 470 #compute the graph diameter of the bidirectional hardware graph , in case we are doing overlap routing diameter = nx.diameter(init graph) 472 #Want to minimize travel cost . 474 creator . create(”FitnessMin” , base. Fitness , weights=(−1.0,−.10)) creator . create(”Individual” , list , fitness=creator .FitnessMin) 476 toolbox = base.Toolbox() toolbox . register (”individual” , init order , creator . Individual , routing order) 478 toolbox . register (”population” , tools . initRepeat , list , toolbox . individual) #toolbox . register (”map”, futures .map) 480 if ga ig router : 482 toolbox . register (”evaluate” , ig route eval , input graph , eval graph , init graph , routing order , constraint dict , ig hw graph , igraph node map , inv igraph node map , igraph edge map , diameter , map config) 484 else : 486 toolbox . register (”evaluate” , route eval , input graph , eval graph , init graph , routing order , constraint dict , diameter , map config) 488 toolbox . register (”mate” , tools .cxPartialyMatched) toolbox . register (”mutate” , tools . mutShuffleIndexes , indpb=0.05) 490 toolbox . register (”select” , tools .selNSGA2) 63 492 test population = toolbox . population( init pop size ) 494 print(”size of test population : ” , len(test population)) 496 return toolbox , test population 498 #@profile 500 502 def tsp genetic algorithm(hw partition , input graph , map config , constraint dict , t0 , app, root node map=None): 504 ”””Top level function for a DEAP genetic algorithm based minor embedding heuristic . 506 Initializes a hardware graph with seed/root nodes , either by calling the vertex model embedder or by running overlay init . 508 :param hw partition : 510 :type hw partition : NetworkX undirected graph :param input graph : 512 :type input graph : NetworkX undirected graph :param map config: 514 :type map config: dictionary of configuration parameters (see quench config file ) :param constraint dict : 516 :type constraint dict : dictionary mapping logical node names as keys to hardware node names as values . 64 :param app: 518 :type app: Cement CLI application object :param root node map: 520 :type root node map: A dictionary mapping input vertices to hardware graph nodes. Can be used to control the placement of the seed nodes the genetic algorithm heuristic is routing between. 522 ””” 524 #if we are using the GA embedder in an overlapping mode, we need to create a 526 #bidirectional version of the hardware graph with only the root/seed nodes on it , #and a working copy to be routed and re−routed by each evaluation of an individual . 528 ga overlap = config util . strtobool(map config[ ’ga overlap ’ ]) 530 ga debug = config util . strtobool(map config[ ’ga debug ’ ]) ga report = config util . strtobool(map config[ ’ga report ’ ]) 532 ga ig router = config util . strtobool(map config[ ’ga ig router ’ ]) ga circular init = config util . strtobool(map config[ ’ ga circular init ’ ]) 534 if ga overlap : 536 bidi hw graph = quench map. bidi overlap hw graph(hw partition) 538 init bidi graph = quench map. bidi overlap hw graph(hw partition) 540 #clear any old embedding that may remain on hw partition . for hw node in hw partition : 542 hw partition .node[hw node ][ ’mapping’] = ’empty’ 65 544 vertex stats = None 546 #if we were passed a root node map to use , map this onto the eval graph if root node map: 548 used hw nodes = [] 550 unmapped input nodes = [] 552 #take the root node map that was either passed in or generated , and map it onto the hw partition . 554 #print(”DEBUG: tsp embed init : root node map: ”, root node map) 556 for input vertex in input graph .nodes() : 558 #We may have been passed an incomplete embedding to use for initialization , #so we need to check if an input node is either not mapped at all or mapped to the same 560 #hardware seed node as another input vertex in the map. #The first input node mapped to that hardware node gets mapped here , 562 #the rest will get mapped to random nodes in the hardware graph. if input vertex in root node map and root node map[ input vertex ] not in used hw nodes: 564 hw partition .node[root node map[ input vertex ]][ ’mapping’] = input vertex 566 used hw nodes.append(root node map[ input vertex ]) 568 else : 66 570 unmapped input nodes.append(input vertex) 572 print(”∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗”) print(”unmapped input nodes: ” , unmapped input nodes) 574 print(”∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗”) 576 #After we’ve mapped all the input nodes in the root node map that we can , go back through the #rejects . Construct a list of all unmapped nodes in the hardware partition , and pick one at random 578 #for each unmapped input vertex . We must regenerate the list of unmapped nodes for each unmapped input #vertex , to ensure we don’t accidentally clobber a previous mapping. 580 for input vertex in unmapped input nodes: 582 unused hw nodes = [hw node for hw node in hw partition .nodes() if hw partition .node[hw node ][ ’mapping’] == ’empty’] select node = random.sample(unused hw nodes , 1) [0] 584 print(”tsp embed init unmapped root map nodes: ” , input vertex) hw partition .node[ select node ][ ’mapping’] = input vertex 586 #copy our seed node mappings onto eval graph , which is used to construct the undirected or directed 588 #init graph , depending on the heuristic ’s mode of operation . eval graph = nx.Graph.copy(hw partition) 590 #if running the vertex model embedder to find root nodes was not selected , 592 #and there is no other root node/seed mapping, run overlay init to get one. else : 594 #If we are not passed one by the calling function , 67 #generate a graph that maps each input graph node to a hardware node , for use with the Dijkstra 596 #shortest path router 598 if ga circular init : 600 input graph . position = nx. circular layout(input graph) 602 else : input graph . position = nx. spring layout(input graph , iterations=50) 604 #label dict = {node: node for node in input graph .graph} 606 #utils . debug plot(input graph , label dict=label dict ) 608 #input graph . label dict = {node: node for node in input graph} eval graph = quench map. overlay init graph(quench map.GraphContainer , constraint dict , 610 hw partition , input graph).graph 612 print(”eval graph init :”) for hw node in eval graph : 614 if eval graph .node[hw node ][ ’mapping’] != ’empty’: print(eval graph .node[hw node ][ ’mapping’ ]) 616 #Construct and initialize an iGraph graph structure for this embedding 618 #ig hw graph = igraph .Graph(edges=[[int(node) for node in pair ] for pair in bidi hw graph .edges() ] , directed=True) ig hw graph = igraph .Graph(directed=True) 620 #construct the topology from the networkX eval graph. 68 622 #what’s going on. 624 igraph node map = {} inv igraph node map = {} 626 igraph edge map = {} 628 for hw node in eval graph : ig hw graph. add vertex(hw node) 630 #Ask iGraph to return the node ID that has been associated with this eval graph label , and store #it in a dict . 632 igraph node map[hw node] = ig hw graph.vs. find(hw node).index 634 #Construct an inverse dictionary mapping iGraph node IDs back to networkX graph node labels for k, v in igraph node map. iteritems () : 636 keys = inv igraph node map. setdefault(v, []) keys.append(k) 638 for pair in eval graph .edges() : 640 #create one directed edge between two connected nodes in the hw partition edgelist . #print(”pair : ”, pair) 642 ig hw graph.add edge(pair [0] , pair [1]) 644 #Ask iGraph to return the edge ID index that has been associated with this directed edge , and store it #in a dict . 646 igraph edge map [( pair [0] , pair [1]) ] = ig hw graph. es . find( source= igraph node map[ pair [0]] , 69 target=igraph node map[ pair [1]]) .index 648 #create the other directed edge connecting the two iGraph Nodes, and store its edge ID index in a local dict . 650 ig hw graph.add edge(pair [1] , pair [0]) igraph edge map [( pair [1] , pair [0]) ] = ig hw graph. es . find( source= igraph node map[ pair [1]] , 652 target=igraph node map[ pair [0]]) .index 654 #If overlap embedding has been selected , copy the embedding on the original undirected eval graph #onto the bidirectional hardware graph for evaluation routing , and make a deep copy of the initial 656 #seed node mapping to reinitialize the hardware graph at the start of each routing evaluation . if ga overlap : 658 for hw node in eval graph : if eval graph .node[hw node ][ ’mapping’] != ’empty’: 660 #need to pass eval graph ’mapping’ property to the set .update function #as a one−element tuple , which requires the trailing comma. 662 init bidi graph .node[hw node ][ ’map set ’ ].add(eval graph .node[hw node ][ ’ mapping’ ] ,) #print(”DEBUG: tsp embed init : mapping ”, eval graph .node[hw node][ ’mapping ’] , ” to ”, hw node) 664 bidi hw graph = init bidi graph .copy() 666 init graph = init bidi graph .copy() eval graph = bidi hw graph .copy() 668 #print(”DEBUG: breakpoint placeholder”) 70 670 #else we are not doing overlap embedding , so make a deep copy of the original eval graph #undirected graph with seed nodes 672 else : 674 #create a copy of the overlay init seed mapping to re−initialize the eval graph with during the run init graph = nx.Graph.copy(eval graph) 676 #The genetic algorithm individuals are lists of input graph edges in the order they will be routed by 678 #the shortest path router . They are initialized with the native NetworkX edge ordering for the #input graph. 680 routing order = input graph .edges() 682 toolbox , population = init tsp (routing order , input graph , eval graph , init graph , ig hw graph , 684 igraph node map , inv igraph node map , igraph edge map , constraint dict , map config) 686 hof = tools .HallOfFame(10) 688 stats = tools . Statistics (key=lambda ind: ind. fitness . values) 690 stats . register (”avg route” , numpy.mean, axis=0) stats . register (”std route” , numpy.std , axis=0) 692 stats . register (”min route” , numpy.min, axis=0) stats . register (”max route” , numpy.max, axis=0) 71 694 stats . register (”avg size” , numpy.mean, axis=1) stats . register (”std size” , numpy.std , axis=1) 696 stats . register (”min size” , numpy.min, axis=1) stats . register (”max size” , numpy.max, axis=1) 698 ngen = int(map config[ ’ngen ’ ]) 700 offspring , logbook = algorithms .eaMuPlusLambda(population , toolbox , mu=4, lambda =5, cxpb=0.5, mutpb=0.4, ngen=ngen , 702 halloffame=hof , stats=stats , verbose=False) 704 #recompute the diameter for the final routing of the best individual found diameter = nx.diameter(init graph) 706 if ga report : 708 print(”hof fitness values :”) 710 for item in hof: print (item , item. fitness . values) 712 route eval(input graph , eval graph , init graph , routing order , constraint dict , 714 diameter , map config , hof [0] , plot=True, debug=True) 716 print(logbook) 718 evo plot(logbook) 720 #Map the best node routing order we’ve found (hof [0]) onto eval graph . route eval(input graph , eval graph , init graph , routing order , 72 constraint dict , 722 diameter , map config , hof [0] , plot=False , debug=False) 724 #print(”outputting best tsp graph ... ”) #quench map. blob cost function(input graph , eval graph , debug=True) 726 #utils . plot subgraphs(input graph , eval graph) 728 #First clear any old mappings off of hw partition for hw node in hw partition : 730 hw partition .node[hw node ][ ’mapping’] = ’empty’ 732 for hw node in eval graph : 734 if eval graph .node[hw node ][ ’map set ’ ]: hw partition .node[hw node ][ ’mapping’] = next( iter (eval graph .node[hw node ][ ’ map set ’ ]) ) 736 #When the heuristic terminates , 738 #transfer the non−overlapping mapping on the bidirectional graph ’s hw nodes back onto the undirected 740 #hardware graph. 742 tsp success = False 744 if quench map. blob cost function(input graph , hw partition , debug=False) == 0: tsp success = True 746 #count vertex model chain sizes 73 748 chain dict = utils . count chains(input graph , hw partition) 750 #construct a stats object to report heuristic performance tsp stats = utils . construct stats(success=tsp success , 752 overlaps=quench map. overlap count(eval graph) , cpu time=time. clock () − t0 , 754 nodes used=sum(1 for hw node in eval graph if eval graph .node[hw node ][ ’map set ’ ]) , 756 max chain=max(chain dict . values()) ) 758 if vertex stats : 760 tsp stats [ ’ iterations ’] = ngen + vertex stats [ ’ iterations ’] else : 762 tsp stats [ ’ iterations ’] = ngen 764 if quench map. broken chains(input graph , hw partition , debug=True): tsp stats [ ’error ’] = ”FAILED WITH BROKEN CHAIN” 766 else : print(”TSP chains aren ’t broken!”) 768 print(”TSP blob cost function : ” , quench map. blob cost function(input graph , hw partition , debug=False)) 770 run error = ”” 772 #If an error has been detected , log it and set success to false . 774 if ’error ’ in tsp stats : run error = tsp stats [ ’error ’] 776 tsp success = False 74 tsp stats [ ’success ’] = False 778 print(”TSP Embedding Succeeded?, overlaps , total nodes used , max chain size , iterations , cpu time (s) , error ( if any)”) 780 print(str(tsp stats [ ’success ’ ]) + ” , ” + str(tsp stats [ ’overlaps ’ ]) + 782 ” , ” + str(tsp stats [ ’nodes used ’ ]) + ” , ” + str(tsp stats [ ’max chain ’ ]) + ” , ” + str(tsp stats [ ’ iterations ’ ]) + ” , ” + str(tsp stats [ ’cpu time ’ ]) + ” , ” + str (run error)) 784 print(”chain dict : ” , chain dict) 786 return tsp success , root node map , hw partition , tsp stats VII. APPENDIX II: GPLV2 OR LATER LICENSE GNU GENERAL PUBLIC LICENSE Version 2, June 1991 Copyright (C) 1989, 1991 Free Software Foundation, Inc. 51 Franklin Street, Fifth Floor, Boston, MA 02110-1301, USA Everyone is permitted to copy and distribute verbatim copies of this license document, but changing it is not allowed. Preamble The licenses for most software are designed to take away your freedom to share and change it. By contrast, the GNU General Public License is intended to guarantee your freedom to share and change free software–to make sure the software is free for all its users. This General Public License applies to most of the Free Software Foundation’s software and to any other program whose authors commit to using it. (Some other Free Software Foundation software is covered by the GNU Lesser General Public License instead.) You can apply it to your programs, too. 75 When we speak of free software, we are referring to freedom, not price. Our General Public Licenses are designed to make sure that you have the freedom to distribute copies of free software (and charge for this service if you wish), that you receive source code or can get it if you want it, that you can change the software or use pieces of it in new free programs; and that you know you can do these things. To protect your rights, we need to make restrictions that forbid anyone to deny you these rights or to ask you to surrender the rights. These restrictions translate to certain responsibilities for you if you distribute copies of the software, or if you modify it. For example, if you distribute copies of such a program, whether gratis or for a fee, you must give the recipients all the rights that you have. You must make sure that they, too, receive or can get the source code. And you must show them these terms so they know their rights. We protect your rights with two steps: (1) copyright the software, and (2) offer you this license which gives you legal permission to copy, distribute and/or modify the software. Also, for each author’s protection and ours, we want to make certain that everyone understands that there is no warranty for this free software. If the software is modified by someone else and passed on, we want its recipients to know that what they have is not the original, so that any problems introduced by others will not reflect on the original authors’ reputations. Finally, any free program is threatened constantly by software patents. We wish to avoid the danger that redistributors of a free program will individually obtain patent licenses, in effect making the program proprietary. To prevent this, we have made it clear that any patent must be licensed for everyone’s free use or not licensed at all. The precise terms and conditions for copying, distribution and modification follow. TERMS AND CONDITIONS FOR COPYING, DISTRIBUTION AND MODIFICATION 0. This License applies to any program or other work which contains a notice placed by the copyright holder saying it may be distributed under the terms of this General Public License. The ”Program”, below, refers to any such program or work, and a ”work based on the Program” means either the Program or any derivative work under copyright law: that is to say, a work containing the Program or a portion of it, either verbatim or with modifications and/or translated into another language. (Hereinafter, translation is included without limitation in the term ”modification” .) Each licensee is addressed as ”you” . 76 Activities other than copying, distribution and modification are not covered by this Li- cense; they are outside its scope. The act of running the Program is not restricted, and the output from the Program is covered only if its contents constitute a work based on the Program (independent of having been made by running the Program). Whether that is true depends on what the Program does. 1. You may copy and distribute verbatim copies of the Program’s source code as you receive it, in any medium, provided that you conspicuously and appropriately publish on each copy an appropriate copyright notice and disclaimer of warranty; keep intact all the notices that refer to this License and to the absence of any warranty; and give any other recipients of the Program a copy of this License along with the Program. You may charge a fee for the physical act of transferring a copy, and you may at your option offer warranty protection in exchange for a fee. 2. You may modify your copy or copies of the Program or any portion of it, thus forming a work based on the Program, and copy and distribute such modifications or work under the terms of Section 1 above, provided that you also meet all of these conditions: a) You must cause the modified files to carry prominent notices stating that you changed the files and the date of any change. b) You must cause any work that you distribute or publish, that in whole or in part contains or is derived from the Program or any part thereof, to be licensed as a whole at no charge to all third parties under the terms of this License. c) If the modified program normally reads commands interactively when run, you must cause it, when started running for such interactive use in the most ordinary way, to print or display an announcement including an appropriate copyright notice and a notice that there is no warranty (or else, saying that you provide a warranty) and that users may redistribute the program under these conditions, and telling the user how to view a copy of this License. (Exception: if the Program itself is interactive but does not normally print such an announcement, your work based on the Program is not required to print an announcement.) These requirements apply to the modified work as a whole. If identifiable sections of that work are not derived from the Program, and can be reasonably considered independent and separate works in themselves, then this License, and its terms, do not apply to those sections when you distribute them as separate works. But when you distribute the same sections as part of a whole which is a work based on the Program, the distribution of the whole must 77 be on the terms of this License, whose permissions for other licensees extend to the entire whole, and thus to each and every part regardless of who wrote it. Thus, it is not the intent of this section to claim rights or contest your rights to work written entirely by you; rather, the intent is to exercise the right to control the distribution of derivative or collective works based on the Program. In addition, mere aggregation of another work not based on the Program with the Pro- gram (or with a work based on the Program) on a volume of a storage or distribution medium does not bring the other work under the scope of this License. 3. You may copy and distribute the Program (or a work based on it, under Section 2) in object code or executable form under the terms of Sections 1 and 2 above provided that you also do one of the following: a) Accompany it with the complete corresponding machine-readable source code, which must be distributed under the terms of Sections 1 and 2 above on a medium customarily used for software interchange; or, b) Accompany it with a written offer, valid for at least three years, to give any third party, for a charge no more than your cost of physically performing source distribution, a complete machine-readable copy of the corresponding source code, to be distributed under the terms of Sections 1 and 2 above on a medium customarily used for software interchange; or, c) Accompany it with the information you received as to the offer to distribute corresponding source code. (This alternative is allowed only for noncommercial distribution and only if you received the program in object code or executable form with such an offer, in accord with Subsection b above.) The source code for a work means the preferred form of the work for making modifications to it. For an executable work, complete source code means all the source code for all modules it contains, plus any associated interface definition files, plus the scripts used to control compilation and installation of the executable. However, as a special exception, the source code distributed need not include anything that is normally distributed (in either source or binary form) with the major components (compiler, kernel, and so on) of the operating system on which the executable runs, unless that component itself accompanies the executable. If distribution of executable or object code is made by offering access to copy from a designated place, then offering equivalent access to copy the source code from the same place counts as distribution of the source code, even though third parties are not compelled 78 to copy the source along with the object code. 4. You may not copy, modify, sublicense, or distribute the Program except as expressly provided under this License. Any attempt otherwise to copy, modify, sublicense or distribute the Program is void, and will automatically terminate your rights under this License. How- ever, parties who have received copies, or rights, from you under this License will not have their licenses terminated so long as such parties remain in full compliance. 5. You are not required to accept this License, since you have not signed it. However, nothing else grants you permission to modify or distribute the Program or its derivative works. These actions are prohibited by law if you do not accept this License. Therefore, by modifying or distributing the Program (or any work based on the Program), you indicate your acceptance of this License to do so, and all its terms and conditions for copying, distributing or modifying the Program or works based on it. 6. Each time you redistribute the Program (or any work based on the Program), the recipient automatically receives a license from the original licensor to copy, distribute or modify the Program subject to these terms and conditions. You may not impose any further restrictions on the recipients’ exercise of the rights granted herein. You are not responsible for enforcing compliance by third parties to this License. 7. If, as a consequence of a court judgment or allegation of patent infringement or for any other reason (not limited to patent issues), conditions are imposed on you (whether by court order, agreement or otherwise) that contradict the conditions of this License, they do not excuse you from the conditions of this License. If you cannot distribute so as to satisfy simultaneously your obligations under this License and any other pertinent obligations, then as a consequence you may not distribute the Program at all. For example, if a patent license would not permit royalty-free redistribution of the Program by all those who receive copies directly or indirectly through you, then the only way you could satisfy both it and this License would be to refrain entirely from distribution of the Program. If any portion of this section is held invalid or unenforceable under any particular circum- stance, the balance of the section is intended to apply and the section as a whole is intended to apply in other circumstances. It is not the purpose of this section to induce you to infringe any patents or other property right claims or to contest validity of any such claims; this section has the sole purpose of protecting the integrity of the free software distribution system, which is implemented by 79 public license practices. Many people have made generous contributions to the wide range of software distributed through that system in reliance on consistent application of that system; it is up to the author/donor to decide if he or she is willing to distribute software through any other system and a licensee cannot impose that choice. This section is intended to make thoroughly clear what is believed to be a consequence of the rest of this License. 8. If the distribution and/or use of the Program is restricted in certain countries either by patents or by copyrighted interfaces, the original copyright holder who places the Program under this License may add an explicit geographical distribution limitation excluding those countries, so that distribution is permitted only in or among countries not thus excluded. In such case, this License incorporates the limitation as if written in the body of this License. 9. The Free Software Foundation may publish revised and/or new versions of the General Public License from time to time. Such new versions will be similar in spirit to the present version, but may differ in detail to address new problems or concerns. Each version is given a distinguishing version number. If the Program specifies a version number of this License which applies to it and ”any later version”, you have the option of following the terms and conditions either of that version or of any later version published by the Free Software Foundation. If the Program does not specify a version number of this License, you may choose any version ever published by the Free Software Foundation. 10. If you wish to incorporate parts of the Program into other free programs whose distribution conditions are different, write to the author to ask for permission. For software which is copyrighted by the Free Software Foundation, write to the Free Software Foundation; we sometimes make exceptions for this. Our decision will be guided by the two goals of preserving the free status of all derivatives of our free software and of promoting the sharing and reuse of software generally. NO WARRANTY 11. BECAUSE THE PROGRAM IS LICENSED FREE OF CHARGE, THERE IS NO WARRANTY FOR THE PROGRAM, TO THE EXTENT PERMITTED BY APPLICA- BLE LAW. EXCEPT WHEN OTHERWISE STATED IN WRITING THE COPYRIGHT HOLDERS AND/OR OTHER PARTIES PROVIDE THE PROGRAM ”AS IS” WITHOUT WARRANTY OF ANY KIND, EITHER EXPRESSED OR IMPLIED, INCLUDING, BUT NOT LIMITED TO, THE IMPLIED WARRANTIES OF MERCHANTABILITY AND 80 FITNESS FOR A PARTICULAR PURPOSE. THE ENTIRE RISK AS TO THE QUALITY AND PERFORMANCE OF THE PROGRAM IS WITH YOU. SHOULD THE PROGRAM PROVE DEFECTIVE, YOU ASSUME THE COST OF ALL NECESSARY SERVICING, REPAIR OR CORRECTION. 12. IN NO EVENT UNLESS REQUIRED BY APPLICABLE LAW OR AGREED TO IN WRITING WILL ANY COPYRIGHT HOLDER, OR ANY OTHER PARTY WHO MAY MODIFY AND/OR REDISTRIBUTE THE PROGRAM AS PERMITTED ABOVE, BE LIABLE TO YOU FOR DAMAGES, INCLUDING ANY GENERAL, SPECIAL, IN- CIDENTAL OR CONSEQUENTIAL DAMAGES ARISING OUT OF THE USE OR IN- ABILITY TO USE THE PROGRAM (INCLUDING BUT NOT LIMITED TO LOSS OF DATA OR DATA BEING RENDERED INACCURATE OR LOSSES SUSTAINED BY YOU OR THIRD PARTIES OR A FAILURE OF THE PROGRAM TO OPERATE WITH ANY OTHER PROGRAMS), EVEN IF SUCH HOLDER OR OTHER PARTY HAS BEEN ADVISED OF THE POSSIBILITY OF SUCH DAMAGES. END OF TERMS AND CON- DITIONS VIII. APPENDIX III: LGPLV3 OR LATER LICENSE GNU LESSER GENERAL PUBLIC LICENSE Version 3, 29 June 2007 Copyright (C) 2007 Free Software Foundation, Inc. ¡http://fsf.org/¿ Everyone is permit- ted to copy and distribute verbatim copies of this license document, but changing it is not allowed. This version of the GNU Lesser General Public License incorporates the terms and con- ditions of version 3 of the GNU General Public License, supplemented by the additional permissions listed below. 0. Additional Definitions. As used herein, ”this License” refers to version 3 of the GNU Lesser General Public License, and the ”GNU GPL” refers to version 3 of the GNU General Public License. ”The Library” refers to a covered work governed by this License, other than an Applica- tion or a Combined Work as defined below. An ”Application” is any work that makes use of an interface provided by the Library, but which is not otherwise based on the Library. Defining a subclass of a class defined by 81 the Library is deemed a mode of using an interface provided by the Library. A ”Combined Work” is a work produced by combining or linking an Application with the Library. The particular version of the Library with which the Combined Work was made is also called the ”Linked Version”. The ”Minimal Corresponding Source” for a Combined Work means the Corresponding Source for the Combined Work, excluding any source code for portions of the Combined Work that, considered in isolation, are based on the Application, and not on the Linked Version. The ”Corresponding Application Code” for a Combined Work means the object code and/or source code for the Application, including any data and utility programs needed for reproducing the Combined Work from the Application, but excluding the System Libraries of the Combined Work. 1. Exception to Section 3 of the GNU GPL. You may convey a covered work under sections 3 and 4 of this License without being bound by section 3 of the GNU GPL. 2. Conveying Modified Versions. If you modify a copy of the Library, and, in your modifications, a facility refers to a function or data to be supplied by an Application that uses the facility (other than as an argument passed when the facility is invoked), then you may convey a copy of the modified version: a) under this License, provided that you make a good faith effort to ensure that, in the event an Application does not supply the function or data, the facility still operates, and performs whatever part of its purpose remains meaningful, or b) under the GNU GPL, with none of the additional permissions of this License applicable to that copy. 3. Object Code Incorporating Material from Library Header Files. The object code form of an Application may incorporate material from a header file that is part of the Library. You may convey such object code under terms of your choice, provided that, if the incorporated material is not limited to numerical parameters, data structure layouts and accessors, or small macros, inline functions and templates (ten or fewer lines in length), you do both of the following: a) Give prominent notice with each copy of the object code that the Library is used in it 82 and that the Library and its use are covered by this License. b) Accompany the object code with a copy of the GNU GPL and this license document. 4. Combined Works. You may convey a Combined Work under terms of your choice that, taken together, effec- tively do not restrict modification of the portions of the Library contained in the Combined Work and reverse engineering for debugging such modifications, if you also do each of the following: a) Give prominent notice with each copy of the Combined Work that the Library is used in it and that the Library and its use are covered by this License. b) Accompany the Combined Work with a copy of the GNU GPL and this license docu- ment. c) For a Combined Work that displays copyright notices during execution, include the copyright notice for the Library among these notices, as well as a reference directing the user to the copies of the GNU GPL and this license document. d) Do one of the following: 0) Convey the Minimal Corresponding Source under the terms of this License, and the Corresponding Application Code in a form suitable for, and under terms that permit, the user to recombine or relink the Application with a modified version of the Linked Version to produce a modified Combined Work, in the manner specified by section 6 of the GNU GPL for conveying Corresponding Source. 1) Use a suitable shared library mechanism for linking with the Library. A suitable mechanism is one that (a) uses at run time a copy of the Library already present on the user’s computer system, and (b) will operate properly with a modified version of the Library that is interface-compatible with the Linked Version. e) Provide Installation Information, but only if you would otherwise be required to pro- vide such information under section 6 of the GNU GPL, and only to the extent that such information is necessary to install and execute a modified version of the Combined Work produced by recombining or relinking the Application with a modified version of the Linked Version. (If you use option 4d0, the Installation Information must accompany the Minimal Corresponding Source and Corresponding Application Code. If you use option 4d1, you must provide the Installation Information in the manner specified by section 6 of the GNU GPL for conveying Corresponding Source.) 83 5. Combined Libraries. You may place library facilities that are a work based on the Library side by side in a single library together with other library facilities that are not Applications and are not covered by this License, and convey such a combined library under terms of your choice, if you do both of the following: a) Accompany the combined library with a copy of the same work based on the Library, uncombined with any other library facilities, conveyed under the terms of this License. b) Give prominent notice with the combined library that part of it is a work based on the Library, and explaining where to find the accompanying uncombined form of the same work. 6. Revised Versions of the GNU Lesser General Public License. The Free Software Foundation may publish revised and/or new versions of the GNU Lesser General Public License from time to time. Such new versions will be similar in spirit to the present version, but may differ in detail to address new problems or concerns. Each version is given a distinguishing version number. If the Library as you received it specifies that a certain numbered version of the GNU Lesser General Public License ”or any later version” applies to it, you have the option of following the terms and conditions either of that published version or of any later version published by the Free Software Foundation. If the Library as you received it does not specify a version number of the GNU Lesser General Public License, you may choose any version of the GNU Lesser General Public License ever published by the Free Software Foundation. If the Library as you received it specifies that a proxy can decide whether future versions of the GNU Lesser General Public License shall apply, that proxy’s public statement of acceptance of any version is permanent authorization for you to choose that version for the Library. 84

Abstract (if available)

Abstract The D-Wave Quantum Annealer is of interest both for its potential as a quantum information processing platform and as an engineered quantum system for controlled physical experimentation. In this work the minor embedding graph theory problem is discussed in the context of mapping Ising model Hamiltonians onto quantum annealing devices. Some original implementations of minor embedding codes are then demonstrated. The work concludes by applying minor embedding to extend a quantum system identification experiment into a novel physical regime.

Linked assets

University of Southern California Dissertations and Theses

Conceptually similar

PDF

Open-system modeling of quantum annealing: theory and applications

PDF

Error correction and quantumness testing of quantum annealing devices

PDF

Error suppression in quantum annealing

PDF

The theory and practice of benchmarking quantum annealers

PDF

Imposing classical symmetries on quantum operators with applications to optimization

PDF

Dynamic topology reconfiguration of Boltzmann machines on quantum annealers

PDF

Theory and simulation of Hamiltonian open quantum systems

PDF

Applications and error correction for adiabatic quantum optimization

PDF

Tunneling, cascades, and semiclassical methods in analog quantum optimization

PDF

Towards optimized dynamical error control and algorithms for quantum information processing

PDF

Explorations in the use of quantum annealers for machine learning

PDF

Towards robust dynamical decoupling and high fidelity adiabatic quantum computation

PDF

Quantum computation by transport: development and potential implementations

PDF

Dissipation as a resource for quantum information processing: harnessing the power of open quantum systems

PDF

Understanding physical quantum annealers: an investigation of novel schedules

PDF

Dynamics of adiabatic quantum search

PDF

Advancing the state of the art in quantum many-body physics simulations: Permutation Matrix Representation Quantum Monte Carlo and its Applications

PDF

Quantum and classical steganography in optical systems

PDF

Open quantum systems and error correction

PDF

Topics in quantum information and the theory of open quantum systems

Asset Metadata

Creator Akerling, Zeve (author)

Core Title Minor embedding for experimental investigation of a quantum annealer

School College of Letters, Arts and Sciences

Degree Master of Science

Degree Program Physics

Publication Date 07/16/2015

Defense Date 06/18/2015

Publisher University of Southern California (original), University of Southern California. Libraries (digital)

Tag adiabatic quantum computing,bipartite,compiler,decoherence,Dijkstra shortest path,engineered quantum systems,genetic algorithm,graph theory,Ising model,minor embedding,OAI-PMH Harvest,programmable quantum annealing,quantum computing,quantum signature Hamiltonian,quantum system identification,simulated annealing

Format application/pdf (imt)

Language English

Contributor Electronically uploaded by the author (provenance)

Advisor Lidar, Daniel A. (committee chair), Haas, Stephan W. (committee member), Spedalieri, Federico (committee member)

Creator Email akerling@usc.edu,zeve.akerling@yahoo.com

Permanent Link (DOI) https://doi.org/10.25549/usctheses-c3-594159

Unique identifier UC11299917

Identifier etd-AkerlingZe-3613.pdf (filename),usctheses-c3-594159 (legacy record id)

Legacy Identifier etd-AkerlingZe-3613.pdf

Dmrecord 594159

Document Type Thesis

Format application/pdf (imt)

Rights Akerling, Zeve

Type texts

Source University of Southern California (contributing entity), University of Southern California Dissertations and Theses (collection)

Access Conditions The author retains rights to his/her dissertation, thesis or other graduate work according to U.S. copyright law. Electronic access is being provided by the USC Libraries in agreement with the a...

Repository Name University of Southern California Digital Library

Repository Location USC Digital Library, University of Southern California, University Park Campus MC 2810, 3434 South Grand Avenue, 2nd Floor, Los Angeles, California 90089-2810, USA