In this first week of the GSoC project, I focused on implementing methods that would simplify terms with Clebsch-Gordan coefficients. This still has a long was to go, but I will outline what I have done so far.

The first step was implementing means of dealing with sums of single coefficients. This would hopefully look something like:

>>>Sum(CG(a,alpha,0,0,a,alpha),(alpha,-a,a+1))

2*a+1

The first implementation of this used an indexing system that was able to index single coefficients, which could then be processed. This allowed the simplification function to act properly in simple numerical cases, so it could do things like:

>>>cg_simp(CG(1,-1,0,0,1,-1)+CG(1,0,0,0,1,0)+CG(1,1,0,0,1,1)+a)

a+3

The problem with this implementation is doing something as simple as having one of the terms have a constant coefficient would break it. In addition, there would be no clear way to extend this to sums involving products of multiple Clebsch-Gordan coefficients.

To deal with this, I started working a solution that could deal with having constant coefficients and products of coefficients. Currently implemented is method which creates list of tuples containing information about the Clebsch-Gordan coefficients and the leading coefficients of the Clebsch-Gordan coefficients. Currently, the only implemented logic is only able to deal with the case in that could be dealt with in the previous implementation, however, this should be able to expand to encompass more exotic cases.

Another thing that was touched on this last week was treating symmetries. These are quite simple to implement, as they need only return new Clebsch-Gordan coefficients in place of old ones, just with the parameters changed in correspondence with the symmetry operation. The key will be using these symmetries to help in simplifying terms. This will be based on the development of better logic in the simplification method and the implementation of some means of determining if these symmetries can be used to apply some property of the Clebsch-Gordan coefficients that can simplify the expression.

I will be out of town this next week on a vacation, and will not be able to get work in, but I will continue working on this when I return, with the intention of getting it to a state that can be pushed within the next couple weeks.

## Tuesday, May 31, 2011

## Tuesday, May 24, 2011

### Official GSoC start

This week marks the official start of the Google Summer of Code. While I started getting my feet wet last week after finishing the last of my finals and grading, the bulk of the work has just started turning out. I'll quick cover what I have from this last week and what I'm looking to get working this week.

Before the start, I worked out expanding the functionality of the currently implemented x/y/z bases, which work I have here. The previous implementation only allowed for evaluating inner products between states in the same basis and representing the states in the Jz basis and then only with j=1/2 states. Using the Wigner D-function, implemented with the Rotation class, I implemented represent to go between the x/y/z bases for any j values. Both _eval_innerproduct and _rewrite_as were then created to take advantage of the represent function to extend the functionality of the inner product and to implement rewrite between any bases and any arbitrary j values.

This seems like this is some documentation and tests away from being pushed, but there is something buggy with the Rotation.d function, implementing the Wigner small d-matrix. I noticed when trying to do

>>>qapply(JzBra(1,1)*JzKet(1,1).rewrite('Jx')

and I wasn't getting the right answer. As it turns out, the Rotation.d function, which uses Varshalovich 4.3.2 Eq 7, does not give the right answer for Rotation.d(1,1,0,-pi/2) or Rotation.d(1,0,1,pi/2). Namely, there is something wrong with the equation that doesn't change the sign of the matrix element when reversing the sign of the beta Euler angle. Running all four differential representations given by Varshalovich for the small d matrix, Eq 7-10, give the wrong result, so the derivations of these will need to be checked to fix this. I have a bug report up here.

As for what I will be implementing this week, I already have the basics of the Wigner3j and CG class implemented, the work for this going up here. This includes creating the objects, _some_ of the printing functionality and numerical evaluation of the elements using the wigner.py functions. The meat of the class that I'm currently working on is the cg_simp function, which will simplify expressions of Clebsch-Gordan coefficients. I currently have one case working, that is

Sum(CG(a,alpha,0,0,a,alpha),(alpha,-a,a)) == 2a+1

which is Varshalovich 8.7.1 Eq 1. There are still some things to smooth out with the implementation, but I should have that worked out a bit better, in addition to some more simplifications by the end of the week.

That's all I have for now, watch for updates within the week as to what I've gotten done and what I have yet to do.

Before the start, I worked out expanding the functionality of the currently implemented x/y/z bases, which work I have here. The previous implementation only allowed for evaluating inner products between states in the same basis and representing the states in the Jz basis and then only with j=1/2 states. Using the Wigner D-function, implemented with the Rotation class, I implemented represent to go between the x/y/z bases for any j values. Both _eval_innerproduct and _rewrite_as were then created to take advantage of the represent function to extend the functionality of the inner product and to implement rewrite between any bases and any arbitrary j values.

This seems like this is some documentation and tests away from being pushed, but there is something buggy with the Rotation.d function, implementing the Wigner small d-matrix. I noticed when trying to do

>>>qapply(JzBra(1,1)*JzKet(1,1).rewrite('Jx')

and I wasn't getting the right answer. As it turns out, the Rotation.d function, which uses Varshalovich 4.3.2 Eq 7, does not give the right answer for Rotation.d(1,1,0,-pi/2) or Rotation.d(1,0,1,pi/2). Namely, there is something wrong with the equation that doesn't change the sign of the matrix element when reversing the sign of the beta Euler angle. Running all four differential representations given by Varshalovich for the small d matrix, Eq 7-10, give the wrong result, so the derivations of these will need to be checked to fix this. I have a bug report up here.

As for what I will be implementing this week, I already have the basics of the Wigner3j and CG class implemented, the work for this going up here. This includes creating the objects, _some_ of the printing functionality and numerical evaluation of the elements using the wigner.py functions. The meat of the class that I'm currently working on is the cg_simp function, which will simplify expressions of Clebsch-Gordan coefficients. I currently have one case working, that is

Sum(CG(a,alpha,0,0,a,alpha),(alpha,-a,a)) == 2a+1

which is Varshalovich 8.7.1 Eq 1. There are still some things to smooth out with the implementation, but I should have that worked out a bit better, in addition to some more simplifications by the end of the week.

That's all I have for now, watch for updates within the week as to what I've gotten done and what I have yet to do.

Subscribe to:
Posts (Atom)