-
Notifications
You must be signed in to change notification settings - Fork 0
GSoC 2012 Report Guru Devanla: Density Operators, Trace and Partial trace for quantum module
(This document is work in progress)
My name is Guru Devanla (github). I am (as of this writing) a PhD Candidate at Univ. of Illinois at Chicago working on research related to Quantum Computing and Algorithms. My research area, my passion to code and interest in contributing to open source let me to participate in the GSoC 2012 project.
This is a brief report outlining the project and the functionality that was implemented as part of GSoC 2012 participation. The report will discuss implementations of some of the modules that were implemented.
Some more context on this project can also be got from reading the initial proposal. More details on how I progressed on a weekly basis over the course of the summer can be found on my blog.
My mentors on this project were Brian Granger and Sean Vig. Ondřej Čertík has helped me along the way providing guidance and making sure my progress remained smooth.
The main goal of the project over summer was to implement modules to support use of Density matrices. This would include operations on Density matrices like Trace, Partial Trace, computing entropy, fidelity and related operations.
Overall, the goals outlined in the proposal was achieved during the summer. Other useful computations will have to be added is part of future projects.
Before starting the implementation of the project there were parts of Density matrix implementation that was implemented by Brian Granger (and his students). I started looking at the implementation and decided to start working off the existing code base. The code base was setup and implemented in such a way that I did not have to spend time coming up with the design from scratch. I was easily able to adapt the code base to what I had in mind.
Density matrices, also referred to as Density operators provide a nice construct for analysis in quantum mechanics especially in quantum computing. We started building the basic class for Density matrices by using other modules such as the current implementation of TensorProducts and Qubit classes as a reference. Once the basic class was ready, then computations like entropy calculations were included.
During the implementation of this module, the way we build support was to first make sure this class could be instantiated for general Kets. Then as we progressed, functionality and required changes were added so that the class supported qubits and tensor products(of Kets) as arguments.
The next core task of the project was to implement Trace and Partial trace operations especially to work on these Density matrices. The Tr class implemented is a generic Tr class. The Partial trace operation is implicit in the arguments that are used to create the Tr class.
During the implementation and the completion of this class, there has been some ongoing discussion on the location and responsibility of this class, as this class has overlapping functionality and inconsistencies with some modules under sympy.matrices. The resolution of the discussion was still pending and is likely to take some more time before these issues are resolved. Discussions on this can be found on the mailing list.
The other core functionality of this class is the partial trace computation. The Qubit class needs its own local implementation of how the partial trace is computed.
All other objects whose Tr can be computed implement related eval methods to enable specific calculation.
The changes to these modules was mainly to accommodate their use as arguments to Density class and also to compute the partial traces.
With a modular approach to the development process and weekly merge requests we were able to put all this together to meet the objective of the initial proposal. I have added more discussion on this approach in the following sections.
One other common theme over the summer was to write down the test cases before I start a task. As I stated earlier, the first important challenge was to plan tasks in such a way that I could submit weekly merge requests. Then, to scope out my tasks, I made it a point to write down as many test cases I could think that was related to the task at hand for the week. This helped me with two things (a) understand the scope of activity I had decide to tackle for the week (b) write better code.
Also, during weeks when I had to extend the first iteration to add more functionality, I used my unit tests to understand and review the implementation. There were instances of complex scenarios the code handled and I could have easily overlooked if not for the representative unit tests.
One other way that was very useful in communicating with the mentors and the team was to provide Notebook examples for code implemented during any given week. The blog has some descriptions on the Notebook examples that were added as part of most of the merge requests.
My typical workflow during each week of GSoC project was to start on a short task that could be completed within a week. This took some planning initially but helped a lot in keep track of my work and achieving weekly goals. During the week, I also worked on addressing code review comments from previous weeks merge request. Therefore, by end of week I complete that week’s tasks and made sure the previous week’s merge request was completed.
One other task I allocated for during the week was to plan out the following weeks tasks and send out emails to my mentors. That way I had enough information to get started on a task the following Monday.
My experience in this year’s GSoC was very rewarding. The new things I learnt include basics such as picking up a good Git workflow which I would incorporate in all my future projects. Another aspect, which I think contributed was to go by my mentor’s suggestion to have small chunks of work well planned out, so that I could submit merge requests every week. This enabled me to quickly address code review comments and get the code to a ‘state’ that was ready to merge.
As of this report, I was happy to say all my merge requests were merged and I was happy to work on additional items(Shor’s algorithm).
My implementation adds a “little” more to the quantum computation module of Sympy. I believe there is a lot more that can be and should be done to the quantum module to make it truly powerful and useful to anyone who would like to use quantum module for their work. For now, I have already started using parts of it for my research work and some toy projects.
As for my plan, I am chugging ahead and working on getting some merge requests submitted as part of implementing the Shor’s algorithm. I am again working on an earlier implementation of code that is incomplete. I hope to get this done over the next few weeks.
As part of future work, I am hoping to continue working on some projects related to quantum circuits to make them fast and efficient!
I would like to thank my mentors for making this summer such an rewarding experience. I believe communication was the key and they were always upto date with what I was doing. Their responses to my questions were prompt and helpful. For future GSoC students who are reading this report, I would suggest having a regular and honest conversation with your mentors regarding your questions and constraints you might face during the project.
Also Aaron Meurer and members on the mailing list were extremely prompt in answering and responding to all students on the GSoC project. This just showed how much they valued the GSoC participation and their willingness to get new members on board.