Finishing current coupled spin work

This last week I made some good headway towards finishing up the coupled spin state work for the coupling of two spin spaces. The decision was made that spin states should not contain any information as to their coupling, which greatly simplifies not only the code, but also the allowable cases when it comes doing things such as applying operators, rewriting, etc. As such, I am very close to finalizing this stage in the coupled spin work. I will try to fix up the implementation for some symbolic cases that should be doable under the current implementation, but all the current code has tests implemented and docstrings in place, so a pull request will be coming up shortly.

With this stage finishing, I will be moving on to generalizing the current implementation to coupling between more than two spin spaces. I will first need to expand cg.py to include Wigner-6j/9j/etc symbols to describe the coupling between these additional spaces. The logic for spin states will need to be reworked as well, not only to implement these new terms for coupling additional spin spaces, but most of the logic will need to be reworked to allow for an arbitrary number of coupled spin spaces.

While the change to get rid of what would be considered a coupled spin state (that is a state where the state has defined the coupled spaces) does simplify the current implementation, it does limit what can be done. For example, an uncoupled operator could not be applied to a coupled state, as the coupled states would need to be uncoupled, which is only possible if the j values of the coupled states is known. However it was suggested by Brian that a new class be created to deal with coupled states in this sense. Time permitting, I will begin to look at the possibility of implementing such a feature into the current spin framework.

Improving rewrite and represent for coupled/uncoupled states

This last week, most of the coding I have done has been working on getting represent working properly for coupled and uncoupled states. After doing a quick double check on what the basis vectors of a coupled or uncoupled state would be, I was able to get this code in. Tests for the represent logic will still need to be added, but so far it seems to be working properly.

In addition, I modified the rewrite logic to implement the represent method. This way all of the coupling and uncoupling logic is taken care of by represent, just as the represent method also takes care of all rotations of coordinate bases. To simplify the rewrite logic, I also implemented a vect_to_state, which returns a linear combination of states given any state vector when provided with the appropriate parameters, to specify coupled or uncoupled and what the j1 and j2 parameters are.

In addition to this work, I also wrote up the shell of the class that would handle tensor products of operators. However, in its current state, it doesn't function as one would expect, as the _apply_operator_* methods are not being called by qapply. This, in addition to noting that there is very little logic that is in the TensorProductState class has been making me think I can move most of the logic for states and operators that are uncoupled out of the spin class, implementing it instead in places like qapply and represent. The only trick would be the uncoupled-> coupled logic, which is just about the only bit of logic that the TensorProductState class has that couldn't necessarily be generalized, and the loss of the j1/j2/m1/m2 properties. I will be trying to do this in the coming week, which will in turn fix the problems I am having with getting tensor products of states to work.

Developing coupled/uncoupled states and operators

Most of this last week was spent developing coupled and uncoupled states, beginning to develop how operators will act on these states and writing tests to ensure the code returns the desired result. This week I finished up writing the code for expressing states, and the logic for rewriting from one to the other and back. In addition to this, I implemented the tests which are used for these rewrites. This mostly finishes up the logic for the coupled/uncoupled states, there is still the represent logic which may need to be implemented, tho this will take some looking into to determine what is appropriate and necessary to implement.

For the operators, using the qapply logic already in place, I have begun to implement how operators act on coupled and uncoupled states. I have thus far only implemented logic for coupled operators, that is, for example Jz = Jz_1 + Jz_2(=Jz x 1 + 1 x Jz in an uncoupled representation). In addition to defining how uncoupled product states are acted upon by spin operators, I have expanded those already implemented methods to act on arbitrary states, as they had only previously been defined in how they act on JzKet's. This was done by defining a basis, such that, with the now improved rewrite logic, any state can be rewritten into an appropriate basis for the state and the state in then acted upon by the operator. I have begun to implement the tests that ensure the implemented logic is valid in all cases, both numerical and symbolic, tho this is still a work in progress.

The focus for this next week will be continuing the development of the spin operators, hopefully getting to working with uncoupled spin operators, i.e. operators given in a tensor product to only act on one of the uncoulped states, and developing the tests necessary to the implementation of these states. If I can complete this, I will be closing in on the completion of the coupling of two spin spaces.

Cleaning up simplification and moving into coupled states

So, as I stated in my last post, the first thing I dealt with was fixing up the _cg_simp_add method by implementing pattern matching and move the logic for determining if the simplification can be performed and performing the simplification out of the _cg_simp_add method and developing a system that can easily be expanded to include additional simplifications. To do this, I created another method, _check_cg_simp, which takes various expression to determine if the sum can be simplified. Using Wild variables, the method takes an expression which is matched to the terms of the sum. The method uses a list to store the terms in the sum which can be simplified, so additional expressions are used to determine the length of the list and the index of the items that are matched. There are also additional parameters to handle the leading terms and the sign of the terms. There are still some issues with this method, as when there is more than 1 Clebsch-Gordan coefficient in the sum, then the leading term cannot be matched on the term.

In addition to the finishing of this component of the Clebsch-Gordan coefficient simplification, I have started into working on the coupled spin states and the methods to rewrite them in coupled and uncoupled bases. Coupled spin states are set by passing j1 and j2 parameters when creating the state, for example

>>> JzKet(1,0,j1=1,j2=1)

|1,0,j1=1,j2=1>

These states can be given in the uncoupled basis using the rewrite method and passing coupled=False, so:

>>> JzKet(1,0,j1=1,j2=1).rewrite(Jz, coupled=False)

2**(1/2)*|1,1>x|1,-1>/2-2**(1/2)*|1,-1>x|1,1>/2

This can also be done with a normal state and passing j1 and j2 parameters to the rewrite method, as:

>>> JzKet(1,0).rewrite(Jz, j1=1, j2=1)

2**(1/2)*|1,1>x|1,-1>/2-2**(1/2)*|1,-1>x|1,1>/2

How the coupled states will be handled by rewrite still needs to be addressed, but that will need some thinking and with another GSoC project doing a lot of changes to the represent function, it may take some coordination to get this and the TensorProducts of states and operators working.

Note that in the python expressions above, the states are given as uncoupled states written as tensor products. Uncoupled states will be written as TensorProduct's of states, which will be extended later to spin operators, being written in the uncoupled basis as a TensorProduct. I've just started playing with the uncoupled states and the various methods that will be used to go from uncoupled to coupled states and I've been putting them in a separate TensorProductState class, which subclasses TensorProduct, which keeps all the spin logic separate from the main TensorProduct class, tho this will have to be expanded to include operators. Developing the logic for these uncoupled spin states will be the primary focus of this next week of coding.

Continuing GSoC work

This last week, I have made progress on my project working on laying the base work for the spin states and in reimplementing logic in the cg_simp method for Clebsch-Gordan coefficients.

First, I have started the work on the implementation of coupled/uncoupled spin states. Currently, this is implemented by adding a coupled property to the spin states. This can be set to True for coupled, False for uncoupled or left as None for other states. As this evolves, I will move to having uncoupled product states be represented by a TensorProduct of two spin states. The next key will be establishing represent and rewrite logic for these spin states. Part of this will be figuring out how exactly these methods will work and what they will return. Namely, the represent method, noting that when representing an uncoupled state as a coupled state, it returns states with multiple j values, which under the current logic, would return matrices of different dimension. Also, we will have to determine what represent will do to uncoupled tensor product spin states. This next week, I will likely rebase this branch against the CG branch so I can start using the Clebsch-Gordan coefficients to implement these functions as the CG pull is finalized.


With the Clebsch-Gordan coefficients, this last week I was able to get the simplification of symbolic Sum objects working. I did this using the pattern matching built into sympy with Wild and .match. The final step with this should be to rework the logic of _cg_simp_add to make it easier to add in additional symmetries.