Technical Manual. Colm Ó héigeartaigh CASE May 6, 2003

Transcription

1 Technical Manual Colm Ó héigeartaigh CASE May 6,

2 Abstract The scope of this document is to detail the technical aspect of this project and to describe various problems encountered and the solutions that were found. The first chapter describes the motivation for undertaking the project, as well as things learned and future directions of the project. The second chapter is concerned with integrating an extension to the Quantum Computing Language called the Bloch Sphere. The third chapter deals with the User Interface of the project. The fourth chapter deals with parallelizing Matrix- Vector multiplication in the QCL to achieve a speedup. The final chapter is a tutor on Quantum Computing. This chapter also describes research undertaken into implementing the Kalman Filter in the Quantum Computing paradigm. 2

3 Contents 1 Motivation for doing Project Major Achievements Things I learned Future Directions The Bloch Sphere Background Quantum Mechanics The Bloch Sphere libplot Bison/Flex - Adding a new statement to the language Integrating the code into the language The Graphical User Interface Remote Method Invocation Extracting information from the cluster The Client Side Patterns used Observer Pattern Proxy Pattern Parallelizing the Quantum Computing Language Motivation Initialising the QCL to run on multiple nodes of the cluster Initialising the parallelization from the root node Initialising the parallelization from every other node Defining a group MPI Routines used for communicating between nodes Parallelizing matrix-vector multiplication Self-scheduling or Master-Slave Algorithm Block-striped partioning Block-checkerboard partitioning Sparse Matrix Computation Saving the newly calculated Quantum State The Cluster

4 5 A Quantum Computing Tutor Qubits - Superposition and Entanglement Application: Superdense coding The Future The Kalman Filter What is the Kalman Filter? Implementing the Kalman Filter in the Quantum Computing paradigm

5 1 Motivation for doing Project The motivation for doing this project was primarily an interest in undertaking a challenging project in an interesting area of research. The opportunity to learn about a new area of computing not covered in lectures was appealing. This area is possibly an area that I might study at postgraduate level. 1.1 Major Achievements The major achievements of this project were to integrate the bloch sphere code into the Quantum Computing Language, to integrate code to farm out matrixvector multiplication to the nodes of a cluster to speed up computation, to implement a graphical user interface to the cluster and to embed an X-Server within it. Possibly the biggest achievement of all was to come to terms with the formidable array of mathematics and formalisms that Quantum Computing embodies. 1.2 Things I learned A vast amount was learned in the course of this project. First and foremost, a large amount of the physics and mathematics of Quantum Computing was learned. I learned how to use the Quantum Computing Language, and to implement programs that demonstrate various aspects of Quantum Computing in the QCL itself. I learned a great deal in modifying the Quantum Computing Language. First of all, I had to learn about GNU Flex and Bison to integrate a new statement into the language. I had to learn how the QCL uses these tools to call corresponding C++ functions. I learned how to use the libplot plotting library to draw the bloch sphere on the screen. I learned about the Message Passing Interface, and how to implement parallel programming on a cluster. I learned about how to integrate such code into the QCL, and how to perform parallel matrix-vector multiplication. In the GUI, I learned how to extract information about the nodes of the cluster from the underlying operating system, and how to embed the X-Server inside the code. I also learned about the Kalman Filter. 1.3 Future Directions If I had more time to implement this project I would investigate extending the parallelization of matrix-vector multiplication to more areas such as the Fast Fourier 5

6 Transform and Grover s Algorithm. I would look at implementing more algorithms in the QCL such as superdense coding. I would also look at porting the QCL to run under non-unix operating systems. 2 The Bloch Sphere This section describes the bloch sphere, and how it is implemented as part of the Quantum Computing Language. 2.1 Background Quantum Mechanics A qubit is normally represented as a linear combination of the basis states 0 and 1, ie; φ = α 0 + β 1 (1) It is a fundamental property of quantum mechanics that we cannot examine a qubit to determine it s quantum state, in other words, to find out what α and β are. Instead, upon measurement, a qubit collapses into the state 0 with probability α 2 and the state 1 with probability β 2, such that; α 2 + β 2 = 1 Because of this requirement, equation (1) can be rewritten as; ( φ = e iγ cos θ eiϕ sin θ ) 2 1, where θ, ϕ and γ are real numbers. We can ignore the factor of e iγ at the front of the equation, because it has no observable effects, and we can therefore rewrite equation (1) as; φ = cos θ eiϕ sin θ 1 (2) 2 6

7 2.2 The Bloch Sphere The numbers θ and ϕ in equation (2) define a point on the unit three-dimensional sphere. This sphere is called the Bloch Sphere. It provides a useful means of visualizing the state of a single qubit. However, there is no simple generalization of the Bloch sphere known for multiple qubits. The north pole of the sphere is assigned the state 0 and the south pole the state 1. A classical bit would be represented on the bloch sphere as being either at the north pole of the sphere or at the south pole. A qubit however, can be a point anywhere on the surface of the sphere. The bloch sphere is not a precise indicator of where the qubit lies on the unit sphere, it merely shows the latitude of the qubit. The latitude defines how close the qubit is to the poles, depending on the probability amplitudes. The sphere has 3 axes; x, y and z. The number θ defined in equation (2) gives the angle of the qubit from the vertical z axis. This angle is easily found in the 7

8 following way: we have already seen that equation (1) can be written as equation (2). By comparing the 0 parts of both equations we get; α 0 = cos θ 2 0 Since α is known, θ can be found by; θ = (cos 1 α) 2 It is impossible to solve the equation to find out where the qubit exists on the semicircle defined by the longitude. The qubit exists on every point on that semicircle, so in the bloch sphere implementation for the Quantum Computing Language, the qubit is assigned an arbitrary longitude of 70 pixels from the vertical z axis. 2.3 libplot To draw the bloch sphere, the GNU libplot library is used. Libplot is a freely available C/C++ function library for device-independent 2-D vector graphics. The C++ class library is called libplotter, which provides an object-oriented interface to libplot s functionality, is used in this project. To use libplot, a pointer to a Plotter object is created with the command; Plotter plot ; The page size and picture size are set by the following commands; Plotter :: parampl( PAGESIZE, (void )optplotpaper. c str ()); Plotter :: parampl( BITMAPSIZE, (void ) 400x400 ); The line size and colour can be set with the following commands; plot >flinewidth (0.25); plot >pencolorname(const char name); The Plotter object can draw strings on the screen with the following command; 8

9 plot >fmove (double x, double y); plot >alabel(int horiz justify, int vert justify, const char s ); The circle for the Bloch Sphere can be drawn with the command; plot >circle(int xc, int yc, int r ); The axes can be drawn with the command; plot >line(int x1, int y1, int x2, int y2); The semi-circle ellipse at the center of the sphere can be drawn with the command; plot >ellipse ( int xc, int yc, int rx, int ry, int angle ); The filled circle which represents the position of the qubit on the bloch sphere, can be drawn with the command; plot >fmarker(double x, double y, int type, double size ); 2.4 Bison/Flex - Adding a new statement to the language The Quantum Computing language uses the GNU Flex and GNU Bison tools to provide a correct syntax for the language. Bison is a parser generator that converts a grammar description for an LALR(1) context-free grammar into a C/C++ program to parse that grammar. A context-free grammar is one where one or more syntactic groupings are specified, with rules for constructing them from their parts. An LALR(1) grammar means that it must be possible to tell how to parse any portion of an input string with just a single token of look-ahead. Bison is used in the QCL to ensure that whatever is typed in at the command line is syntactically correct in accordance with the grammar of the Quantum Computing Language. The grammar for the QCL is stored in the file qcl.y. 9

10 GNU Flex is a tool for generating scanners. A scanner is a program that recognizes patterns in text. In the QCL, Flex reads the qcl.lex file, for a description of a scanner to generate. The description in that file is in the form of pairs of regular expressions and C++ code, called rules. Flex generates as output a C source file, lex.cc. When the code is compiled and linked with the bison parser, Flex analyzes the input on the command line input for occurrences of the regular expressions. Whenever it finds one, it executes the corresponding C++ code. To enable the user to call the bloch sphere function on a qubit from the command line, a new statement was inserted into the Quantum Computing Language. The syntax of this statement is simply; bloch a where a is a quantum register containing exactly one qubit. To enable the lexical scanner to identify this statement, the following line was inserted into the qcl.lex file; Listing 1: Extract from qcl.lex \ textsl { bloch yylval.obj=0; return tokbloch;} \\ To enable the parser to correctly parse this statement, the following code must be inserted into the qcl.y file; Listing 2: Extract from qcl.y \%token tokbloch 607 \\ $ tokbloch ; \{ \$\$ = YYNEW(sBloch()); \} $ \\ $ tokbloch expr ; \{ \$\$ = YYNEW(sBloch(\$2)); \} $ \\ $ tokbloch expr, expr ; \{ \$\$ = YYNEW(sBloch(\$2,\$4)); \} $ \\ The above code ensures that what is typed in is syntactically correct. It starts the sbloch() class which draws the quantum register argument. The semantics of the command, ie. insuring that there is only one qubit in the quantum register argument, is handled further in in the code, it is not handled in the grammar itself. 2.5 Integrating the code into the language In order to integrate the Bloch Sphere code into the QCL, a new class called sbloch was created. This class implements a pre-existing QCL class called sstmt. The scanner created by flex calls the constructor of this class once the bloch command has been entered at the command line. The QCL keeps the execution 10

11 functions of all the classes in a file called exec.cc. Whenever a command is called, this class contains the functions that act upon the inputted information. A new function called sbloch::exec was placed into this class, which takes a reference to the Quantum Heap as its argument. The Quantum Heap contains all the quantum registers allocated in the QCL. The exec function of the sbloch class checks that the quantum register is not empty, and then calls the appropriate function in the bloch.cc file. The libplot library detailed above is used to draw the bloch sphere and qubit on the screen. To extract the amplitude of the qubit basevectors, a const iterator object provided by the QCL is used. This serves as an iterator to an object of type map<bitvec,complx>, called state map. This object is a map of the basevector and corresponding amplitude of each basevector in the quantum state. Below is an example, of how this object is used to extract an amplitude of a basevector; Listing 3: Extract from bloch.cc state iter i ; state map state m = q >new state map(); i = state m >begin(); tcomplex z = ( i ). second; double alpha = z. real (); When the amplitudes are extracted, they are passed through to the drawing functions in bloch.cc, and the qubit is drawn on the bloch sphere. 3 The Graphical User Interface 3.1 Remote Method Invocation The server program runs on a UNIX cluster, such as the CA Linux cluster. This program monitors the nodes of the cluster dynamically. The observer pattern is used to update an observer object, whenever the cluster changes in any way. This object is broadcast using RMI(Remote Method Invocation). The client GUI connects into the server, and gets a proxy to the observer object, which is used to update a graphical display, showing the status of all the nodes in the cluster. The server broadcasts an object, using the Naming.rebind method. The object 11

12 which is broadcast is the Spy class which contains all the information about the cluster. The Spy class implements an interface called SpyInterface which extends Remote. Every method defined in this interface must throw a RemoteException because they are going to be called remotely. Listing 4: Extract from Monitor.java UnicastRemoteObject.exportObject(spy ); Naming.rebind( rmi :// localhost : + port + /spy, spy ); The client application can obtain a proxy to this object, by calling the Naming.lookup object. This is then casted into a SpyInterface object, which is the remote interface. This object is then passed through to the GUI, where the information is extracted from it. Listing 5: Extract from RmiClient.java Object object = Naming.lookup( rmi:// + ipaddress + : + port + /spy ); SpyInterface spyinterface = ( SpyInterface ) object ; The main reason for using RMI over a multi-threaded ServerSocket implementation on the server-side, is that it is more efficient. There is no need to create a socket for every client machine that logs on to the server. The most important motivation for using RMI though, is that there is a relatively large amount of information to be sent to the client applications. It is much more efficient to package this information in an object and then broadcast it using RMI, than to send multiple arrays from server to client. 3.2 Extracting information from the cluster The Monitor class is run on the cluster. This class is a thread which calls two other classes every five seconds. The first class, Status, checks to see which nodes are not operational. It does this by calling the pbsnodes -l command. This command outputs a two columned list. The left-hand column is a list of all nodes that are down, the right hand side gives their exact status. An example of this command running is the following; 12

13 poprad peanut Listing 6: Sample pbsnodes -l output state unknown,down state unknown,down All of the command-line programs that are called and parsed in this project, are called in the same way. This involves instantiating a Runtime object, and calling it s exec method with the command name as a parameter. The output of this command is captured in an ArrayList object using an InputStream object. The following is a code extract from Status.java ; Listing 7: Extract from Status.java // Launch cmd. line program Runtime runtime = Runtime.getRuntime(); Process p = Runtime.getRuntime(). exec( pbsnodes l ); ArrayList list = new ArrayList (); // Capture output of program InputStream input = p. getinputstream (); BufferedReader br = new BufferedReader(new InputStreamReader(input )); // Read in data String temp; while((temp = br.readline ())!= null ) { list.add(temp); } p. waitfor (); // wait for cmd to terminate if (p. exitvalue ()!= 0) // check the process s exit value System.err. println ( process error ); br. close (); // Convert the ArrayList to a String array String [] temparray = ( String []) list. toarray(new String [0]); The second class that the Monitor class calls, Load, is the main class which extracts information from the cluster. The first thing this class does, is to get a list of the names of the node machines in the cluster. It does this by querying the /etc/bind/db.cluster file. This file contains a list of the node names in a column on the left. This information is extracted using the following shell script command, which is run from the java program; 13

14 Listing 8: Extract from Load.java String [] cmds = {/bin/sh, c, cat / etc /bind/db. cluster cut f1}; The next thing the Load class does, is to parse the uptime command to find the 1 minute load on each node. This is done by going through the list of node names extracted in the previous example, and running the uptime command on each of them. This is done using the rsh or remote shell command. Listing 9: Extract from Load.java String [] cmds = { rsh, node, uptime }; Process p = Runtime.getRuntime(). exec(cmds); The next method that is called parses the uptime command again, this time to get the number of users on each node and the uptime of each node, ie how long it has been since the node was last rebooted. To find out the memory usage of each node, the following command is run on each node; rsh <node> cat / proc/ meminfo Listing 10: Extract from Load.java The /proc/meminfo file may not be used by other versions of Unix than the Linux kernel, so if this program is being run on another OS other than Linux, it might need to be changed. Another Linux-dependent file is the /proc/cpuinfo file. This file contains information about the central processing unit of the current processor. This output of this file is parsed on each node, to determine the processor model, it s speed in megahertz, and it s cache size. The next command the Load class issues, is to find out what the highest running process is on each node. The output of the ps aux command on Linux is sorted according to the percentage of cpu time each process is taking up, and then the greatest entry is returned. This is done with the following command; Listing 11: Extract from Load.java rsh <node> /bin/sh c ps aux sort +2n tail 1 14

15 The next command that is run is to find out the list of users logged on to each node. This can be done by parsing the who command on Unix, in the following way; Listing 12: Extract from Load.java rsh <node> /bin/sh c who cut f1 d \ \ sort u The final command run by the Load class is to see which of the users on the head node have their messages turned on or off. This is to complicated to do under java. Instead, a program written in c is called, passing through the terminal number that each user is logged in from. This file is adopted from code written for the hey project written by people on redbrick. The Spy class is initialised by the Monitor class with a Status and Load object, before being bound to a port using Remote Method Invocation. The Spy class is updated by the Status and Load classes whenever these classes change. The exact method is detailed in the Patterns section below. The Spy class provides methods, defined in the SpyInterface class, to return various types of cluster information. The client can call these methods on the proxy object to obtain this information. The Spy class also parses the unix uname command to find out the operating system name and version. This is in the class, because it only needs to be run once at the start of the server, rather than every five seconds, as this information does not change. 3.3 The Client Side The client application is embedded inside an application called WeirdX. WeirdX is a pure Java X Window System Server, which is released under the GPL. It allows you to run a graphical application on a server machine and then to redirect the graphical output to another machine where it is displayed using WeirdX. It was necessary to launch the client application deep within the WeirdX code, due to the poorly designed way this program is written. The client application constructs the X-Server in a JTabbedPane object, and then passes this object through to the Display class where it is inserted into the main frame. The Display class is a JFrame that hold two tabs at the top of the frame, one 15

16 which holds the cluster information panel, and the other that holds the WeirdX X-Server. The cluster information panel is comprised of a customised Abstract- TableModel class called MainTableModel, as well as a node information panel on the left. Whenever a user clicks on a row on the table of nodes, information about the corresponding node appears on the left-hand panel. This panel consists of two moving graphs, and some information about the node. The moving graphs show the average load of the node over a period of time, and the percentage of memory being used. Whenever the Display class is updated with new values from the cluster, which happens every four seconds, these graphs are updated, with all previous values being shifted one slot to the left. 3.4 Patterns used Observer Pattern The Status and Load classes all extend the java.util.observable class. This means, that whenever they are updated with new values, an Observer class is notified. This is done with the following two statements; setchanged(); notifyobservers (); Listing 13: Extract from Load.java The Spy class implements the java.util.observer interface. This class observes the instances of Load and Status that are passed to it. To implement an Observer interface, you must inform the Observable class that it has an Observer. This can be done like this; status. addobserver( this ); Listing 14: Extract from Spy.java The public void update(observable o, Object args) method must also be implemented. As the Spy class observes two different classes, polymorphism is used to distinguish between them, e.g.: 16

17 if ( observable instanceof Names) Listing 15: Extract from Spy.java The observer pattern was implemented here because the Spy class must be kept updated at all times, as it is broadcast using RMI. The Load and Status classes should not have the responsibility of directly updating the object, as this is bad design. Using Observer here simplifies the design greatly, as updating is done automatically, and there is no need to pass the Spy class to the observable classes Proxy Pattern Java s Remote Method Invocation(RMI) enables you to call methods on a proxy object, which forwards the calls to the real object on a remote machine. The Proxy pattern was implemented in this project, simply because the client application needs to get information from an object which runs on a remote machine. This is much more elegant that using Sockets to communicate between remote objects, as a protocol would have to be devised to parse the input and output. 4 Parallelizing the Quantum Computing Language 4.1 Motivation Simulating a quantum computer on a classical computer is a computationally hard problem. Each quantum register in the Quantum Computing Language contains a number of basevectors, each with a corresponding amplitude. As the qubits in the quantum register are superposed with each other, the number of basevectors increases exponentially. For example, a quantum register of only size 10 qubits, has 1024 basevectors. Any operation which is applied to a quantum state can be represented as a matrix. The matrix to be applied to any particular quantum state is a square matrix of the same dimension as the number of basevectors. Applying a matrix to a large quantum state takes a very long time on one computer. Most serious scientific simulation now occurs on huge clusters of ordinary workstations, rather than supercomputers, due to cost effectiveness and easy maintainability. Simulating a large quantum system on a parallel cluster has never been 17

18 fully achieved before, to my knowledge. The actual operation which is performed when applying an operation to a quantum state, is simply a matrix-vector multiplication, where the operation is represented by a matrix, and where the amplitudes of the basevectors of the quantum state is the vector. This part of the project will rewrite the matrix-vector multiplication routines of the Quantum Computing Language to farm out computation to the nodes of the Computer Applications 23-node Linux cluster. 4.2 Initialising the QCL to run on multiple nodes of the cluster The parallel programming library used in this project, the Message Passing Interface, cannot be started and run from within another program. It must be started from the command-line, as it must be run with the mpirun command, which specifies the number of nodes the code should be run on. The initialisation program of the QCL, qcl.cc, had to be altered to accommodate this. After compilation using the MPI C++ compiler; instead of running the qcl simply by entering./qcl, it must be started like the following; mpirun np <nodes> machinefile <nodes file>./qcl Any MPI program must have certain code at the start, to initialise running the program over multiple nodes. This code gets the rank of each node, where zero is the rank of the root node, and the size of the process, ie how many nodes are running the program in total. This information is needed in the parallel routines themselves, so the rank and size are declared as global variables. The user only wants to type information into one node, and then parallelize the computation over multiple nodes. Therefore, after the rank is determined on each node, every rank except the zero rank, or root node, is shunted into a function where it remains inside a while(1) loop until it receives the command from the head node to exit the function. int rank = 0; int size = 0; Listing 16: Extract from qcl.cc int main(int argc, char argv ) {... MPI Init(&argc,&argv); 18

19 MPI Comm size(mpi COMM WORLD,&size); MPI Comm rank(mpi COMM WORLD,&rank); int namelen; char processor name[mpi MAX PROCESSOR NAME]; MPI Get processor name(processor name,&namelen); // If not root node, go into receive mode... when exit from that just // exit program if (rank!= 0) { recvmatrix (); return 0; }... } 4.3 Initialising the parallelization from the root node The QCL stores matrix operations in the extern.cc class. One particular operator, called Matrix, takes a quantum register and a complex matrix as it s arguments, and then applies the operation to the matrix. This is used as the base for the parallel matrix routines used in this project. The QCL stores each operation name in an array of structs. It searches through this array to find the location of the code to handle each operation. To add an operation to the QCL, it is sufficient to add an entry to this array pointing to the name of the routine; { &ext pargenmatrix1, ParMatrix1 }, Listing 17: Extract from extern.cc The name of the function must also be added to the default.qcl file to allow the QCL compiler to identify it. This is done by adding the following line at the top of the extern.cc class; Listing 18: Extract from extern.cc //! extern operator ParMatrix1(complex matrix u,qureg q); 19

20 The QCL searches through the file after compilation and extracts all operators proceeded by //!. There are five parallel routines, however their operation in the extern.cc class is alike so only the ParMatrix1 function is detailed here. After checking that the matrix to be applied is unitary, and that the matrix has the same dimension as the number of basevectors of the quantum state, the matrix is converted into a 2-dimensional matrix. This is then passed to the appropriate parallelization function along with the quantum state, the dimension of the matrix, and array which will hold the amplitudes after the operation is complete. This is then applied to the quantum register using the apply function of a class called opparallel, in the QCL s numerical simulation library. Listing 19: Extract from extern.cc... // Create new double matrix from v matrix double matrix[dim dim]; complx complexvalue; for( i = 0; i < (dim dim); i++) { complexvalue = (v[i ]. tocomplex()); matrix[ i ] = complexvalue.real (); } // This holds the state of the qubit after the operation is applied double final qubit [dim]; memset(&final qubit, 0, sizeof ( final qubit )); parallelmatrix1 (q, final qubit, matrix, dim); opparallel (). apply( q, final qubit ); 4.4 Initialising the parallelization from every other node Every other node than the root node, is caught in a while(1) loop, in a function in the receive.cc class. When parallelization occurs, each node receives the dimension of the matrix. This also doubles as allowing the nodes to terminate gracefully when the program exits. In this case, the root node broadcasts a predefined exit matrix to the nodes, allowing them to exit gracefully. Each node then receives which algorithm to use, and calls the appropriate algorithm via a switch statement; Listing 20: Extract from receive.cc 20

21 while (1) {... // Receive width of matrix from head node MPI Bcast(&dim, 1, MPI INT, 0, MPI COMM WORLD); MPI Barrier(MPI COMM WORLD); // Test to see if received matrix is a predefined exit matrix if (dim == 3) { MPI Finalize (); return; } // Receive which algorithm to use MPI Bcast(&algorithm, 1, MPI INT, 0, MPI COMM WORLD); MPI Barrier(MPI COMM WORLD); } // Execute receive for the appropriate algorithm switch( algorithm ) { case 1: recvmatrix1(dim ); break; case 2: recvmatrix2(dim ); break; case 3: recvmatrix3(dim ); break; case 4: recvmatrix4(dim ); break; case 5: recvmatrix5(dim ); break; } 4.5 Defining a group Not all the nodes running the program must be used for running a parallelization routine. The MPI collective communication routines normally send information to all the nodes, so an MPI Group must be defined of the correct number of nodes, and information will then be sent only to this group. The MPI Comm split function is used to create a new group from an old group, in this case the MPI COMM WORLD group of all nodes. The MPI Comm split function must be run on every node at the same time. The typical way a node determines whether it is to be included in a group communication or not, is by seeing whether it s rank is less than the dimension of the matrix or not. If it isn t, then it takes no further part in the 21

22 communication. Listing 21: Extract from receive.cc // Define new group of above dimension MPI Comm group1; int color ; if (rank < dim) color = 1; else color = MPI UNDEFINED; MPI Comm split(mpi COMM WORLD, color, rank, &group1); if (rank >= dim) return; When the parallelization of the matrix-vector multiplication is complete, the group should be freed, to save on memory. This can be done with the MPI Group free command. 4.6 MPI Routines used for communicating between nodes The Message Passing Interface is a standard used for message passing. Typically it is used in conjunction with a C or C++ program to farm out computation to the nodes of a cluster. The implementation of MPI used in this project was the opensource MPICH library. Two types of MPI operations were used in this project, collective and non-collective operations. Only two non-collective operations were used. MPI Send is used to send data from one node to another, MPI Recv is used to receive data from a particular node. Both these operations are blocking, meaning that the node which calls the operation pauses until the operation is complete. MPI Send(void buf, int count, MPI Datatype datatype, int dest, int tag, MPI Comm comm) MPI Recv(void buf, int count, MPI Datatype datatype, int source, int tag, MPI Comm comm, MPI Status status) The other operations used are all collective. The MPI Bcast operation broadcasts a message from the root node to all other nodes/processes in the specified 22

23 group. This is used to broadcast the dimension of the matrix to all nodes, and also to broadcast an exit matrix to each node. MPI Bcast(void buffer, int count, MPI Datatype datatype, int root, MPI Comm comm) When the group of nodes that are to work on the matrix-vector multiplication has been set up, the root node must give out a portion of the matrix to each node. This can be achieve with MPI Send, but it is much more efficient to use the MPI Scatter operation. This operation farms out pieces of an array to different node. Thus, the decomposition of the matrix can be achieved in just one command! MPI Scatter(void sendbuf, int sendcnt, MPI Datatype sendtype, void recvbuf, int recvcnt, MPI Datatype recvtype, int root, MPI Comm comm) There is also a function called MPI Gather that implements the opposite function of MPI Scatter. When called on the root node, it gathers in data of a fixed size from all the nodes in the specified group, into an array. This is used to gather in the newly calculated qubit vector from the nodes, when the calculation is finished. MPI Gather(void sendbuf, int sendcnt, MPI Datatype sendtype, void recvbuf, int recvcount, MPI Datatype recvtype, int root, MPI Comm comm) None of the collective operations detailed above are blocking, even though they must operate at the same time on each node. To synchronize all the nodes, the MPI Barrier operation is called after a collective function. This ensures that all nodes in the group are operating in the correct place. MPI Barrier(MPI Comm comm) 4.7 Parallelizing matrix-vector multiplication This section details the different types of matrix-vector multiplication implemented in the Quantum Computing Language for this project. 23

24 4.7.1 Self-scheduling or Master-Slave Algorithm The master process distributes work to slave processes. When a slave finishes, it informs the master, which assigns it a new workload. Slave processes do not communicate with each other. The master process broadcasts vector X to each slave. The master sends one row of the matrix to each slave. The master loops, and gets back one entry of the new vector from each slave. It then sends back new rows of the matrix to the slaves when the slaves are finished, until the matrix is solved. This algorithm is inefficient, due to the extremely large amount of communication required Block-striped partioning A matrix of size (n n) is striped row-wise amoung p processes, so that each processor stores n/p rows of the matrix. A Vector of size n is sent to each processor. Each processor multiplies it s chunk of the matrix with the corresponding rows of the vector. The root process then gathers in all the values. This is more efficient than the previous solution, as the entire matrix is broadcast to the nodes at the start, instead of looping around and sending one row at a time Block-checkerboard partitioning The matrix is divided into small squares size (2 2). Each node gets a block each. The vector X is distributed in portions of size two to each process in the group. A refinement of this is also implemented, where the vector X is distributed in equal portions to the first process in each column(block) of the matrix. The first process in each column broadcasts this vector downwards to the whole column. Each processor multiplies it s block by it s vector. The MPI Gather operation is then used to gather the results in from each node to the head node, where it adds all the information received from each row and inserts it into the final qubit vector Sparse Matrix Computation A Sparse Matrix is a matrix which has very few non-zero entries. The general definition of sparseness is if one has an (n n) non-singular matrix, then the matrix is sparse if; the number of non-zeros << n 2 24

25 Every operation in Quantum Computing can be represented by a matrix, with the requirement that the matrix be unitary. A general trait of a unitary matrix is that it has a large number of zeros, although this is not always the case. The following matrix is an example of a sparse unitary matrix. It is called the controlled-z gate It is highly inefficient in terms of both memory storage and network bandwidth to distribute a highly sparse matrix in normal rectangular format over the network. For example, if one were to distribute an 8x8 matrix, such as the Toffoli gate, one would be sending 64 numbers, only 8 of which would be non-zeros! An efficient way of storing sparse matrices is called the Compressed Sparse Row format. Instead of a single large rectangular array, three arrays are used to store the matrix. The first array contains the non-zeros of the array, starting from the first row, and reading from left to right across each row. The second array contains the corresponding column subscripts of the entries in the first array. The third array contains the subscript of the first number in each row. Instead of storing (n n) numbers, as in the standard rectangular matrix format, the CSR format stores just q non-zero numbers, and n+q integers, which are the row and column subscripts. In the QCL code, the matrix is transformed into CSR format. The array of row subscripts is broadcast to all the nodes, as is the qubit vector. The root node then sends out a portion of the non-zero values, and column indices to each node. This saves space on just broadcasting the whole arrays over the network. Each node the computes it s own result, and sends the result back to the head node. 4.8 Saving the newly calculated Quantum State When each of the parallel routines in extern.cc are finished, the new amplitudes of the baseterms are stored in an array. These values need to be stored in the same quantum state that the initial amplitudes were extracted from. The qc subdirectory of the QCL contains code that directly manipulates the quantum state. A new class was defined called opparallel, which contains a single function called apply. This function takes a quantum state and an array of amplitudes as parameters. The function finds out how many baseterms the quantum state contains, and then loops through each baseterm. It finds out the basevector of each baseterm and uses 25

26 this to index in to the array of amplitudes to find the correct amplitude for this basevector. A new object of type complx is then constructed with the appropriate amplitude, and is stored in the quantum state. Listing 22: Extract from operator.cc void opparallel :: apply( qustate& qs, double array []) { int i, index = 0; term t ; bitvec m; if (!qs.mapbits ()) return; // Loop through all the basevectors in the state... for( i = 0; i < qs. baseterms (); i++) { t = qs.baseterm( i ); m = t. vect (); // Find index of vector index = static cast <int>(vec2doub(m)); complx z( array [index ], 0); // Store baseterm in quantum state qs. setbaseterm (z, i ); } } 4.9 The Cluster The computing surface which was used for this project is the Computer Applications Linux Cluster. This cluster has 23 nodes, each being containing a Pentium Pro 180mhz machine with 64 Megabytes of RAM. Each node is running Debian GNU/Linux. This cluster is a Beowulf cluster, which means that one of the machines is the head node, and all the other nodes simply compute jobs given to them and send back results. The network used is a 100 megabit Ethernet. This cluster was built purely as a proof of concept; the machines and network are too old and slow to be used in any serious way for scientific computing. 5 A Quantum Computing Tutor The following is a basic tutorial on the fundamentals of quantum computing. It explains how Quantum Computing is more powerful than the classical paradigm, 26

27 as well as explaining some quantum algorithms. 5.1 Qubits - Superposition and Entanglement Modern classical computers store and manipulate a unit of information called the bit, which takes either 0 or 1 as it s value. The classical paradigm seems to be limited however in the types of problems it can solve; there is a vast amount of problems that are intractable on modern computers. Herein lies the promise of Quantum Computers. A Quantum Computer uses a different fundamental unit of information, called the Qubit. A Qubit has two base states, normally denoted by the Dirac notation, 0 and 1. The difference between a qubit and a classical bit, is that it is possible for a qubit to be in a linear combination of states, denoted by; φ = α 0 + β 1 (3) The numbers α and β are complex numbers. The property of being able to exist in multiple states is called superposition. Quantum mechanics does not allow us to view what the amplitudes, ie. α and β, of the two basevectors are. Instead, when we measure a qubit, we get the state 0 with probability α 2, and the state 1 with probability β 2. Both of these probabilities must add up to 1. If a quantum operation is performed on a qubit in multiple states, then the operation is performed on all states simultaneously. When the qubit is observed, it will collapse back into a single state stochastically, according to the squares of the probabilities. The famous physicist R. Feynmann suggested that a qubit α 0 + β 1 occupies all the states between 0 and 1 simultaneously, but collapses into 0 or 1 when observed physically. A qubit can therefore encode an infinite amount of information, but most of this information is useless as it can never be observed. This raises all kinds of interesting philosophical questions about what information is. As stated previously, when observed, a qubit collapses into one of it s basis states. No one knows why this happens, it is one of the basic tenets of quantum mechanics. The explanation that a quantum state collapses upon physical observation is known as the Copenhagen Interpretation, and is the standard(though not the only) way of explaining the collapse upon measurement. Superposition is one of the properties that allows the Quantum Computing paradigm to supercede classical computing. The other is entanglement. A two qubit system 27

28 has four computational basis states, which are 00, 01, 10 and 11. The two qubit system can be in any superposition of these states. There are four very interesting states that such a system can be prepared in. These states are refered to as the Bell States or EPR states. An example of one of these states is the following; φ = (2) (4) When one measures the first qubit in this state, there are two possible results; 0 with probability 1/2 leaving the other qubit in the state 00, and 1 with probability 1/2, leaving the other qubit in the state 11. This means that when the second qubit is measured it will always be in the same state as the first qubit! This correlation between the qubits is known as entanglement. Bell proved that the measurement correlations between the two qubits are stronger than could ever exist between classical systems. For example, entanglement between two qubits can persist even thought they are spatially seperated. Bell states are used as the basis of quantum teleportation and super-dense coding. The properties of entanglement and superposition mean that certain speedups can be used in quantum algorithms that will never be achievable on classical computers. The two most famous quantum algorithms are Shor s algorithm, which can factor a number which is the product of two large primes in exponential time, and Grover s algorithm which searches an unsorted database in quadratic time. 5.2 Application: Superdense coding Two qubits are prepared in the Bell state illustrated in (4). Alice takes one qubit and Bob takes the other. By sending a single qubit to Bob, Alice can subsequently communicate two bits of classical information to Bob. Alice follows the following rules, if she wants to send information to Bob. To Send Apply the transformation to her qubit 00 Don t apply anything to the qubit 01 Apply the phase flip (Z) 10 Apply the Not gate (X) 11 Apply the iy gate 28

29 The state of the qubit after these transformation is one of the four Bell states previously discussed. Alice transmits her qubit to Bob. Bob then measures the entangled pair against the Bell orthonormal basis, thus enabling him to determine which of the four possible classical bit strings Alice sent him. 5.3 The Future It is as yet unclear as to how powerful the quantum computing paradigm is. The fact that an NP problem such as factoring can be solved in exponential time is an extremely encouraging indication. Quantum Algorithms are difficult to design due to the difficulty of engineering the system to collapse into a state that leads to the solution of a problem. It is known that the complexity space of the quantum computer is a subset of PSPACE, ie the class of problems that can be solved on a Turing machine with a bound on memory, but with unlimited time. It is probable that Quantum Computing can solve a few more NP problems, and can speedup the solution to many more. A useful Quantum Computer has never been built, due to the engineering difficulties in preventing the quantum state decohering, and in isolating the quantum state from the outside world. It is probable however that a prototype will be constructed some time in the near future. Shor s algorithm was demonstrated in 2001 by a group at IBM, which factored 15 into 3 and 5, using a quantum computer with 7 qubits. 5.4 The Kalman Filter Kalman filtering would appear to be ideally suited to modeling a quantum system, because it does not require the exact state of the system to be known. Due to Heisenberg s uncertainty principle, a degree of uncertainty always exists in a quantum system. Quantum Mechanics also has the general property of being linear, which fits one of the requirements of the Kalman Filter What is the Kalman Filter? The Kalman Filter is a recursive optimal estimator that can extract data from inaccurate or uncertain observations. Various conditions must be met to use the Kalman Filter; 29

30 The system must be linear and dynamic. The system being modeled must be capable of being formulated using the linear equations given in the table below. State Equation: Output Equation: x k+1 = Ax k + Bu k + w k y k = Cx k + z k (A, B, C are matrices. w and z are noise. u is an input to the system.) The system must contain measurement and process noise, both of which must be Gaussian. The Kalman Filter is widely used in controlling and observing projectile motion, such as aircraft navigation, missile control and radar tracking Implementing the Kalman Filter in the Quantum Computing paradigm The first stage of tackling this problem, was to investigate whether a stochastic process could be implemented in the Quantum Computing paradigm. A key tenet of Quantum Computing is that the quantum circuits are always invertible, ie. the starting states of an operation can always be recovered from the final states. The reason for this is that Quantum Mechanics does not permit information loss from a system. As an interesting aside, this implies that quantum computing does not expend any energy, as energy consumption in computation is linked with the reversibility of the computation. Trying to apply invertibility to a probabilistic system is impossible however. The set of products of a unitary matrix is a cyclical group so that a quantum system based on that set is also cyclical. Stochastic processes however, are not cyclical and converge to a steady state. This implies that the transition matrix of a stochastic process is not unitary, and cannot therefore be implemented on a quantum computer. This conclusion leads me to believe that there is no easy way to implement Kalman Filtering on a Quantum Computer. There is simply no easy way to ensure the key tenet of reversibility. A lot of research remains to be done at the doctorate level, before it can be proven either way. 30

31 References [1] Nielsen, Michael A. & Chuang, Isaac L. Quantum Computation and Quantum Information. Cambridge University Press, [2] Ömer, Bernhard. A Procedural Formalism for Quantum Computing. Technical University of Vienna, [3] Ömer, Bernhard. Quantum Programming in QCL. Technical University of Vienna, [4] Ömer, Bernhard. Classical Concepts in Quantum Programming. quant-ph/ , [5] Hirvensalo, Mika. Quantum Computing. Springer, [6] Levin F.S. An Introduction to Quantum Theory. Cambridge University Press, [7] Snir, Marc & Otto, Steve & Huss-Lederman, Steven & Walker, David & Dongarra, Jack. MPI: The Complete Reference. 31