GSoC 2015 Proposal Discussion

[amitjamadagni]

I would like to put forward a proposal for participating in Google Summer of Code 2015 as a student under the possible mentorship of @acroy. Though Julia has not been selected as an organization this year, we could submit the proposal to NumFocus which has Julia as one of the sub-orgs. One of the key requirements is a good structured proposal detailing the idea of the project along with the implementation design. @acory had suggested the following as potential projects :

1. Implementation of Propagators for Quantum Dynamics :
   Design and Implement a unified framework for propagating quantum states
2. Visualization of quantum states

It would be really helpful to hear from the community more about the above ideas and also other ideas which could potentially end up in a project spanning over 12 - 14 weeks. The combined efforts would result in the construction of a robust Julia based Quantum Library. Hoping to hear from the community. Thanks.

[i2000s]

I think those directions are good enough for a 12-14 week long project. @acroy can definitely guide you to achieve this goal. He has a prototype package under development already.

If you would like to be more ambitious--maybe @acroy has already told this to you, I think you can consider highlighting and integrating some advanced features of Julia language into the project--for example, parallel computing on multi-thread CPUs, clusters and GPUs. Considering the nature of GSoC, I think they would like to see more exciting features of programming techniques being integrated into a project. On the other hand, there have been a lot of tools for simulating quantum dynamics written in other programming languages. Parallel computing and a few other native features of Julia could make your work unique and appealing. In the proposal, you may want to include an over review section on existing packages (like QuTiP and Sagemath you were working on before) and their drawbacks, and explain what features that you are capable and going to implement could make your project superior than the others. Those features as optional buttons for future users may be relatively easily employed while you are designing the library from scratch rather than to be developed as separated plugin packages. Certainly, all of these should be decided with your mentor under serious discussions.

Good luck with your endeavor!
Qi

[amitjamadagni]

@i2000s thank you for the reply. For the starters I have looked into the implementation of solvers in QuTiP. Coming to the use of parallel computing on multi thread CPU's, clusters and GPU's, could you further provide me with references on what we could possibly implement, as my knowledge is bit limited in the applications of these fields to quantum ideas. But that said, I would like to target these in the second phase (post mid-term review) of the project as I would like to focus more on constructing the base machinery in the first half . For this I was looking through the dynamic solvers and time evolution in QuTiP here. I am trying to go through the limitations of the various implementations in QuTiP as well as others and will try to come up with what we can do better to tackle some of the issues these packages are facing, if any, in terms of efficiency and robustness. Hoping to hear from the community on the issue of what we can implement on a basic level which could possibly incorporate the parallel computing features of Julia.

[acroy]

Maybe I should explain a bit what I had in mind: There are plenty of methods to propagate quantum states ("direct" matrix exponentiation, "classic" ODE solvers, Monte-Carlo based methods, ...). The goal of the project would be to come up with and implement a generic framework/interface, which makes those different methods useable for JuliaQuantum. It is not necessarily about implementing more methods. In fact, there are already quite a few solvers available (ODE.jl, Sundials.jl, ExpmV.jl, Expokit.jl, ...), which we could try to use (and maybe contribute to improve them).

One idea would be to have a function propagate(qu_p, qu_s0, trange; options), where qu_p denotes the problem to be solved (a Hamiltonian, Lindblad super-operator, ...) and qu_s0 is the initial state (density matrix or state vector). Depending on the method specified in options the function propagate returns some object which can be used to obtain the propagated state. Maybe an iterator-like interface would be nice (like proposed in SciML/ODE.jl#49)?

The framework should in particular support parallel methods like MCWF (there is a mcwf branch and a PR for it in QuDOS.jl). So we will need options to set the number of processes etc ...

[amitjamadagni]

Thank you @acroy for the further detailing. I guess I have got a more clearer picture now. I was looking through this from QuDOS.jl which I could relate to from the above comment. I would look through the mentioned PR to gain further insight. Thanks once again.

[i2000s]

All sounds good.

Just to clarify on the PR I wrote for QuDOS.jl: it was targeting at including both CPU and GPU parallel-computing supports when a potential contributor expressed interest on this direction. However, this task on flexible parallel-computing was not implemented in the PR. It may also have bugs, for example, on the random number generator which could be a problem of Julia V0.3. At the time of coding, that collaborator who was studying parallel computing in Julia from the MIT Julia studio where I met him for the first time then may have become very busy on other stuffs and shifted his interest afterwards. I wrote the code mainly to help him understand the MCWF algorithm with very detailed commits. @amitjamadagni, you may find the PR helpful for you to understand the basic algorithm of physics as it re-implemented the same MCWF functions of QuTIP in Julia, but you need to think out more details on parallel computing and other useful techniques.

[amitjamadagni]

@i2000s thanks for the insight.
@acroy @i2000s I have been looking through the following resources, mostly which are QuTiP based :

• The Quantum Optics Toolbox which has been the basis for QuTiP here
• Construction of QuTiP here
• QDPack here from the author of QuTiP. It is basically in C and also looks at solving the time evolution.
• Thesis related to QMC simulations explaining the parallelism that could be implemented
  • Link 1
  • Link 2

We still need the idea of density matrix in QuBase which plays quite a crucial part in the scheme of things, but that said I would be making a draft of the proposal of the project with above references including the construction of density matrix which might be done before we start with the actual project, given the fact we are given a slot. I will try prototyping the ideas mentioned by @acroy, in one of the previous comments, in the process of the construction of the proposal. Any further references and also any further comments would be really helpful. Thanks.

[i2000s]

@amitjamadagni If you have time for this generalization work, also check this summary for related packages.

[amitjamadagni]

@i2000s @acroy I am looking at essolve, mcsolve, mesolve, propagator, sesolve, stochastic implementations in QuTiP. These above would form options if we prototype as mentioned in one of the comments i.e., propagate(qu_p, qu_s0, trange; options) . Also in addition we could aim at enhancing the current methods by using parallel techniques which I am currently putting my efforts to understand. Please do let me know if this is going in the right direction. Thanks.

[i2000s]

@amitjamadagni To me, those are a good set to begin with. The PR to QuDOS.jl is a straightforward functionality clone to the QuTiP counterpart. You can see it becomes much cleaner and simpler, which is a result of the language itself. Due to the language differences, I would suggest you start from the algorithm documentations of those QuTiP functions rather than the Python codes (they are unnecessarily complicated). With a clean mind on the theory and algorithm, you can write a good Julia code and then you can dig into the Python functions for comparison later.

For fast implementation, testing or benchmarking, you could also use their Fortran solvers like mcsolve_f90 as well. It may worth your time to just write an interface to their open-source Fortran solvers from Julia once/if you are familiar with the interfacing part. You may find interfacing with Fortran is much easier and faster in Julia compared to the Python partner.

For parallel computing part, QuTiP uses parfor and _paralle_map_ functions. See here. You can do some comparison works. One direction for parallel computing in Julia could be to make it general, smart and easy to deploy, based on my limited experience.

I have contacted some core developers of QuTiP days ago, as most of them are shifting their attentions to other directions. I have also announced in the QuTiP discussion group regarding our projects in Julia. They may interact with us at some point. Feel free to ask questions on QuTiP through their discussion group and redirect this thread to them.

[amitjamadagni]

@i2000s Thanks for this !!!!
I was just going through the documentation :), it has many intersections from the QuTiP article which was linked to in one of the references. Sure I will post them a message, if necessary, as we progress further. Thanks once again :)

[acroy]

@i2000s : Do you know which license QuTiP uses?

@amitjamadagni : This looks like a reasonable list. As Qi said you could start by trying to understand the implementation of mcsolve in QuDOS.jl (the mcwf branch might also be interesting, but is not well documented)...