So this is the last week of the GSoC program. I'll be writing up a full report on what I've done over the summer here and it will be updated over this next week. This blog post will be recapping this last week of progress and looking forward past the GSoC.
The main thing to report with this last week was the finishing the work on the spin coupling work that was laid out last week and the writing of the code for Coupled spin states, the last pull request I'll get in during the GSoC project is currently open and should only need a last bit of code review to get pulled.
The main thing now is moving beyond the work that will be done during the GSoC project. While I'll be starting classes this next week and I have my qual the next week, so work will definitely slow down. However, this last week, I worked on the multi_coupling branch, which takes the coupling work that is in the current pull and expands it to allow for an arbitrary number of spin bases. The first thing to implement with this was a means of representing the coupling between the spin bases, since the order in which spaces are coupled matters. To do this, I added a jcoupling option to the functions that deal with coupled states. It currently seems pretty messy, but I'm not sure of a better way to do it, as coupling multiple spaces will just pick up a bunch of additional quantum numbers that need to be represented somehow. Basically, this parameter is passed as a list of lists, where each element of the outermost list represents a coupling between two spin spaces. These inner lists have 3 elements, 2 giving the number of the space that is being coupled and the third being the j value of these spaces coupled together. For example, if we wanted to represent a state |j,m,j1,j2,(j12),j3>, the jcoupling would be ( (1,2,j12), ). If this option is not set, then the methods default to coupling the spaces in numerical order, i.e. 1 and 2, then 1,2 and 3, etc. Using this, I have been able to rewrite the uncouple code. The results do not yet have tests, and I'll definitely need to do some calculations by hand to make sure this is working properly, but looking at it, I am pretty confident in the results, tho the code could use some cleaning up.
Moving forward from this would be to get the couple method working with arbitrary spin spaces and run through all of the functions that deal with spin coupling and make sure nothing is still hard coded to use two spin bases. Other than that, the project that I'd set out to work on has been basically completed. I'll continue to work with and develop sympy when I have some spare and hopefully continue to add features and functionality to the quantum module.
Friday, August 19, 2011
Friday, August 12, 2011
Getting coupled_spin merged
The biggest development this week was working out what is needed to get the coupled_spin which implements spin coupling merged back into master. There were some things to clean up with non-spin modules and a few minor things to address, but in cleaning this up, there will be some big changes to the way spin coupling works. First, with respect to things that have been implemented, rewrite and represent will no longer handle the coupling and uncoupling of states. To do coupling and uncoupling, instead, a couple and uncouple method will be created to handle the coupling and uncoupling of states. In addition, coupled states will now be represented by new classes, J?KetCoupled for the Cartesian directions. These will be returned by rewrite when a TensorProduct is coupled and will return the proper vector for the coupled space when it is represented and can be uncoupled when an uncoupled operator acts on it.
Most of these new changes have been implemented to varying degrees. There is some functionality lacking, but much of what remains for this is to implement tests for the new functions and make sure everything is working properly.
The coupling of arbitrary number of spin spaces had made slow progress due to some ambiguity when coupled states were created using normal states, but with the new Coupled classes, specifying the coupling should be possible, thus making the computations easier.
Most of these new changes have been implemented to varying degrees. There is some functionality lacking, but much of what remains for this is to implement tests for the new functions and make sure everything is working properly.
The coupling of arbitrary number of spin spaces had made slow progress due to some ambiguity when coupled states were created using normal states, but with the new Coupled classes, specifying the coupling should be possible, thus making the computations easier.
Friday, August 5, 2011
Moving beyond first coupling iteration
In the last week, one of the main things I did was to submit a pull request for the coupled spin machinery that I have been working on. This pull request can be seen here. This implements the coupling and uncoupling operations for states and operators and how these states and operators interact for coupling of two spin states. This pull still has some kinks to work out and some details to iron out, but should be finished up soon.
Moving beyond this pull, the rest of this week has been in working on modifying the coupling methods developed in this pull and making them work for an arbitrary number of spin spaces. The current idea will be to pass a tuple of j values which are to be coupled instead of passing j1 and j2 parameters. While this would work, it would be nice to be able to define how the terms are coupled, noting that the order of how the spaces are coupled matter in determining the coefficients and what will be diagonal in the basis of the coupled states. The current way I am working the coupling is to couple j1 and j2, then couple this to j3, etc. I have currently changed the all the methods to accept the tuple of j values, however, the coupling and uncoupling methods have not been changed to accept arbitrary numbers of spaces. Most of this week has been thinking and trying to determine a good way to implement this machinery that scales to arbitrary numbers of spaces. While it is not directly necessary for dealing with spin states, I will likely also implement Wigner-6j/9j/12j coefficients in cg.py, which will be very similar to the Wigner-3j symbols that were implemented with the Clebsch-Gordan coefficients.
While I am starting to work on this final component of my project, it will be a close call as to whether or not it can get pushed in time to make it in before the end of the project, which will be in just 2 weeks. The initial coupling stuff should get in, but this will be a much closer call. That said, I will definitely see this last part of the project into master.
Moving beyond this pull, the rest of this week has been in working on modifying the coupling methods developed in this pull and making them work for an arbitrary number of spin spaces. The current idea will be to pass a tuple of j values which are to be coupled instead of passing j1 and j2 parameters. While this would work, it would be nice to be able to define how the terms are coupled, noting that the order of how the spaces are coupled matter in determining the coefficients and what will be diagonal in the basis of the coupled states. The current way I am working the coupling is to couple j1 and j2, then couple this to j3, etc. I have currently changed the all the methods to accept the tuple of j values, however, the coupling and uncoupling methods have not been changed to accept arbitrary numbers of spaces. Most of this week has been thinking and trying to determine a good way to implement this machinery that scales to arbitrary numbers of spaces. While it is not directly necessary for dealing with spin states, I will likely also implement Wigner-6j/9j/12j coefficients in cg.py, which will be very similar to the Wigner-3j symbols that were implemented with the Clebsch-Gordan coefficients.
While I am starting to work on this final component of my project, it will be a close call as to whether or not it can get pushed in time to make it in before the end of the project, which will be in just 2 weeks. The initial coupling stuff should get in, but this will be a much closer call. That said, I will definitely see this last part of the project into master.
Subscribe to:
Posts (Atom)